Back to Basics – Adding the Computer to an AD Group during Deployment

In this post you find guidance on using a script to add the local computer to an Active Directory group during deployment. This script has basic logging built-in, supports multiple domains, and is available on GitHub.

Note #1: While I typically would use a web service for any AD operations – either managed code, or PowerShell driven – sometimes the security team are a bit hesitant of allowing that. Even though that design by its very nature is more secure. Anyway, sometimes you need to get the work done and resort to client-side scripting. PowerShell to the rescue.

Note #2: This post also serves as an example of what you need to configure when running PowerShell scripts in the task sequence as a different user.

Update December 9, 2023: Added a section for MDT Lite Touch, the main article is for ConfigMgr.

Download the script: https://github.com/DeploymentResearch/DRFiles/blob/master/Scripts/AddComputerToADGroup/AddComputerToADGroup.ps1

Prerequisites

For the script to work you obviously need have an Active Directory group created, and you need to have a service account that has permissions to add machines to that group. In my example I created a user account named AD_SA and a global security group named ViaMonstra Computers.

Permissions

The service account used to add the computer to the group needs permission to do so in Active Directory. The account needs to have Read Members and Write Members permissions on the group, in this case on the ViaMonstra Computers group.

Addin the script to the Task Sequence

Adding the script to the task sequence is quite straightforward, and ConfigMgr offers multiple options of running scripts in a task sequence. You have the Run PowerShell Script action, or the old school Run Command Line action to choose from. Now, for a small script like this I would prefer to use the Run PowerShell Script action since it allows me to embed the script in the task sequence itself, removing the need for me to create a package, and distribute the package to all my DPs.

The fine print: Sounds pretty easy, right? Well, since I'm running a client-side script, I need to authenticate as the service account, and when doing so I will be running as a normal user account. This account will actually not have access to the location the ConfigMgr Client is storing embedded task sequence scripts. Meaning the C:\WINDOWS\TEMP\SMSTSPowerShellScripts folder. So, to fix this you need to temporarily grant the service account local admin rights, and then when the script has completed, remove the rights.

Step 1. Add a Run Command Line action, name it Add Service Account to Admin Group, and set the following command line: net localgroup administrators /add VIAMONSTRA\AD_SA

Step 2, Add a Run PowerShell Script action, name it Add Computer to AD Group, paste the script in the Enter a PowerShell script area, and add the following parameters: -GroupName 'ViaMonstra Computers'

Note: Since the group name had spaces in it, I had to surround the name with single quotes.

Set the PowerShell execution policy to Bypass, and configure the Add Computer to AD Group action to run as the VIAMONSTRA\AD_SA service account.

Step 3, Add a Run Command Line action, name it Remove Service Account from Admin Group, and set the following command line: net localgroup administrators /delete VIAMONSTRA\AD_SA

MDT Lite Touch

If using MDT Lite Touch, you have to use a slightly different command:

Powershell.exe -ExecutionPolicy Bypass -Command "New-Item -Path C:\temp -ItemType Directory -Force;Copy-Item '%SCRIPTROOT%\AddComputerToADGroup.ps1' -Destination C:\Temp; C:\Temp\AddComputerToADGroup.ps1 -GroupName 'ViaMonstra Computers'; Remove-Item C:\Temp\AddComputerToADGroup.ps1 -Force"

Troubleshooting Reference

Here is the smsts.log file showing the error you will see when running a PowerShell script as a different user that is not a local admin on the device: