First, we need to decide how to enumerate information about a remote machine... and what better way than WMI. Enter: Get-WmiObject. If you take a second to fire up your PowerShell console and run Get-Help Get-WmiObject, you should see something like this, hopefully without the red arrow.

Based on that syntax, and the conspicuous red arrow, you can see that we're able to use -computername and a string array (hence the two brackets) to connect to remote machines. The array part is important. What it means is that we're able to use -computername and a single name after, or we can use -computername and a comma-separated list of computers. We could also create an array prior to running the command at all, and pass that in.

Comma Separated List

In the screen snip below, you can see that I'm able to pass a comma separated list to Get-WmiObject to find the free disk space on each of my DCs. Pretty straightforward.

Pre-Defined Array

In this next example, I demonstrate the use of an array, stored in a variable, then passed to the Get-WmiObject cmdlet. What I've done is created a variable called $computers, then, using the array syntax, I add 4 strings to the array. Boom. A variable of type string[]. I run the Get-WmiObject cmdlet just like I did in the previous example, except after -computer (which is short for -computername, and valid to use), I pass in the $computers array.

For more on Arrays, type get-help about_arrays in your PowerShell console.

Where-Object

 At this point you can see how to connect to multiple machines using Get-WmiObject, and how to get a list of all of the physical disks. We'll use what we've done so far to make the list a bit more readable. Unless you're living in the early 90s, you probably aren't concerned about the A drive. Also, the D drive, which in this case is optical media, isn't needed on the report. Using Where-Object, we can filter out those device types, or more specifically, only include the hard disks. To do that, we simply pipe the Get-WmiObject result to Where-Object and set the condition so that we only get back DriveType 3. It looks like this:

Get-WmiObject win32_logicaldisk -computername $computers | Where-Object { $_.DriveType -eq 3 }

As you probably guessed, that'll give us only fixed disks. Try it out yourself. I'll wait.

Ultimately, you could filter on anything there. You could change it to say Where-Object { $_.FreeSpace -lt 5GB }. That will only show servers where free disk space is less than five gigabytes (Side Note: Type 5GB, or 1MB, or 1024KB in your console and see what you get!)

Pretty cool, isn't it? But, you want a report of MANY computers and you want it to readable and sortable and sendable to managementable. That's understandable. Simple!

Export-Csv

With what you've done to this point, you can use the Export-Csv cmdlet to send the results of your query off to a spreadsheet. And who doesn't like spreadsheets? We take that bolded one-liner we ran above, and tack on one more thing:

Get-WmiObject win32_logicaldisk -computername $computers | Where-Object { $_.DriveType -eq 3 } | Export-Csv C:\temp\MyDiskSpace.Csv

Now, open up that spreadsheet and what have you got? I'll tell you what you've got: Goo.

Ok, that's not totally true. When you use a cmdlet such as Export-Csv (or Format-List *, or Format-Wide *, etc) it'll output all of the properties on that PowerShell object. In our case here, we dumped out every single property on the win32_LogicalDisk object. Management won't like that. And PowerShell was just doing what you told it to do. Now let's clean it up a bit.

Select-Object

Since we're just looking at free disk space on the disks, we probably only need the computer name, the drive letter, free space, total space, and for kicks we'll throw in the volume name. Looking at the spreadsheet that was just generated makes it easy to map out those values and what the property name will be on the object in PowerShell.

• Computer Name = SystemName
• Drive Letter = DeviceID
• Volume Name = VolumeName
• Free Space = FreeSpace
• Total Space = Size

By consulting get-help export-csv -full you can see that there's a way to get only those properties in to the output. Select-Object. If we pipe the result of our filtered Get-WmiObject cmdlet to Select-Object and then export to a csv, maybe we'll get somewhere.

Get-WmiObject win32_logicaldisk -computername $computers | Where-Object { $_.DriveType -eq 3 } | Select-Object SystemName,DeviceID,VolumeName,FreeSpace,Size | Export-Csv C:\temp\MyDiskSpace.Csv

Now if we open up the resulting CSV in notepad, we get something a bit more useful. It'll be even more useful when you open it up in Excel, add some colors, and ship it off to the powers-that-be to show them exactly why you need to add 10TB to the SAN.

It's also worth mentioning that if you don't want that TYPE header in the CSV, you can add -NoTypeInformation to Export-Csv and it won't be in the CSV.

Conclusion

Based on everything I've showed you, I hope that you've got a better understanding of how to get information from a remote computer, filter that information based on certain criteria, extract just the pieces of information you need, then how to export that to a more friendly, readable CSV file, all with one line.

-Tom

In the intro post, we had a new AD domain controller in the new Contoso.com (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!

Conclusion

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. 

-Tom 

My goal with this series of posts is to outline the requirements of using the Active Directory PowerShell module, and then to show examples of different administrative tasks. By the end of the series, I hope that a reader will feel comfortable with using this module to manage their own AD environment. So let's get to it.

Requirements

• The AD PowerShell module requires a Server 2008 R2 DC in your environment, unless you follow Ashley's guide located here.
• The AD Web Services service needs to be running on at least one DC in the environment. Read more about ADWS here.

During this series, I will start with a new forest running a single Windows Server 2008 R2 domain controller. From there, I'll show how to create subnets, sites, users, groups, and more - all with PowerShell. If you don't have a test environment built, I recommend doing that before starting. You'll want a sandbox where you can add and remove objects without worrying about breaking something in production. Go ahead and build that now... I'll wait.

Ok, now that you've got your brand new test lab running a single Windows Server 2008 R2 domain controller, log on to the DC. There are a few different ways to load up the Active Directory module. The first way to load the AD Module is to click Start, go to Administrative Tools, and find "Active Directory Module for Windows PowerShell." That will start PowerShell and automatically load the module. That requires too many clicks for my liking, so I generally hit the shortcut on the taskbar and type Import-Module ActiveDirectory. It should look like this:

Now, you might see that error message. If you do, no worries. The message is telling you exactly what you think it's telling you: ADWS isn't running. Assuming you're logged on to the 2008 R2 DC, you could just use net start to start the service...but this is a series about PowerShell. To verify the state of the service, utilize the get-service cmdlet.

Running that cmdlet shows that the service is stopped. Using start-service, we can start the service, then unload and import the module again.

And now you've successfully imported the AD module for PowerShell.

Conclusion

At this point, you've got at least one Windows Server 2008 R2 domain controller running the AD web service and are successfully able to import the AD PowerShell module. If you want to verify that it's working, you can use the AD PSDrive Provider to do a quick check.

The PSDrive is just what is sounds like: A "drive" that is mapped to AD. To get to the AD PSDrive, you simply type cd AD: and hit enter. That's it. Once you're there, type get-childitem and you should see a list of all naming contexts found on that DC.

This indicates that ADWS is running, the AD module has been imported, and we're able to retrieve data from the directory. Watch for my next post when I start to describe how to build out your subnets and sites using only PowerShell.

My name is Tom Moser. I'm a Premier Field Engineer at Microsoft based out of Metro Detroit. My areas of expertise are Platforms, specifically Active Directory, and PowerShell. I've also got some experience in various areas of .NET and C#, but I hesitate to refer to myself as a developer.

I plan to update at least monthly, so stay tuned for random posts on AD, PowerShell, or whatever I happened to have learned or created that week (ok, month).