{"id":1486,"date":"2014-06-19T01:41:38","date_gmt":"2014-06-19T01:41:38","guid":{"rendered":"http:\/\/microsoftgeek.com\/?p=1486"},"modified":"2014-06-19T01:41:38","modified_gmt":"2014-06-19T01:41:38","slug":"managing-active-directory-with-powershell","status":"publish","type":"post","link":"https:\/\/microsoftgeek.com\/?p=1486","title":{"rendered":"Managing Active Directory with PowerShell"},"content":{"rendered":"

Introduction<\/strong><\/h2>\n

There\u2019s no question that PowerShell is here to stay as an automation tool for Windows. And with it, comes a variety of ways to automate management Windows infrastructure. For sure one of the most important areas where PowerShell automation can provide big benefit, is in the management of Active Directory. AD lends itself to automation\u2014whether it\u2019s being able to create a bunch of users from a text file list, or add users to groups, or modify the \u201cdepartment name\u201d on a set of users\u2014PowerShell provides a relatively easy way to make those tasks quick and easy. In this article, I\u2019ll walk through how you can get started using PowerShell to manage AD, and provide examples of some of the common tasks you can perform.<\/p>\n

What Do I Need?<\/strong><\/h2>\n

The first thing you need to get started is a PowerShell \u201cmodule\u201d that provides the cmdlets, or units of function, for managing AD. Of course, Microsoft provided an AD PowerShell module, starting with Windows Server 2008-R2 and Windows. Using this module requires something called the Active Directory Web Services (ADWS) service be running on at least one DC in the AD domain that you plan to manage. If your DCs are running Server 2008-R2 or above, then you are good to go\u2014the ADWS is installed by default on these. If you are running an earlier version of Windows Server, like 2008 or 2003, as your domain controllers, you can install a standalone version of the ADWS so that you can use the cmdlets against these environments. The download is available\u00a0here<\/a>.<\/p>\n

Once you have ADWS running on at least one DC, then you\u2019re ready to get and use the PowerShell AD module. You\u2019re going to need at least Windows 7 or Server 2008-R2 in order to install the cmdlets. If you are using a client Operating System, like Windows 7, or a non-DC Windows Server version, the AD module comes as part of the Remote Server Administration Tools (RSAT) download available on the Microsoft download center. Once you install the RSAT tools, go into the Control Panel, Program and Features applet, and select \u201cTurn Windows Features on or off\u201d and scroll down to the RSAT section. Under \u201cRole Administration Tools\u201d, expand the \u201cAD DS & AD LDS Tools\u201d node and select the \u201cActive Directory Module for Windows PowerShell\u201d checkbox, as shown in Figure 1, and then press OK. The install will then install the AD module.<\/p>\n

\"Image\"
\nFigure 1:<\/strong>\u00a0Installing the AD Module from RSAT<\/p>\n

Note that the AD module is already installed by default on a Server 2008-R2 or above Domain Controller, so you don\u2019t need to perform this step if you\u2019re working from your DCs.<\/p>\n

Finally, I will mention that while the Microsoft AD module is a good one, and the one I\u2019ll talk about in this article, it is by no means the only offering in this space. Long before Microsoft released their AD module, Quest Software had created a set of cmdlets for managing AD from PowerShell. This set of cmdlets is different than the Microsoft one, but it also works without ADWS and Windows 7 or above as a pre-requisite. You can download these cmdlets for free\u00a0here<\/a>.<\/p>\n

Using the Cmdlets<\/strong><\/h2>\n

The first thing you\u2019ll need to do to use the cmdlets, is to load up the AD module into your PowerShell session. There\u2019s at least a couple of ways to do that. The first, and most obvious, is to open the Administrative Tools Start Menu Program Group and select the \u201cActive Directory Module for Windows PowerShell\u201d shortcut, which will launch PowerShell and load the module. Alternatively, you can just start PowerShell yourself and type:<\/p>\n

Import-module ActiveDirectory<\/em><\/p>\n

And get the same effect. Now, how do you know where to begin? You can get a list of the cmdlets that are available in the AD module by typing in PowerShell:<\/p>\n

Get-command\u00a0 \u2013module ActiveDirectory<\/em><\/p>\n

What you\u2019ll see when you issue this command on Server 2008-R2 or Windows 7, is a list of 76 cmdlets that provide a variety of AD and AD LDS management functionality from PowerShell. I will also mention that the AD module comes with a \u201cPSProvider\u201d. The PSProvider lets you interact with AD as if it were a drive letter. So, you can \u201cchange directories\u201d into your AD domain, do a \u201cdir\u201d of an OU and even write-changes to AD objects. That said, there\u2019s probably fewer scenarios where that makes sense than just using the regular cmdlets, so I won\u2019t be covering the PSProvider in this article.\u00a0So let\u2019s dive into some examples.<\/p>\n

Creating a New User<\/strong><\/h2>\n

The simplest example is creating a new user account. Let\u2019s say we want to create a new user account in the Marketing OU and set a few properties on that account at creation. Let\u2019s see how we can do that. The following PowerShell command calls the\u00a0New-ADUser<\/strong>\u00a0cmdlet to get the job done:<\/p>\n

New-ADUser -Name “Ron Smith” -Enabled $true -SamAccountName “rsmith”\u00a0 -GivenName “Ron” -Surname “Smith” -DisplayName “Ron Smith” -Path ‘OU=Marketing,DC=contoso,DC=com’ -AccountPassword (Read-Host -AsSecureString “pwd”) -ChangePasswordAtLogon $true -HomeDirectory “\\\\server\\home\\rsmith” -HomeDrive “H:” -OtherAttributes @{‘comment’=”Created from PowerShell Script”}<\/em><\/p>\n

This command is doing a lot of work. Let\u2019s break it down by each parameter and see what is going on. First we call the New-ADUser and pass in the \u2013Name parameter, that specifies the full name of the user. Next, we called the \u2013Enabled parameter and pass $true, indicating we want to create the user account as enabled. Note that this will only work if we set a password for the user as well, since typically AD won\u2019t let you create an enabled user account without a password if the domain requires a password.<\/p>\n

Next, we set the SAMAccountName using the parameter of the same name. The next three parameters\u2014GivenName, Surname and Displayname, set the user\u2019s first, last and display name as it appears in AD. The Path parameter provides the Distinguished Name of the OU that I want to put this user account into. The AccountPassword parameter is interesting. It lets me assign a password to the user, but what you see after it requires some explanation. That block in parentheses,\u00a0Read-Host -AsSecureString “pwd”)<\/em>, will prompt the user to enter a secure password after the command executes. It then passes that secure password to the parameter and continues on its way.<\/p>\n

The next parameter, ChangePasswordAtLogon, flips the bit in the user account to require the new user to change their password at first logon. The HomeDirectory and HomeDrive parameters set those properties on the user and then finally the OtherAttributes parameter lets me populate attributes on the object that are exposed directly via a cmdlet parameter. In this example, I\u2019m populating a PowerShell hashtable (@{}) with the key-value pairs I want to modify. In the example above, I have a single attribute\u2014called \u201ccomment\u201d that I am populating with some text indicating that the user was created from a PowerShell script.<\/p>\n

Group Members<\/strong><\/h2>\n

How about finding out quickly and easily, the members of a group, including all \u201crecursive\u201d memberships?<\/p>\n

No problem, here\u2019s a command that does the job to find all the members of the \u201cSales Users\u201d group:<\/p>\n

Get-ADGroupMember \u2013Identity \u201cSales Users\u201d \u2013Recursive<\/em><\/p>\n

Figure 2 shows the difference between running this command without the Recursive parameter and with it.<\/p>\n

\"Image\"
\nFigure 2:<\/strong>Enumerating Group Memberships<\/p>\n

Note that in the first instance, only 3 direct members were found, but in the second instance, all nested groups were enumerated and those members were found as well.<\/p>\n

Miscellaneous Things You Can Do<\/strong><\/h2>\n

With 75+ cmdlets, there\u2019s obviously a lot more you can do with the AD module than I indicated above. Want to find out information about your current forest, including forest functional level, FSMO role holders, all the sites in the forest? Simply type:<\/p>\n

Get-ADForest<\/em><\/p>\n

And you can surface a bunch of information about your forest. Or, want to find out what the current password policy is for your domain? Simply type:<\/p>\n

get-addefaultdomainpasswordpolicy<\/em><\/p>\n

Which will return the current working password policy (not fine-grained password policy but GPO-based password policy) in place in the domain.<\/p>\n

Want to unlock a user account who has locked themselves out? Try:<\/p>\n

Unlock-ADAccount \u2013Identity \u201crsmith\u201d<\/em><\/p>\n

In this example, I pass in the samAccountName of the user I had created earlier, using the Identity parameter, and, assuming I have rights in AD to do it, the user\u2019s account in unlocked in seconds\u2014no fuss, no muss!<\/p>\n

Summary<\/strong><\/h2>\n

I\u2019ve only skinned the surface of what you can do with the AD module in PowerShell. There\u2019s so many more cmdlets and scenarios you can automate, especially when you start to take the PowerShell pipeline into account, and use it to pipe the output of one cmdlet into the input of another. Many automation scenarios around AD account management start to present themselves. I hope this has given you a starting point for exploring what you can do with PowerShell and Active Directory!<\/p>\n","protected":false},"excerpt":{"rendered":"

Introduction There\u2019s no question that PowerShell is here to stay as an automation tool for Windows. And with it, comes a variety of ways to automate management Windows infrastructure. For sure one of the most important areas where PowerShell automation can provide big benefit, is in the management of Active Directory. AD lends itself to […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42,59],"tags":[],"class_list":["post-1486","post","type-post","status-publish","format-standard","hentry","category-ad","category-powershell"],"_links":{"self":[{"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=\/wp\/v2\/posts\/1486","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1486"}],"version-history":[{"count":2,"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=\/wp\/v2\/posts\/1486\/revisions"}],"predecessor-version":[{"id":1488,"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=\/wp\/v2\/posts\/1486\/revisions\/1488"}],"wp:attachment":[{"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1486"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1486"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1486"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}