Microsoft Lync Server 2010 Setup and Deployment Module 04

1. Microsoft� Lync� Server 2010Setup and DeploymentModule 04 Microsoft Corporation Slide Objective: Provide an introduction of who you are and an introduction on the agenda for the module to be presented. Notes: At a high level, we�re going to talk about setup and deployment with Lync Server 2010, some of the improvements we�ve made in terms of setup and deployment and what some of the experiences will be around that. Slide Objective: Provide an introduction of who you are and an introduction on the agenda for the module to be presented. Notes: At a high level, we�re going to talk about setup and deployment with Lync Server 2010, some of the improvements we�ve made in terms of setup and deployment and what some of the experiences will be around that.

2. Session Objectives and Takeaways Session Objectives: Prerequisites: Software and Hardware requirements Changes in Setup and Deployment in this release Overview of End-to-End Setup and Deployment process Central Management Server and Store Planning Tool and Topology Builder Demo Takeaways: Lync Server 2010: what has changed and why Purpose of Planning Tool, Topology Builder, and Setup and how it integrates 2 Slide Objective: Provide an overview to make sure you understand what has changed and why we changed this for how Lync Server 2010 is deployed. As well as the various tools now available to you (Topology Builder, Planning Tool and Local Setup) and how these will all integrate as part of your deployment experience. Notes: We�ll talk about some of the new prerequisites we now have in preparation for the setup and deployment of Lync Server 2010, relative to the (2) previous release. We�ll walk through an end-to-end overview of the setup and deployment experience, as well as talk a little bit about the Central Management Store or Content Management Server (CMS) and the whole reasoning behind this new component. We�ll also talk about the new Planning and Topology Builder tools. Slide Objective: Provide an overview to make sure you understand what has changed and why we changed this for how Lync Server 2010 is deployed. As well as the various tools now available to you (Topology Builder, Planning Tool and Local Setup) and how these will all integrate as part of your deployment experience. Notes: We�ll talk about some of the new prerequisites we now have in preparation for the setup and deployment of Lync Server 2010, relative to the (2) previous release. We�ll walk through an end-to-end overview of the setup and deployment experience, as well as talk a little bit about the Central Management Store or Content Management Server (CMS) and the whole reasoning behind this new component. We�ll also talk about the new Planning and Topology Builder tools.

3. Agenda Hardware recommendations and Software requirements Changes in Setup and Deployment Central Management Store and data in Active Directory� Domain Services (AD DS) Setup Components and Setup Flow Prepare AD DS Setup and Deploy Demo Database setup Other setup tasks 3 Slide Objective: Discuss the agenda of this module. Notes: We�ll go over the hardware and software requirements, the changes within the setup and deployment areas. We�ll also look at a high level overview of what the Central Management Store is compared to the data we store within Active Directory. Then we�ll go into details on the UI experience for preparing Active Directory, as well as we�ll walk through the Powershell cmdlets for performing those actions. We�ll also walk thru a demo of the Topology Builder tool and what the local setup flow looks like. Lastly, there�s a section around database setup that we�ll walk through reviewing the Powershell cmdlets that are involved as part of that setup and discuss how the new databases within Lync Server 2010 play a more important role for core functionality and performance of the product.Slide Objective: Discuss the agenda of this module. Notes: We�ll go over the hardware and software requirements, the changes within the setup and deployment areas. We�ll also look at a high level overview of what the Central Management Store is compared to the data we store within Active Directory. Then we�ll go into details on the UI experience for preparing Active Directory, as well as we�ll walk through the Powershell cmdlets for performing those actions. We�ll also walk thru a demo of the Topology Builder tool and what the local setup flow looks like. Lastly, there�s a section around database setup that we�ll walk through reviewing the Powershell cmdlets that are involved as part of that setup and discuss how the new databases within Lync Server 2010 play a more important role for core functionality and performance of the product.

4. Software Requirements Lync Server 2010 Lync Server 2010 roles Windows Server� 2008 SP2 x64 Windows Server 2008 R2 x64 PowerShell V2 Admin Tools, and Core Component Windows 7 (x64 only) Windows Vista� SP2 (x64 only) PowerShell V2 4 Slide Objective: Provide an overview of the software required for deploying Lync Server 2010 within your environment. Notes: So, our software requirements are pretty straight forward, we have Windows Server 2008 SP2 and Windows 2008 R2, which are x64 only, as well as we require Powershell V2. One thing to note is that Powershell v2 is not part of the Windows 2008 operating system, so that requires a separate install if that�s the OS you decided to deploy upon. However if you decide to deploy with Windows 2008 R2, then Powershell v2 will be part of that OS be default. We�ll also have Admin tools requirements and we�ll go into further detail for what�s not included as part of that and we also have �core� which is our new Powershell core provider, which you can only install on Windows 7 and Vista SP2, x64 only. Currently we have no support for Admin Tool support for the 32-bit platform. On the backend, we have �recommend� SQL 2005 SP3 and SQL 2008 SP1 on the x64 platform for maximizing best performance. For the Active Directory domain and forest levels, we have the same requirements as we had with OCS 2007 R2, which is Windows 2003, 2008 and Windows 2008 R2 with the domain and forest levels at Windows 2003. Of interest, we do support Read Only Domain Controllers (RODC) as part of a Windows 2008 R2, along with new features available having that particular OS for a domain controller.Slide Objective: Provide an overview of the software required for deploying Lync Server 2010 within your environment. Notes: So, our software requirements are pretty straight forward, we have Windows Server 2008 SP2 and Windows 2008 R2, which are x64 only, as well as we require Powershell V2. One thing to note is that Powershell v2 is not part of the Windows 2008 operating system, so that requires a separate install if that�s the OS you decided to deploy upon. However if you decide to deploy with Windows 2008 R2, then Powershell v2 will be part of that OS be default. We�ll also have Admin tools requirements and we�ll go into further detail for what�s not included as part of that and we also have �core� which is our new Powershell core provider, which you can only install on Windows 7 and Vista SP2, x64 only. Currently we have no support for Admin Tool support for the 32-bit platform. On the backend, we have �recommend� SQL 2005 SP3 and SQL 2008 SP1 on the x64 platform for maximizing best performance. For the Active Directory domain and forest levels, we have the same requirements as we had with OCS 2007 R2, which is Windows 2003, 2008 and Windows 2008 R2 with the domain and forest levels at Windows 2003. Of interest, we do support Read Only Domain Controllers (RODC) as part of a Windows 2008 R2, along with new features available having that particular OS for a domain controller.

