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

Task sequence with steps added.

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"
An MDT Lite Touch Task Sequence configured to run the script.

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:

About the author

Johan Arwidmark

5 3 votes
Article Rating
Subscribe
Notify of
guest
14 Comments
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
Ben
Ben
4 months ago

The script is not consistent for me and mostly fails. I see this in the SMSTS.log: Process completed with exit code 1 Retrieving the COM class factory for component with CLSID {00000000-0000-0000-0000-000000000000} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)). PowerShell command line returned code 1 Process completed with exit code 1 ….and the machine does not get added to the group I assume this happens because we are using a RUN-AS account and it is trying to access the TS environment and fails: $TSEnv = New-Object -ComObject Microsoft.SMS.TSEnvironment -ErrorAction SilentlyContinue Any way… Read more »

Ben
Ben
4 months ago

Thanks for the response. I can confirm that the service account gets added to local admin before the script runs, and that account has the required AD permissions. If I login with the account and run the script it works as expected, but does not work in the the task sequence. I will try and capture the exception to see why it exits in the TS with an error code 1. I can see the log file in C:\Windows\Temp, so it must be exited on the main part of the script where it has the exception and exit of 1

Last edited 4 months ago by Ben
Ben
Ben
4 months ago

I think I've found the issue. It was installing this after a sub task sequence full of apps, and if I removed that sub task sequence it works. This has security related software in and I can only assume that it was interfering with script running successfully, so I've moved the script before it installs any apps.

Khro
Khro
4 months ago

Hello,
I tried your script with MDT, with "Run command line" :
Powershell.exe -ExecutionPolicy Bypass -File "%SCRIPTROOT%\AddComputerToADGroup.ps1" -GroupMember "mygroup" with the another user's checkbox checked.
Unfortunately, the script doesn't run. I see warning mentionning " is not digitally signed. You cannot run this script on the current system.".

Running manually with the account used in the "Run Command Line" the command Powershell.exe -ExecutionPolicy Bypass -File "%SCRIPTROOT%\AddComputerToADGroup.ps1" -GroupMember "mygroup" with %SCRIPTROOT% replaced is working.

Do you know how to solve it ? Thanks a lot for your work.

Last edited 4 months ago by Khro
Khro
Khro
4 months ago

Hello, i'm only using MDT with "Run Command Line", Powershell.exe -ExecutionPolicy Bypass -File "%SCRIPTROOT%\AddComputerToADGroup.ps1" -GroupMember "mygroup" ;
with the another user's checkbox checked with credentials.
When i run this script as this user, it's working, but not with MDT. Looks like -Bypass isn't working

Ali
Ali
1 year ago

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&nbsp;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 »

Ali
Ali
10 months ago

Yes, it was a copy-paste error from the browser.

steyrs
1 year ago

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 »

Arnaud
Arnaud
1 year ago

Thank you very much Johan, fortunately you shared this article ! I was looking for a fix since this morning.

Last edited 1 year ago by Arnaud
Matt
Matt
1 year ago

Thanks Johan, for your dedicated supports and efforts.

matt


>