Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Off-load some users to Office 365, reducing on-premise costs.Combine Lync Server and Lync Online using federation and “Split Domain.” Authentication using Microsoft Active Directory.Allows Lync Online users to get a DID from Lync on-premises.Lync on-Premises offers interoperability for PBX, Video Conferencing and Contact Center.Move users based on their profile needs.

Centralized &amp; scale: Enterprise telephony system and management, distributed resources.Same configuration and policies across clients.Single user directory for all communications.One dial plan, CAC and location information across the enterprise.One Administration for all voice scenario, gateway, devices and phones.Feature rich: Built-in telephony features required by today’s organizations.Response Group Service Manager built-in, including IVR.SIP Trunk and Inter-trunk routing. Hosted Voice: DID on-premise, user online using hybrid cloud.IP phone support for Office 365.Lync-to-phone for O365 only deployments.

While we delivered High Availability and Disaster Recovery options in Lync 2010 and previous releases, we continuing feedback from customer has been that these capabilities are critical, but that we could do some work to help make this capability easier to deploy, and that we could reduce the capital and operational expenditures needed to enable these critical functions.Some specific feedback was that the stretched pool approach to delivering metro site resiliency was difficult to deploy, and that there was a need to have an idea what SLAs could be supported with the various HA/DR approaches.To this end we have made several investments in HA and DR:Decreasing the cost of HA/DRWe made investments in removing our dependency on SQL clustering and SAN-based storage and removing dependencies on metro site resiliency for DR using SQL Mirroring and specific real-time SQL replicationEnhancing service resiliencySupport for auto failover / fallback for pool backend failuresFull UC enterprise grade support including presence, voice and conferencing resiliency as part of our pool pairing approach to DRFaster recoveryThe paired pool approach allows us to target failover recovery times between 5 and 30 minutes for recovery from catastrophic outages. Automatic failover can be scriptedThis is achieved by peering identical pools where 50% of the users are split across the 2 poolsDeployment of HA/DR-ready infrastructure will be easier for customers and partners due to integration across our deployment and manageability tools, for HA/DR support from end-to-endPlanning toolTopology builderLync Server Control PanelSystem center for alarmingPowerShell

Virtual Desktop Infrastructure, or VDI, is one of the areas in which we have invested significantly in order to enable the client virtualization scenarios our customers are looking to deploy with Lync. Our virtual client support is targeted to deliver enterprise-grade Audio/video communications in remote desktop environments, be easy to deploy and manage, and continue to deliver a robust Lync user experience and feature set.The overall approach that we are taking is to used media redirection to separate the audio and video streams from the other signaling, allowing the “thin” client to do encoding / decoding of audio and video locally rather than round-tripping this process to and from a remote desktop server. This results in low bandwidth consumption, higher server scalability, and an optimal user experience (compared to other options such as device remoting or codec compression). The approach is platform independent, and is targeted to work across Vmware, Citrix, and Microsoft based VDI deployments (and we are working with each of these platform partners to enable support). On the hardware side we are working with partners to enable support of thin clients.Deployment of the Lync VDI Plugin for thin clients is via an enterprise administrator packaged image, and for thick clients from the customer’s download center.Supported features includeInstant Messaging (IM)/Presence AudioVideoData collaboration Office/line-of-business (LOB) application integrationDevice integrationAutomatic device selectionHuman Interface Devices (HID) (including multiple HID)Click to join online meetingsMode and participant escalationsCall Admission Control (CAC), Call Park, Media Bypass, E911, Location…Some features that will not be supported in Lync 2013 include Multi-view video, recording, and call continuity in the case of network outages.

Lync is completely integrated with Active directory to support user authentication, security and policiesDirectory service for all components in the enterprise providing user access, security and policiesProvides automatically certificate services across the enterprise and to Lync Servers, users and devicesLync is completely integrated and supports all forest and domain deployments models including resources forest model and read-only DCLync store AD information in its CMS database avoiding potential impact on your Active Directory, while removing it’s dependency to Active Directory outages.One identity across on-premises and O365 using corporate Active Directory via Active Directory federation servicesOne identity across on-premises and Office 365. Authentication using Kerberos and high encryption.Standards based LDAP.

Server monitoring for the entire deployment including overall health model.Lync monitoring pack and alerts for System Center.Real time alerts based on Monitoring Server QoE data* provide notification of calls, media quality, network and server problems.Automatic Lync Architecture Discovery for fast deployment and update.Automatic testing and troubleshooting of end to end communication using Active Monitoring* and other Synthetic transitions.*New or improved in Lync Server 2013

Slide Objective: Discuss why Server-to-Server is required but keep in mind the next module is about Oauth. Keep it high level. Notes:End user data is spread out in Lync, Exchange, and SharepointData should be accessible by the new generation of clients so agregation by windows client is no longer a good solutionHybrid scenario are not compliant with certificate server authenticationThe authentication problem was the same for all Office subteams and should be addressed in a global way. The work was achieved by the AD team and respecting industry standardThere are a lot of new scenarios that rely on this technology: UCS, consolidated archiving, scheduling from OWA