5. Hardware Recommendations 5 Slide Objective: Provide an overview of the hardware required for deploying MCS14 within your environment. Notes: If you happen to have a CPU that runs at 1.99 Ghz, it will still work � these are just guidelines with what�s been tested and certified and what we�ve seen has worked best from other customer deployments. From a CPU perspective, you�ll see that (8) cores are required, for Memory. We�re recommending 12 GB of RAM for attached storage, 72 GB in space minimum, and that you use disk drives rated at 10K RPM or greater. The other thing to note is though these requirements fall under the Front End role, these will be the same requirements for some other specific roles as well (i.e. Archiving, Edge, and Monitoring). From a network perspective, we�re recommending (2) network interfaces (NICs) as a best practice, though they�re not absolutely required. We mention this should you be doing remote administration, backup or monitoring of these servers � dedicating a network interface for those services will provide you the best experience for your environment in terms of performance. For the SQL backend, we essentially have the same requirements, the only difference being Memory where we require 32 GB of RAM since we�re extremely sensitive to the performance of the backend database. Lastly, we�ll be supporting Server Virtualization for all roles, which is a great capability now to consider as part of your deployment effort. Interesting to note is that we�ll be including support for virtualizing the audio, app sharing and video workloads as part of the story, with the caveat; �i.e. you must closely follow the virtualization guidelines to support audio and video, and even then it could be�more susceptible to jitter and latency). Slide Objective: Provide an overview of the hardware required for deploying MCS14 within your environment. Notes: If you happen to have a CPU that runs at 1.99 Ghz, it will still work � these are just guidelines with what�s been tested and certified and what we�ve seen has worked best from other customer deployments. From a CPU perspective, you�ll see that (8) cores are required, for Memory. We�re recommending 12 GB of RAM for attached storage, 72 GB in space minimum, and that you use disk drives rated at 10K RPM or greater. The other thing to note is though these requirements fall under the Front End role, these will be the same requirements for some other specific roles as well (i.e. Archiving, Edge, and Monitoring). From a network perspective, we�re recommending (2) network interfaces (NICs) as a best practice, though they�re not absolutely required. We mention this should you be doing remote administration, backup or monitoring of these servers � dedicating a network interface for those services will provide you the best experience for your environment in terms of performance. For the SQL backend, we essentially have the same requirements, the only difference being Memory where we require 32 GB of RAM since we�re extremely sensitive to the performance of the backend database. Lastly, we�ll be supporting Server Virtualization for all roles, which is a great capability now to consider as part of your deployment effort. Interesting to note is that we�ll be including support for virtualizing the audio, app sharing and video workloads as part of the story, with the caveat; �i.e. you must closely follow the virtualization guidelines to support audio and video, and even then it could be�more susceptible to jitter and latency).

