I have noticed a few odd behaviors with PowerShell’s ActiveDirectory module, one regarding the msDS-UserPasswordExpiryTimeComputed attribute of the Get-ADUser cmdlet, and another regarding the New-ADServiceAccount cmdlet.
On a brand new Server 2008 R2 domain, the following command returns values for only a small percentage of the accounts in the domain but the vast majority of accounts return with no value.
Get-ADUser -filter * -Properties “msDS-UserPasswordExpiryTimeComputed” | ft name, “msDS-UserPasswordExpiryTimeComputed” –AutoSize
Also on this domain, issuing the following command often results in an “Access is denied” error, but not always. In fact, typically if I receive the error and then leave my RDP session to the computer open for 30 to 60 minutes and try command again (hit the Up Arrow key on the keyboard), the command runs without error.
New-ADServiceAccount svc_test
This seems to indicate a general problem with the ActiveDirectory PowerShell module.
The following article pointed me in the right direction for a workaround.
http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2general/thread/5947c0eb-9549-4161-afa1-edb451fc742f
The problem appears to be a bug in the way the ActiveDirectory module behaves when User Account Control (UAC) is enabled. The workaround is to disable UAC, which requires a reboot. When UAC is left enabled, even when PowerShell is run with elevated permissions, the problem still occurs.
I’ve confirmed the experiences above both on domain controllers and on member servers, and in two different Active Directory forests.
One reply on “ActiveDirectory module and UAC”
As an update to this issue, Microsoft has acknowledged the problem for Server 2008 R2 as well as Server 2012, and released a patch for each platform. Both are discussed here:
http://support.microsoft.com/kb/2806748
I installed the update on a Server 2012 domain controller, but it appears to have had no impact on the problem, even with UAC disabled. I have not tested the patch on Server 2008 R2.