For the last few weeks I’ve been performing all the preparation work for Lync 2013 in our organization. We’ve had a very successful Lync 2010 pilot, and instead of expanding the 2010 to production, and later having to do a full environment replace for 2013, we decided to jump straight to 2013. Part of the steps, whether a fresh install or an upgrade, is some Active Directory Forest and Domain preperations. These can either be done using the installation wizard, or via PowerShell.
One of these commands is
Grant-CsOUPermission. This command is required if you don’t keep your users/servers/computers in the standard containers in AD (I.e, Users in the Users container). In our environment, we move the users into a People OU, so we needed to run the
Grant-CsOUPermission command to update some container permissions for Lync to work properly, and allow us to delegate user management. To save some time, I was executing all the commands from one domain, to one of the other child domains in the forest. This was because I didn’t have access to a 64bit machine in that environment without spending additional time spinning up a client to test with. The Lync PowerShell cmdlets allow for this, and this is what I was doing, and having issues with.
I’d first start a PowerShell prompt as a domain admin in the other domain using the
Next is to import the Lync modules:
Then the final step is to enable the domain, and grant the necessary permissions to the OUs I needed to modify.
This is where I was hitting a road block, the first command would execute just fine, but the second command would result in a permissions error.
The user is not a member of “Domain Admins or Enterprise Admins” group.
This was a weird error because I know I am a domain admin in the other domain, it wouldn’t have let me execute the
Enable-CsAdAdmin if I wasn’t, and that went fine.
After some bashing of my head, and a good nights sleep, I realized the issue when I started looking at it this morning. I’d failed to specify the domain for the
Adding the domain allowed execution. The problem here was that it was trying to bind to mychild.domain.tld and then access the OU through the link to otherchild.domain.tld. The problem here was that my account in otherchild.domain.tld didn’t have domain admin access in mychild.domain.tld, and hence the error.
So, learning lesson of the day, either execute all the commands on a server in the domain you are worknig on, or remember to specify the domain. As a side note, the Microsoft documentation is a little fuzzy around this area because it says you must sign in to a domain member on the domain you wish to execute the commands, but then specifies that you can execute the commands in a different domain. It gets a little confusing, but once you get your head wrapped around the fact that you can do this across domains, and that you must specify the domain, even if the OU hints at a different domain, things are a little easier to work with.