6. Operating System Component Prerequisites PowerShell V2 RTM Not supported are PowerShell V1 and PowerShell V2 prerelease versions Internet Information Services (IIS) rewrite module 2.0 (redistributable) Selected IIS modules .NET 3.5 (SP1) Visual C++ (redistributable) Microsoft Message Queuing (MSMQ) required for selected roles if Monitoring and/or Archiving functionality is deployed Active Directory Domain Services Tools optional for AD Prep SQL 2005 Back Compatibility module required by Install-CsDatabase cmdlet 6 Slide Objective: Provide an overview of the pre-requisites required from the Operating System point of view, depending on which Lync Server 2010 you�ll be planning to deploy. Notes: For prerequisites, we require Powershell V2 (RTM). We emphasize that as we�ve seen some issues if versions other than RTM have been installed. We have also released a new redistribution of a new software module required, which is the IIS Rewrite Module 2.0. We also have .net 3.5 SP1 that�s required. Again, if your OS is Windows 2008 R2, then that component will already be installed as part of the base operating system and will be a separate install if your operating system is Windows 2008. For archiving and monitoring, we do need MSMQ on the Archiving and Monitoring servers, as well as on the Front End servers themselves to also include the Survivable Branch appliance, if that will be part of your deployment. So for these components, we require them to be installed and checked to confirm that the right versions are there. However, we won�t actually install any of these components for you, aside from Visual C++ and .NET 3.5 SP1 since they�re required dependencies form when the initial setup executable is launched. You�ll see Active Directory Domain Services tools noted here. That will only be required if you plan to run the AD preparation tasks from the server you�re installing Lync Server 2010 on. Now you can also run the Active Directory preparation task from a domain controller; however you�d have to install Powershell on that domain controller, as well as require our �Core� component as prerequisites for that. Lastly, you�ll see we�ve got the SQL 2005 Backward Compatibility module listed, this is key as it�s a necessary component to provide the Distributed Management Objects (DMO) interface required when running the Install-CSDatabase cmdlet.Slide Objective: Provide an overview of the pre-requisites required from the Operating System point of view, depending on which Lync Server 2010 you�ll be planning to deploy. Notes: For prerequisites, we require Powershell V2 (RTM). We emphasize that as we�ve seen some issues if versions other than RTM have been installed. We have also released a new redistribution of a new software module required, which is the IIS Rewrite Module 2.0. We also have .net 3.5 SP1 that�s required. Again, if your OS is Windows 2008 R2, then that component will already be installed as part of the base operating system and will be a separate install if your operating system is Windows 2008. For archiving and monitoring, we do need MSMQ on the Archiving and Monitoring servers, as well as on the Front End servers themselves to also include the Survivable Branch appliance, if that will be part of your deployment. So for these components, we require them to be installed and checked to confirm that the right versions are there. However, we won�t actually install any of these components for you, aside from Visual C++ and .NET 3.5 SP1 since they�re required dependencies form when the initial setup executable is launched. You�ll see Active Directory Domain Services tools noted here. That will only be required if you plan to run the AD preparation tasks from the server you�re installing Lync Server 2010 on. Now you can also run the Active Directory preparation task from a domain controller; however you�d have to install Powershell on that domain controller, as well as require our �Core� component as prerequisites for that. Lastly, you�ll see we�ve got the SQL 2005 Backward Compatibility module listed, this is key as it�s a necessary component to provide the Distributed Management Objects (DMO) interface required when running the Install-CSDatabase cmdlet.

7. Changes in Setup and DeploymentLync Server 2010 Slide Objective: Provide an introduction into the next slide, emphasizing that many things are new, transitioning to some of the rationale behind What we�ll cover in the next slide to follow. Notes: So, it�s all new and your probably wondering why we�ve changed things. It all went so well in previous releases for OCS 2007 and 2007 R2, so why did thing changes? Slide Objective: Provide an introduction into the next slide, emphasizing that many things are new, transitioning to some of the rationale behind What we�ll cover in the next slide to follow. Notes: So, it�s all new and your probably wondering why we�ve changed things. It all went so well in previous releases for OCS 2007 and 2007 R2, so why did thing changes?

