Search This Blog

Showing posts with label Lync Server 2010. Show all posts
Showing posts with label Lync Server 2010. Show all posts

Wednesday, October 12, 2011

Lync Server 2010 Deployment – Part 3

Lync Server 2010 Deployment – Part 3

Update:  This process is identical to (and has been tested with) the public release version of Lync Server 2010.
The next step is to enable a few existing user Active Directory accounts for Lync so that client connections can be tested to the Standard Edition Front End server.  Notice that ‘existing users’ was stated as the Lync Control Panel can only enable AD user accounts and not create new user accounts; that must first be performed using Active Directory for Users and Computers (ADUC) or whatever similar tool is desired.
  • On the Lync Control Panel select Users and then Enable Users.  Search for the first user account to enable (e.g. Jeff) Select a different user account than the one currently used to logon the Lync Server as an ‘insufficient rights’ error will be returned if an attempt is made to enable the current account.  Assign the user to the single pool in the environment and then generate the SIP address using the desired format (e.g. <SAMAccountName>  Leave the Telephony and other policies at the default setting for now, these setting will be modified later on.
  • Enable additional accounts now so that this test user account will have at least one other account to contact within the Lync client.
  • Sign-in to two separate clients with any of the new accounts and enter the names of the other accounts in the search bar.  Depending on if the previous address book files were downloaded or are still in the process then no results should appear, returning either “No results found” (address book was downloaded but no name was match found) or “The address book is preparing to synchronize”.
image     image
    Now all standard modalities should be available between the clients, including IM/Presence, conferencing, and application sharing.  The next step is to enable these users for Enterprise Voice (EV) and then configure the Voice features in Lync Server so that not only will Communicator calls be available between them but also Enterprise Voice calling.

Enabling Enterprise Voice

Configuring Enterprise Voice is basically the same steps as it was in OCS but some of he individual steps are handled differently in Lync Server.  For example the OCS Location Profile has been replaced with a Dial Plan in Lync which is an expanded scope that is not just a global definition now but can also be assigned at the user, pool, or site level as well.
For the purposes of this lab a single site will be defined (Chicago) and a single block of telephone numbers will be dedicated to internal Lync users (312-555-75xx).  As usual a fully RFC3966 compliant numbering pattern will be used throughout the Lync and Active Directory fields and a basic 4-digit extension pattern will be added to allow for easy 4-digit dialing.
  • Start off by setting the desired phone numbers on each AD user object in the Telephone Number field (telephoneNumber attribute).  Two different formats are shown in the example below.
Regarding the format used for the phone numbers there are two ways this can be approached.  The easiest solution which requires no additional configuration is to populate the numbers directly into RFC3966 format as in             +13125557500      .  Lync will display these by default as they require no normalization.  But if a more common display format of             (312) 555-7500       is used then these numbers will not be normalized by Lync for contacts and require additional configuration of the Address Book service to be displayed in the Lync client.  See this previous blog article for more details on this process.
And in keeping with the running theme of pointing out differences between OCS and Lync another beneficial change can be seen at this point.  In OCS the was no default EV configuration; no location profile, no route, no normalization rules. They all had to be created from scratch.  But in Lync Server the Voice Routing section of the Control Panel will show that number of default configuration object are already defined: a default global dial plan (Global), a default route (Localroute), etc.
So instead of creating all these objects only some minor changes will be applied to customize them for the desired numbering plan.
A logical place to start out would be the dial plan, which will be customized with two new normalization rules.
  • On the existing Global dial plan create a New Normalization Rule which will be used to properly handle many different formats of 10 and 11 digit strings.  This pattern is discussed in detail in one of my older OCS articles.
  • Add another New Normalization Rule which will be used to support direct dial of 4-digit extensions in the 7500-7599 range.  This simple pattern will match against any 4-digit string starting with 75 and then translate it into a normalized RFC3966 pattern (+E.164).
    • Remove the default Prefix All rule and reorder the new rules so that the Extension Dialing rule is at the top.  This will not impact the functionality at this point as the only two records are mutually exclusive and do not overlap. But as a habit more specific records should be placed towards the top of the rules list and more generic rules should be towards the bottom.
    • Save the changes to the Global dial plan and then Commit All changes.
Now a couple of the Lync-enabled user account need to be enabled for Enterprise Voice as well since all enabled accounts were previously only configured for PC-to-PC Communications.
  • Search for and edit the properties of the two primary test accounts in the Lync Control Panel under Users.  Select Enterprise Voice for the Telephony setting and enter the user’s telephone number using the proper Line URI format.  Commit the changes to each user (e.g. tel:            +13125557501      ).
image     image
  • Sign-out and back into both Lync clients with the two updated test accounts and the first indication of the change should be the addition of the Call Forwarding menu at the bottom of the Lync client.
  • To test Enterprise Voice calling for internal users as well as the extension-specific normalization pattern enter a 4-digit extension into the search bar and notice that both the normalized number and the resolved internal user are returned in the results.
image     image
Now would be a good time to define a phone number for the Conferencing Attendant, which can be performed using the Control Panel and is similar to the configuration used by OCS.  But before a Dial-In Access Number can be created a region must first be defined.
  • Edit the Global Dial Plan under Voice Routing and enter a descriptive name for the Dial-In Conferencing Region (e.g. Chicago).  Then Commit All changes to apply the change to Lync Server.
  • Under the Conferencing options select Dial-In Access Number and create a new entry, using a unique Line URI and SIP URI.  The Display Name and Display Number will be displayed on the Lync contact for this number.
Display Number
            (312) 555-7555      

Display Name
Conference Bridge

Line URI
tel:            +13125557555      


  • Add an Associated Region and select the region created in the previous step (e.g. Chicago).
  • Manually update the address book files using the process detailed in this previous article.
  • Search for 7555 from the Lync client to show the new contact object (it is normal for it to appear Offline as the presence is not active on contact objects).

Deploying a Media Gateway

As this walkthrough is meant primarily for test usage in a lab this media gateway will be configured in a unique, yet applicable scenario.  As SIP Trunking becomes more common (which may be addressed in a future article) media gateways will be used less for a default route to the PSTN and more often to bridge Lync Server to an existing legacy PBX system.  So in this lab the routing configuration will be sending only calls to numbers in the r(312) 555-77xx range.  Later on a SIP Trunk will be configured with a default route to handle any calls outside of the defined 75xx and 77xx ranges.
A step which was skipped during the initial deployment in Part 1 must first be addressed: specifying a PSTN gateway. In my lab there is a NET Tenor AF configured on and the Lync Topology must now be updated to reflect this.
  • Launch the Topology Builder , download the topology from the existing deployment, and then save the latest configuration data to a .tbxml file.
  • Locate PSTN Gateways and select the action to create  a New IP/PSTN Gateway and enter the IP address of the desired media gateway, changing the default port and protocol options to allow for TCP connections to the default listening port on the media gateway of TCP 5060. Normally a secured (certificate-based) TLS connection would be used and is recommended for all production deployments, but for the purposes of this article and the lab a TCP connection is used. Also some older media gateways do no have the ability to have certificates imported on them and thus cannot supported TLS connections.
    • Edit the properties of the existing Mediation Pool and select Enable TCP Port on the Mediation Server and leave the default TCP port of 5068 which is the where the Mediation Server will listen for incoming TCP connections for the media gateway.
  • Also click Add to associate the Mediation Server with the newly defined PSTN Gateway.
  • Publish the topology to apply the changes for the Mediation Server configuration to the Lync environment.
  • Modify the Global Voice Policy and create a new PSTN Usage Record (e.g. TenorAF), and add a new Associated Route using the setting in the following section.
Analog Phones

Routes calls to 77xx numbers to internal analog phones.

Match this Pattern

Associated Gateways

  • Enter a sample telephone number (in it’s normalized end-state) within the route’s defined range to test the pattern match.
  • Apply and Commit All changes.
At this point +E.164 numbers in the +131255577xx range will be routed to the Tenor gateway but the normalization rules will need to be updated to allow for 4-digit dialing of these numbers within Lync (e.g. 7701).  The simplest approach may seem to be to just create a new normalization rule to handle (7700-7799) digits, but because the internal Lync numbering plan is so similar (7500-7599) then the existing rule can be slightly tweaked to handle both ranges.
  • In the Global dial plan edit the Extension Dialing normalization rule and edit the pattern.  Replace the 5 with [5,7] which will expand this regex rule to apply to both 75xx and 77xx (but not include 76xx) as the comma means to match either 5 or 7.
  • Commit the changes and tests both 75xx and 77xx extensions from the Lync client (a restart of the client may be required if testing immediately).
Well, that wraps up Part 3 of this series and nearly every feature on Lync Server has been activated for use.  Upcoming articles may focus on configuring Conferencing features, deploying currently available Lync Phone Edition devices (e.g. CX700/Tanjay), and finally Edge Server deployment to allow external access to all these features.  Exchange Integration for UM and IM features will also be covered.


Lync Server 2010 Deployment – Part 2

Lync Server 2010 Deployment – Part 2


Where Part 1 left off was just shy of deploying the Standard Edition server itself as most of the back-end configuration was completed.  A few additional steps will be left for later discussion (e.g. client Automatic Configuration DNS records) when those topics are addressed.  So for now left’s get the Lync Server deployed an functional.
Update:  This process is identical to (and has been tested with) the public release version of Lync Server 2010.

Install Lync Server System

What these steps do is install a second SQL Express named instance (this one being named RTCLOCAL) on the local server which will contain a replica of the existing RTC named instance.  Although it may initially seem inefficient to have two SQL instances with duplicate data on the same server the separation of the Central Management Store and a CMS replica is key to how multiple server’s function in a single organization.
Only the first Standard Edition server in the organization would contain this authoritative RTC instance, while all other Lync Front End Servers (and even Edge Servers) would contain their own RTCLOCAL instance to replicate the Central Management Store data.  This approach also allows for the  new redundancy and availability features which were lacking in previous versions of OCS.  This RTCLOCAL instance can only ever be stored in an automatically installed SQL Express instance, it is not supported to locate this data in a full SQL Server instance.
  • Back at the Deployment Wizard main menu select Install or Update Lync Server System. Run Step 1: Install Local Configuration Store and leave the default setting to Retrieve the configuration data directly from the Central Management Store.  By reviewing the results in the execution window we can confirm a number of actions, most importantly that the second SQL Express instance of RTCLOCAL was installed.
Checking prerequisite PowerShell2…prerequisite satisfied.
Checking prerequisite SqlExpressRtcLocal…installing…success
Checking prerequisite VCredist…prerequisite satisfied.
Checking prerequisite SqlNativeClient…prerequisite satisfied.
Checking prerequisite SqlBackcompat…prerequisite satisfied.
Checking prerequisite UcmaRedist…prerequisite satisfied.
Installing OcsCore.msi(Feature_LocalMgmtStore)…success

  • Secondly the Local Configuration Store was installed and enabled using the Import-CsConfiguration and Enable-CSReplica cmdlets.
> Install Local Configuration Store Import-CSConfiguration -FileName "C:\Users\ADMINI~1.CSM\AppData\Local\Temp2\" -Verbose -LocalStore
> Enable local replica service Enable-CSReplica -Verbose -Confirm:$false -Report "C:\Users\administrator.CSMVP\AppData\Local\Temp2\Enable-CSReplica-[2010_09_15][12_10_23].html"
  • To confirm the location of the RTCLOCAL database files on the server check the default SQL Server installation directory for the existence of the xds files.
  • Run Step 2: Setup or Remove Lync Server Components and if the process halts with an error requesting a reboot as shown below then restart the server and run this step again.  This can occur because the Windows Media Format Runtime package requires a server restart after installation.
Checking prerequisite Wmf2008R2…installing…failure code 3010
The server must be restarted before installation can continue. To continue the installation after the server has restarted, start the Deployment Wizard and complete this step again.
  • At the completion of this step all of the Lync Server services and components have been installed locally.  A look at the Services applet will show a large list of installed services which are not yet running as a certificate still needs to be configured and assigned to them.
  • Some of the newly added database files for the pool can be seen in the default SQL Server DATA directory as well.

So about now would be a good time to briefly sidebar and try to understand what is going on with all these different SQL instances and databases with similar names. I was scratching my head as well the first time I installed all this in an early beta release.  So basically here is a brief rundown of
  • Using SSMS there are two instances (both SQL Express) on the Lync Server, RTC and RTCLOCAL on the server to connect to, each with a different set of databases.
Instance Database Description
RTC lis Location Information Services data
RTC xds Central Management Store data
RTCLOCAL rtc Standard Edition Pool data
RTCLOCAL rtcdyn Standard Edition transient user data
RTCLOCAL xds Local replica of Central Management Store data
And now moving back into the server deployment the next pending step is to request and assign a certificate so that the services can be started.
  • Run Step 3: Request, Install or Assign Certificates and then expand the Default Certificate entry to verify that all roles are checked.  Click Request and enter the information listed in the following tables.
Delayed or Immediate Requests
Send the request immediately to an online certificate authority

Choose a certificate Authority
Select from a list detected in your environment

Certificate Authority Account

Specify Alternate Certificate Template

Name and Security Settings
Friendly Name Lync SE Certificate
Bit Length 2048

Organization Information
Organization <Company Name>
Organizational Unit <Department Name>

Geographical Information
Country/Region United States
State/Province IL
City/Locality Chicago

Subject Name / Subject Alternate Names
Subject Name
Subject Alternate Name

SIP Domain setting on Subject Alternate Names (SANs)
Configured SIP Domains

Configure Additional Subject Alternate Names

  • This process will execute the Request-CsCertificate cmdlet with the provided configuration information, performing and online request against the CA and then automatically importing the return certificate into the Local Computer store.
> Request Certificate
Request-CSCertificate -New -Type Default,WebServicesInternal,WebServicesExternal -CA "\CSMVP-RootCA" -Country US -State "IL" -City "Chicago" -FriendlyName "Lync SE Certificate" -KeySize 2048 -PrivateKeyExportable $False -Organization "Schertz Lab" -DomainName "" -Verbose -Report "C:\Users\administrator.CSMVP\AppData\Local\Temp2\Request-CSCertificate-[2010_09_15][14_55_56].html"
  • Click Assign and select the new certificate from the local store.  The following Set-CsCertificate cmdlet is automatically run by the wizard to assign the desired certificate to the three server roles.
> Assign Certificate
Set-CSCertificate -Type Default,WebServicesInternal,WebServicesExternal -Thumbprint 7B8E17E800F4702EC14228C4A6E84C019F9F6AB6 -Verbose -Confirm:$false -Report "C:\Users\administrator.CSMVP\AppData\Local\Temp2\Set-CSCertificate-[2010_09_15][15_03_04].html"
  • Once the certificate is assigned to all roles the wizard should reflect that, although a Refresh may need to be required to see the changes.
  • Run Step 4: Start Services to see the fruits of your labor converted into a bunch of happily-running services.  The Start-CsWindowsService cmdlet is executed with no parameters which by default will attempt to start all Lync services.
> Start Services
Start-CSWindowsService -NoWait -Verbose -Report "C:\Users\administrator.CSMVP\AppData\Local\Temp2\Start-CSWindowsService-[2010_09_15][15_40_36].html"
Let us briefly take a look at another major difference between OCS and Lync which is how IIS is configured by the installation process.
  • For one, certificates previously had to be manually defined and SSL enabled in IIS, but in Lync Server the setup wizard now does this automatically.
  • The other noticeable difference is the amount of new Application Pool defined, as well as the separate internal and external web sites.
Because there was no step in the deployment asking for additional IP addresses and it is still a best practice to use a single IP address on the Standard Edition server the External and Internal web sites in IIS are clearly not configured on the same listening ports.
  • The Lync Server Internal Web Site shows the default TCP80 and TCP443 ports assigned to it.
  • Yet the Lync Server External Web Site indicates different listening ports of TCP8080 and TCP4443 ports.  This configuration indicates that an external publishing server (e.g. ISA Server) must be configured to listen for client connections on the standard 80 and 443 ports yet it will forward traffic to the internal Front End server over ports 8080 and 4443 so that external client connections are directed to the External Web Site.
Before enabling user accounts now would be a good time to add the required internal DNS records to support Automatic Configuration. This is allow for any AD Integrated replication to fully propagate the new DNS records before attempting to sign-in with the Lync client.
  • Create a DNS Service Locator (SRV) and Host (A) records on the internal DNS server’s forward lookup zone.
As a general best practice I always prefer to add a second DNS record which the client will use as a fallback during Automatic Configuration in the case that the SRV record is not available or unsupported.  The Communicator and Lync clients will automatically lookup sipinternal, sip, and sipexternal host records in the SIP domain if the SRV lookup first fails.
  • A quick look at the details of the requested certificate shows an additional entry for in the Subject Alternate Name field even though it was now specifically entered in the certificate wizard.  The ‘Configured SIP Domain’ which was identified as during the setup automatically added a “sip.” record for that domain, so that record will suit our purposes.
  • Create a new DNS Host (A) record on the internal DNS server’s forward lookup zone for the desired SIP domain (e.g. and provide the same IP address which is statically assigned to the Lync Front End server.
  • Verify the new records using the following nslookup commands from the standard Windows Command Prompt.
    C:>nslookup -q=srv  SRV service location:
              priority       = 0
              weight         = 0
              port           = 5061
              svr hostname   =        internet address =


Lync Control Panel

In a major shift away from MMC-based management consoles Lync Server can only be managed by either the Silverlight-based Lync Server Control Panel or the PowerShell-based Lync Server Management Shell.
  • Launch the Lync Server Control Panel from the Microsoft Lync Server 2010 (RC) program group and re-enter the current account’s credentials. (Make sure this account has been added to the CsAdministrator domain group as covered in the Part 1 article.)
  • (Optional Step) In order to suppress the additional authentication prompt when opening the control panel then on local server go to Internet Options > Security > Local Intranet > Sites > Advanced and add the FQDN of the Lync Server to the zone (e.g.
At this point we should have a fully functional Lync Server and are ready to start configuring accounts, policies, and additional services.  Part 3 in this series moves on to enable a few user accounts for Lync Server to test client connections to the Front End server.

Lync Server 2010 Deployment

Lync Server 2010 Deployment – Part 1

Now that the general public has access to the Release Candidate software for Lync Server 2010 it is now appropriate to cover the deployment process in depth. The purpose of this article is to take a look at what the installation process actually does in order to generate a deeper understanding of the product. Not just simply follow a bunch of screenshots of the deployment wizard.

I’m starting with the Standard Edition as this is both the simpler approach and the more common deployment for testing purposes.  A host of new features and concepts have been introduced which are all available in single-server Standard Edition pool, not to mention that the required amount of individual physical hosts have been reduced thanks to improved collocation support.  So a single Windows Server can now fill the role of both a consolidated Standard Edition server and a Mediation server.  Additional roles like the Monitoring Server can also be collocated with the Standard Edition server, but a full SQL Server installation must be performed on the server prior to deploying Lync Server on it.  Previous versions of OCS Standard Edition did not support this level of co-mingling, or support anything but the default SQL Express instance.
For the purposes of this walkthrough I will start to introduce a number of PowerShell cmdlets in some of the processes, but understanding that PowerShell may still be new to many people I will utilize the deployment wizard throughout the majority of the steps.  Later on I plan to document a complete Lync Server deployment using PowerShell cmdlets at every possible step.
Much of this process is already detailed in Microsoft’s official Lync Server 2010 (RC) Lab Deployment Guide but I’ve gone into further details on many of the steps, as well as mixed up some of the order as a few of the prerequisite steps are redundant.  That document also includes configuration and deployment steps for a Director and Edge Server which I will not cover now, but will address in later articles.
Update:  This process is identical to (and has been tested with) the public release version of Lync Server 2010.


  • Physical Host: Windows Server 2008 R2 Hyper-V running on a Core2 Duo desktop-class system with 8GB RAM.
  • Domain Controller: A single Windows Server 2003 guest promoted to a domain controller for the new Active Directory forest root domain of  (Newer versions of Windows Server 2008 can be used but for the sake of saving precious RAM resources on my lab server I opted for Server 2003.)
  • Lync Server: A second virtual guest running Windows Server 2008 R2 x64 Enterprise and joined to the domain.
  • The domain account used to perform all steps is a member of the Domain Admins, Enterprise Admins, and Schema Admins domain security groups.
  • The Forest and Domain functional levels were elevated to Windows Server 2003.
  • A Windows Enterprise Certificate Authority was deployed on the DC.

Active Directory Preparation

Before we can run any of the AD preparation steps included in the deployment wizard a few server prerequisites must first be installed.  The various IIS features are not required until just prior to deploying the Lync Server components but for simplicities sake installing all features in one step is best.
  • Launch Windows PowerShell buy selecting ‘Run As Administrator’ and enter the following cmdlets to quickly install the .NET Framework 3.5.1 package, the Remote Server Administrative Tools, and all IIS7 features then perform the required server reboot. (The Telnet Client is not a requirement but I always install the feature as it is a handy troubleshooting tool. If Windows Server 2008 SP2 is used then PowerShell 2.0 will also need to be installed).
PS C:> Import-Module ServerManager
PS C:> Add-WindowsFeature NET-Framework,RSAT-ADDS,Telnet-Client,Web-Server,Web-Static-Content,Web-Default-Doc,Web-Http-Errors,Web-Http-Redirect,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Http-Logging,Web-Log-Libraries,Web-Http-Tracing,Web-Windows-Auth,Web-Client-Auth,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,Web-Scripting-Tools -Restart
  • From the installation media launch the setup wizard found at the following location:
  • At this point the setup will automatically ask to install the Microsoft Visual C++ 2008 Redistributable x64 package.  Confirm and wait for the next setup window to appear. (It may take a minute as the installation runs in silent mode, but also keep an eye on the taskbar as the installation window likes to pop-up behind other windows.  Also note that this process no longer leaves a bunch of files on the root of the drive where it is installed as the previous OCS installation used to.)
  • Accept the default Installation Location, or enter a different path, and select Install. Then accept the End User License Agreement.
C:\Program Files\Microsoft Lync Server 2010
  • From the main menu select Install Topology Builder to install the Administrator Tools on the local server.  This will install the Lync Server Management Shell which will be used to execute a few cmdlets to verify various AD preparation steps.
  • From the Deployment Wizard select Prepare Active Directory. Run Step 1: Prepare Schema and review the log to verify no errors were reported.  Verify the process using has completed successfully by checking the rangeUpper (1100) and rangeLower (14) values of the ms-RTC-SIP-SchemaVersion Schema object with adsiedit.msc.
  • Run Step 2: Prepare Forest and use the settings in the table below.  Review the results log to verify no errors were reported.
Universal Group Location Local Domain
  • Verify that the forest preparation was successful by executing the following cmdlet from the Lync Server Management Shell and looking for a response of LC_FORESTSETTINGS_STATE_READY.
PS C:> Get-CsAdForest
  • Run Step 3: Prepare Domain and review the log to verify no errors were reported.  Verify that the process was successful by executing the following cmdlet from the Lync Server Management Shell and looking for a response of LC_DOMAINSETTINGS_STATE_READY.
PS C:> Get-CsAdDomain

Server Preparation

In previous beta builds a number of prerequisite supporting installations had to be manually deployed, but in the Release Candidate we see our first glimpse of how the upcoming RTM product will smoothly handle all of these for us.
This process will install the SQL 2008 Native Client and SQL Server 2008 Express, as well as configure firewall exceptions for SQL. Mostly importantly it also deploys the first SQL Express named instance, simply called RTC.  This instance will be the default location for the Central Management Store which is where Lync will store the majority of the global (forest-wide) configuration data.  The RTC Service container in the AD Configuration partition is still used to store some data, but mainly for coexistence with previous versions of OCS.
  • From the main Deployment Wizard menu select Prepare first Standard Edition server.
Checking prerequisite WMIEnabled…prerequisite satisfied.
Checking prerequisite NoOtherVersionInstalled…prerequisite satisfied.
Checking prerequisite SupportedOS…prerequisite satisfied.
Checking prerequisite PowerShell2…prerequisite satisfied.
Checking prerequisite VCredist…prerequisite satisfied.
Checking prerequisite SqlNativeClient…installing…success
Checking prerequisite SqlBackcompat…prerequisite satisfied.
Checking prerequisite UcmaRedist…prerequisite satisfied.
Checking prerequisite SqlExpressRtc…installing…success

> Creating firewall exception for SQL instance
netsh advfirewall firewall add rule name="OCS SQL RTC Access" dir=in action=allow program="c:Program Files\Microsoft SQL Server\MSSQL10.RTC\MSSQL\Binn\sqlservr.exe" enable=yes profile=any
> Creating firewall exception for SQL Browser
netsh advfirewall firewall add rule name="SQL Browser" dir=in action=allow protocol=UDP localport=1434
  • A quick glance at the Programs and Features control panel shows all of the components which were just installed.
  • Also locate and launch the SQL Server Configuration Manager to verify the local SQL services are properly installed and running.
  • The newly installed SQL Server Express instance default database files can be found in the following default location:
  • In a slight change from previous versions of Communications Server it’s not enough to simply be logged in as a Domain Admin to fully administer the Lync Server environment.  Before moving further the domain Administrator account used throughout this process should be added as a member to the domain security groups CsAdministrator and RTCUniversalServerAdmins.
  • This user account should then logoff and back on to the Windows Server where Lync is being installed to update the associated security token.  Once logged back on use the following commands in the Windows Command Prompt to verify the new group membership:
C:> whoami /groups /fo list | findstr /i CsAdmin
Group Name: CSMVP\CSAdministrator

C:>whoami /groups /fo list | findstr /i RTCUniv
Group Name: CSMVP\RTCUniversalGlobalReadOnlyGroup
Group Name: CSMVP\RTCUniversalUserReadOnlyGroup
Group Name: CSMVP\RTCUniversalServerAdmins
Group Name: CSMVP\RTCUniversalServerReadOnlyGroup
Group Name: CSMVP\RTCUniversalGlobalWriteGroup
The final preparation step is to manually create a file share on the server which will later be referenced during the Lync Server topology configuration.
  • Create a new folder on the server named lyncshare anywhere on the server.  The following path was used in this lab deployment:
C:\Program Files\Microsoft Lync Server 2010\LyncShare
  • Configure the NTFS file security on the new  folder to grant Read & Execute permissions to Everyone.
  • Also verify that the Administrators group is already granted Full Control.
  • Then enable file sharing with the Share name of lyncshare and configure the share permissions so the administrator account used to perform the installation is granted Full Control.  A later server deployment process will customize the share and file permissions accordingly.
image     image

Topology Builder

Because the Lab Deployment Guide uses the Planning Tool and this is not required I will instead walkthrough the basic Topology Builder process.
  • Launch the Lync Server Topology Builder application found in the Microsoft Lync Server 2010 (RC) program group.
  • Select New Topology from initial prompt and save the .tbxml file with any desired name (e.g. chicago.tbxml).
  • For the Primary SIP domain enter the desired domain namespace (e.g. This does not have to be the same namespace utilized by Active Directory.  If an Exchange Server or other messaging platform exists in this forest then whatever the current primary SMTP namespace is should typically be selected as the SIP domain as well.
  • Do not add an additional supported domains at this point unless desired.  A single SIP domain is sufficient to test all of the features of Lync Server in a lab environment.
  • Define the Name (e.g. Chicago) and Description (e.g. Main Site) of the first site.  This is also a new component of Lync Server as previous versions did not include and type of site definition.  The site information will be used by many of the new resiliency features in Lync Server.
  • Provide City, State/Province, and Country/Region Code information specific to your first site.
  • Complete the topology definition and open the New Front End Wizard.
  • In the Define New Front End Pool wizard select the following options and enter the desired information specific to your own lab.  The pool FQDN should be the FQDN of the server where you will be installing the Lync Server Standard Edition server components.
Define the Front End Pool FQDN
Type Standard Edition Server

Select Features
  • Conferencing, which includes audio, video, and application sharing
  • Dial-In Conferencing
  • Enterprise Voice
  • Call Admission Control
Select Collocated Server Roles
  • Collocate A/V Conferencing Server
  • Collocate Mediation Server
Associate Server Roles with this Front End Pool
  • (Leave all options unchecked )
Define the SQL Store
  • Because this is a standard Edition installation and SQL Express has already been deployed all options are disabled.  The default RTC instance on the local server will be used.
Define the File Share
File Server FQDN
File Share lyncshare

Specify the Web Services URL
Internal Base URL
External Base URL

Specify PSTN Gateways
  • Leave these options blank for now as Enterprise Voice will be enabled in a later article.
  • Back at the main Topology Builder window select Edit Properties on the Lync Server 2010 (RC) root-level object.  Highlight the Simple URLs section and enter the desired Administrative Access URL. (Note the additional for Phone Access URLs and Meeting URLs are already configured.)
  • Also highlight the Central Management Server section and select the new Front-End server from the drop-down menu if it is not already selected.
At this point it is now time to publish the topology which will populate the RTC instance with new databases, create the folder structure in the shared directory, and publish configuration settings into the CMS and Active Directory.
  • From the Action menu select Publish Topology.  Select the local server FQDN for the Central Management Store location which should be the only option in the drop-down menu.  If all previous configuration steps were completed correctly then the wizard should complete successfully.
As indicated by the To-Do List shown under Next Steps a couple of DNS records will need to be manually created to match the FQDN set in the Lync Server topology.
  • Create new DNS Host (A) records on the internal DNS server’s forward lookup zone which matches the SIP domain used.  Each record should point to the static IP address used by the server where the Standard Edition roles will be deployed.
To validate and understand the changes the Topology Builder has applied to Active Directory there are a number of places to look throughout the various results logs, within Active Directory, and the SQL databases themselves.
  • Highlight Setting Central Management Store location… on the Publishing wizard complete window and select View Logs.  This log shows that the Set-CsConfigurationStoreLocation cmdlet was used to define the location of the CMS for all future Lync Servers to know how to locate the forest’s configuration data.
  • Use adsiedit.msc to view the Configuration context and browse to the path shown below.  View the properties on the only object in the Global Settings container to see that the supplied configuration data among the attribute values.  Also note that the whenCreated attribute should coincide with the time the topology was just published.
CN=Global Settings,CN=RTC Service,CN=Services,CN=Configuration,DC=csmvp,DC=net
  • From another computer on the network with SQL Server 2008 Management Studio Express installed the SQL Server Management Studio can be used to connect to the RTC instance on the Lync Server to view the databases.  Here we see the XDS and LIS databases created by the CMS setup.
  • The raw database files can be found on the Lync Server in the default installation directory shown below.
  • Additionally the manually defined file share is now populated with new folder structure.


At this point all organization preparation steps have been completed and the next step is to actually install the Standard Edition server components
The next article in this series jumps right into that process with Part 2.