Moving Computers to another OU during deployment – Webservice style

Here is a step-by-step guide to configure a MDT Lite Touch or ConfigMgr task sequence to move a computer to another OU during deployment. The webservice used in this guide does the same job as Maik Koster's version available here: http://maikkoster.com/moving-computers-in-active-directory-during-mdt-deployments-step-by-step but I have include the C# source code for my version, so you can review, or modify it if you want to.

Note: In the guide I'm using a MDT Lite Touch task sequence, but this works great in ConfigMgr task sequences too. Just add the same actions there 🙂

Update October 20, 2022: Added instructions on using group Managed Service Account (gMSA)

Download the Webservice and sample script

The AD Webservice used in this post is available in compiled format here: https://deploymentresearch.com/DRFiles/ADWebService.zip

If you rather want to check out the source code, and/or compile yourself (C#, Visual Studio 2015), go here: http://github.com/arwidmark/AD-Webservice

The script that actually calls the webservice in the task sequence: https://deploymentresearch.com/DRFiles/ZTIMoveComputer.zip

Scenario #1 – Refreshing or Upgrading Computers

When using MDT or ConfigMgr for OSD, if you are refreshing or upgrading existing computers (keeping the same computer name), it does not really matter what value you assign to the MachineObjectOU variable, the solutions on their own are not going to move the computer to a new OU. That's simply how AD works, the computer account, again when keeping the name, is going to stay in the current OU.

But, by adding a Webservice, you can easily have the task sequence move the computer object to a new OU, even when the computer name is the same.

Scenario #2 – Using a Staging OU

Having group policies breaking your MDT Lite Touch deployment? Continue reading, here is the fix 🙂

When deploying machines with MDT, unlike when using ConfigMgr, the task sequence does not suppress group policy processing, and sometimes you have group policies (admin account renames, or company policy notifications), that simply breaks the MDT task sequence. The best way to work around that is to use a staging OU. Just create an OU to which you don't link the policies, and in the in end of the task sequence, call a web service that moves the computer to the real OU.

Step 1 – Install IIS and the webservice

The first step is to install IIS on your MDT server, or whatever server you want to use, and install the webservice

In this example my MDT server is named MDT01, and I'm using the VIAMONSTRA\MDT_WS service account to run the web service, and I have created two OU's:

ViaMonstra / Staging
ViaMonstra / Workstations

The Staging OU does not have any policies linked to it, and the VIAMONSTRA\MDT_WS has the needed permissions to manage computer objects in those OUs. For a script that sets the correct permissions, check this post: https://deploymentresearch.com/353/PowerShell-Script-to-set-permissions-in-Active-Directory-for-OSD

1. On MDT01, install IIS and some needed components by using the following PowerShell script:

$ServicesToInstall = @(
    "Web-Windows-Auth",
    "Web-ISAPI-Ext",
    "Web-Metabase",
    "Web-WMI",
    "NET-Framework-Features",
    "Web-Asp-Net",
    "Web-Asp-Net45",
    "NET-HTTP-Activation",
    "NET-Non-HTTP-Activ",
    "Web-Static-Content",
    "Web-Default-Doc",
    "Web-Dir-Browsing",
    "Web-Http-Errors",
    "Web-Http-Redirect",
    "Web-App-Dev",
    "Web-Net-Ext",
    "Web-Net-Ext45",
    "Web-ISAPI-Filter",
    "Web-Health",
    "Web-Http-Logging",
    "Web-Log-Libraries",
    "Web-Request-Monitor",
    "Web-HTTP-Tracing",
    "Web-Security",
    "Web-Filtering",
    "Web-Performance",
    "Web-Stat-Compression",
    "Web-Mgmt-Console",
    "Web-Scripting-Tools",
    "Web-Mgmt-Compat"
    )
 
Install-WindowsFeature -Name $ServicesToInstall -IncludeManagementTools

2. On your MDT server, create the ViaMonstraWebServices folder, I used the E: drive in my environment, and grant the VIAMONSTRA\MDT_WS service account modify permissions to the E:\ViaMonstraWebServices folder.

3. Download the webservice from this link, https://deploymentresearch.com/DRFiles/ADWebService.zip and extract the content to the E:\ViaMonstraWebServices folder.

4. Modify the E:ViaMonstraWebServices\ADWebService\Web.config file with your domain (FQDN) and the webservice service account and password.

5. Create the E:\ViaMonstraWebServices\Tracing folder, for the webservice log file.

6. Using Internet Information Services (IIS) Manager, expand Sites, right-click Default Web Site, and select Add Application. Use the following settings for the application:

Alias: ADWebService
Application pool: Default
Physical Path: E:\ViaMonstraWebServices\ADWebService

Note: If running other IIS applications on the MDT server, you may want to create a separate application pool for the web service.

7. Using Computer Management, add the VIAMONSTRA\MDT_WS service account to the local IIS_IUSRS group.

8. Test the MoveComputerToOU function by adding a computer to the Staging OU, and then navigating to http://MDT01/ADWebService/ad.asmx, and use the MoveComputerToOU method to move it to another OU. In the below example, I tested with moving PC0025 to the OU=Workstations,OU=ViaMonstra,DC=corp,DC=viamonstra,DC=com OU

If the move was successful, you should see the following:

Step 2 – Add script, configure Rules and modify Task Sequence

Once you verified that the web service works, you need to add the sample script, configure the CustomSettings.ini file with the needed variables, as well as instructing the task sequence to to the job.

1. Download the ZTIMoveComputer.wsf script from here: https://deploymentresearch.com/DRFiles/ZTIMoveComputer.zip and extract it to your Scripts folder in your deployment share.

2. Add the following info to your CustomSettings.ini file.

[Settings]
Priority=Default
Properties=StagingOU, FinalOU
 
[Default]
JoinDomain=corp.viamonstra.com
DomainAdmin=VIAMONSTRA\MDT_JD    
DomainAdminPassword=P@ssw0rd
StagingOU=ou=Staging,ou=viamonstra,dc=corp,dc=viamonstra,dc=com
FinalOU=ou=Workstations,ou=viamonstra,dc=corp,dc=viamonstra,dc=com<br>FinishAction=REBOOT

[MoveComputerToOU]
WebService=http://MDT01/ADWebService/ad.asmx/MoveComputerToOU
Parameters=OSDComputerName, MachineObjectOU

In the MDT task sequence, add a Set Task Sequence Variable action after the first Gather local only action with the following settings

Name: Set Staging OU
Task Sequence Variable: MachineObjectOU
Value: %StagingOU%

4. In the very end of the task sequence, create a new group named Move Computer to OU and add two actions in it.

The first action is a Set Task Sequence Variable action with the following settings

Name: Set Final Target OU
Task Sequence Variable: MachineObjectOU
Value: %FinalOU%

The second action is a Run Command Line action with the following settings:

Name: Move Computer to Final Target OU
Command line: cscript.exe "%SCRIPTROOT%\ZTIMoveComputer.wsf"

Using a group Managed Service Account (gMSA)

If you want to use a group Managed Service Account (gMSA) instead of a normal service account, you simply need to configure the application pool to use that as an identity instead. Don't forget to add the $ in the end of the account, and also make sure to remove the identity impersonate line from the web.config file.

Below are some PowerShell commands you can use to create and install group Managed Service Accounts. In this example my site server was in the ConfigMgr Site Servers group.

# For lab only, make the key available quickly
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))    

