Managing Active Directory via PowerShell: Sites

Last time, I did a brief introduction on using the Active Directory PowerShell module. In this post, I will cover how you go about creating sites in Active Directory by using PowerShell.

In the intro post, we had a new AD domain controller in the new (surprise!) forest. At this point, to make a real AD forest, we would want to add some additional DCs and maybe some sites, put some subnets on those sites, then create site links to enable replication between the locations.  Let's start by adding sites.

Adding AD Sites

Normally, you'd go to AD Sites and Services and simply create the new site there. Following that, you'd edit the site link cost and replication interval, and be on your way. By default, you'd probably put the site in the default site link, or a temporary site link until you were able to create a new dedicated site link. In the next few posts, we'll do that in a little different order, and with PowerShell.

First, open up PowerShell and execute import-module ActiveDirectory to import the AD module (the AD tools need to be on the machine, or you need to be on a 2008 R2 DC). Since there isn't a cmdlet specifically for creating sites, we need to use the generic New-ADObject cmdlet. Right now, you should type get-help New-ADObject -full in PowerShell and read through the help. I'll wait.

Great, now that you've read through that, you don't need to read the rest of this post...if you're only creating a subnet, contact, or container. Based on what you saw in the help, you can see that the New-ADObject cmdlet requires a few things. First, you need to specify the type of object you'd like to create. In this first example, it's pretty simple: Site. Next, you need a name for the object. Since we're creating a site, we'll call this first one something descriptive like "HQ." Finally, you need to specify a path for the new object. You're probably thinking "But, Tom, I'm creating a site, why doesn't it go in the Sites container?"

Good question, I'm glad you asked. Since you're using a generic object creation cmdlet to create any type of object you want, you need to specify where you want to create it. A good example of this is a user. If I were using this cmdlet to add a user, I'd need to specify the OU or container where I want that user to live. The same goes for sites (Side note: You can place sites in another container if you've created a custom sitesContainer. Don't do that). I need to tell it to use the CN=Sites,CN=Configuration,DC=Contoso,DC=com path so it uses the proper container in the configuration partition.

Let's do it.

New-ADObject -type Site -name "HQ" -path "CN=Sites,CN=Configuration,DC=Contoso,DC=com"

The Result:

Well, that was anti-climactic.

But, if we follow that up with a Get-ADObject...

Solid. You've got a site. Problem: Open AD Sites and Services and compare it to your other sites. What's missing? I hope you said the Servers container and NTDS Site Settings object.

If you look in ADSIEdit at the object type for the NTDS Site Settings or Servers container under Sites in the Config partition, you'll see ntdsSiteSettings and ServersContainer as the classes, respectively. That means for the type in our command, we need to use those. Since these objects belong in the specific site container (ie, HQ), we need to use that for the path.

New-ADObject -type ServersContainer -name "Servers" -path "CN=HQ,CN=Sites,CN=Configuration,DC=Contoso,DC=Com"

New-ADObject -type ntdsSiteSettings -name "NTDS Site Settings" -path "CN=HQ,CN=Sites,CN=Configuration,DC=Contoso,DC=Com"

If you check out sites and service now, you'll see a site where you could drop a DC and you'll see the NTDS Site Settings object. If you move a DC in to the site and check properties on the NTDS Site Settings object, you should see the ISTG for the site is now your DC. Good work!


Originally, I had planned to make this post about adding sites, subnets, and site links. I felt it was more important to focus on the New-ADObject cmdlet itself instead of just "how to do it." Creating sites in PowerShell isn't something you'll do much, but it's important to understand how it works, since some of the following posts may cover things you need to do regularly or automate. In the next post, I'll go deeper on the New-ADObject cmdlet and demonstrate some techniques that will be useful anywhere in PowerShell. 


Comments (0)

Skip to main content