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.

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.

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
6 Comments
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
Ali
Ali
8 months 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
6 months ago

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

steyrs
9 months 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
11 months ago

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

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

Thanks Johan, for your dedicated supports and efforts.

matt


>