Windows Server 2008 R2 PowerShell CMDLETS
The main focus of this tutorial is to introduce you to a numerous amount of PowerShell cmdlets and how they fit into the more common tasks that they are needed for. By familiarizing yourself with these new cmdlets and their functions, you lay the groundwork for you to pick and choose the ones that are helpful and can make your life easier. You will learn a lot more about them by using them than simply reading about them.
Active Directory cmdlets
The PowerShell Active Directory module introduces over 70 cmdlets to provide full support for almost any Active Directory function an administrator might require. But before you can use this newfound power, you either have to import the module or use the Active Directory Module for PowerShell. The easy path is to use the AD Module for PowerShell, but some people like to do things the challenging way. To get the Active Directory cmdlets in your active PowerShell window, type in Import-Module Active Directory. You can then check to see if it was imported properly by typing Get-Help *ADA*. If the get-help cmdlet returns some Active Directory commands, then you can be sure that the Module was installed. Table-2 lists some Active Directory User focus cmdlets.
Table-2 Active Directory User Focus cmdletscmdlet Name Description
New-ADUser This cmdlet creates a new Active Directory User.
Requires only a name and will populate the rest of
the fields with default values for you
Set-ADUser This cmdlet sets/modifies the properties of the
specified ADUser
Get-ADUser This cmdlet gets an object representing the ADUser
Remove-ADUser This cmdlet removes/deletes the specified ADUser
If you actually want to list all the Active Directory cmdlets, then at the PowerShell prompt, type Get-Command *AD* and hit enter. We must warn you that there are a lot of them. Now that the power is within your grasp, you must learn to use it properly, or else great destruction and loss of job could ensue. As soon as people hear you have the power, requests start coming in for you. The first cry for help comes from accounting. "Help brave superhero! We need you to create a new user account in AD for us" is the call for help. An e-mail arrives right afterward with all the details. The message reads, "Dear Superhero," we need a new AD User account for a new employee named Mike Ryan. You keep in mind the first initial last name naming convention that the company adheres to and quickly start on the task. You type New-ADUser -Name "Mike Ryan" -SamAccountName "MRyan" and hit enter. This will create a basic user with the name of the User object as Mike Ryan and the SamAccountName as MRyan. The only mandatory field in the New-ADUser cmdlet is the -Name flag. If you leave that out, then you will get a prompt asking for it. If you only provide the -Name field and leave the SamAccountName out, the SamAccountName will be populated with the -Name value by default. This is because you need to have a SamAccountName for an Active Directory User to exist. When the cmdlet executes, it will have created a new Active Directory User for you. If a user with the same SamAccountName already existed, you would have gotten an error similar to how you get an error when trying to duplicate a user in the Active Directory Users and Computers GUI, and would have had to create him with a SamAccountName of MRyan02 or as what the company naming convention dictated. You can check that the account you created exists by using Get-ADUser "MRyan" and hitting the enter key. This created a very basic account with almost nothing populated.
You could also have created the user from a template. This would allow you to have a large amount of values already set consistent with the company policy and only change the necessary ones for the user. In the previous example of Mike Ryan, the account has all the default values for password expiration, change at next log on, etc. With a template, you would be able to specify universal properties for all new users as long as you create them all from the same template. Imagine you have a ADUser you created and populated completely with all the default values for any new account. When the time comes to create a new account, all you would have to do is to use the -Instance flag to specify the new user. Assume that you decided to create user "Mike Ryan" from the "New Guy" template, this is what you would do.
$templateAccountHolder = Get-ADUser -Identity "Nguy" New-ADUser -Name "Mike Ryan" -SamAccountName "MRyan" -Identity "MRyan"
This would create the new user Mike Ryan using Nguy as a template. In essence, you are taking all his set properties and changing the ones you want for the new user you are creating. Once you have finished creating his account, you realize you did not specify his e-mail, and that Nguy@SuperTechs.com, the default one from the template, does not really work. It is time to use your skills again. You type Set-ADUser -Identity "MRyan" -EmailAddress "MRyan@SuperTechs.com and hit enter. When the cmdlet executes, you will have updated or set the e-mail for that user to the desired value. After clearly overcoming your first task, you check your inbox for the next one and click on it as soon as it arrives. A message comes in with a simple, yet sad request. You are to delete the account for the user Jason Todd with identity Jtodd. According to the message, he is no longer with the company, and therefore his name must be removed from Active Directory. You put your skills to use again and type Remove-ADUser -Identity JTodd and hit enter. You hit Y to confirm his deletion and then his name will cease to exist.
You have now touched on the basics of the AdUser operations in AD. The full potential of these cmdlets is astonishing to say the least. But with the knowledge of these basic blocks, you can accomplish great things. Always keep in mind that when a cmdlet asks for the identity of a user, you will need to specify one of a few specific things. For identity, you can use the Distinguished Name (DN), the Global Unique Identifier (GUID), Security Identifier (SID), or the Security Accounts Manager (SAM) Account Name. All these fields have flags that correspond to their names like the -SAMAccountName flag.
Table-3 lists Active Directory group focus cmdletscmdlet Description
New-ADGroup This cmdlet creates a New Active Directory Group.
Requires the name and group scope fields to create
the group
Set-ADGroup This cmdlet is used to set/modify existing
properties of the ADGroup
Get-ADGroup This cmdlet gets an object representing the
specified ADGroup
Remove-ADGroup This cmdlet removes/deletes the specified ADGroup
Your skills still need to grow in the area of Active Directory Groups. The next task that comes in proves to be the perfect testing ground. The new task being delegated to you is to create a newdistribution group for all the users of special talents like yourself. You type New-ADGroup -SAMAccountName "Supers" -GroupCategory 0 -GroupScope 0 and hit enter. The cmdlet will execute and create a new group for you with all the default values, except for the ones you specified. The -GroupCategory flag is what determines if the group is a security group or a distribution group. A value of 0 is set as a distribution group, while a 1 is set as a security group. The default value is 1, security group, if the flag is left off. The -GroupScope flag 0 corresponds to domain-local,while 1 isglobal and 2 isuniversal.You could have simply typed New-AdGroup and hit enter and it would have worked as well. It would then have prompted you for a Name and a group scope. It would be fast and easy, but some of the default values are not what you want. The Name would then be used as the SAMAccountName as well, and you would have had to go back and modify the group and change it to a distribution group since that is what you wanted. To do this, you would have needed to use the Set-ADGroup cmdlet by typing Set-ADGroup Supers -GroupCategory 0 and then hit enter. Another way you can create a new Active Directory Group is by using a different group as a template. Assume that you have a security group called "AM Shift" that has everything set perfectly the way you need it. Now, you have the need to create a newgroup called "PMShift" but want to use the same settings and properties of theAMShift group. This would save you all the trouble of reconfiguring the new group to match the already existing one, or even worse, you are not even exactly sure what all the properties are. You just know that you need another group just like that one. This is the perfect example of why you would use the first one as a template. This process is almost identical to what you did with the ADUser you created from a template. You start by declaring a variable and assigning the template group to it and then using the -Instance flag with the New-ADGroup cmdlet to accept the variable. This creates a new group based on the instance of the old group with all the properties of the old group, except for anything you add.
$groupUsedAsTemplate = Get-ADGroup -Identity "AM Shift" New-ADGroup -Name "PM Shift" -Instance $groupUsedAsTemplate-GroupScope 0
You will also need to specify the -GroupScope of the new group you are creating or it will prompt you for it.
You can check the properties of any of the groups you created by using Get-ADGroup Supers.
As you get more familiar with the cmdlets, you can see that groups are very similar to users in how you create them, get them, and modify/set them. So, it will come as no surprise to you that to remove them is just as simple. If you wanted to remove the group you just created, you would type Remove-ADGroup Supers. Once you hit enter, you will get the confirmation screen and then it is done.
Now that you have created the group, you need to move on to the next part of your task and add the users on the list to the Supers Group you just created. You will be using the Add-ADGroupMember cmdlet to accomplish your task. This cmdlet and some other Active Directory group member focus cmdlets are described in Table-4. Typing Add-ADGroupMember is enough since PowerShell will prompt you for the mandatory values it needs. But since it is better to learn the common flags for when you are writing your own PowerShell scripts and need to automate as much as possible, you will type Add-ADGroupMember -Identity Supers -Members "MRyan," "CKent".
Once you have added the AD Users to the group with the Add-ADGroupMember cmdlet, you check to see that they made it in properly by typing Get-ADGroupMember Supers and hitting enter.
You finish adding all the members on the list to the group and start to relax thinking you are done when an updated request is sent to you. Apparently, one of the names in the original list should not be added to the group. His name is going to be cleared with the rest of the members before he is added, since apparently he is very volatile. You have already finished adding all the names though, so the only thing you can do is delete him from the group. You type Remove-ADGroupMember -Identity "Supers" -Member "BBanner" and hit enter. A confirmation pops up and you hit enter. The named member is no longer a part of the group. You reply to the request that you are finished and get a heart-felt "thanks, you saved us."
You are taking a breather when your next task comes in. Clicking it you see that now that they are identifying these gifted individuals, they are going to need a way to apply GPOs to them as well as administer them separately from the rest of the users. You are tasked with creating an Active Directory Organizational Unit for them. Table-5 lists some Active Directory Organizational Units focus cmdlets.
Creating an Active Directory Organizational Unit is simple for someone with your powers. Just like a new AD User or AD Group, you can start one from scratch with as many default parameters or specific parameters as you want or you can base the creation on an already existing one using the -Instance flag. You start by typing New-ADOrganizationalUnit -Name "VeteranSupers" -ManagedBy "CKent" and hit enter. When the cmdlet executes, a new OU will exist. OUs do not have as many parameters as AD Groups or AD Users but they have one parameter that is worth mentioning, the one set by the -ProtectFromAccidentalDeletion flag. If this is set to True, then you cannot delete the OU by normal means without first setting the parameter to False. So, assume that the OU you created was not supposed to be protected from accidental deletion, but by default it is and you did not specify otherwise. You need to change the parameter with the Set-ADOrganizationalUnit cmdlet. The tricky part is that to set or get an OU, you need to know its DN; its regular name will not work. Trying any set or getting an OU using its name as its -Identity will fail. So, you need to get a list that would include the OU you need and get its DN from there. We know what you are thinking. Instead of going through all this, why not just delete it and create the OU again, this time with the flag specified as false? It won't let you because the flag is set to true. The name, however, lets you look for the OU with a -Filter. You type Get-ADOrganizationalUnit -Filter "Name -Like 'VeteranSuper'" j FT Name, Distinguished Name and hit enter. You see the DN and can now use that to call the Set-ADOrganizationalUnit cmdlet. Your DN will be different since you are going to have different AD environments, so for the italic part, just replace with your specific value. You type Set-ADOrganizationUnit -Identity "OU=VeteranSuper, DC=smeekers,DC=com" -ProtectFromAccidentalDeletion $false and hit enter. When the cmdlet executes, the property will be updated and VeteranSuperOUwill no longer be safe from deletion, accidental, or otherwise. You decide to test it and type Remove-ADOrganizationUnit -Identity "OU=VeteranSuper,DC-smeekers,DC=com" and hit enter.
