Lync RBAC with Child Domains Bug- Fixed in CU2

Prior to Lync Server CU2, if you attempted to create a custom Administrator Role to a child domain, with a user scope set to that child domain it would not work. Example Provided Below: Empty root domain


1x Std Edition Front End w/ CMS


1x Std Edition Front End

Lets say we wanted to create a custom admin role that gave an administrator in the CHILD2 domain to manage his users specifically in the CHILD2 domain. Assume In this scenario you would be logged into the CHILD1 domain with full admin permission on all domains, and CSAdministrator.

The cmdlet would look like this:

New-CSAdminRole –Idenetity Child2CSUserAdministrator –UserScopes “OU:ou=Users,dc=child2,dc=contoso,dc=com” –Template CSUserAdministrator

Before Applying CU2 you would receive the following error:

Set-CSAdminRole : Organization unity (OU) or container “ou=Users,dc=child2,dc=contoso,dc=com” does not exist. Specify a valid OU or container, and then try again.

Once you apply CU2 this error would go away and you would successfully be able to create the custom Admin Role.

Another similar issue with creating or modifying admin roles to have a use OU scope, is that they are Case Sensitive! The OU must be in the exact case as is seen in Active Directory. See the screenshot below for an example, in my lab, when trying to set an admin role with “users” instead of “Users” it fails, switching to “Users” succeeds.


Hope this helps!


Posted on by Randy Wintle in Lync, Lync Server 2010, Microsoft, RBAC, Unified Communications 1 Comment

Deploying DSCP QoS On Server 2003 R2 and Server 2008 R2

This is a brief post to summarize my experiences with deploying quality of service in a recent deployment.

In this engagement, the customer had existing OCS 2007 R2 infrastructure, these were running Server 2003 R2 with the latest service pack, and were running on HP hardware with Teamed NICS for redundancy, not load balancing.

When attempting to deploy packet tagging on the servers using the QoS Packet Scheduler and related policies, packets would not tag at all. When breaking the NIC Team packets would tag, and on any servers without a teamed NIC the same policies worked fine. This was identified as a known issue with 2003 R2 and Teamed NICS.

The good news, is that while we are upgrading to Lync Server 2010 their new servers are running Server 2008 R2 and on similar hardware with Teamed NICS. As of today we have tested QoS deployed using the packet scheduler and related policies and it does work with the Team.


Posted on by Randy Wintle in Lync, Lync Server 2010, Microsoft, Networking, OCS 2007 R2, Unified Communications Leave a comment

Deploying a Lync SBA? Watch out for port 444 (Updated with more ports)

As Lync deployments start ramping up, we are starting to notice a few gotchas in documentation and deployments. One thing that has come up a couple of times is deploying a Lync SBA in a branch site with a firewall between the Datacenter and branch office.

The firewall ports required for the SBA are not well documented, particularly one that is very important to making the SBA Work.

Port 444 TCP is required for front end to SBA communications, below is the only documentation I have found on it so far in the CHM.

Front End Servers

Front-End service




Used for HTTPS communication between the Focus (the Lync Server component that manages conference state) and the individual servers.

This port is also used for TCP communication between Front End Servers and Survivable Branch Appliances.


I reviewed the Lync 2010 Workloads Poster and it is not showing this port as well. However, I have requested an update which we will hopefully see soon.

So, very important, open port 444 TCP between your Data Center and your Branch Office or users will not be able to register against the SBA. Reference of the ports can be seen below.



As a follow up, one of my colleagues pulled together the full list of firewall requirements for branch users. As many enterprises have firewalls between branch and central sites, this list becomes very important. Look for a workloads poster focused on firewalls from Microsoft soon, but hopefully this comes by then. Credit for this list goes to Peter Pawlak at UnifySquare:

SBA (ASM side) <-> Central Site Pool(s):

· TCP/5061 (both ways)

· TCP/444 (both ways)

· TCP/445

· TCP/448

· TCP/5062-5065

· TCP/5072-5073

· TCP/5076

· TCP/5080

(NOTE: I’m not 100% positive that ports in RED are really needed)

SBA -> Monitoring Server(s) (to support MSMQ)

· TCP/135

· TCP/389

· TCP/1801

· TCP/2101

· TCP/2103

· TCP/2105

SBA (ASM side) <-> Exchange UM servers

· TCP/5061

· UDP/<ExUM media port range>

SBA (ASM side) <-> Edge Server(s):

· TCP/5061

· TCP/5062

CMS servers -> SBA (ASM side) (for local config store replication)