Lync content stored in Exchange user mailboxes.*Single management between Exchange and Lync.*Simple end-user access to archives through Outlook.*Discovery and content preservation using SharePoint &amp; Exchange e-Discovery.*Single repository for all contact information using Exchange Unified contact store.Monitoring service collocated on Front-End connected to a SQL Database.

Lync storage service is a new architecture for storage and exchange data across services. It helps to improve IT efficiency in several areas:Exchange Archiving- Requires Exchange 2013 but can still use w14 archiving model based on SQL Server archiving storage- Archiving Policy: Lync honors mailbox hold policy from Exchange- IM Archiving: Lync archives IM data to ExchangeEnd-user accesses IM conversations in Exchange conversation history folderCompliance admin discovers and preserves IM content using Exchange compliance toolsMeeting archiving: Lync archives Meeting content to ExchangeCompliance Admin discovers and preserves meeting content using Exchange compliance toolsExchange 2013 contact storeThis feature solve the problem of disjoint contact list, broken search or mobile platform inconsistency. It also solve the UX issues and framework challenges. For example: some contacts in Phone contact store, some duplicated in apps (Lync), some not in contact store but in an app (MyOffice, MySite followers).Now Lync providesSame People card across Lync and Office and allows to update themSame favorites and buddy List across Lync, Outlook, OWADe-duped and aggregated people searchHigh-resolution photos Exchange is the unified contact store across Office in Lync 2013Enabled by policy when Exchange 2013 is deployedLync 2013 clients work with Exchange 14All Lync 2013 clients will go to Exchange 2013 for storing, retrieving, and updating of contacts Legacy clients (Lync clients, Exchange 14 devices, web and mobile clients) will remain in sync (read access only)Monitoring service is now collocated on the front end and connecting to a single database, removing the need to manage another server role.

Between enterprises using Lync Server, Lync Online, Office communication or server. With consumers using Windows Live Messenger, AOL and Yahoo! or Google Talk.Enable rich unified communications to customers, suppliers, and partners through Internet.Allow anywhere access to your employees using secured anywhere remote access for peer-to-peer, audio, video and web conference without VPN.Allows rerouting of encrypted voice and video traffic when WAN is over subscripted or out of service.Ensure IT policies using Lync management toolStandard protocols (SIP and XMPP).

Slide Objective: Explain XMPP Notes:No more separate box – integrated as a Front End service and in the Edge Server.Propose the same level of scalability and HA as Edge and Front End infrastructure

Slide Objective: Describe approach of voice with Lync Online Notes:The challenge regarding voice in the cloud is having the PSTN access existing contextUser management is on the cloud

Slide Objective: Agenda for this sessionNotes:This session will address Lync 2013 Preview design goals and how they influence the Lync 2013 Preview architecture.

Slide Objective: Explain Lync 2013 Preview investmentsNotes: The investments for Lync 2013 Preview include:Simplified TopologiesSimpler deployment topologies and reduction of server rolesScalabilityThe newly introduced Brick Architecture reduces the load on the back end database and allows larger pools to “scale out”Storage ModelLync Storage Model (LySS) is the technical foundation for the brick model. It allows better integration to Exchange 2013 Preview.ResiliencyIn Lync 2010, Disaster Recovery was complicated and expensive to deploy and maintain. Lync 2013 Preview is designed to address Disaster Recovery.Online IntegrationHybrid is becoming more and more important, Lync 2013 Preview enables new scenarios that build hybrid deployments between on-premises and online.

Slide Objective: Topology changesNotes: Lync 2013 Preview has a lot of improvements to topologies, making deploying Lync easier to manage.ScalabilityLync 2013 Preview allows more Front End servers per poolAudio/Video (A/V) conferencing ServerIn Lync 2013 Preview A/V Conferencing Server will be always collocated with the Front End Server. The improved scalability does not require dedicated AV Conferencing Servers.Monitoring and Archiving ServerMonitoring and Archiving are not dedicated servers anymore, but run as a service on the Front End servers.Archiving on Exchange 2012 PreviewInstead of a SQL database, Exchange 2012 Preview can be used to archive Lync data. SQL server can still be used as alternativeWeb Application Companions (WAC) ServerWAC Server is used in Lync 2013 Preview to render meeting data. It supports a wide range of devices and systems. WAC is not a Lync component, but can be used for the whole Office family and will support products like Exchange 2013 Preview and SharePoint 2013 Preview.

Slide Objective: Discuss Topology changesNotes:XMPP gatewayXMPP is a native part of the Lync Front End server and Edge Server. XMPP is supported without an additional XMPP Gateway server.SQL mirroringSince SQL clusters are expensive to deploy and maintain, Lync 2013 Preview supports mirroring to provide High Availability to the back end database.SQL mirroring is tightly integrated with Lync manageability interfaces – Lync 2013 Preview Topology Builder, Lync Server Control Panel, and Windows PowerShell™Background information: AlwaysOn Availability Groups (SQL Server) are on the roadmap for future Lync releases beyond Lync 2013 PreviewBefore describing “disaster recovery,” you should define the terms “high availability” and “disaster recovery” as we use them in Lync:High availability: Server redundancy via pooling. If a server running a certain server role fails, the other servers in the pool running the same role take the load of that server. This is generally automatic and without administrator intervention (except in the case of a SQL mirror without a witness server).Disaster recovery: Geographical dispersement of your servers into two data centers to provide continuation of service should one entire pool or site go down. InLync Server 2013 Preview, this generally will require administrator intervention.Disaster RecoveryThe new disaster recovery model in Lync 2013 Preview allows pairing of pools to provide disaster recovery. There are no requirements for pools to be in the same metropolitan area like there was in Lync 2010.

