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:

Contoso.com: Empty root domain

Site 1:Child1.contoso.com

1x Std Edition Front End w/ CMS

Site2: child2.contoso.com

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!

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.