In this article:
In any Windows-centric environment, Microsoft Active Directory is an indispensable tool for managing user accounts, device connectivity, security policies, folder access, and more. It is with Active Directory (AD) that administrators can set up and assign ownership to email distribution lists and shared mailboxes. AD also can play a role in controlling group membership and permissions for Microsoft SharePoint sites and team spaces in Microsoft Teams.
In short, AD underpins everything in a complex Microsoft environment, whether it’s an on-premise implementation or the Microsoft 365 cloud-based environment.
AD has a graphical user interface (GUI) for administrators to execute their day-to-day tasks. It also enables users to generate all manner of built-in reports. But sometimes system administrators want more than what the AD GUI can provide:
To fill these gaps and achieve some level of automation, many organizations have turned to Microsoft PowerShell. PowerShell (PS) is a scripting tool that enables users to write complex command-line scripts that can automate almost anything that can be done from the Windows command line. Microsoft has implemented PS functionality for many Microsoft GUI applications, including AD. And more AD functionality is being made available for PS with each new version of the PS framework.
Before getting started, there are some prerequisites you should be aware of. The most important is knowing something about PowerShell. If you aren’t familiar with PS or the syntax of its scripting language, there are numerous online tutorials available to get you up to speed.
Next, your computing environment (the administrative PC you will use and the server on which AD runs) must meet the following conditions:
Finally, the PS Active Directory module must be available to import into the PS session. The most common way to do this is to first install the module on the administrative PC. The method for installing the module varies by Windows or Windows Server operating system, so search online for the method that applies to you.
Once the module is installed, you must import it into the PS session. This must be done with every new PS session to make the relevant commands (known in PS parlance as “cmdlets”) available in that session. The import command is simple:
Now: On to the commands!
Adding a new user account is one of the most common tasks for AD administrators. Specifying all the necessary information for a user account can be a tedious and error-prone task in the AD GUI, so if some of the parameters are the same for all users or can be derived from other information, it can be helpful to automate the process by leveraging the New-ADUser cmdlet.
New-ADUser is quite powerful. You can use the -Instance parameter to load an existing user object as a template and override only those attributes that are unique to the new user. If you have a large number of user accounts to add, you can create all of them at once by loading the data from a comma-separated-valued (CSV) file. Learn more about New-ADUser.
Another common task is creating an account for a computer, such as a PC, server, or other device. You can use the New-ADComputer cmdlet to create the computer object before joining the computer to an AD domain.
Like user accounts, computer objects can be created using a template or en masse by uploading a CSV file. Learn more about New_ADComputer.
Once a computer object is created, it can be joined to an AD domain, which involves updating the device itself. This task is necessary so that the device and its users can access resources within the AD domain. The task can be automated (to a degree) with the Add-Computer cmdlet.
Joining a computer to a domain requires the device to be rebooted. The user will be prompted for an administrative password prior to rebooting the device, so full automation is somewhat limited. Learn more about Add-Computer.
Users have an annoying habit of locking their user accounts (by allowing their passwords to expire or by mistyping their passwords too many times) or forgetting their passwords. Either of these situations usually results in a help desk call.
Unlocking a locked user account can be accomplished with the Unlock-ADAccount cmdlet:
Resetting a user’s password can be done with the Set-ADAccountPassword cmdlet:
Of course, the administrator should verify that the person requesting a password reset is that actual user and not some impostor trying to hack the user’s account.
Learn more about Unlock-ADAccount and Set-ADAccountPassword.
AD groups are one of the most powerful and useful concepts in Active Directory. Groups simplify the task of managing the users or computers that can access certain resources. For example, instead of granting different folder access permissions to individual users and dealing with the resulting management nightmare, administrators can grant permissions to a security group for that folder and add or remove users from the group as needed.
As such, modifying a group’s membership is a common AD administrator task. The cmdlets for adding and removing group members are, respectively, Add-ADGroupMember and Remove-ADGroupMember.
In both of these examples, the -Members parameter argument is a comma-separated list of objects (users or computers). The -Members parameter has multiple ways to specify a list of objects. Learn more about Add-ADGroupMember and Remove-ADGroupMember.
The AD PS commands enable reporting on specific types of objects (such as users or computers) or all AD objects. Each object type has a “Get” cmdlet (Get-ADUser, Get-ADComputer, Get-ADGroup, and so on) for extracting information on one or more objects. The -Filter parameter in each of these cmdlets is a powerful wildcard-enabled search tool that narrows the search results to specific matching objects.
Unlike the “Get” cmdlets for individual object types, the Get-ADObject cmdlet can be applied to search through any and all AD objects. For example, if you want a list of all objects that were changed after a certain date, you could run the following:
The first line creates a variable called $ChangeDate with the datetime value of interest (18 November 2022 at 1:40:02 a.m., in this case), and the second executes Get-ADObject to return all objects, regardless of object type, that were changed after that datetime value.
The -Filter parameter has a specific syntax with many options. Learn more about Get-ADObject and the -Filter parameter syntax.
As you can see, the AD PS commands provide a way to automate many AD management and reporting tasks. Multiple cmdlets can be combined into powerful scripts that can save administrators time, reduce errors, maintain security, and increase customer satisfaction. There is much more to learn about the AD PS commands, and Microsoft provides a complete reference.
Building PS scripts to automate AD tasks must be done with extreme care. It’s all too easy to mess up your AD environment beyond recognition if you aren’t careful. Every script should be reviewed and tested before deployment in the production environment. (For this reason, most AD cmdlets have a -WhatIf parameter that shows what would happen if the cmdlet were run, without making any actual changes.)
If you don’t think you or your team are quite ready to start automating your AD tasks and reporting with PowerShell, there’s another way: CoreView. CoreView has identified numerous AD tasks that can be automated and has done the scripting and testing for you, all in one intuitive, visual package. CoreView takes much of the drudgery and tedium out of managing your AD environment and provides advanced reports so you know what’s going on in your environment at any time.
For more information about how CoreView can help automate your AD management tasks, contact a CoreView representative today.