Slide Objective: Discuss Topology changesNotes:OAuth OAuth is used as server to server authentication for richer integration with Exchange 2013 PreviewPersistent ChatPersistent chat is now a first class citizen in Lync 2013 Preview: it is a full server role in topology builder and has the same installation experience as other Lync Server roles.HybridHybrid allows scenarios like branch office in the cloud but also a shared sip domain between onprem and online. Hybrid Voice will allow online users to use onprem Enterprise Voice features.Director RoleIn Lync 2013 Preview routing improvements on the Edge Servers will lessen the requirements on having a Director. The Director will only be required if customers want to have an additional hop between Edge Server in internal server, e.g. for security reasons.

Slide Objective: Use the reference diagram to highlight topology changesNotes: Note that there is no Director and no dedicated A/V Conferencing. There is also no dedicated Monitoring Server. Also highlight XMPP and Hybrid on the Edge side.

Slide Objective: Discuss Office Web App Server Farm in Lync Enterprise DeploymentNotes:Office Web App Server is not something we built specific for LyncThis is an Office Editing/Viewing capability that Lync, SharePoint, and Exchange leveragesRecommended to create a centralized Office Web App Server FarmAll office products can leverage the farmLync uses a small portion of this – viewing capabilitySetup your Enterprise Deployment and “tell us” where the Office Web App Server Farm is located

Slide Objective: Explain the brick modelNotes: In previous versions, the back end database was always a bottleneck that prevented more users on a single pool as well as more servers per pool. In Lync 2013 Preview, the dependency between the pool and the back end is less strict: the Front End Servers are managing user states between each other. There are only lazy writes to the back end, which are required to rehydrate a pool (after a pool was shut down completely) and disaster recovery.User states are copied between the Front End Servers in a pool directly. Each user belongs to a specific user group, three servers peer pool hold a copy of the data of each user group. If one of the servers is not online anymore, the secondary (or tertiary) server will automatically take over for this user group.In order to always have at least one server per user group available, there is a minimum quorum required per pool. This will be addressed in a later slide.All these changes allow pools to scale out to more servers than Lync 2010 allowed.

Slide Objective: The diagrams compares the model used in Lync 2010 and Lync 2013 PreviewNotes: In the Lync 2010 Pool, the database is used for all updates to presence and subscription (user state). In the Lync 2013 Preview Brick Pool, this data is maintained on the Front End Servers itself. There is no dynamic data on the back end database. However, for disaster recovery and rehydration, the persistent data is still written to the back end database (blob store).

Slide Objective: Explain Windows FabricNotes: Windows Fabric is an internal Microsoft technology that is used to synchronize data between servers. Windows Fabric is transparent to the administrators; there are no options to configure anything and it will be installed automatically when installing Lync Servers.

Slide Objective: Explain pool quorumNotes: To ensure that for every user group, at least one copy is online, the pool can only be active if the required quorum of servers is met. The table above shows how many servers are required depending on the pool size.This means also, if you plan to have a pool with eight servers, you will not be able to test the pool until five servers are online.

Slide Objective: Discuss upgrade domainsNotes: A management shell command will enable you to see which combination of servers can be taken offline at the same time for maintenance.The Front End Servers in an Enterprise Edition pool are organized into upgrade domains. These are subsets of Front End Servers in the pool. Upgrade domains are created automatically by Topology Builder. Each particular user hosted by the Front End pool has user data stored at three Front End Servers in the pool, each of which are in different upgrade domains. When you upgrade the software on Front End Servers in a pool, you should do so on one upgrade domain at a time. This way, the data pertaining to every user is always available on at least one Front End Server which is up and running.

Slide Objective:Speaker NotesTransition Slide

Slide Objective: Discuss SQL back end mirroringNotes: High Availability for the back end database is provided via SQL mirroring. A witness is required in order to enable automatic failover between databases. Witness is also a SQL database.“Database Mirroring Witness” in the MSDN Library at http://go.microsoft.com/fwlink/?LinkId=247345.

Slide Objective:Speaker NotesBecause we are not supporting clustering technologies, the solution is mirroring.After synchronization finishes, every transaction committed on the principal database is also committed on the mirror server, guaranteeing protection of the data. This is achieved by waiting to commit a transaction on the principal database, until the principal server receives a message from the mirror server stating that it has hardened the transaction&apos;s log to disk. Note that the wait for this message increases the latency of the transaction. The time required for synchronization depends essentially on how far the mirror database was behind the principal database at the start of the session (measured by the number of log records initially received from the principal server); the work load on the principal database; and the speed of the mirror system. After a session is synchronized, the hardened log that has yet to be redone on the mirror database remains in the redo queue.As soon as the mirror database becomes synchronized, the state of both the copies of the database changes to SYNCHRONIZED. Synchronous operation is maintained in the following manner: On receiving a transaction from a client, the principal server writes the log for the transaction to the transaction log. The principal server writes the transaction to the database and, concurrently, sends the log record to the mirror server. The principal server waits for an acknowledgement from the mirror server before confirming either of the following to the client: a transaction commit or a rollback. The mirror server hardens the log to disk and returns an acknowledgement to the principal server. On receiving the acknowledgement from the mirror server, the principal server sends a confirmation message to the client. High-safety mode protects your data by requiring the data to be synchronized between two places. All of the committed transactions are guaranteed to be written to disk on the mirror serverTo be able to deploy SQL mirroring, your servers must run a minimum of Microsoft SQL Server® 2008 R2. This version must run on all the involved servers: the primary, mirror, and the witness. For details, see http://go.microsoft.com/fwlink/p/?linkid=3052&amp;kbid=2083921.In general, setting up SQL mirroring between the two Back End Servers with a witness requires the following:The primary server’s version of SQL Server must support SQL mirroring.The primary, mirror, and the Witness (if deployed), must have the same version of SQL Server. The primary and the mirror must have the same edition of SQL Server. The Witness may have a different edition.For SQL best practices in terms of what SQL versions are supported for a Witness role, see “Database Mirroring Witness” in the MSDN Library at http://go.microsoft.com/fwlink/?LinkId=247345 .

Slide Objective:Speaker NotesOpen Topology BuilderTo ensure high availability for your Back End Servers, you can deploy two Back End Servers for a single Front End pool, using synchronous SQL mirroring. This topology is optional but is recommended to maintain your organization&apos;s business continuity. In the rest of this presentation, SQL mirroring refers to synchronous SQL mirroring, unless otherwise explicitly stated. Asynchronous SQL mirroring is not supported for Back End Server high availability in Lync 2013 Preview.When you deploy this high availability solution, all Lync databases in the pool are mirrored, including the Central Management store, if it is located in this pool, as well as the Response Group application database and the Call Park application database, if those applications are running in the pool. With SQL mirroring, you do not need to use shared storage for the servers. Each server keeps its copy of the databases in local storage. You may choose to deploy SQL mirroring with or without a Witness. We recommend using a Witness because it enables failover of the Back End Server to be automatic. Otherwise, an administrator must manually invoke failover. Note that even if a Witness is deployed, an administrator can manually invoke Back End Server failover, if necessary.If you use a Witness, you can use a single Witness for multiple pairs of Back End Servers. There is no strict 1:1 correspondence between Witnesses and pairs of Back End Servers. Deployments that use a single Witness for multiple pairs of Back End Servers are not quite as resilient as topologies with a separate Witness for each Back End Server pair. Either as part of the pool build-out or after the fact, configure mirroring at the Lync 2013 Preview pool level.Enable mirroring at the pool level.Create two SQL Stores (one primary and one mirror) – typically done during the pool setup.Enable the SQL mirror port.Enable Mirroring for the SQL store.Select Enable SQL Server Store.Select SQL Mirroring Witness.Enable mirroring for the Monitoring database (optional).Enable mirroring for the Archiving database (optional).Configure the Witness Server and set the port – change from 7022 to 5022 during Beta.Publish the topology.Install the database – this will create databases on both the primary and mirror SQL server.Beta – did not create RTCShared or RTCXDS to the mirror server – had to manually enable mirroring in SQL Server Management Studio.Backup database on primary server -&gt; Create new DB/Restore on mirror.Install-CSMirrorDatabase

Slide Objective:Speaker NotesTo fail over your back-end databaseBefore failing over, determine which is back-end database is the principal and which is the mirror by typing the following cmdlet: Get-CsDatabaseMirrorState -PoolFqdn &lt;poolFQDN&gt; -DatabaseType UserIf the Central Management store is hosted in this pool, type the following cmdlet to determine which is the principal and which is the mirror for the Central Management store: Get-CsDatabaseMirrorState -PoolFqdn &lt;poolFQDN&gt; -DatabaseType CMSPerform the failover of the user database: If the primary has failed and you are failing over to the mirror, type: Invoke-CsDatabaseFailover -PoolFqdn &lt;poolFQDN&gt; –DatabaseType User -NewPrincipal mirror –VerboseIf the mirror has failed and you are failing over to the primary, type: Invoke-CsDatabaseFailover -PoolFqdn &lt;poolFQDN&gt; –DatabaseType User -NewPrincipal primary –VerboseIf the pool hosts the Central Management server, perform the failover of the Central Management store. If the primary has failed and you are failing over to the mirror, type: Invoke-CsDatabaseFailover -PoolFqdn &lt;poolFQDN&gt; –DatabaseType CMS -NewPrincipal mirror –VerboseIf the mirror has failed and you are failing over to the primary, type: Invoke-CsDatabaseFailover -PoolFqdn &lt;poolFQDN&gt; –DatabaseType CMS -NewPrincipal primary –Verbose

Slide Objective:Speaker NotesRecovery time for automatic Back End Server failoverFor automatic Back End failover, the engineering target for recovery time objective (RTO) is 5 minutes. Because of the synchronous SQL mirroring, we do not anticipate data loss during Back End Server failures except in rare occasions when both the Front End Servers and the Back End Server go down simultaneously while data is being moved between the servers. The engineering target for recovery point objective (RPO) is 5 minutes.User experience during Back End Server failureUser experience during a failure depends on the nature of the failure, and on your topology.If you have a Witness configured and the principal fails, Back End Server failover happens automatically and quickly. Active users should not notice much interruption to their ongoing sessions.If no Witness is configured, it will take some time for the administrator to manually invoke the failover. During that time, active users will likely see effects. They will continue their sessions for a few minutes, and then they are switched to Resiliency mode, meaning that they are unable to perform tasks that require a persistent change on Lync Server (such as adding a contact).If both the principal and the mirror Back End Servers fail, or if one of those servers and the Witness fails, the Back End Server will become unavailable (even if it is the principal that is still working). In this case, active users are switched to Resiliency mode after some time.

Slide Objective: Transition SlideSpeaker Notes

Slide Objective:Speaker NotesWhy are we investing in High Availability and Disaster Recovery improvements in Lync 2013 Preview?Key requirements from Enterprise CustomersResponse to customersWhat we have heard: current HA/DR measures are complex and expensive to deploy.

Slide Objective:Speaker NotesWalk through the progression of HA/DR features/capabilities among the product versions.Point out new HA/DR features in Lync Server 2013 Preview: SQL mirroringPool resiliencyCover the features/capabilities at a very high level, as we will get into details later.

Slide Objective:Speaker NotesThe metropolitan site resiliency solution described in this section entails the following:Splitting the Front End pool between two physical sites, hereafter called North and South. In Topology Builder, these two geographical sites are configured as one single Lync Server 2010 site.Creating separate geographically dispersed clusters (physically separated Microsoft Windows Server® 2008 R2 failover clusters) for the following:Back End ServersGroup Chat database serversFile serversDeploying a Windows Server 2008 R2 file share witness to which all server clusters are connected. To determine where to place the file share witness, refer to the Windows Server 2008 R2 failover cluster documentation at http://go.microsoft.com/fwlink/?LinkId=211216.Enabling synchronous data replication between the geographically dispersed clusters.Deploying servers running certain server roles in both sites. These roles include Front End Server, A/V Conferencing Server, Director, Edge Server, and Group Chat Server. The servers of each type in both sites are contained within one pool of that type, which crosses both sites. Except for Group Chat Server, all servers of these types, in both sites, are active. For Group Chat Server, only the servers in one site can be active at a time. The Group Chat Servers in the other site must be inactive.Additionally, Monitoring Server and Archiving Server can be deployed in both sites; however, only the Monitoring Server and Archiving Server in one site are associated with the other servers in your deployment. The Monitoring Server and Archiving Server in the other site is deployed but not associated with any pools, and it serves as a &quot;hot&quot; backup. The solution described in this section assumes that your Lync Server deployment meets both the core requirements described in the product documentation and all of the following prerequisites. To qualify for Microsoft support, your failover solution must meet all these prerequisites.All servers that are part of geographically dispersed clusters must be part of the same stretched virtual local area network (VLAN), using the same Layer-2 broadcast domain. All other internal servers running Lync Server server roles can be on a subnet within that server’s local data center. Edge Servers must be in the perimeter network, and should be on a different subnet than the internal servers. Also, the perimeter network need not be stretched between sites.Synchronous data replication must be enabled between the primary and secondary sites, and the vendor solution that you employ must be supported by Microsoft.Round-trip latency between the two sites must not be greater than 20 ms.Available bandwidth between the sites must be at least 1 Gbps.A geographically dispersed cluster solution based on Windows Server 2008 R2 Failover Clustering must be in place. That solution must be certified and supported by Microsoft, and it must pass cluster validation as described in the Windows Server 2008 R2 documentation. For details, see the “What is cluster validation?” section of “Failover Cluster Step-by-Step Guide: Validating Hardware for a Failover Cluster” at http://go.microsoft.com/fwlink/?linkid=142436 .All geographically dispersed cluster servers must be running the 64-bit edition of Windows Server 2008 R2.All your servers that are running Lync Server must run the Lync Server 2010 version.All database servers must be running the 64-bit edition of one of the following:Microsoft SQL Server 2008 with Service Pack 1 (SP1) (required) or latest service pack (recommended)Microsoft SQL Server 2008 R2

Slide Objective:Speaker NotesMake clear that the metropolitan site resiliency solution supported for Lync Server 2010 is NOT supported for Lync Server 2013 Preview. This solution involved spanning a single Front End pool across two data centers in the same metropolitan area.When covering the last point on the slide, point out that if you do this, you must make sure that the stretched pool servers running Lync Server 2013 Preview continue to work within the topology, and that the metropolitan site resiliency disaster recovery procedures still serve the intended purpose.

Slide Objective:Speaker NotesQuick pool resiliency overview:Two pools are associated with one another.The relationship is one-way.The Backup Replication Service replicates data from the pool in Site 1 to the pool in Site 2.

Slide Objective: Discuss Disaster recoveryNotes: In Lync 2013 Preview, two pools in different datacenters can be paired in order to provide disaster recovery. A service on the Front End is used to copy all required data between the pools. If a pool is lost, an administrator can enable disaster recovery and failover to the failover pool.It is recommended to run the pools at maximum 50% capacity in an active-active mode, so that each pool is able to take over the full load of the pared pool.This topic will be discussed in detail in the disaster recovery session.

Slide Objective:Speaker Notes

Slide Objective:Speaker NotesTwo Pools:Pair together, starts Backup Service.Replicating in real time.Pool 1 goes down.Users will be forced to sign out.Replication stops.User will be redirected to sign in to Pool2.Running in Resiliency mode until pool failover has been completed.Read-only operationsFailback – choose this time appropriately (maintenance hours).User will be forced to sign out. User experience during pool failureIf a pool fails and failover is invoked, all users of the affected pool are forced to sign out and then sign in to the backup pool. For a brief period, users who sign into the backup pool may be in Resiliency mode. In Resiliency mode, users are unable to perform tasks that would cause a persistent change in Lync Server, such as adding a contact. After the failover is complete, all users can get all services from the backup pool. Any sessions a user has when the pool fails are disrupted, and the user must reestablish those sessions after failover to continue.Users are not rehomed during failover or failback. Users who are homed on a pool that fails will be temporarily serviced by the backup pool. When the home pool is restored, those users are failed back to be serviced by their original home pool. Note that in Lync 2013 Preview, the Local Information Server (LIS) database is not replicated to the backup pool. As a best practice, the administrator should regularly back up the LIS database and use the latest backup copy to restore the LIS database in the backup pool after the failover. There are several potential issues regarding interoperability between Lync Server 2010 and Lync Server 2013 Preview in the context of Lync Server 2013 Preview pool failover. Microsoft has fixed all of these issues in both this release and in Lync Server 2010 with the CU5 HF2 update, which is available to customers who have the Lync Server 2013 Technical Preview. Microsoft recommends that you install this update so that these interoperability issues do not arise. The rest of this presentation assumes that you have applied the update to all your servers running Lync Server 2010.The potential interoperability issues that the CU5 HF2 update fixes are as follows.Users homed on Lync Server 2010 cannot communicate with Lync Server 2013 Preview users who have been failed over to a backup pool.Lync Server 2010 Directors do not support client auto discovery after the Lync Server 2013 Preview pool has been failed over. Therefore if you are using a Lync Server 2010 Director and a user homed on the failed over pool was not signed in before the failover, the user will not be able to sign in to the backup pool after the failover.If a Conferencing Auto Attendant call intended for a pool running Lync Server 2013 Preview comes in after that pool has failed over, Front End Servers and Directors running Lync Server 2010 cannot redirect those calls to the backup pool. Users homed on Lync Server 2013 Preview pools that have been failed over cannot use mobile devices to log in to Lync Server. User experience during failoverWhen a user is in a pool that fails, the user is logged out. Any peer-to-peer session the user was participating in is terminated, as are conferences organized by that user. The user cannot log back in until either the Registrar resiliency timer expires or the administrator initiates failover procedures, whichever comes first. When the user logs back in, they will log in to the backup pool. If they log in before the failover has completed, they will be in Resiliency mode until failover is complete. Only then is the user able to establish new sessions or reestablish previous sessions.User experience during failbackPool failback can happen while an affected user is logged on to the backup pool, and the user remains logged on and working during the failback. The tables on the following slides show more details about how a user is affected during and after failback, and also how users in other pools see and interact with a user in a pool who is being failed back.The term affected user refers to any user who was failed over from the home pool and is being serviced by the backup pool. By definition, any user originally homed on the backup pool is not an affected user.

Slide Objective:Speaker NotesBest practices for pairing front end poolsThere is no restriction on the distance between two data centers that are to include Front End pools paired with each other. We recommend that you use two data centers in the same world region, with high-speed links between them. It is best if the two data centers are separated enough to avoid a single disaster hitting both at the same time. Having two data centers across world regions is possible, but this could incur higher data loss due to latency in data replication.When you plan which pools to pair, you must keep in mind that only the following pairings are recommended as best practices:Enterprise Edition pools can be paired only with other Enterprise Edition pools. Similarly, Standard Edition pools can be paired only with other Standard Edition pools.Physical pools can be paired only with other physical pools. Similarly, virtual pools can be paired only with other virtual pools.Neither Topology Builder nor topology validation will prohibit pairing two pools in a way that does not follow these recommendations. For example, Topology Builder allows you to pair an Enterprise Edition pool with a Standard Edition pool. However, these types of pairings are not recommended.Each pool in a pair should have the capacity to serve all users from both pools in the event of a disaster. If you pair Enterprise Edition pools, you can also implement high availability on the Back End Servers, but for pairs of Standard Edition pools, only the disaster recovery measures are available.