8. Microsoft Office Communications Server 2007 and 2007 R2Improvements from Previous Releases Configuration Data in AD DS, SQL, Windows Management Instrumentation (WMI) Now centralized with Lync Server 2010 Changes to Office Communications Server (OCS) 2007 and OCS 2007 R2 configuration required changes to the AD DS schema Required schema changes delayed or blocked deployment Little or no schema changes moving forward Edge server with local configuration Edge configuration will not get out sync Service User Accounts and password expiration Lync Server 2010 services run as Network Service 8 Slide Objective: Provide an overview of the improvements from previous releases of OCS that were focused to be addressed as part of the new changes within Lync Server 2010. Notes: We kept the configuration data stored within Active Directory, SQL, and WMI. The data in Active Directory was mainly user data, but a lot of our server configuration data was kept within Active Directory as well. We also had a pool that was stored within the backend database and then on top of that, we had local configuration data, that was local to the server itself that was stored within WMI. The challenge that we had with this approach was that if we wanted to change a small setting, we always had to go into Active Directory and change the schema. As you know, the schema within Active Directory isn�t something that can be taken lightly and needs a lot of preparation time. This was a challenge for us for aligning the changes around or release cycle since an update to the schema was required, along with the planning and considerations that had to be scheduled for getting those changes deployed. This created a challenge as we had some customers that only allowed schema changes 1x a year, which is impactful when an organization is looking to benefit and deploy features from our latest versions; which led to a lot of deployment blockers. The other consideration for Active Directory were planning issues around storing global settings within the System or Configuration container as there were obvious trade-offs. For example, if you stored your global settings within the System Container and didn�t have a lot replication, then everyone always had to talk to a �root� Forest Global Catalog and Domain Controller server. However if you had a very distributed deployment in this scenario, if you had to deploy OCS servers around the world, it could take hours for replication to update, requiring the servers to always go back and talk to a Global Catalog and Domain Controller server from the Forest root domain. To alleviate this, with OCS 2007 R2, we moved to storing these Global Settings from within the Configuration container, which assisted with this issue, but this approach now introduced more replication traffic. Additionally, we also had our Edge deployment, which is in a DMZ and could be either domain joined or remain as part of an isolated workgroup. So what would happen is for each Edge server, you would have a local WMI configuration, which you had to get right. For example, if you added another pool, you�d have to go to each of your Edge servers and update individually. Additionally, if you had a scaled Edge deployment and forgot to update a server or two, this would result in random connectivity behavior as some servers worked and others didn�t. This could lead to configuration being out of synch within your edge environment. Also we had service accounts which were a big item due to compliance with password maintenance policies within an organization. What would happen is that the password would expire, you�d apply a patch and then reboot the server only to discover that the services would no longer start. Slide Objective: Provide an overview of the improvements from previous releases of OCS that were focused to be addressed as part of the new changes within Lync Server 2010. Notes: We kept the configuration data stored within Active Directory, SQL, and WMI. The data in Active Directory was mainly user data, but a lot of our server configuration data was kept within Active Directory as well. We also had a pool that was stored within the backend database and then on top of that, we had local configuration data, that was local to the server itself that was stored within WMI. The challenge that we had with this approach was that if we wanted to change a small setting, we always had to go into Active Directory and change the schema. As you know, the schema within Active Directory isn�t something that can be taken lightly and needs a lot of preparation time. This was a challenge for us for aligning the changes around or release cycle since an update to the schema was required, along with the planning and considerations that had to be scheduled for getting those changes deployed. This created a challenge as we had some customers that only allowed schema changes 1x a year, which is impactful when an organization is looking to benefit and deploy features from our latest versions; which led to a lot of deployment blockers. The other consideration for Active Directory were planning issues around storing global settings within the System or Configuration container as there were obvious trade-offs. For example, if you stored your global settings within the System Container and didn�t have a lot replication, then everyone always had to talk to a �root� Forest Global Catalog and Domain Controller server. However if you had a very distributed deployment in this scenario, if you had to deploy OCS servers around the world, it could take hours for replication to update, requiring the servers to always go back and talk to a Global Catalog and Domain Controller server from the Forest root domain. To alleviate this, with OCS 2007 R2, we moved to storing these Global Settings from within the Configuration container, which assisted with this issue, but this approach now introduced more replication traffic. Additionally, we also had our Edge deployment, which is in a DMZ and could be either domain joined or remain as part of an isolated workgroup. So what would happen is for each Edge server, you would have a local WMI configuration, which you had to get right. For example, if you added another pool, you�d have to go to each of your Edge servers and update individually. Additionally, if you had a scaled Edge deployment and forgot to update a server or two, this would result in random connectivity behavior as some servers worked and others didn�t. This could lead to configuration being out of synch within your edge environment. Also we had service accounts which were a big item due to compliance with password maintenance policies within an organization. What would happen is that the password would expire, you�d apply a patch and then reboot the server only to discover that the services would no longer start.

9. Microsoft Lync Server 2010Configuration Data Moved to Custom Store Introducing Central Management Store XML documents stored in SQL database Contain all data: Topology, Policies, Configuration Single master database (DB) per deployment Central Management Server Runs on one Pool per deployment Pushes (replicates) changes to configuration to each server Replication via HTTPS to Edge servers in Perimeter Network Replica Each server has replica copy of master DB Servers continue to operate without access to master DB 9 Slide Objective: Provide an overview of the changed enhancements now possible with Lync Server 2010 and some of the reasoning behind that. Notes: So, what did we do. First off, we introduced a new component called the Central Management Store (CMS) which in essence is a SQL database containing configuration data and a number of XML configuration documents. Some of the most important XML documents are configuration, policy, and topology documents. So for example, a meeting policy is part of the policy XML document stored within the CMS with an object in Active Directory that points to it for backward compatibility purposes. Now this particular setting is outside of Active Directory and we decided to make a change to this with additional fields; for example, a schema change for Active Directory is now no longer required. As part of the new CMS architecture, we have this concept of a �single� Master database and we�ll have replicas of that which I�ll talk about in a moment. For the Central Management Server, we have (2) key pieces � CMS discussed previously and the Central Management Server (a different component) which is a special role that normally runs on the first Lync Server 2010 front end server from your Lync Server 2010 pool within your deployment. This server component pushes out and replicates all changes that are made to CMS to all Lync Server 2010 servers identified as needed to be updated via replication. We also can expand this capability by performing configuration replication to the Edge and since the Edge server is normally not domain joined, we�ll utilize certificates for that. From the Edge server itself, we no longer leverage or require IIS, we now have our own http/https listener which would be the component on the Edge server receiving these configuration updates. Lastly, we have the �Replica� which runs on each Lync Server 2010 role/system, which is a SQL Express database and contains a copy of the complete topology documents form the CMS. So what happens now with Lync Server 2010 is when a server starts up and it sees that its configuration (replica) is current, it won�t attempt to talk to anyone else for starting its services. Also if the CMS is offline, each Lync Server 2010 role will use the data from its local replica � so there�s more resiliency in that way. So now having our own data store provides us a lot of advantages and going forward greater flexibility. The cost to that however is some added costs in terms of migration as customers migrate from previous OCS releases to Lync Server 2010. Slide Objective: Provide an overview of the changed enhancements now possible with Lync Server 2010 and some of the reasoning behind that. Notes: So, what did we do. First off, we introduced a new component called the Central Management Store (CMS) which in essence is a SQL database containing configuration data and a number of XML configuration documents. Some of the most important XML documents are configuration, policy, and topology documents. So for example, a meeting policy is part of the policy XML document stored within the CMS with an object in Active Directory that points to it for backward compatibility purposes. Now this particular setting is outside of Active Directory and we decided to make a change to this with additional fields; for example, a schema change for Active Directory is now no longer required. As part of the new CMS architecture, we have this concept of a �single� Master database and we�ll have replicas of that which I�ll talk about in a moment. For the Central Management Server, we have (2) key pieces � CMS discussed previously and the Central Management Server (a different component) which is a special role that normally runs on the first Lync Server 2010 front end server from your Lync Server 2010 pool within your deployment. This server component pushes out and replicates all changes that are made to CMS to all Lync Server 2010 servers identified as needed to be updated via replication. We also can expand this capability by performing configuration replication to the Edge and since the Edge server is normally not domain joined, we�ll utilize certificates for that. From the Edge server itself, we no longer leverage or require IIS, we now have our own http/https listener which would be the component on the Edge server receiving these configuration updates. Lastly, we have the �Replica� which runs on each Lync Server 2010 role/system, which is a SQL Express database and contains a copy of the complete topology documents form the CMS. So what happens now with Lync Server 2010 is when a server starts up and it sees that its configuration (replica) is current, it won�t attempt to talk to anyone else for starting its services. Also if the CMS is offline, each Lync Server 2010 role will use the data from its local replica � so there�s more resiliency in that way. So now having our own data store provides us a lot of advantages and going forward greater flexibility. The cost to that however is some added costs in terms of migration as customers migrate from previous OCS releases to Lync Server 2010.

