A while back I was migrating a pilot OCS 2007 R2 solution to a Lync production solution. After moving the users I found that they had inherited their policies regarding external access and voice from OCS. In this case I was utilizing global policies in Lync and removing the need for granting specific policies to the users.
To change this I created a simple little script to reset these policies. The script is used at your own risk.
Download it here: https://msunified.net/lyncdownloads/script-reset-userpolicies-ps1/
The Script Does the Following
- Gets all users that have an external policy set to other than $null
- For each user all policies are set to $null
- Writes the users who are changed, can be exported to csv if wanted
- Also checks if any users failed and prints their names
If you can’t change settings on some users it is probably because of permission issues on the user object in AD. To check if that is the case do the following:
- Open Active Directory Users and Computers (dsa.msc) from the Lync Front End server or any other server with ADDS
- Go to View and select Advanced Features
- Now find the user with the permission issues and select Properties
- Select the security pane and click on Advanced
- Make sure that “include inheritable permissions from this object’s parents” are checked
- If not check it and OK out of there
- Wait for AD replication and try again
This is an old Exchange AvtiveSync and OWA issue where users could not access these features. The affected users where probably a member of the below groups or have been at some point.
Found a good description of what can make this occur at: http://alanhardisty.wordpress.com/2010/03/05/activesync-not-working-on-exchange-2010-when-inherit-permissions-not-set/
The reason this happens is because Active Directory uses something called the AdminSDHolder to define what permissions the default protected security groups receive. Whilst you can change the inherited permissions, a process called SDPROP will run, by default every 60 minutes on the domain controller that holds the PDCe role. It will check the ACL of the protected groups and reset their inherited permissions and the users within the groups, with what has been defined by the AdminSDHolder object.
Microsoft’s recommendation and best practice is that if you are a domain administrator that you have 2 accounts. One for your everyday user which is restricted in the same way that every other user is and a second for your administration role.
The built in groups that are affected with Windows 2008 are:
Read-only Domain Controllers
The built in users that are affected with Windows 2008 are: