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.
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

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:

I have a lots of errors in the smsts.log At C:\Windows\TEMP\SMSTSPowerShellScripts\{424DE257-2F7C-4677-8330-D00D5E8D3FE7}.PS1:209 char:17 RunPowerShellScript 2023. 03. 10. 13:50:24 4056 (0x0FD8) + Sign up RunPowerShellScript 2023. 03. 10. 13:50:24 4056 (0x0FD8) + ~ RunPowerShellScript 2023. 03. 10. 13:50:24 4056 (0x0FD8) The ampersand (&) character is not allowed. The & operator is reserved for future use; wrap an amp RunPowerShellScript 2023. 03. 10. 13:50:24 4056 (0x0FD8) ersand in double quotation marks ("&") to pass it as part of a string. RunPowerShellScript 2023. 03. 10. 13:50:24 4056 (0x0FD8) At C:\Windows\TEMP\SMSTSPowerShellScripts\{424DE257-2F7C-4677-8330-D00D5E8D3FE7}.PS1:214 char:209 RunPowerShellScript 2023. 03. 10. 13:50:24 4056 (0x0FD8) + … k Button–medium Button d-lg-none color-fg-inherit p-1"> <span cla … RunPowerShellScript 2023. 03. 10. 13:50:24 4056 (0x0FD8) + ~ RunPowerShellScript 2023. 03. 10. 13:50:24 4056 (0x0FD8) The '<' operator is reserved for future use. RunPowerShellScript 2023.… Read more »
Sounds like a copy and paste issue of sorts. Does it work if you run it in full Windows via PowerShell ISE or VS Code?
Yes, it was a copy-paste error from the browser.
Thank a bunch for sharing this Johan. Implemented this in our organization – and it works like a charm! Note to anyone who stumbles upon this. Beware that when you get to this step: net localgroup administrators that it is language specific. For instance we deploy Windows 10/11 with danish language, and I had to change it to net localgroup administratorer to make it work. If you deploy another language than English – then check on a client – in a command prompt: net localgroup That will list the local groups and with the proper names to be used. Just… Read more »
Thank you very much Johan, fortunately you shared this article ! I was looking for a fix since this morning.
Thanks Johan, for your dedicated supports and efforts.
matt