Use PowerShell Active Directory Cmdlets Without Installing Any Software
Summary: Learn how to use Windows PowerShell remoting to manage user objects without installing software on the client.
Hey, Scripting Guy! I was reading your article about using the Microsoft Active Directory Windows PowerShell cmdlets, and it looks really cool. The problem is that I do not want to install the Windows Remote Server Administration tools just to be able to use the Microsoft cmdlets. I guess what I am asking is this: “Is there a way to use the Microsoft Active Directory Windows PowerShell cmdlets without having to install anything extra?” If it helps you any, I am using Windows 7 Professional (64-bit) and our domain controllers are all running Windows 2008 R2. We even promoted our Active Directory so that it is in Windows 2008 R2 mode.
—KL
Hello KL,
Microsoft Scripting Guy Ed Wilson here. Last week’s Windows PowerShell workshop in Seattle was a lot of fun. The students were really engaged and asked some great questions. My friend from Philadelphia, Pennsylvania, is out there this week doing an Exchange workshop. Anyway, during the class, I decided it would be a good idea to use Windows PowerShell remoting to perform Active Directory administration. In this way, I avoided the need to install the Remote Server Administration Tools (RSAT) on the client machine.
The first thing to do is to enter a remote Windows PowerShell session. To do this I use the Enter-PSSession cmdlet. I specify the computername and the credentials for the remote session. The credentials is an account that has the administrator rights on the remote machine. This command is shown here:
Enter-PSSession -ComputerName dc1 –credential nwtraders\administrator
If I the account I am using for my client computer also has administrator rights on the remote machine, I can leave off the credential parameter. After I have entered the session, I generally set my working location to the root of the drive so that I have more space for my commands. I then import the ActiveDirectory module. These commands appear are shown here:
Set-Location c:\
Import-Module activedirectory
The commands and the associated output are shown in the following image. Note how I use the aliases for the commands because it makes it easier to type.
Now I will create a new user in Active Directory. I think I will name the user ed. The command to create a new user is simple; it is New-ADUser and the user name. The command to create a disabled user account in the users container in the default domain is shown here:
new-aduser -name ed
When the preceding command that creates a new user has completed, nothing is returned to the Windows PowerShell console. To check to ensure the user is created, use the Get-ADUser cmdlet to retrieve the user object:
Get-aduser ed
When I am certain my new user is created, I decide to create an organizational unit (OU) to store the user account. The command to create a new OU off the root of the domain is shown here:
new-ADOrganizationalUnit scripting
Just as with the previously used New-ADUser cmdlet, nothing is returned to the Windows PowerShell console. If I use the Get-ADOrganizationalUnit cmdlet, I must use a different methodology. A simple Get-ADOrganizationalUnit command returns an error; therefore, I use an LDAPFilter parameter to find the OU. The command using the LDAPFilter parameter to find my newly created OU is shown here:
Get-ADOrganizationalUnit –LDAPFilter “(name=scripting)”
The commands and associated output to create the user, get the user, create the OU, and get the OU are shown in the following figure.
Now that I have a new user and a new OU, I need to move the user from the users container to the newly created scripting OU. To do that, I use the Move-ADObject cmdlet. I first get the distinguishedname attribute for the scripting OU, and store it in a variable called $oupath. Next, I use the Move-ADObject cmdlet to move the ed user to the new OU. The trick here is that, whereas the Get-ADUser cmdlet is able to find a user with the name of ed, the Move-ADObject must have the distinguishedname of the ed user object in order to move it. The error that occurs when not supplying the distinguishedname appears in the following figure. I could have used the Get-ADUser cmdlet to retrieve the distinguishedname in a similar method as I did with the scripting OU, but I wanted to illustrate what the distinguishedname would look like.
The next thing I need to do is enable the user account. To do this, I need to first assign a password to the user account. The password must be a secure string. To do this, I can use the ConvertTo-SecureString cmdlet. By default, warnings are displayed about converting text to a secure string, but these prompts are suppressible by using the force parameter. Here is the command I use to create a secure string for a password:
$pwd = ConvertTo-SecureString -String “P@ssword1” -AsPlainText –Force
Now that I have created a secure string to use for a password for my user account, I call the Set-ADAccountPassword cmdlet to set the password. Because this is a new password, I need to use the newpassword parameter. In addition, because I do not have a previous password, I use the reset parameter. This command is shown here:
Set-ADAccountPassword -Identity ed -NewPassword $pwd –Reset
When the account has a password, I can enable the account. To do this, I use the Enable-ADAccount cmdlet and specify the user name to enable. This command is shown here:
Enable-ADAccount -Identity ed
As with the previous commands, none of the cmdlets returns any information. To ensure I have actually enabled the ed user account, I use the Get-ADUser cmdlet. In the output, I am looking for the value of the enabled property, which is a Boolean, so I am expecting the value to be true. The commands to create the secure string for a password, set the password, enable the account, and get the account are shown in the following figure along with associated output.
Well, KL, that is all there is to connecting to a domain controller, creating a user and OU, moving a user, and enabling the account. Join me tomorrow when I will continue talking about remote Active Directory management techniques.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments