In this post you learn how to configure your ConfigMgr task sequence to add a machine to a collection during deployment via the ConfigMgr AdminService. You will setup a service account, grant the minimal permissions for a service account in ConfigMgr, and then use a PowerShell script in the task sequence to trigger the ConfigMgr AdminService (administration service) to add the machine to the collection.
Update November 5, 2023: Worked with Adam Gross (last weekend) to fix an issue when running in environments using username and password. Adam created a Johan edition of the PowerShell module that works in full OS deployment task sequences. Thanks Adam!
Credits: Big thanks to the following Community Champions: To Adam Gross (again) for his amazing ConfigMgr.AdminService PowerShell module, and to Nickolaj Andersen and Maurice Daly for a solution to the below error message that you may encounter when trying to use the ConfigMgr Admin Service:
System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.Authenticati
onException: The remote certificate is invalid according to the validation procedure.
at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
Creating the Device Collection
First, you need to have a device collection to which you want to add the computer account. In my lab the device collection was named Co-Management Clients. I use this collection to only have a subset of my machines being enrolled into Intune by ConfigMgr. Meaning that the Automatic enrollment in Intune feature is set to Pilot in the Co-Management Properties.
Real World Note: When configuring these settings in ConfigMgr, you will find that ConfigMgr deploys a set of internal configuration policies to that collection. These are used for the enrollment process.

Creating the Service Account
In Active Directory, create a domain user account, and configure its password to never expire. I named my service account CM_OSD, and gave it the following description: CM Service Account – Add Computer to Collection.

Creating the Security Role in ConfigMgr
To ensure the service account cannot do more in ConfigMgr than it should, I created a custom security role named Add to Collection that only had access to modify resources for a given collection. For simplicity I made a copy of the built-in Read-only Analyst security role, and allowed modification of collections by changing the following permissions to Yes under Collection:
- Modify
- Modify Resource
Note: You probably don't want the service account to manage all collections, so you will select the specific collection when adding the service account as an administrative user in ConfigMgr.
Adding the Service Account as an Administrative User in ConfigMgr
Using the ConfigMgr console, in Administrative Users, add the CM_OSD service account, and assign it the Add to Collection security role.
Note: Don't remove the default All Systems collection. Machines that you deploy will be created in this collection, and you need permissions to read those devices in order for adding them to another collection.

Creating a Package with the ConfigMgr.AdminService PowerShell module
Download the ConfigMgr.AdminService PowerShell module from this URL: https://github.com/AdamGrossTX/ConfigMgr.AdminService/tree/JohanEdition
Then run the build.ps1 script to create a folder with the PowerShell module.
Make a note of the output path from the build.ps1 script, and copy the content of that folder to a folder where you keep your data sources for ConfigMgr. In my example, I copied the module to a folder on a DFS Share: \\corp.viamonstra.com\fs1\Sources\OSD\Modules\ConfigMgr.AdminService.

