Category Archives: Communications Server 2010
A common theme I am seeing lately is that people have setup Lync test environments, and are required to start from scratch for one reason or another. The problem is active directory is still detecting their old topology and causing issues with moving forward with the new environment.This post will cover what is required to remove references to the Lync deployment from Active Directory.
One very important thing to note here, once you extend your AD Schema, unless you revert from a backup, you will not be able to back out those changes. As a quick reference, lets go over what Lync Server 2010 does when you extend the schema.
In Office Communications Server 2007 R2, majority of configuration data was stored in Active Directory, however Lync Server 2010 stores most of the configuration data in the Central Management Store, which is a SQL database that lives on your servers in the topology. Lync Server 2010 still stores certain information in active directory including:
- Schema extensions:
- User object extensions
- Extensions for Office Communications Server 2007 and Office Communications Server 2007 R2 classes to maintain backwards compatibility with supported previous versions
- Data (stored in Lync Server extended schema and in existing schema classes):
- User SIP Uniform Resource Identifier (URI) and other user settings
- Contact objects for applications such as Response Group and Conferencing Attendant
- A pointer to the Central Management store
- Kerberos Authentication Account (an optional computer object)
Now, there are a ton of Attributes and Classes involved, because of the backwards compatibility with OCS 2007 R2, however I am simply going to cover the references to your pools, pool servers and your topology, and how to get rid of them. When the RTM documentation is released, it will have a full list of all attributes and classes.
Central Management Store References
The key change in Lync Server 2010 is the reference to the Central Management Store that is created in active directory. When you install your first server in the environment an Active Directory Service Connection Point is created in AD referencing the location of the central management store, all servers going forward pull from that reference point to identify where they should be pulling configuration data from. Once they have made that first pull, Lync Server 2010 keeps each of the local configuration stores up to date in a replication process. It’s a similar setup to Active Directory, if you think about domain controllers having a local store of data, and it replicates across all, same concept with the Lync CMS.
You can view this SCP through ADSI Edit.
Open ADSI Edit and connect to the context where your data is stored, either Configuration or System. Below I am showing System.
Expand Microsoft->RTC Service->Topology Settings
If your right click and choose Properties you will see the most important data, the server and version that is holding the CMS.
Essentially the commands below manage this entry.
There are a couple PowerShell commands that can be used to manage the CMS Connection in Active Directory.
Commands to view the status and location of the CMS
The command Get-CSManagementStoreReplicationStatus
This command can be run by itself to see the status of replication across all of the servers in your topology
You can also run this command with the switch –CentralManagementStoreStatus to view information about your central management store:
This command will give you very valuable information, for this purpose it will show you what your connection point is referencing, and in troubleshooting, you will be able to identify any issues with your CMS.
You can also do a very basic command to report on the location of the CMS.
The command Get-CSConfigurationStoreLocation
This simple command will print the CMS location in a single line.
There are a couple ways we can change where the CMS reference in AD points to, as well as to completely remove the connection point.
Modifying or Deleting the CMS Location in Active Directory
The command Move-CSManagementServer
This command will move your CMS between pools. This is useful if you have your existing CMS still online, and will be making a smooth transition to the new servers. If you do not have your old CMS server available, you will not be able to use this command unless you have a valid backup of your configuration data. These backups can be obtained by running Export-CSConfiguration and Export-CSLISConfiguration. That will backup to ZIP files, which can then be used with the Move-CSManagement store command to restore the configuration and repoint the SCP to the new pool.
The syntax for this command is pretty basic, here is the reference from the Help File:
Before you move the Central Management Server, you must do the following:
1. Verify that you have created the new Central Management store. This is d
one by running the Install-CsDatabase cmdlet and using the CentralManagemen
2. If you are moving the Central Management Server to a Standard Edition se
rver, verify that you have used local setup to run the Prepare Standard Edi
tion server option. This advance preparation is required to add firewall ru
les that will allow Windows PowerShell to remotely access the new Central M
3. Verify that there is enough free disk space on the computer where Move-C
sManagementStore is being run to accommodate the Central Management Server.
4. Verify that the Front End Server service has been installed on the compu
ter where Move-CsManagementStore is being run. If this service is not insta
lled, and running, then the move will fail.
5. Verify that you can successfully run the Enable-CsTopology cmdlet on the
computer where Move-CsManagementStore is going to be run. If Enable-CsTopo
logy cannot be run on that computer then the move will fail and you will no
longer have a functioning Central Management store.
After you have completed these steps, all you need to do to move the Centra
l Management Server from Pool A to Pool B is log on to a computer in Pool B
and then call Move-CsManagementServer without any additional parameters:
When you do that, Move-CsManagementServer will consult the topology to dete
rmine the prior location of the Central Management Server (Pool A), and th
en transfer the Central Management Server and the Central Management store
to the current pool (Pool B).
If the move succeeds, Move-CsManagementServer will display a list of comput
ers on the screen. In order to finish the move, you must run local setup on
each of these computers. Computers in Pool A will still be running an inac
tive version of the Central Management service; running local setup will de
lete that service. The computer in Pool B where the Central Management Serv
er was moved will be running the Central Management service; however, other
computers in the pool will not. Running local setup on these computers wil
l install the Central Management service.
Two important parts:
- Make sure you have properly prepared your new Front End/Pool Server prior to running this command (see documentation on setting that up)
- Login to the NEW server which will contain the CMS, open the Lync Powershell, and run Move-CSManagementServer
The command Remove-CSConfigurationStoreLocation
This command will actually remove the service control point in Active Directory that points to your Central Management Store. You can also include the parameter –Report with a file path to output a report of the activity for confirmation.
When you perform Remove-CSconfigurationStoreLocation the reference is deleted from active directory.
This step would be more common in lab scenarios where you are starting from scratch and just need a quick and dirty way to remove reference to your topology. To completely remove references to old topology objects, you will also need to remove some additional entries using ADSI Edit.
How to Remove Server Entries from AD using ADSI Edit
When you deploy a Lync topology in your environment, the servers are also references in AD. Most importantly, when you do not properly remove a server, there will be stale references to this throughout the entire RTC Service CN in Active Directory.
- I will show you how to remove references to these old servers and old pools.
- When you are looking at the tree, you will find specific references to servers and pools in Global Settings, Pools, Trusted MCUs, Trusted Services and Trusted WebComponentsServers.
You may also find old references to application contacts and conference directories if those were not properly removed. It is safe to say that you can run through each of these and remove references to your old servers if you are certain they will not be in use anymore.
Global Settings and Trusted Services
If you expand Global Settings you will see entries, the number of entries will depend on how much you have going on in your environment.
We can search for specific servers are are looking to remove by using LDP to perform queries looking for this server.
First, you must open LDP and bind to the correct DN.
Start->Run type LDP and hit enter
Select Connection choose Connect and enter a valid domain controller to connect to
Then you must Bind as a valid user, choose Connection and choose Bind, either use the currently logged in user, or specify an account with privileges.
Now we will display the Tree we will be searching through. Select View->Tree
If your information is stored in your System container, you must choose DC=domain,DC=com where domain is your domain. If it is stored in configuration you should choose CN=Configuration,DC=Domain,DC=COM
Expand down to your RTC Service container that we were viewing before in ADSI Edit
Now that we are bound and connected to the correct tree, its time to start searching. If your server is referenced in Global Settings or Trusted Services we will be looking for msRTCSIP-TrustedServerFQDN
Right Click on RTC Service and choose Search
For the filter enter the following, replacing serverfqdn with the server you wish to remove
In my example I am searching for “winx-cs2010b3.winxnet.com”
Make sure to select Subtree so it searches all trees below for this entry.
Select Run, the query should return results in the right pane with specific CNs, we will want to navigate to these Cs and delete them.
Copy these results, we will use them as a reference to delete these entries using ADSI edit.
Before deleting, review the properties of each of the CN to make sure it is a valid item to delete. Most of these are references to the individual services on those machines, which is evident from the different TrustedServicePort and ServiceType
Open ADSI Edit for each entry in your search results, navigate to the full DN, right click and choose Delete
Pools usually does not require the use of LDP as the list is so short and easy to identify. Lync identifies pools in active directory with numbers, if you have any beta pools, you may also see them referenced as Sitename:1,2,3 . As you can see in my screenshot, I have a few of each. identify the pool you want to delete, and simply right click and choose Delete
The Trusted MCUs entry is similar to Trusted Services. We will perform a LDP query for the attribute msRTCSIP-TrustedMCUFQDN
Follow the steps above for Global Settings and Trusted Services replacing msRTCSIP-TrustedServerFQDN with msRTCSIP-TrustedMCUFQDN
Your results should return three per server, because of IM/Audio/Video and Data. Copy the results and set aside.
Following the same steps above for Global Settings and Trusted Services, delete each DN that you wish to remove.
Trusted WebComponentsServers entries are created usually per front end server you put in your environment both for OCS 2007 R2 and Lync Server 2010. You can search using LDP and the attribute msRTCSIP-TrustedWebComponentsServerFQDN
Follow the same steps above to search for that attribute, and delete any DNs associated with the server you are trying to remove.
I hope this helps people understand how the central management store is referenced in active directory, and also how to do some cleanup if you did not properly remove servers from your environment. As always. open to comments about ways to improve the methods, or your own methods for performing these steps!
I am very proud to announce that I have been awarded 2010 Microsoft MVP for Communications Server!
Here is a quote from the MVP site on what this means exactly:
The Microsoft MVP Award recognizes exceptional technical community leaders from around the world who voluntarily share their high quality, real world expertise with others. Microsoft MVPs are a highly select group of experts representing technology’s best and brightest who share a deep commitment to community and a willingness to help others. Worldwide, there are over 100 million participants in technical communities; of these participants, there are fewer than 4,000 active Microsoft MVPs.
At Microsoft, we believe that technical communities enhance people’s lives and the industry’s success by providing users with the opportunity to have conversations about technology that catalyze change and innovation. Technical communities help users adopt new technologies more quickly and more effectively. Also, they help Microsoft product developers understand the "pulse" of our users and better meet our customers’ needs. As the most active, expert participants in technical communities, MVPs are recognized and awarded for their inspirational commitment to technical communities.
In order to receive the Microsoft MVP Award, MVP nominees undergo a rigorous review process. Technical community members, current MVPs, and Microsoft personnel may nominate candidates. A panel that includes MVP team members and product group teams evaluate each nominee’s technical expertise and voluntary community contributions for the past year. The panel considers the quality, quantity, and level of impact of the MVP nominee’s contributions. Active MVPs receive the same level of scrutiny as other candidates each year.
MVP Award recipients reflect Microsoft’s global customer base and the breadth of Microsoft’s technologies. MVPs have been awarded in new categories such as Windows Live, Xbox, VSTO, Microsoft Dynamics, and Visual Developer Team System. A significant portion of new MVPs represent emerging markets in China, Russia, and Korea, as well as smaller markets like Ghana, Nepal, Macedonia, and Macao.
MVPs also represent the diversity of today’s technical communities. Respecting the user’s desire to get technical information in a variety of ways, Microsoft recognizes both online and offline community contributions. Reviewers consider the contributions that nominees make to traditional communities such as public newsgroups and third-party Web sites, as well as emerging community venues such as forums and blogs.
Microsoft MVPs are an amazing group of individuals. By sharing their knowledge and experiences and providing objective feedback, MVPs help people solve problems and discover new capabilities. It gives us great pleasure to recognize and award MVPs as our way of saying thank you for their demonstrated commitment to helping others in technical communities worldwide. We sincerely appreciate their efforts. Microsoft would like to congratulate and thank this year’s MVPs.
Thanks to everyone who views my blog, and finds this information useful. More great content to come this year!
In my first blog post around TMG 2010, I outlined the setup of TMG and configuration for publishing OCS 2007 R2 web components and then CWA services through that same server. Please reference that post for the basics around the network configuration for this TMG server, and I will cover configuring publishing rules for your Lync Server Simple URLs and web components in this post.
First, I assume you have configured simple urls and web services when deploying your topology, and now need to publish this externally.
My URL information is as follows:
|Component||URL||IP Internal||IP External||Port on Front End||Port on External/ISA|
|Web Services||lyncweb.winxnet.com||10.117.117.9||220.127.116.11||8080 and 4443||80 and 443|
|Dialin Simple URL||dialin.winxnet.com||10.117.117.9||18.104.22.168||8080 and 4443||443|
|Meet Simple URL||meet.winxnet.com||10.117.117.9||22.214.171.124||8080 and 4443||443|
First off, let me point out by saying that you can use a single external IP address for all three of these URLs, as they go to the same place. Also, if you open IIS manager on your front end server, you will notice there is an internal, and an external site, the internal listens on 80 and 443, and the external on 8080 and 4443. When proxying requests through TMG, you will be sending external clients to the external site, listening on 8080 and 4443.
Also, one not so commonly known fact is that the Meet simple URL is required to provide external access to meetings. You will notice when clicking on the link to Join Online Meeting in your outlook, it is directing you to your meet simple URL.
As far as certificates go, you must also have a certificate with the following names:
Common Name: lynecwebservicesexternalurl.domain.com (lyncweb.winxnet.com
Subject Alt Name(s): meetsimpleurl.domain.com,dialinsimpleurl.domain.com(meet.winxnet.com,dialin.winxnet.com)
Import this certificate to the TMG server, and you can proceed with the following steps for configuration.
Another important thing regarding DNS:
If you have a separate internal domain name, you will need split brain DNS to get this working. You should already have split brain DNS configured to get your internal clients to work with auto signin.
For example, if your internal domain name is winxnet.local and your external is winxnet.com, your simple urls should be for the winxnet.com namespace, however you will need to resolve the winxnet.com simple URLs to the correct internal address.
At winxnet, we actually have a single namespace, winxnet.com so it was an oversight to point out the fact that you would need these DNS entries resolvable
internally and externally for this to work.
Thanks to Adam in the comments for pointing this out and working through the issue with me. Check out this link for a great review on how this DNS
configuration works for the rest of the services:
Steps to Create Publishing Rule
While in the TMG or ISA management console, Right click on Firewall Policy and choose New->Web Site Publishing Rule
Enter a name for the rule like Lync Web
Follow the wizard with the following options:
Select Rule Action : Allow
Publishing Type: Publish a single web site or load balancer
Server Connectivity Security: Use SSL to connect to the published Web server or server farm
Internal publishing details:
Internal Site Name: FQDN of front end server (winx-lyncrc1.winxnet.com)
If your internal server is a Standard Edition server, this FQDN is the Standard Edition server FQDN. If your internal server is an Enterprise pool, this FQDN is a hardware load balancer VIP that load balances the internal Web farm servers. The TMG Server must be able to resolve the FQDN to the IP address of the internal Web server. If the TMG Server is not able to resolve the FQDN to the proper IP address, you can select Use a computer name or IP address to connect to the published server, and then in the Computer name or IP address box, type the IP address of the internal Web server. If you do this, you must ensure that port 53 is open on the TMG Server and that it can reach an internal DNS server or a DNS server that resides in the perimeter network.
Path (optional): /*
Public Name Details:
Public Name: FQDN of external web services (lyncweb.winxnet.com)
Select Web Listener: Select New(This will open the new web listener wizard)
Web Listener Name: Anything you want, something like Lync Web Listener)
Client Connection Security: Require SSL secured connections with clients
Web Listener IP Address: Select External and then Select IP Address choose the appropriate IP address and add it to the listener
Listener SSL Certificates: Select Assign Certificate for Each IP Address, select the IP associated before, and choose your valid certificate.
Authentication Setting: No Authentication
Single Sign On Setting: Ignore, click Next
Complete the web listener wizard and choose Finish
Authentication Delegation: No Delegation, but client may authenticate directly
User Set: Ignore, click Next
Complete the rule configuration wizard and choose Finish. Then at the top hit Apply to save the configuration.
Once the rule is created, there are a couple important settings that need to be changed, this is really the only thing that makes the Lync setup different from OCS R2.
Open the newly created rule and modify the following settings.
On the To tab, ensure that the Forward the original host header instead of the actual one check box is checked.
On the Listener Tab, click to modify the properties of the web listener
Navigate to the Connections tab and enable port 80
On the Bridging tab, select to Redirect requests to SSL port and Redirect requests to HTTP port, enter 8080 and 4443 for your ports.
On the Public Name tab, add the Simple URLS to the list of allowed public names. In my example: meet.winxnet.com and dialin.winxnet.com.
Once these changes have been made, Apply the configuration and you are done. To verify access, you can test the following URLs in Internet Explorer.
For address book server: https://externalwebservicesfqdn/abs (https://lyncweb.winxnet.com/abs) You should receive an HTTP challenge, because directory security on the ABS folder is configured for Windows Authentication by default.
For Web conferencing: Generate an online meeting request in Outlook, or a meet now request in Lync 2010, try joining the URL provided from external, it should be similar to this: https://meet.winxnet.com/rwintle/KG2K4HDM
You should now have functioning simple URLs and web services which provide the following functionality:
- Enabling external users to download meeting content for your meetings.
- Enabling external users to expand distribution groups.
- Enabling remote users to download files from the Address Book Service.
- Accessing the Reach client
- Accessing the dial-in Web page
- Accessing the Location Information Service
- Enabling external devices to connect to Device Update Service and obtain updates.
One of the new enhanced telephony features supported in Communications Server 2010 is Call Park.
This feature allows you to “park” a call, and allow another user to pick up this call from the assigned extension. This was a common scenario on traditional PBX systems. Think of “Randy, you have a call on 12345”. I can go to any phone, dial 12345, and answer the call on hold for me.
This feature requires you to dedicate a block of numbers in your environment for call park. This set of numbers can also start with a * or #. You must also be using Communicator 2010 to retrieve a parked call. Below, I will outline how to create a basic call park number range, and how to use this feature in the communicator client.
Note: These commands and screenshots are from the Beta release of Communications Server, appearance of commands may change at release
Creating the Call park Number Range
You can create or modify call park ranges in powershell or in The communications Server Control Panel, the new silver light based control panel for Communications Server.
First, make sure you are on a machine or server with the CS 2010 Admin Tools Installed, Open the Communications Server Management Shell
For the Beta, the set of commands related to the Call Park service are:
As you can see below, in my environment when I run a Get-CsCallParkOrbit I have a number range configured as park test already in my beta deployment:
The call park number ranges have very basic information associated with them, The identity, and a set of number ranges and a server.
Lets create a new call park range with the name Winxnet Parking Lot and the number range #900-#950
This configuration would allow for me to have 50 Parked calls based on that range.
The command we are concerned with here is New-CsCallParkOrbit
Below is the cmdlet help information on this command:
Creates a new, named, range of extensions assigned for parking calls within
New-CsCallParkOrbit -Identity <XdsGlobalRelativeIdentity> -NumberRangeStart
<String> -NumberRangeEnd <String> -CallParkService <String> [-Confirm [<Sw
itchParameter>]] [-InMemory <SwitchParameter>] [-Priority <Int32>] [-Tenant
<Nullable>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]
Parking a call assigns a received phone call to a specific extension for la
ter retrieval. A call park orbit is the set of extensions defined to a spec
ific call park server for this purpose. The New-CsCallParkOrbit cmdlet defi
nes the extensions for a call park orbit and applies them to a specific a s
ervice. Calls parked within the given range will be parked on the specified
Call Park Service. Multiple call park orbits can be created; each must hav
e a globally unique name and a unique set of extensions.
For my example, this command will read:
New-CsCallParkOrbit –Identity “Winxnet Parking Lot” –NumberRangeStart “#900” –NumberRangeEnd “#950” –CallparkService winx-cs2010b3.winxnet.com
Note the number range being in quotes because I am using a # symbol.
The output should look like below:
Communications Server Control Panel
The Communications Server Control Panel is the replacement for the old MMC snapin with previous OCS Versions. This is a silverlight based web client to manage majority of Communications Server Settings.
To complete the above configuration in the UI, first open Internet Explorer and navigate to your CSCP web page:
This UI may be changing a bit, so I will just cover what is involved in creating a call park group.
In the left navigation menu, choose Voice Features
You will see in the screenshot above the Call Park Number Range I previously created using powershell.
To create a New range Select New
You will be presented with a form to enter the same information as above. The only difference is that “Destination” is the CallparkService from your power shell command.
Now that you have created a Call Park Number Range in your communications server environment, your clients should be able to place calls on park hold, and retrieve these calls.
While in a call, under the Transfer menu, you will have a new Option for Parking Lot
When you choose Parking Lot it will park the call, and notify you the call has been parked, and what number to dial to retrieve. You also have the option to Copy the text. If you copy the text it can be pasted into an IM or an Email to send to another user.
Now, in communicator I can dial the number specified in the message, to retrieve the call.
Once the call has been retrieved, the user will be notified that the call was retrieved, and the person retrieving the call will be connected to the user on the line.
The left side of the screenshot is the notice that the call was answered, and the right side is what it looked like when I retrieved the call.
This is one of the many great new functionalities coming with Communications Server 2010 later this year, to find out more please visit: http://www.microsoft.com/uc/
To learn more about CS 2010 Powershell, check out this awesome blog http://blogs.technet.com/b/csps/
I am currently investigating an issue I have internally, and have heard someone else having on the Technet forums: http://social.technet.microsoft.com/Forums/en-US/ocsconferencing/thread/f9512694-c298-4951-b6d6-0d240ccd0397
The issue is that when in a communicator conference call, you cannot send DTMF tones to a PSTN participant. The scenario is as follows:
- Communicator call, or communicator conference call is initiated
- User invites a PSTN number to that conference call
- PSTN number requires DTMF tones, whether it is a conference bridge, or an attendant menu, could be various situations
- No DTMF is received by the PSTN number.
So far, I have been able to confirm a couple of things. This happens with CS2010 as well as OCS 2007 R2. Internally we use a Dialogic DMG2120 gateway, and I have confirmed that I do not see DTMF on the gateway’s SIP side from OCS.
I am using this post to hopefully get some partners and customers to try this scenario, and see if they have the same issue. I would find it hard to believe that this is a bug in OCS/CS2010 that Microsoft has not addressed, but I am hoping to find a common configuration among people experiencing this issue so we can maybe narrow it down.
Typically this is a gateway issue, however like I said, I have not seen any DTMF come from OCS to the gateway when in the conference call.
Please respond in the comments with a brief description of your OCS setup and gateway/SIP trunk, and if you experience this issue or not.
It is identified in the above article. AVMCU does not support DTMF Relay. Thanks to the commenter!
In OCS 2007 you could configure warning messages through group policy, along with a ton of other settings, reference to which can be found here:
In CS 2010 these settings can still be applied through existing Group Policy Objects, however CS has introduced Client Policies to replace these group policy settings. These client policies come down through in-band provisioning to the communicator client.
The example I will show here is one of the most common, and that is the IM Warning.
First, login to your CS 2010 server, and open the Communications Server Management Shell
To see your client policies, and the settings associated with them type the following and hit Enter:
As you can see, there are a lot of familiar settings available in these client policies.
As you can see, the policy in my Beta deployment is just the Global Policy. These policies can be configured, and then applied on a per user basis, with the default Global Policy getting applied to users if no other policy is specified.
Now on to the example here, configuring the IM Warning.
The Powershell command to set this is:
Set-CSClientPolicy -Identity Policyname -IMWarning “IM Warning Text Here”
If you only have one policy, you do not need to specify an identity, it will default to your Global policy.
To see a full description of the Set-CsClientPolicy and New-CSClientPolicy commands in Powershell simply type:
Get-Help Set-CsClientPolicy or Get-Help New-CSClientPolicy
In my ennvironment I will be entering in:
Set-CsClientPolicy -IMWarning “Communications Server 2010 Rocks!!”
To confirm the settings have applied correctly, type Get-CsClientPolicy and hit enter.
To apply these settings to your communicator client, exit the client and restart the client.
Now, open an IM Window to confirm the warning message is displayed:
As you can see, the future of CS management is in powershell, for even the smallest things like the IM Warning.
I will cover in more detail Client Policies and Voice/Conferencing policies soon on this Blog, but this should be a good introduction to what you can do with CS Client Policies and Powershell.
Communications Server “14” or 2010 had all of its features finally announced and made public today at TechEd. Hopefully soon I will have some blog posts out on the new functionality and new configurations!