10. Data Remaining in Active DirectoryLync Server 2010 Active Directory User extensions Back Compatibility Schema Office Communications Server 2007 and 2007 R2 schema extensions Enables interoperability and migration from previous versions Lync Server 2010 will create back compatibility entries for previous versions Third party application compatibility Will be discontinued in future releases 10 Slide Objective: Provide an overview for what data remains within Active Directory, why Lync Server 2010 maintains that in parallel to the new CMS model referencing configuration data and some of the reasoning behind that (i.e. for maintaining a seamless interoperability experience). Notes: So there is still data within Active Directory, which are the user extensions and we still carry a schema along from a server perspective, comparable to what we did with previous OCS releases which is required as part of the interoperability story. The reasoning behind this is that the down level pools from previous releases can�t interoperate without this data. For example, now when you create a pool within Lync Server 2010, we still publish a subset of this data within Active Directory which pools from previous OCS versions that can reference and route traffic accordingly. Another reasoning for storing a subset of information within Active Directory is so that any 3rd party application that may have developed from previous OCS releases will continue to function as well. Slide Objective: Provide an overview for what data remains within Active Directory, why Lync Server 2010 maintains that in parallel to the new CMS model referencing configuration data and some of the reasoning behind that (i.e. for maintaining a seamless interoperability experience). Notes: So there is still data within Active Directory, which are the user extensions and we still carry a schema along from a server perspective, comparable to what we did with previous OCS releases which is required as part of the interoperability story. The reasoning behind this is that the down level pools from previous releases can�t interoperate without this data. For example, now when you create a pool within Lync Server 2010, we still publish a subset of this data within Active Directory which pools from previous OCS versions that can reference and route traffic accordingly. Another reasoning for storing a subset of information within Active Directory is so that any 3rd party application that may have developed from previous OCS releases will continue to function as well.

