Create and Manage Users and Groups in Active Directory
- 6/29/2015
- Create users
- Create and manage groups
- Create and manage OUs
- Summary
Create and manage OUs
Organizational units, or OUs, are used to segregate groups of users, computers, or other objects in Active Directory without the overhead of creating a whole new domain for them. You can apply different group policies to different OUs and have different password requirements.
Create an OU
Use the New-ADOrganizationalUnit cmdlet to create a new OU. The cmdlet parameters can be used to set commonly used properties of OUs, such as DisplayName, Description, and ProtectedFromAccidentalDeletion. The only required parameter is the Name parameter.
For properties that aren’t covered by the cmdlet parameters shown in Table 3-2, use the OtherAttributes parameter. The OtherAttributes parameter accepts a hashtable with property name and property value pairs.
Table 3-2 The parameters of New-ADOrganizationalUnit
Parameter |
Type |
Name |
String |
City |
String |
Country |
String |
Credential |
PSCredential |
Description |
String |
DisplayName |
String |
Instance |
ADOrganizationalUnit |
ManagedBy |
ADPrincipal |
OtherAttributes |
Hashtable |
PassThru |
Toggle |
Path |
String |
PostalCode |
String |
ProtectedFromAccidentalDeletion |
Boolean |
Server |
String |
State |
String |
StreetAddress |
String |
Name |
String |
There are three basic ways to use New-ADOrganizationalUnit:
- Create an OU by specifying all details on the command line.
- Create an OU from a template object—either one you create or an existing OU.
- Use a CSV file to create multiple OUs from a list of OUs and properties.
To create a new Engineering OU for our TreyResearch.net domain, use the following command.
New-ADOrganizationalUnit -Name Engineering `
-Description 'Engineering department users and computers’ `
-DisplayName 'Engineering Department’ `
-ProtectedFromAccidentalDeletion $True `
-Path “DC=TreyResearch,DC=NET” `
-PassThru
Note that the path specified is actually the default path, so we could have skipped that parameter, and the same is true for the ProtectedFromAccidentalDeletion parameter, which defaults to True. Because we used the -PassThru parameter, the command returned the following.
City :
Country :
DistinguishedName : OU=Engineering,DC=TreyResearch,DC=NET
LinkedGroupPolicyObjects : {}
ManagedBy :
Name : Engineering
ObjectClass : organizationalUnit
ObjectGUID : c2b42af8-a80b-48c1-949d-c8dbd6d60ee9
PostalCode :
State :
StreetAddress :
And, as we can tell in Figure 3-4, the new Engineering OU is created in the root of the TreyResearch.net domain tree.
)
Figure 3-4 The TreyResearch.net domain, showing the new Engineering OU
Add computers and users to an OU
Now that we have an Engineering OU, we should move our engineering users and computers into that OU. You might expect that there would be a Move-ADUser cmdlet, but there isn’t, and you might even quite reasonably expect that you could use Set-ADUser with a Path parameter to do the job. But no, there isn’t a Path parameter and you can’t move users that way either. After poking around a bit, however, it occurred to me to use Windows PowerShell to help me find the solution.
Get-Command -Module ActiveDirectory -Verb Move | ft -auto CommandType,Name
CommandType Name ----------- ---- Cmdlet Move-ADDirectoryServer Cmdlet Move-ADDirectoryServerOperationMasterRole Cmdlet Move-ADObject
Well, I don’t want to move the directory server, nor the Flexible Single Master Operation (FSMO) roles, at least not right now, so those won’t help. But users and computers are just a form of Active Directory object, so that last item looks promising. Let’s find out what its syntax is.
syntax Move-ADObject
Syntax for Move-ADObject is: Move-ADObject [-Identity] <ADObject> [-TargetPath] <string> [-WhatIf] [-Confirm] [-AuthType ADAuthType>] [-Credential <pscredential>] [-Partition <string>] [-PassThru] [-Server <string>] [-TargetServer <string>] [<CommonParameters>]
That looks like it should do what we want. We need to specify the identity of the object we want to move, and the target path we want to move it to. And it supports a WhatIf parameter to make sure it’s going to do what we expect. So, I remember that one of my users is an engineering manager, but which one? Well, let’s find out.
Get-ADUser -Filter {Description -like “*Engineering*” }
DistinguishedName : CN=Harold Catz,CN=Users,DC=TreyResearch,DC=net Enabled : True GivenName : Harold Name : Harold Catz ObjectClass : user ObjectGUID : 944bb855-0342-4875-a8d2-8447ab6f93e5 SamAccountName : Harold SID : S-1-5-21-910751839-3601328731-670513855-1133 Surname : Catz UserPrincipalName : Harold
Ah, yes, Harold. Of course. So, now that we know who we want to move, let’s verify where we want to move him to.
Get-ADOrganizationalUnit -Filter {Name -eq “Engineering” }
City :
Country :
DistinguishedName : OU=Engineering,DC=TreyResearch,DC=net
LinkedGroupPolicyObjects : {}
ManagedBy :
Name : Engineering
ObjectClass : organizationalUnit
ObjectGUID : c2b42af8-a80b-48c1-949d-c8dbd6d60ee9
PostalCode :
State :
StreetAddress :
The Distinguished Name is the target path for our move, so let’s check that we’ve got everything as we want it.
Get-ADUser -Filter {Description -like “*Engineering*” } | Move-ADObject `
-TargetPath (Get-ADOrganizationalUnit -Filter {Name -eq “Engineering” }) `
-WhatIf
What if: Performing the operation “Move” on target “CN=Harold Catz,CN=Users,DC=TreyResearch,DC=net”.
That looks like we’re moving Harold, which was the plan, so we remove the WhatIf, and issue the command again.
Get-ADUser -Filter {Description -like “*Engineering*” } | Move-ADObject `
-TargetPath (Get-ADOrganizationalUnit -Filter {Name -eq “Engineering” })
Oops, we forgot to include the -PassThru parameter, so our move happened silently. No problem, let’s just verify that the user Harold is in the correct OU.
Get-ADUser -Identity Harold
DistinguishedName : CN=Harold Catz,OU=Engineering,DC=TreyResearch,DC=net Enabled : True GivenName : Harold Name : Harold Catz ObjectClass : user ObjectGUID : 944bb855-0342-4875-a8d2-8447ab6f93e5 SamAccountName : Harold SID : S-1-5-21-910751839-3601328731-670513855-1133 Surname : Catz UserPrincipalName : Harold
And the DistinguishedName property shows that he is in the Engineering OU. Good. Now, let’s just move Harold’s desktop over to the same OU. A quick check finds that TREY-DESK-22 is assigned to Harold.
Get-ADComputer -Filter {Description -like “*Harold*” }
DistinguishedName : CN=TREY-DESK-22,CN=Computers,DC=TreyResearch,DC=net DNSHostName : trey-desk-22.TreyResearch.net Enabled : True Name : TREY-DESK-22 ObjectClass : computer ObjectGUID : 46df71bd-ba88-4b26-9091-b8db6e07261a SamAccountName : TREY-DESK-22$ SID : S-1-5-21-910751839-3601328731-670513855-1141 UserPrincipalName :
Looks like Harold only has one computer, so let’s do it by simply specifying the identity of the computer we want to move. Move-ADObject accepts the DN or the GUID for the Identity parameter, or the result of Get-ADUser, Get-ADGroup, Get-ADComputer, Get-ADServiceAccount, Get-ADOrganizationalUnit, or Get-ADFineGrainedPasswordPolicy. We’ve got both the DN and the GUID in the output from your Get-ADComputer, so after a bit of copy and paste we get the following.
Move-ADObject -Identity “46df71bd-ba88-4b26-9091-b8db6e07261a” `
-TargetPath “ OU=Engineering,DC=TreyResearch,DC=net” `
-PassThru
DistinguishedName Name ObjectClass ObjectGUID ----------------- ---- ----------- ---------- CN=TREY-DESK-22, OU=Engine... TREY-DESK-22 computer 46df71bd-ba88-4b26-9091- b8db6e07261a
Even though we only moved a single computer and a single user, the same methods can be used to move hundreds or even thousands of users. Of course, making a mistake when moving one user is a nuisance, for both you and the user, but it’s fairly easily corrected. Making a mistake by moving thousands of users is still easily corrected but is likely to cause somewhat more annoyance. Therefore, always check your work before committing to large changes that will affect many users.