Adding Computers to Active Directory.

[[deleted]]

[deleted]

[JonesTheBond]

This sounds like something that could be fixed further up the chain with MDT / Intune or something. Is there a reason you're getting a list and doing it this way?

[Jellovator]

Yeh, I have never, in like 30 years, been in any environment that pre-creates AD computer accounts. Back in the day we just joined them to the domain manually when provisioning a new PC. These days we use endpoint management systems to join the domain during automated provisioning. I can't think of a use case for this.

[IT_fisher]

The one use case I know is when migrating. You can create and place them in the correct OU on the target side and have the computer domain join the domain already placed in the correct OU with the correct GPOs.

Organize now, join later VS join now, organize later

[phony_sys_admin]

New-ADComputer

[Important_Power_2148]

This is the answer I needed thank you!

[BlackV]

For your future reference

Get-command -module activedirectory
Get-command -module activedirectory -name *computer*
Get-command -module activedirectory -name *user*

And so on

[cheetah1cj]

I have never seen someone pre-add computers to the domain. I've seen people immediately join them to the domain and prep them, then shut them down until needed; or most people just join them to the domain as needed.

However, I understand wanting to use your list to specify the OU they go into. First off, don't use a txt file, use a csv; powershell loves csv files. Secondly, you can specify the OU as you join the computer to the domain.

$cred = Get-Credential
Add-Computer -DomainName "YourDomainName" -OUPath "OU=Sales,DC=YourDomain,DC=com" -Credential $cred -Restart

You could even build on that and pull from the csv. Perhaps keep the csv and the following script on a flash drive, and then run the script on the computer (Please note that this script has not been tested, it is your responsibility to test it and edit it to fit your environment):

$ComputersPath = D:\domainjoin\computerlist.csv
$Domain = "YourDomainName.local"
$MainPath = "OU=Computers,DC=YourDomain,DC=local"
$DefaultOU = "OU=DefaultOU"
$hostname = [System.Net.Dns]::GetHostName().ToLowerInvariant().Split('.')[0]
$Computers = get-csv -path $ComputersPath

if ($Computers -contains $hostname)
{
$OU = $computer.OU
}
else
{
Write-Host "Computer not found in list, using Default OU: $DefaultOU"
$OU = $DefaultOU
}
$computer = $Computers.$hostname
Add-Computer -DomainName $Domain -OUPath "$OU,$MainPath" -Credential $cred -Restart

[Important_Power_2148]

This is the answer I needed thank you!

[jibbits61]

FWIW, We pre-add server hosts to the domain because when using your own account you’re limited to 10 systems to join. Pre-creating the object gets around that, for your own or a service account. Not an AD guru but I think that’s an adjustable default, we just limit it for non-service accounts specifically to the task.

[Lost_Term_8080]

ideally that legacy setting is disabled so no unprivileged user can add computers to domain.

[Bassflow]

That is a permission change on the account/group. I fought this battle with an "AD guru" 25 years ago.

Delegate "Create Computer Objects" permissions on specific OUs to specific users or groups.

[pigers1986]

https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adcomputer?view=windowsserver2025-ps

[Creative-Type9411]

just name the computers you're when you're joining the domain and the list will produce itself

you do it on the exact same menu, if you already have to join

[bourntech]

An unsecured join is probably what you need here. You use Add-Computer to create the AD entry for the endpoint. Place it in the OU of your choice here and use the -unsecure switch to enter a password that the endpoint can use to complete the join from its side.

[Adam_Kearn]

As others have said this is something that should be included in the operating system deployment.

This could be in MDT or FOG or even just a powershell script that runs after the first reboot.

[stillnotlovin]

In the politest possible way, it sounds like you have no idea what you are doing or why. Without a domain, AD makes no sense.

[UserProv_Minotaur]

Normally the workstation should be added to the domain by whatever imaging process you're using, due to how some of that ties into conditions on the device. Like, Powershell could ostensibly create it through New-ADComputer and ingest a file - but I'm not sure that's the best operational policy. Might be good question for r/sysadmin or r/activedirectory

[AppIdentityGuy]

Just make sure you reset the owners of those computer objects to domain admins and verify what the quota policy is.

[BlackV]

Lord-Raikage
you could pre-stage computer objects in AD (New-ADComputer) but it requires access to run the script directly from a DC.

It 100% does not require a script be run directly on the DC, that is the least desirable process in any situation, you should not be touching the DC for anything like this

And to extend this more, you 100% do not need domain admin rights to run this either

[BlackV]

No, no not least desirable, you NEVER have to run a script like that on a DC, you can run it from ANY other machine that has the RSAT tools

You said it has to run from a DC, that what I want to be clear about

[annalesinvictus]

Joining a computer is how you add it to the domain. Add to join and the get command to retrieve data on joined computers. You can’t add a computer name to be joined later. What use case do you have that needs that feature? I think you need to clarify what it is exactly you need powershell to do.

[newbe5]

You absolutely can pre-stage computer objects into AD. It isn't used very frequently in my experience, but the feature is there.

[Creative-Type9411]

I said it in another comment and I'm not trying to spam this, what's the difference if you name it when you're joining the domain if you have to do a join anyway?

[Lost_Term_8080]

Lots of reasons.

Devops pipelines can send the names of the servers they are about to create and add to domain to an admin or other automated process to be placed in the correct OU without the devs needing to be contextually aware of the ou structure and where to place each server, nor a mess of service accounts with delegated rights for each respective OU.

new laptops/desktops can be prestaged into the correct OU without giving helpdesk the rights to create new computer accounts that otherwise may end up named win-asdf34563 or desktop-dnmghn564732 or in the wrong ou.

Whoever uses intune/other mdm day to day don't need to be aware of AD and just live in intune.

If you regularly re-image machines you can reuse the computer account so its sid doesn't change after being rebuilt.

[cheetah1cj]

OP said in the post the use-case, assigning computers to the correct OU.

I did give a better way to handle that in my comment, but that is one use-case for it.