Slide Objective:Speaker NotesIn addition to providing disaster recovery ability, two paired pools serve as the backup Registrars for each other. In Lync Server 2013 Preview, backup Registrar relationships between Front End pools are always 1:1 and reciprocal. This means that if P1 is the backup for P2, then P2 must be the backup for P1, and neither can be the backup for any other Front End pool. This is a change from Lync Server 2010, in which Front End pool backup relationships could be many to one.Even though backup relationships between two Front End pools must be 1:1 and symmetrical, each Front End pool can still also be the backup Registrar for any number of Branch Office Appliances, just as in Lync Server 2010.Lync Server 2013 Preview does not extend disaster recovery support to users homed on a Survivable Branch Appliance. If a Front End pool that serves as the backup for a Survivable Branch Appliance goes down, users signed into the Survivable Branch Appliance fall into resiliency mode even after users homed on the Front End pool are failed over to the backup Front End pool.

Slide Objective:Speaker NotesEnabled through Topology Builder.Edit Properties of the Pool:Resiliency Section:Associate Backup PoolSelect Secondary PoolImportant: Associations are only one-way, so if you want the second location to be resilient back to the first, you must enable resiliency on the second pool and associate it back to the firstPublish Topology:Run the Deployment Wizard on each of the Front End servers and then rerun Setup or Remove Lync Server Components.It is possible to associate Pool 1 to Pool 2, Pool 2 to Pool 3 and Pool 3 to Pool 1, 2, or 3.Considerations: These are typically Active/Active pools, to ensure that the associated pool can handle the additional load from the first pool if failover occurs.Best practices for pairing Front End poolsThere is no restriction on the distance between two data centers that are to include Front End pools paired with each other. We recommend that you use two data centers in the same world region, with high-speed links between them. It is best if the two data centers are separated enough to avoid the possibility of a single disaster hitting both at the same time. Having two data centers across world regions is possible, but could incur higher data loss due to latency in data replication.When you plan which pools to pair, you must keep in mind that only the following pairings are recommended as best practices:Enterprise Edition pools can be paired only with other Enterprise Edition pools. Similarly, Standard Edition pools can be paired only with other Standard Edition pools.Physical pools can be paired only with other physical pools. Similarly, virtual pools can be paired only with other virtual pools.Neither Topology Builder nor topology validation will prohibit pairing two pools in a way that does not follow these recommendations. For example, Topology Builder allows you to pair an Enterprise Edition pool with a Standard Edition pool. However, these types of pairings are not recommended.Each pool in a pair should have the capacity to serve all users from both pools in the event of a disaster.If you pair Enterprise Edition pools, you can also implement high availability on the Back End Servers, but for pairs of Standard Edition pools, only the disaster recovery measures are available.

Slide Objective: Discuss Lync Storage ServiceNotes: LySS is a storage framework intended to be used by LySS consumers for accessing storage platforms in the overall Lync system. It can use Exchange Web Services (EWS) and SQL Server as storage platforms.OAuth (explained later) is used for authentication between Lync and Exchange. Once the OAuth certificates are configured, LySS is full functional.

Slide Objective: Discuss Lync Storage ServiceNotes:Sync the interface to replicate data between Front End Servers.Async Interface used for Archiving, CDR, QoE and Web Conferencing. Lazy writes to back end database.Connection management manages connections to Exchange.There is no more dedicated Monitoring and/or Archiving Server required. However Monitoring still requires a SQL database to store the data and SQL reporting services for reports. Archiving data can be either stored in a SQL database or Exchange 2013 Preview.

Slide Objective:Server to Server AuthenticationNotes:Server-to-server authentication is an Office vision (Single Authentication Mechanism in Lync 2013 Preview for Office Servers and services)Trying to build a simple authentication mechanism that will allow authentication to SharePoint and ExchangeTo work for an Online deployment, users need an on-premises deployment, a cross-premises deployment, or a cross-org as well as third partyDuring development, the Lync team wanted a familiar experience for the developers and the software industryOauthSupported ScenariosAnother supported scenario not being discussed is the SharePoint EDUKey talking pointsOauth is used by many technologies outside these – e.g. Salesforce has OAuth supportAll current implementations rely on some form of proprietary extensions in order to be successful --- none of the big players have generic interoperability across their current OAuth implementations100% standardization is not a requirement for Lync 2013 Preview ship, but successful alignment and interoperability with key stakeholders like Facebook and Google is core

Slide Objective: Discuss OAuthNotes: OAuth is an industry standard for server-to-server authentication. In Lync, it is used to enable secure connections between Lync 2013 Preview and Exchange 2013 Preview.

Slide Objective: Server-to-Server AuthenticationNotes:Three Deployments in this SlideOn-premises - on the leftOnline – on the rightAnd cross-premises – middleWhen applications need to talk they get a token from the ACSOn-premises should be just that no online requirementsExchange Online to Lync on-premises (cross-premises) the ACS token is grabbed from an online ACS server and presented Definitions:MSODS – Microsoft Online Directory StoreBEC – STB – ACS – Access Control System

Slide Objective: Discuss Archiving improvementsNotes: While archiving can still use SQL server as a database, it can alternatively also use Exchange 2013 Preview. This allows administrators a common experience for compliance and eDiscovery for Exchange Mailbox and Lync.

Slide Objective: Discuss Archiving with Exchange 2013 Preview integrationNotes: If archiving is integrated with Exchange 2013 Preview, Lync honors the hold policy of Exchange. While users can still save their conversation history to their Exchange mailboxes, this is independent from the administrator-only accessible Archive.

Slide Objective: At a High level, discuss ArchivingNotesArchiving for conferences and IMs (this functionality has been available since OCS 2007)Improvements are made with every releaseCall out the new components for what is archivedHigh AvailabilityThree Tier ArchivingArchiving Agent (runs on each Front End Server)Archiving Server (Mid Tier)DatabaseMid Tier did not have a good way to support HACustomers got creativeTwo Data centers close together and split pools across data centersThe Mid Tier was removedWe put all functionality besides storage as part of the Front End ServerArchiving component caches information from different sessionsFront End replicates temporary data to other Front End Servers (you do not lose data in case of Front End Server failure)Exchange IntegrationA big complaint has been that data is just captured and dumped into SQLNo tools are provided to discover the dataExchange made a lot of investment in this area (preserve mailbox data and discover mail items)server-to-server authentication and infrastructure is already thereUsers can now go to one place to configure archiving (instead of going to Lync for Lync Users and Exchange for Exchange Users)After the data is captured from Lync, it is put directly into Exchange MailboxUsers can use the Exchange Tools to discover the data

Slide Objective : Show thatExchange integration is not the only supported method for archiving dataNotesWhile users do not have to use Exchange for data storage, Lync 2013 Preview does not offer any discover tools for the data stored in SQL.Session export tool can be used to export archived data, which creates searchable transcripts of the archived data.

Slide Objective: Discuss Unified Contact Store (UCS)Notes: Unified Contact Store can be enabled for users to store their contact list on Exchange. This allows the contact list to be maintained from Outlook Web App.When the user is migrated from Lync 2010 or OCS 2007 R2 and enabled for UCS, the contact list will be migrated the first time the user signs in with a Lync 2013 Preview client. After migration of the contact list, legacy clients cannot be used anymore to make changes to the contact list, however they can still receive the contact list from the server.

Slide Objective:Contact Store ArchitectureNotes:Lync 2013 Preview Server migrates the contact list to Exchange 2013 Preview, then the notification is sent to client that the operation was completedLync Mobile and Lync 2010 clients go through a Lync 2010 ServerLync 2010 Clients will remain in sync as Read OnlyAll updates are proxied from Exchange to Lync (Legacy Mode)Single Contact Store for all of OfficeAll contact updates go from Exchange to the Lync Server (only Lync 2013 Preview rich client can modify the contacts)The interface between Exchange Server and Lync Server is Exchange Web Services (EWS)Benefits are that the same contact card (people card) are used across all of office (one store for all contacts)Aggregation of people search benefits from Contact Store Model

34.
High Availability - Architecture • Lync Users are automatically mapped to “Groups” • Each “Group” is dynamically assigned to 3 Front-end servers within a Pool (a Primary, a Secondary and a Tertiary). • When a user logs in, the Primary server will start servicing all of the user’s requests. • Changes to the user’s data (such as Contact list changes) will be synchronously replicated to secondary/tertiary as well (3 replicas). • If a primary server dies, then this group would fail over to the secondary. (No data loss) • Writes to the back-end database occur periodically (not synchronous). • When a server dies, all the “Groups” assigned to that server as will failover to different servers (load balancing).

35.
High Availability – How does it work? • Bob is homed on FE1 (primary) Pool Back-end • There are 3 copies of this user’s data: 1 primary (FE1), 2 backups (replicas in FE2, FE3) • User is signed in to primary • User’s activities, data are replicated • Primary goes down • User re-signs to one of the backups • Replicated data is available on FE2. User

37.
Quick overview of mirroring Primary publisher (principal) Secondary subscriber Witness Server (optional, but enables automatic failover; this is a SQL Server High-safety mode (synchronous)Mirroring requirements Primary, mirror, and witness must have the same version of SQL Primary and mirror must have the same edition; Witness can be different edition Not required to have same instance name between primary/mirror, recommended for ease of administration/deployment

42.
Lync requirementsServices for IM, presence information, andconference callingFast failover while preserving user state to Group 2 Groupmaintain in-flight user sessions 1 Windows Fabric Group Group NodeAutomatic scaling and load-balancing when new User Group 1 3 Window Windowsnodes are added to the cluster s Fabric Fabric Node 1 NodeLync failover model Group 2Users are mapped to groups Group Group 3 1Each group is a stateful service with three replicas Windows Fabric Node Group Windows 2 FabricUser calls go to the primary replica of the service Group Windows Node User Group 3 Fabric 2Resolve cross-group calls using the NodeWindows Fabric Naming service