Add the below script to the root of the package, name the script Add-ComputerToCollection.ps1.
<#
.SYNOPSIS
Script to add the local computer to a specified collection.
.DESCRIPTION
This script will use the ConfigMgr.AdminService from Adam Gross to add the local compouter to a collection via the ConfigMgr Admin Service.
.PARAMETER CollectionName
The ConfigMgr collection to add the computer to
.PARAMETER SMSProvider
The SMS Provider on which the ConfigMgr AdminService is installed. Typically the site server.
.EXAMPLE
.\Add-ComputerToCollection.ps1 -CollectionName "Co-Management Clients" -SMSProvider "cm01.corp.viamonstra.com"
.NOTES
FileName: Add-ComputerToCollection.ps1
Author: Johan Arwidmark
Contact: @jarwidmark
Created: 09/25/2023
Updated: 09/25/2023
Version history:
1.0.0 - 09/25/2023 - Script created
#>
param(
[Parameter(Mandatory)]
[string]$CollectionName,
[Parameter(Mandatory)]
[string]$SMSProvider
)
$Logfile = "C:\Windows\Temp\AddComputerToCollection.log"
# Delete any existing logfile if it exists
If (Test-Path $Logfile){Remove-Item $Logfile -Force -ErrorAction SilentlyContinue -Confirm:$false}
Function Write-Log{
param (
[Parameter(Mandatory = $true)]
[string]$Message
)
$TimeGenerated = $(Get-Date -UFormat "%D %T")
$Line = "$TimeGenerated : $Message"
Add-Content -Value $Line -Path $LogFile -Encoding Ascii
}
Write-Log "Starting Add-ComputerToCollection.ps1"
$ComputerName = "$env:COMPUTERNAME"
Write-Log "Computer name is: $ComputerName"
Write-Log "Collection name is: $CollectionName"
Write-Log "SMS Provider is: $SMSProvider"
Write-Log "Importing ConfigMgr.AdminService PowerShell module"
Import-Module "$PSScriptRoot\ConfigMgr.AdminService.psd1"
# For testing
# $CollectionName = 'Co-Management Clients'
# $SMSProvider = 'cm01.corp.viamonstra.com'
# Import-Module "C:\Temp\ConfigMgr.AdminService\ConfigMgr.AdminService.psd1"
# Get Credentials from task sequence variables
$TSEnv = New-Object -ComObject Microsoft.SMS.TSEnvironment
$username = $TSEnv.Value("OSDAddToCollectionUserName")
$password = ConvertTo-SecureString $TSEnv.Value("OSDAddToCollectionPassword") -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential($username, $password)
Write-Log "Username set to $username"
Write-Log "Password set to ***Secret***"
# Initialize CMAdminService
Write-Log "about to run the Initialize-CMAdminService function"
Try {
Initialize-CMAdminService -AdminServiceProviderURL "https://$SMSProvider/AdminService" -UseLocalAuth -LocalAuthCreds $credential -ErrorAction Stop
}
Catch {
$errorMessage = $_.Exception.Message
write-Log "Initialize-CMAdminService Failed, error message: $errorMessage"
}
# Add Computer to Collection, try for up to 10 minutes
$MaxRetries = 10
$i = 1
do {
Write-Log "Searching for the $ComputerName device in ConfigMgr, Attempt $i of $MaxRetries"
Try {
$Device = Get-CMDevice -Name $ComputerName
}
Catch {
$errorMessage = $_.Exception.Message
write-Log "Get-CMDevice failed, error message: $errorMessage"
}
If ($Device){
$DeviceCount = ($Device | Measure-Object).Count
If ($DeviceCount -eq 1){
$SelectedDevice = $Device
Write-Log "One Device found matching the $ComputerName computer name having Resource ID: $($SelectedDevice.MachineId)"
}
Else {
Write-Log "$DeviceCount Device(s) found matching the $ComputerName computer name, selecting the first match"
$SelectedDevice = $Device | Select -First 1
Write-Log "Selected Device matching the $ComputerName computer name having Resource ID: $($SelectedDevice.MachineId)"
}
# Check wether its a real Resource ID and not a discovery record
If (([string]$SelectedDevice.MachineId).substring(0,1) -eq 1){
Write-Log "Adding $ComputerName to the $CollectionName collection"
Try {
$CMDirectRule = New-CMDirectRule -InputObject $SelectedDevice -RuleName $ComputerName -ErrorAction Stop
$Collection = Get-CMCollection -Name $CollectionName
Add-CMCollectionRule -Collection $Collection -CollectionRule $CMDirectRule -ErrorAction Stop
}
Catch {
$errorMessage = $_.Exception.Message
write-Log "Adding Computer to Collection Failed (New-CMDirectRule,Get-CMCollection and Add-CMCollectionRule commands), error message: $errorMessage"
}
# Exit the loop
Break
}
}
Else{
Write-Log "Device not found in ConfigMgr, retrying to find $ComputerName. Attempt $i of $MaxRetries"
Start-sleep -Seconds 60
}
$i++
}
while ($i -le $MaxRetries)
You should now have a folder structure looking like this:

Create a ConfigMgr Legacy Package using the preceding content as its data source. No program needed. I named my package Add Computer To Collection via AdminService.
Configuring your Task Sequence(s)
1. In the Windows phase of your task sequence, typically near the end, add a new group named Add Computer To Collection via AdminService. In that group, add the following actions:
2. Add a Set Dynamic Variables action named Set Add To Collection Variables. Add the OSDAddToCollectionUserName and OSDAddToCollectionPassword variables to match your environment.
3. Add a a Run PowerShell Script action. Configure it with the following settings:
- Name: Disable Provisioning Mode
- Enter a PowerShell script: (use below script
Invoke-WmiMethod -Namespace root\CCM -Class SMS_Client -Name SetClientProvisioningMode -ArgumentList $false
- PowerShell execution policy: Bypass
4. Add a Run Command Line action. Configure it with the following settings:
- Name: Pause for 5 Minutes
- Command line: powershell.exe -Command Start-Sleep -Seconds 300
4. Add a Run PowerShell Script action. Configure it with the following settings:
- Name: Add Computer To Collection
- Package: Select the Add Computer To Collection via AdminService.
- Script name: Add-ComputerToCollection.ps1
- Parameters: -CollectionName "Co-Management Clients" -SMSProvider "cm01.corp.viamonstra.com"
- PowerShell execution policy: Bypass

Dear Johan,
This was working with Windows 11 24h2 When I used this with Windows 11 25H2 its not working
Should not matter if it's Windows 24H2 or Windows 25H2. Did you by any chance update ConfigMgr? CM 2509 removed NTLM authenticate from the admin service, and you have to use UPN (Kerberos)
When it comes Configmgr yes its 2509 but the strange things is it works with the collections that created before 2509 or it may be with OS
I will check the OS and Old collection , will update the result
Ca fonctionne parfaitement merci bien.
Pour la collection il faut pas mettre de caractères speciaux sinon ca va pas marcher.
I had to translate that to English, but I appreciate it, and yes, stay away from using special character.
Add-ComputerToCollection.ps1 failed in OSD, i double checked all values, variables etc. what could be wrong ? (continue)
Add-ComputerToCollection.ps1 failed in OSD, i double checked all values, variables etc. what could be wrong ?
It looks like it didn't import the module. Try launching a PowerShell prompt via ServiceUI.exe, so you can troubleshoot interactively while the TS is running. See this post: https://www.deploymentresearch.com/troubleshooting-cm2012-task-sequence-actions-using-serviceui/
I'm also having issues with getting this to work. From the bit of troubleshooting I've done, it appears to be a problem either with the dot-sourcing not importing the functions correctly, or with the module not exporting the cmdlets. I don't have a lot of experience troubleshooting PS modules, so it's hard to get much further than that.
Does it work if you run the script in full Windows on a device?
Same thing, it seems. It fails to recognize Initialize-CMAdminService as a cmdlet, then it fails on Get-CMDevice with the same message.
Here's what the output of Get-Module looks like after running the Add-ComputerToCollection.ps1 script in a TS environment running in full Windows.
Which CM version is this? In ConfigMgr 2509, Microsoft removed NTLM as authentication method for call to the AdminService. The workaround is switch to UPN for the account.
Customer is still on 2503, but I can try switching to UPN to see if that helps.
Thank you Johan for this solution to speed the process up. Tested this, and works just fine.
However, how are you dealing with delays after that? The machine requires to run the machine policy the retrieve the CoMgmtPilot configurations and the client is still dependent on the configuration baselines to run.
This leaves my device in a partly co-managed state in the beginning (Intune saying "See ConfigMgr), until everything is completely processed.
You can run policy refreshes after the TS is completed, via the SMSTSPostAction task, or via a scheduled task that the TS creates
great article, does the service account need any membership access?
Thanks, and the account needs to have permissions specified in the post.
does it require any specific permissions in AD?as i'm getting access errors , everything is set up correctly in the console
Nothing is required in AD (other than the user account). To verify the service account can add a computer to a collection, open the ConfigMgr console as that service account, and add a resource from the All Systems collection to it.
Hi Johan,
Thanks a lot for this helpful guidance!
Is there also a way to remove machines out of a collection via the ConfigMgr AdminService?
Regards
Uli
I don't think Adam's module has one, but here is a deletemembershiprules WMI method you can try calling.
Do you have a example of the WMI method, or where can I research it?
I don't, but Adam wrote about the process a while back: https://www.asquaredozen.com/2019/11/29/configmgr-adminservice-and-wmi-methods-a-match-made-in-the-cloud-1910/
Hrmm… I can't seem to get this to work. when running the import command manually on a machine, it looks like it import it. I don't see it in a "get-installedmodule" list, and none of the commands are recognized.
Try adding a -verbose to the import-module command.
verbose shows the modules being exported but commands still not recognized. I went back and checked to make sure i had the current version (it looks like there was an update at some point after MMS) and everything looked correct. Im using the Johan version.
It sure sounds like you didn't run the build.ps1 script, or is not importing the module that was built. I made a short video: https://www.youtube.com/watch?v=gh1q4n8vl4g
Does the module only work on a system that ran the build.ps1? I built the module and then copied the files to the network share.
No, it works fine on other devices too. I just tested by copying the ConfigMgr.AdminService folder from the bin\release folder after building it to a freshly deployed Windows 10 machine.
Does this work with Windows 11? I really want this to work. Ill have to rebuild and see if something is missing.
It works fine in Windows 11, I just deployed a fresh Windows 11 23H2 and ran some tests. Here is the script I used for testing: https://github.com/DeploymentResearch/DRFiles/blob/master/Scripts/ConfigMgr/Test-ConfigMgrAdminServiceModule.ps1
This is really helpful, thanks a lot!
Is it possible to have a workaround having the User Password in plain text in the Task Sequence (even if only Admins have access to the Task Sequence)?
Maybe with a "Run PowerShell Script" step with option "Run this step as the following account"
Hi David,
The run-as option for the script turned out not to be working great with the admin service calls. We tried that first. However, when adding hidden variables in the TS, they are not stored or visible in clear text.
Thanks for all the work on this. No matter how I configure the task sequence, the AddcomputertoCollection.log always returns "Initialize-CMAdminService failed: The term 'Initialize-CMAdminService' is not recognized" and "Get-CMDevice failed, error message: The term 'get-CMDevice' is not recognized…"
I don't see an error about importing Configmgr.AdminService powershell module.
Thanks for any advice.
Try adding some extra logging around the import line in the script, for example, test for the existence of the module in the script path.
Re-download the files from https://github.com/AdamGrossTX/ConfigMgr.AdminService/tree/JohanEdition
You most likely snagged the files from the main tree (https://github.com/AdamGrossTX/ConfigMgr.AdminService/tree/main) which the Initialize-CMAdminService function on that tree does NOT have a parameter for LocalAuthCreds.
Ask me how I know 🙂
Hello Adam,
Thanks for your work on this. I followed the steps provided for use in one of our SCCM OSD task sequences. However, it's failing because none of the commands are recognized (when checking the log).
Is there some sort of pre-req required that I'm missing?
There are no real prerequisites. Does it work if you run the script on a machine you already deployed? (logged in as the service account).
Thanks for this! Is there any reason why steps 2 and 3 were separated out instead of included in the main powershell script? Seems it would be cleaner and use fewer steps
Only to make it slightly easier to see which account is used and update the password if needed. Either will work. Credentials stored in variables are also slightly better protected since they are not shown in real text. The PowerShell scripts are downloaded as a simple base64 hash.
Apologies, I meant steps 3 and 4 – disabling provisioning and the sleep command. Seems to me both of those can be rolled into the beginning of the script in step 5.
I fully agree with using the variables to keep the username/password hidden.
Ah, yes, that would work great. I like to see when I have a pause or a different action, but that's just a preference.
Hi Johan,
Great article / solution to adding a PC to a collection during the TS. Thanks!
During your testing, did you ever have the error of "error creating the web proxy specified in the 'system.net/defaultproxy' configuration section" when trying to run the script?
I haven't been able to get it working due to that error
I also had to give the domain service account local admin permissions temporarily to get that far.
Yes, if running the script as a separate user, it must be temporarily granted admin permissions (or copy the script somewhere else). However, I worked with Adam during the weekend to develop a more reliable way of calling the script in a full OS deployment task sequence. What happened was that the separate user account specified via runas was not used during a full OS TS. Adam made a special module version for full OS task sequences, and I updated the script to take a username/password as task sequence variables instead. Blog post updated.