· TCP/4443

· TCP/444

· TCP/445

Branch Clients -> SBA (ASM side):

· TCP/5061 (client->SBA)


· UDP/<media port range> (assumes no media bypass)

Branch Clients <-> SBA (GW side):

· UDP/<media port range> (assumes media bypass will be used)

Branch Clients -> Central site Pool (must be pool in site associated with Branch site)

· TCP/8057 (and TCP/8058 if using Lync’s legacy data conf service)

· TCP/5061 (to allow failover to backup central site)

· TCP/<app share conf MCU port range>

· UDP/<A/V conf MCU port range>

Branch Clients -> Central site Pool Web service HLB VIP (pool in site associated with Branch site)

· TCP/443

· TCP/80 (needed by Lync PE devices)

Branch clients <-> Clients & Mediation servers/services in other sites

· UDP/ <media port range>

· TCP/<media port range>

Branch clients <-> Edge servers (running media relay)

· UDP/3478

· UDP/ <media port range>

· TCP/443

· TCP/<media port range>

Branch clients -> Exchange UM servers

· UDP/<ExUM media port range>

Branch clients -> Exchange CAS servers (for EWS)

· TCP/443


Posted on by Randy Wintle in Lync, Microsoft, Networking, Unified Communications 8 Comments

Using OCS 2007 R2 CWA with Lync Server 2010

At this time, there are going to be a few scenarios where you may need to deploy the R2 version of Communicator Web Access with Lync Server 2010. The core reason here, is that the RTM Version of Lync Server 2010 contains a feature on the front end called Lync Web App. Eventually, Lync Web App will become a full featured web client, however, today it is only used for users to join online meetings from the web. There is no ability to access Lync Web App from a URL and sign-in, or use it as a instant messaging too. This is planned to be released SP1 of the product, that timeframe is unknown right now.

To fill this gap, customers will have to deploy the OCS 2007 R2 CWA role, which can register against a Lync Server 2010 Pool. This post will show you how to configure OCS 2007 R2 CWA to work in your Lync Server 2010 environment.


Preparing the Environment

The most important piece of information in this blog, is that the Schema Prep for OCS 2007 R2 must be run in the environment before the Lync Server 2010 Schema Prep, or you will not be able to install the R2 version of CWA. If this is a deployment where there have not been prior installs of OCS 2007 R2, you will need to obtain this media, and run that Schema Prep before your Lync deployment starts, so it is very important to plan for this in your design/planning phase of your project.

Also, to get straight to the point for this blog, I am going to assume you have prepared the schema in the correct order, have your Lync Server 2010 environment online, and have already installed the CWA Role on a server. I will walk through creating the virtual directory, as well as integrating it with your Lync environment.

Use this Deployment Guide to install and configure the CWA role

Creating the OCS 2007 R2 Virtual Web Server

One you have the CWA role installed, and a valid certificate installed on the server, you must configure the virtual web server that clients will access.

I will walk you through the process for creating an External web server, however the same process applies for the Internal web server. The difference being the types of authentication allowed, external allows forms, where as internal also allows NTLM authentication.

Login to your R2 CWA server, and open the Communicator Web Access Admin Console


Once in the admin console, right click on your server and choose Create Virtual Web Server


Navigate through the setup wizard, choose only your Web Server Type, in my case I am choosing External. Make sure to select a valid HTTPS certificate when prompted.

When you get to this section, Specify IP Address and Port it is important to note that this is the IP and listening port for your web server, not the communication between Lync and your CWA server, we will get to that next.


After entering a description for your virtual web server, the most important part of this wizard is the Specify a Listening Port section. This port defines what this application will listen on, and communicate with your Lync front end on. Because of the change in ports between OCS R2 and Lync, previously used values like 5070, or 5071 as you will see in older blog posts of mine do not work. You must pick a port that is not being used by an application currently. For my example I am using 4790.This can be any port, as long as your Lync front end and this server can communicate on that port.


Next, define your next hop pool, choose the appropriate Lync pool as your next hop and leave the port to default 5061.


Complete the wizard and start the virtual server.

Your settings should look similar to this


Now that you have completed this, you will need to make Lync aware of this server.