# On DC01, create the account
w-ADServiceAccount -Name gMSA_WS -PrincipalsAllowedToRetrieveManagedPassword "Domain Controllers", "Domain Admins", "ConfigMgr Site Servers" -DNSHostName gMSA_WS.corp.viamonstra.com -KerberosEncryptionType AES256 -Path "OU=Service Accounts,OU=ViaMonstra,DC=corp,DC=viamonstra,DC=com"

# On the target server (CM01), install and test the account
Add-WindowsFeature RSAT-AD-PowerShell
Install-ADServiceAccount -Identity gMSA_WS
Test-ADServiceAccount gMSA_WS

Troubleshooting

If you run into any issues, check the ZTIMoveComputer.log on the client, and the E:\ViaMonstraWebServices\Tracing\ADWebService.log on the MDT01 server. Here is an example where the service account, VIAMONSTRA\MDT_WS in my case, didn't have permissions on the OU's in Active Directory: Unhandled exception finding provider namespace on server System.UnauthorizedAccessException: Access is denied.

Another example of permissions error is the following, which doesn't appear to be a permission error at all, but it really was: Unhandled exception finding provider namespace on server System.DirectoryServices.DirectoryServicesCOMException (0x80072032): An invalid dn syntax has been specified.

Happy Deployment, Johan