11. Central Management StoreImpact on Setup and Deployment Topology document contains Pools, server (fully qualified domain name (FQDN)/Internet Protocol (IP) addresses/Ports), Server roles/components and dependencies Local Setup uses Topology document to install and activate Topology document needs to be authored before any server role can be installed A SQL DB is required for initial deployment Enterprise Edition Pool requires full SQL instance deployed Standard Edition uses a SQL Express instance which has to be installed in a separate step 11 Slide Objective: Provide an overview of the new Topology document, what it contains and compare it to issues with previous versions of OCS, as well as the new dependency for having the Topology document authored first before setup can commence. Secondly, emphasize the SQL requirements by version type that are necessary for bootstrapping a Lync Server 2010 deployment. Notes: So, the Topology document is in essence an XML document that contains the pools, the servers including FQDN, IP address and Port information, as well as the server component, role, and dependencies. For example, the Topology document will contain information about a pool, that this particular server is a front end. and the list of dependent applications and components required in support of that (i.e. you will use this file share, file store, database, Mediation server, etc.). What we did in terms of setup is that with Lync Server 2010, you�ll now author this Topology document first and then reference this as part of the setup process � now locally and unattended. With this approach, you can begin to see where we�re going with this, looking forward to the future where you can automate your deployments more and more. For Lync Server 2010 however, we will still require you to touch the machine, install the dependencies, configure and install the certificates, and so on. However, this lays the foundation for automated and unattended deployment capabilities for future versions of OCS that will follow. So with Lync Server 2010, this Topology document is now centralized and every Lync Server 2010 role can now make use of and references it. If you look back, our issues with Edge deployments in previous releases equated to forgetting to add a new pool to the Edge configuration that was recently deployed, so it wouldn�t work. Now, with the centralized Topology document approach, if you create a new pool (in effect authoring an update to the Topology document), this updated XML document will get replicated to all Lync Server 2010 roles and the new Lync Server 2010 Edge will automatically be updated to support the new pool added. The other advantage of using the Topology document is that with the Edge configuration in previous releases, you would define the next hop, but there wasn�t much in the way of logic for ensuring that the name entered was correct, which resulted in an additional troubleshooting exercise. Now by referencing the Topology document, we have several validation checks in place at various levels so that we can make sure there�s no misconfiguration. There�s still room for error to have a misconfiguration within the Topology document, however it�s significantly reduced now compared to misconfiguration issues with previous OCS releases. So, the Topology document has to be authored first before the first Lync Server 2010 server can be installed, which now leads us to the new deployment and setup process we now have to follow. Since the CMS stores this document, we need to have a SQL store beforehand before we can start our deployment. So in the case where you�re deploying Enterprise Edition, a SQL instance will already be deployed beforehand for supporting the backend, however with relation to Standard Edition server, we will have a �chicken before the egg� problem. For the Standard Edition deployment, it will use SQL Express and what we have for this is for the Standard Edition deployment, we now have the option to prepare the Standard Edition server first before continuing deployment of a Lync Server 2010 Standard Edition role. What the Standard Edition �prepare� process will do is install a new SQL Express instance on the local machine so that we have a SQL instance to boot strap from for carrying the deployment and setup process forward.Slide Objective: Provide an overview of the new Topology document, what it contains and compare it to issues with previous versions of OCS, as well as the new dependency for having the Topology document authored first before setup can commence. Secondly, emphasize the SQL requirements by version type that are necessary for bootstrapping a Lync Server 2010 deployment. Notes: So, the Topology document is in essence an XML document that contains the pools, the servers including FQDN, IP address and Port information, as well as the server component, role, and dependencies. For example, the Topology document will contain information about a pool, that this particular server is a front end. and the list of dependent applications and components required in support of that (i.e. you will use this file share, file store, database, Mediation server, etc.). What we did in terms of setup is that with Lync Server 2010, you�ll now author this Topology document first and then reference this as part of the setup process � now locally and unattended. With this approach, you can begin to see where we�re going with this, looking forward to the future where you can automate your deployments more and more. For Lync Server 2010 however, we will still require you to touch the machine, install the dependencies, configure and install the certificates, and so on. However, this lays the foundation for automated and unattended deployment capabilities for future versions of OCS that will follow. So with Lync Server 2010, this Topology document is now centralized and every Lync Server 2010 role can now make use of and references it. If you look back, our issues with Edge deployments in previous releases equated to forgetting to add a new pool to the Edge configuration that was recently deployed, so it wouldn�t work. Now, with the centralized Topology document approach, if you create a new pool (in effect authoring an update to the Topology document), this updated XML document will get replicated to all Lync Server 2010 roles and the new Lync Server 2010 Edge will automatically be updated to support the new pool added. The other advantage of using the Topology document is that with the Edge configuration in previous releases, you would define the next hop, but there wasn�t much in the way of logic for ensuring that the name entered was correct, which resulted in an additional troubleshooting exercise. Now by referencing the Topology document, we have several validation checks in place at various levels so that we can make sure there�s no misconfiguration. There�s still room for error to have a misconfiguration within the Topology document, however it�s significantly reduced now compared to misconfiguration issues with previous OCS releases. So, the Topology document has to be authored first before the first Lync Server 2010 server can be installed, which now leads us to the new deployment and setup process we now have to follow. Since the CMS stores this document, we need to have a SQL store beforehand before we can start our deployment. So in the case where you�re deploying Enterprise Edition, a SQL instance will already be deployed beforehand for supporting the backend, however with relation to Standard Edition server, we will have a �chicken before the egg� problem. For the Standard Edition deployment, it will use SQL Express and what we have for this is for the Standard Edition deployment, we now have the option to prepare the Standard Edition server first before continuing deployment of a Lync Server 2010 Standard Edition role. What the Standard Edition �prepare� process will do is install a new SQL Express instance on the local machine so that we have a SQL instance to boot strap from for carrying the deployment and setup process forward.