As you will find in the OCS 2007 R2 to Lync Server 2010 Migration Guide, you must merge your Legacy (OCS 2007 R2 components in to your Lync Topology.

Configuring Lync Server 2010

Now that we have our CWA server configured, we must make the Lync topology aware of this server. To do so, we will merge the legacy topology in to our Lync topology. This is possible through PowerShell using the Merge-CSLegacyTopology cmdlet, however I will be using the GUI.

Before completing this task, you must install the OCS WMI Backwards Compatibility tool, this can be found on the install media, called ocswmibc.msi

First, navigate to your Lync front end and open the Topology Builder.

If you already have coexistence with a R2 environment you will be very familiar with this process, and you will also see the BackCompatSite listed.


Right click where it says Lync Server 2010 and choose Merge 2007 or 2007 R2 Topology


In this post, I am assuming there are no R2 pools, and we are just importing the CWA server and web site. Because of that, you will actually leave the wizard blank when it asks for servers. This wizard will connect to servers in your environment and pull configuration data out of WMI, and input them into this BackCompatSite that will reside on the CMS. This is the major change from OCS 2007 R2 to Lync, is what used to be in WMI, is now in the CMS. You can find plenty of resources to get into more detail about that on Nexthop.




Verify the setting selected in the wizard, and choose Next to merge your legacy topology.

Everything should complete, choose Finish and you will now see your new site.


Expand BackCompatSite and expand TrustedApplicationServers for this blog post, we are concerned only with the trusted application servers, this is where your CWA, and other R2 server roles like group chat will appear.


Once you have verified that your R2 CWA server appears correctly, right click where it says Lync Server 2010 and choose Publish Topology.



Once you have published your topology, we will have one last step to verify our web server was imported correctly.

Open the Lync Server Management Shell and run the following command: Get-CSTrustedApplication

This command will return trusted applications that are associated with Trusted Application Servers and Trusted Application Pools in your environment, you may have many depending on your topology. However the two we are looking for, involve CWA.

Your output should return something similar to below:


I have crossed out my server names, however there should be the FQDN of your CWA server where I have marked.

The two entries represent the external facing web site that users hit, as well as the port that is used to communicate with the Lync front end, as you can see highlighted below, the port you assigned should be listed there.


You should now be able to login to CWA as a Lync Server 2010 user! If you run into issues, make sure to check out this blog relating to the SPN error related to CWA service accounts in R2.

Also, make sure that your CWA server is on the latest release of OCS 2007 R2 patches which can be found here:


I hope this helps you extend CWA capability to your Lync users, if you have any issues please contact me via the comments and I will try to help you the best I can.


Posted on by Randy Wintle in CWA, Lync, Lync RC, Microsoft, OCS, OCS 2007 R2, Reach Client, Unified Communications 39 Comments

Error When Installing UM Role on Exchange 2010 SP1

11/12/2010 12:31:24.0997] [2] Active Directory session settings for ‘install-umservice’ are: View Entire Forest: ‘True’, Configuration Domain Controller: domaincontrollerfqdn, Preferred Global Catalog: “domaincontrollerfqdn”, Preferred Domain Controllers: ‘{ domaincontrollerfqdn }’
[11/12/2010 12:31:24.0997] [2] Beginning processing install-UMService
[11/12/2010 12:31:26.0012] [2] [WARNING] An unexpected error has occurred and a Watson dump is being generated: There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[11/12/2010 12:31:26.0012] [2] [ERROR] There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[11/12/2010 12:31:27.0668] [1] The following 1 error(s) occurred during task execution:
[11/12/2010 12:31:27.0668] [1] 0.  ErrorRecord: There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[11/12/2010 12:31:27.0668] [1] 0.  ErrorRecord: System.Runtime.InteropServices.COMException (0x800706D9): There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
   at Interop.NetFw.INetFwRules.Add(NetFwRule rule)
   at Microsoft.Exchange.Security.WindowsFirewall.ExchangeFirewallRule.Add()
   at Microsoft.Exchange.Configuration.Tasks.ManageService.Install()
   at Microsoft.Exchange.Management.Tasks.UM.InstallUMService.InternalProcessRecord()
   at Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()


When running the wizard to add the UM role to your Exchange 2010 Sp1 server, you may have this error appear in the install wizard:

ErrorRecord: System.Runtime.InteropServices.COMException (0x800706D9): There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)

If you take a look at the Exchange setup log, it is trying to add firewall rules, and fails, and kills the install. If your windows firewall service is not running, you must start it.  Re run the installation with windows firewall running, and all is fine Smile


Posted on by Randy Wintle in Enterprise Voice, Exchange 2010, Exchange UM, Lync, Microsoft, OCS 2007 R2, Server 2008 R2, Unified Communications 5 Comments

Powershell Script to create new user, enable for Exchange, UM and Lync Server

I created this powershell for our internal onboarding process, figured I would share it with the masses.

I think there are a couple good takeways from this script, it remotes into Exchange 2010 and Lync Server 2010 Powershell sessions, so nothing except Powershell 2.0 is required on the client side, which is standard with Windows 7. It also shows how you can simultaneously use Exchange and Lync powershell commands in the same script to get things done.

A couple of disclaimers:

I am in no way advanced at powershell scripting, so nothing fancy here.

This was developed specifically for my internal needs, you will probably have to add/remove variables and requirements.


Script is above, any freedback is appreciated, if you improve on this at all, I would love to see it as well.


Posted on by Randy Wintle in Enterprise Voice, Exchange 2007, Exchange 2010, Exchange UM, Lync, Lync RC, Microsoft, OCS, OCS 2007 R2, Unified Communications 12 Comments

OCS 2007 R2 Cumulative Updates- September 2010

So, if you recall, the July updates were pulled due to some issues with response groups. Today, the OCS team has released two September updates, one for the Response group, and one for web components.

Check this link here for all information and download links for the updates.


Posted on by Randy Wintle in Microsoft, OCS 2007 R2, Unified Communications Leave a comment

OCS 2007 R2 Cumulative Updates- September 2010

So, if you recall, the July updates were pulled due to some issues with response groups. Today, the OCS team has released two September updates, one for the Response group, and one for web components.

Check this link here for all information and download links for the updates.


Posted on by Randy Wintle in Microsoft, OCS 2007 R2, Unified Communications Leave a comment

Reference: Setting Event Log Levels for Exchange UM

Exchange 2007 and Exchange 2010 allow you to configure different event logging levels for all Exchange services.

I commonly have to enable more detailed Exchange UM logging on UM servers to troubleshoot call flow issues, so here is a quick reference of how to do this.

First off, here is the technet reference to doing this for all services:

In Exchange 2007, you must do this through Powershell, Exchange 2010 however is available right in the Exchange MMC.

For Exchange 2007:

Start by opening your Exchange Management Shell

The following powershell commands are required for the Exchange UM services

set-eventloglevel -identity “MSExchange Unified MessagingUMWorkerProcess” -level Expert
set-eventloglevel -identity “MSExchange Unified MessagingUMCore” -level Expert
set-eventloglevel -identity “MSExchange Unified MessagingUMManagement” -level Expert
set-eventloglevel -identity “MSExchange Unified MessagingUMService” -level Expert
set-eventloglevel -identity “MSExchange Unified MessagingUMClientAccess” -level Expert
set-eventloglevel -identity “MSExchange Unified MessagingUMCallData” -level Expert

In Exchange 2010 the same powershell commands will work, however, if you are more comfortable with the UI, you can do it directly in the Exchange MMC.
First open the Exchange Management Console
Expand your On-Premise Organization and select Server Configuration

Select your UM server from the list of available servers, and you will notice on the right hand side, under Actions for that server you will have Manage Diagnostic Logging Properties

Select Manage Diagnostic Logging Properties and you will be prompted with a full list of services on your Exchange server to manage. Expand MSExchange Unified Messaging, for each service you wish to raise the level, select that service, and then select the option for whatever level you wish to enable. Expert is typically a good level to have if dealing with UM.
Once you have configured all of your service levels, choose configure. This will basically execute the Powershell commands listed above and confirm Completion.


Posted on by Randy Wintle in Exchange 2007, Exchange UM, Microsoft, Unified Communications 1 Comment

Install the OCS Enterprise Edition Backend Database in Separate Forest

So the title of this post sounds kind of crazy, and you may be asking yourself, WHY???

Well, internally we have two networks and two separate forests connected over a gigabit fiber link. These locations are in two separate buildings in the city. One is in our office, and one is in our hosted data center.

Without diving too deep into our network setup, the point is, we have a SQL server in our office that is currently being decommissioned, and it holds the OCS R2 Enterprise Pool backend. In our data center, we have a very nice SQL 2008 server to move all the databases to.

To sum things up, this does indeed work, at least in our situation. It is important to note that it is not supported nor recommended as I have only tested basic functionality, and done no performance testing. Also, we have a full two way trust between these forests, so permissions were not an issue.

In the end, we decided not to do it because we rely too heavily on OCS as our complete UC platform, and did not want to risk any performance issues.

If this is something you absolutely must do, it does in fact work.


Posted on by Randy Wintle in Microsoft, OCS 2007 R2, Server 2008 R2, Unified Communications Leave a comment