Consider the following scenarios.
Scenario 1
- You have a Windows Server 2012 or Windows Server 2008 R2-based domain controller that has User Account Control (UAC) enabled.
- You log on to the domain controller by using a Domain Admins user account.
- You make sure that no Windows PowerShell window is running.
- You start Active Directory Module for Windows PowerShell directly without promoting it by using administrator privilege.
- You run the Move-ADObject cmdlet to move one Active Directory object to a different container or domain. For example, you run the following cmdlet to move computer A from organizational unit 1 (ou1) to organizational unit 2 (ou2):Move-ADObject "cn=computerA,ou=ou1,dc=test,dc=com" -targetpath "ou=u2,dc=test,dc=com"
- The cmdlet fails as expected, and you receive an "Access is denied" error message.
- You keep the PowerShell window open, and then you start Active Directory Module for Windows PowerShell as an administrator to open another PowerShell window.
- You run the Move-ADObject cmdlet again.
Scenario 2
- You have a Windows Server 2012 or Windows Server 2008 R2-based domain controller that has User Account Control (UAC) enabled.
- You log on to the domain controller by using a Domain Admins user account.
- You make sure that no Windows PowerShell window is running.
- You start Active Directory Module for Windows PowerShell as an administrator.
- You run the Move-ADObject cmdlet to move one Active Directory object to a different container or domain. For example, you run the following cmdlet to move computerA from ou1 to ou2:Move-ADObject "cn=computerA,ou=ou1,dc=test,dc=com" -targetpath "ou=u2,dc=test,dc=com"
- The cmdlet finishes as expected.
- You keep the PowerShell window open, and then you start Active Directory Module for Windows PowerShell as an administrator to open another PowerShell window.
- You run the Move-ADObject cmdlet again.