12. Setup Components What Is New? Lync Server 2010 Core (OCSCore.msi) Core component and DLLs PowerShell Provider (PowerShell V2 is required) Planning Tool Topology Builder Setup User Interface (UI) - local Setup 12 Slide Objective: Provide an overview of the new components, capabilities, dependencies and processes required for supporting a Lync Server 2010 deployment. Notes: So, we have (1) �core� component and it�s called �OCSCore.msi� which contains the Core component and necessary DLLs, as well as the required Powershell Provider. What you can do with this �core� component is install it on a designated administration machine for remote administration purposes. Additionally, the �core� component is required for installation upon all Lync Server 2010 roles, which is the first component installed when you insert your media. With the first prompt, we�ll install �OCSCore� for you. One thing to note is that Powershell V2 (RTM) is required as a dependency for the �OCSCore.msi� to install successfully. The other new item we have is what�s called the Topology Builder tool, which in simpleton terms is an enhanced XML editor which operates upon XML documents, providing a UI for authoring your Lync Server 2010 topology. As part of the tool, it includes a lot of built-in knowledge and consistency checking for how to properly author your Lync Server 2010 topology and keep the new Lync Server 2010 deployment in line with what�s possible and supported. The underlying Topology document itself actually allows you more configuration customization; which in most cases doesn�t make a lot of sense and can lead to unexpected configuration issues as a result. So by using the Topology Builder tool, we can verify consistency within your Lync Server 2010 deployment and that what you defined will be supported and just work. The last piece that�s new is updated setup UI, which allows for some of the preparatory and setup tasks, like preparation of Active Directory, synonymous from previous releases. One item that�s new however is that the setup UI now allows you do a local installation (setup wizard) once your machine has been authored within the Lync Server 2010 Topology document so that no additional configuration effort is required, the wizard will automatically configure and setup Lync Server 2010 upon the server specified. The other benefit with local setup is that since we already asked the necessary questions when authoring the Topology document, no questions will be asked from the local setup, resulting in a pretty much unattended installation (aside from certificates) � easing your deployment effort forward.Slide Objective: Provide an overview of the new components, capabilities, dependencies and processes required for supporting a Lync Server 2010 deployment. Notes: So, we have (1) �core� component and it�s called �OCSCore.msi� which contains the Core component and necessary DLLs, as well as the required Powershell Provider. What you can do with this �core� component is install it on a designated administration machine for remote administration purposes. Additionally, the �core� component is required for installation upon all Lync Server 2010 roles, which is the first component installed when you insert your media. With the first prompt, we�ll install �OCSCore� for you. One thing to note is that Powershell V2 (RTM) is required as a dependency for the �OCSCore.msi� to install successfully. The other new item we have is what�s called the Topology Builder tool, which in simpleton terms is an enhanced XML editor which operates upon XML documents, providing a UI for authoring your Lync Server 2010 topology. As part of the tool, it includes a lot of built-in knowledge and consistency checking for how to properly author your Lync Server 2010 topology and keep the new Lync Server 2010 deployment in line with what�s possible and supported. The underlying Topology document itself actually allows you more configuration customization; which in most cases doesn�t make a lot of sense and can lead to unexpected configuration issues as a result. So by using the Topology Builder tool, we can verify consistency within your Lync Server 2010 deployment and that what you defined will be supported and just work. The last piece that�s new is updated setup UI, which allows for some of the preparatory and setup tasks, like preparation of Active Directory, synonymous from previous releases. One item that�s new however is that the setup UI now allows you do a local installation (setup wizard) once your machine has been authored within the Lync Server 2010 Topology document so that no additional configuration effort is required, the wizard will automatically configure and setup Lync Server 2010 upon the server specified. The other benefit with local setup is that since we already asked the necessary questions when authoring the Topology document, no questions will be asked from the local setup, resulting in a pretty much unattended installation (aside from certificates) � easing your deployment effort forward.

13. Setup flow 13 Slide Objective: Provide an overview of the setup flow walking thru the dependencies and steps required in order for preparing a customer�s environment for Lync Server 2010. Additionally, walking through what�s required beforehand for deploying the different roles once a topology has been authored and the steps necessary for making changes to an existing topology afterwards (things to consider should it be required). Notes: So in terms of setup flow, you have the preparation of Active Directory that is required and have to pick a domain joined machine for that. This can be any domain joined machine or can be the first Lync Server 2010 server within in your deployment. Once this is machine is identified, your Active Directory preparation steps will run from there; this could even be run from a designated domain controller if that is the machine of choice. The next thing you�ll do is install the Topology Builder tool which can be installed upon the same machine use for Active Directory machine or can be another machine of your choice � but this is the tool you�ll utilize for authoring your desired Lync Server 2010 topology. So you�ll go through the wizard, configuring your first server � you�ll have to deploy at least (1) pool before we can publish the authored Topology document making it active. Then once the Topology document has been authored, we�ll �publish� that document which will be inserted into the backend database supporting the first pool. For Standard Edition, this would be the SQL Express installed as part of the Standard Edition preparation for Enterprise Edition, this would be the SQL instance that would have already been deployed beforehand. One thing to note as part of the SQL Express installation for Standard Edition is that the 1st SQL Express is not enabled for �remote access� by default; however our setup process will auto-resolve that issue for us. One interesting thing to note is if you 1st deploy a Standard Edition server and decide later if you want to migrate it to Enterprise Edition. We will have a process that allows the migration for that from a CMS configuration store perspective. So after the Topology document is published to the database, you will go to the 1st Lync Server 2010 server you want to deploy, running the local setup again and the first component we�ll install is the �OCSCore.msi� component, requiring Powershell V2 (RTM) being installed as a dependency. Once that�s complete, the setup routine will reference a Service Connection Point (SCP) object from Active Directory, which will point the setup to the Central Management Store database. This is where we�ll connect and pull down the Topology document configured (authored), installing the Lync Server 2010 components/role as defined and performing activation of those services and roles accordingly. As the next step, you�ll go through the certificate wizard process, similar with OCS from previous releases, where you�ll run through a wizard, generating the certificate request, installing the received certificate response on the machine specific and binding that certificate to the Lync Server 2010 services and roles specified. Additionally, just like in previous releases, you have the lifecycle of the certificates that must be managed and will have to come back through the certificate wizard process for renewing and re-assigning new certificates to the Lync Server 2010 roles and services defined. The last thing to mention is that as changes are made to your Lync Server 2010 environment, so say for example you change the URL path for web services or change a port that IIS uses, you�ll have to reflect those changes by authoring the Topology document via Topology Builder 1st. Then once that�s complete, you�ll have to publish that new Topology document and will be prompted to re-run setup on the Lync Server 2010 servers affected for those configuration changes to be made and in essence put into effect.Slide Objective: Provide an overview of the setup flow walking thru the dependencies and steps required in order for preparing a customer�s environment for Lync Server 2010. Additionally, walking through what�s required beforehand for deploying the different roles once a topology has been authored and the steps necessary for making changes to an existing topology afterwards (things to consider should it be required). Notes: So in terms of setup flow, you have the preparation of Active Directory that is required and have to pick a domain joined machine for that. This can be any domain joined machine or can be the first Lync Server 2010 server within in your deployment. Once this is machine is identified, your Active Directory preparation steps will run from there; this could even be run from a designated domain controller if that is the machine of choice. The next thing you�ll do is install the Topology Builder tool which can be installed upon the same machine use for Active Directory machine or can be another machine of your choice � but this is the tool you�ll utilize for authoring your desired Lync Server 2010 topology. So you�ll go through the wizard, configuring your first server � you�ll have to deploy at least (1) pool before we can publish the authored Topology document making it active. Then once the Topology document has been authored, we�ll �publish� that document which will be inserted into the backend database supporting the first pool. For Standard Edition, this would be the SQL Express installed as part of the Standard Edition preparation for Enterprise Edition, this would be the SQL instance that would have already been deployed beforehand. One thing to note as part of the SQL Express installation for Standard Edition is that the 1st SQL Express is not enabled for �remote access� by default; however our setup process will auto-resolve that issue for us. One interesting thing to note is if you 1st deploy a Standard Edition server and decide later if you want to migrate it to Enterprise Edition. We will have a process that allows the migration for that from a CMS configuration store perspective. So after the Topology document is published to the database, you will go to the 1st Lync Server 2010 server you want to deploy, running the local setup again and the first component we�ll install is the �OCSCore.msi� component, requiring Powershell V2 (RTM) being installed as a dependency. Once that�s complete, the setup routine will reference a Service Connection Point (SCP) object from Active Directory, which will point the setup to the Central Management Store database. This is where we�ll connect and pull down the Topology document configured (authored), installing the Lync Server 2010 components/role as defined and performing activation of those services and roles accordingly. As the next step, you�ll go through the certificate wizard process, similar with OCS from previous releases, where you�ll run through a wizard, generating the certificate request, installing the received certificate response on the machine specific and binding that certificate to the Lync Server 2010 services and roles specified. Additionally, just like in previous releases, you have the lifecycle of the certificates that must be managed and will have to come back through the certificate wizard process for renewing and re-assigning new certificates to the Lync Server 2010 roles and services defined. The last thing to mention is that as changes are made to your Lync Server 2010 environment, so say for example you change the URL path for web services or change a port that IIS uses, you�ll have to reflect those changes by authoring the Topology document via Topology Builder 1st. Then once that�s complete, you�ll have to publish that new Topology document and will be prompted to re-run setup on the Lync Server 2010 servers affected for those configuration changes to be made and in essence put into effect.

14. Standard Edition SetupSingle Server �All-in-one� Deployments Is the Standard Edition Server being deployed the first pool in this deployment? Use �Setup Single Standard Edition Server� from the Setup main menu to install a SQL Express instance For subsequent Standard Edition Server pools the above step is not necessary 14 Slide Objective: Notes: For the single server �All-in-one� deployments, Slide Objective: Notes: For the single server �All-in-one� deployments,

15. Setup UI Main Screen 15 Slide Objective: Notes: Slide Objective: Notes:

16. Prepare Active Directory � Overview 16 Slide Objective: Notes: Slide Objective: Notes:

17. Prepare Active DirectoryPowershell Cmdlets Schema Prep Install-CSADServerSchema �ldf <PathtoLDFfiles> Current state: Get-CSSchemaState Forest Prep Enable-CSAdForest Current state: Get-CSForestState Domain Prep Enable-CSAdDomain Current state: Get-CSDomainState 17 Slide Objective: Notes: Slide Objective: Notes:

18. Demo: Topology Builder 18 Slide Objective: Notes: Slide Objective: Notes:

19. Local SetupRunning �Install or Update Lync Server system� 19 Slide Objective: Notes: Slide Objective: Notes:

20. Setting Up DatabasesCmdlet install-CsDatabase and when to use Cmdlet Install-CsDatabase Reads Topology document and configures SQL Stores based on assigned roles (remotely) Access SQL instance and check for connectivity and permissions Creates databases and table Creates DB roles and store procedures Run by Topology Builder Integrated in Topology Builder Requires admin to have SQL admin Run as standalone cmdlet SQL admin may be separate from Lync Server 2010 Admin More flexibility Special usages: custom path, SQL cluster 20 Slide Objective: Notes: Slide Objective: Notes:

21. Other Setup Tasks Kerberos Authentication option IIS as Network Service, service principal name (SPN) for Pool Solution via using a Computer Account in Active Directory Computer Account password does not fall under password expiration policies PS Cmdlet available to create, assign, and manage account name and password Optional configuration If not configured, NTLM authentication is used 21 Slide Objective: Notes: Slide Objective: Notes:

22. Q&A 22 Slide Objective: Notes: Slide Objective: Notes:

23. 23 Slide Objective: Notes: Slide Objective: Notes: