How To Use The 2012 Active Directory PowerShell Cmdlets From Windows 7

아티클
06/27/2013

Antique Tools?

The Windows Server 2012 Active Directory PowerShell module has some handy new cmdlets. However, many IT shops struggle to stay current on the latest operating system releases due to a variety of issues (budget, resources, compatibility, etc.). They desperately want to use the latest features, but their deployment standards have not caught up yet. This leaves them with workable, but sometimes inefficient, tools from previous releases.

Today’s article will show you how to use the latest Windows Server PowerShell modules in a legacy Windows 7 environment. As a bonus we’ll explore compatibility of the AD cmdlets across the different operating systems.

Interchangeable Parts

Today we have several domain controller operating systems that support the Active Directory module cmdlets: 2003, 2008, 2008 R2, 2012. Clients on Windows 7 and 8 can install the Remote Server Administration Tools (RSAT) to script with the Active Directory module against these DCs.

With all of these versions now the first question that comes to mind is compatibility. I already know that I can use the Windows 7 RSAT AD module against 2003, 2008, and 2008 R2 DCs.

Are Windows 8 and Windows Server 2012 compatible with my existing AD PowerShell scripts?
Can I use the Windows 8 RSAT AD module against 2008 R2 or 2003 DCs?
Can I use the Windows 7 RSAT AD module against 2012 DCs?

The short answer to all of these compatibility questions is “yes”. Key Point: You can use any version of the AD cmdlets against any version DC running the AD Web Service.

Let's look at compatibility from both the server and the client. The picture below explains this rather simply.

When I refer to RSAT in this article I am using it as a blanket term to describe either the RSAT installed on a Windows client or the RSAT in Windows Server Features.

Server

2003 and 2008 DCs can install the AD Gateway Management Service (ADGMS) to support the AD cmdlets running against them. That is a fancy name that just means AD Web Service (ADWS). Look for ADWS in Services once it is installed.
2008 R2 and 2012 DCs already have the AD Web Service installed and running.
Key Point: Once the ADWS is installed, it will answer to any version of the cmdlets. That means you can use the latest 2012 cmdlets against a DC running 2003 and the ADWS. Cool!

Client

While you can install the AD Web Service on 2003 and 2008, you cannot use those servers to run the AD cmdlets locally. Neither of these servers can install the RSAT or AD DS PowerShell feature to get the cmdlets. These servers will only answer to remote AD cmdlets run against them.
Windows 7 or 2008 R2 RSAT will give you the first version of the AD cmdlets (PowerShell v2).
Windows 8 or 2012 RSAT will give you the second version of the AD cmdlets (PowerShell v3). This is your best scenario.
In order to use the 2012 AD cmdlets from Windows 7 or 2008 R2 you will have to use PowerShell implicit remoting.
Key Point: The RSAT version determines the functionality of the cmdlets, whether used locally or imported remotely.

Can I use the 2012 AD cmdlets from a Windows 7 client?

Yes. There are three ways to use the latest 2012 cmdlets from Windows 7:

PowerShell v2 or v3: Import-PSSession
- Temporarily imports the cmdlets from a remote machine into a local session.
PowerShell v2 or v3: Export-PSSession
- Imports the cmdlets from a remote machine into a local session.
- Saves the cmdlets and session information locally for future use.
- New local sessions will automatically reconnect to the remote host when the module is imported locally.
PowerShell v3: Import-Module –PSSession
- Import-Module has a new parameter for PSSession.
- This is equivalent to the PowerShell v2 Import-PSSession functionality.

Each of these methods use a technique called implicit remoting to bring the module cmdlets to the local machine via a remote PowerShell session. Cmdlets are used locally as normal, but behind the scenes they execute in the remote session and return the results to the local session.

Note: Implicit remoting does not support PowerShell providers. That means you will not get the AD: drive letter as you do when using the cmdlets in a traditional local install.

The Exchange folks have used this technique for a long time, but traditionally AD PowerShell users have installed the cmdlets locally via the RSAT. In this case we cannot install the latest RSAT on Windows 7, so it’s time to learn a PowerShell feature that has been there since version 2.0.

Note: Don Jones wrote articles here and here about how to do this in PowerShell v2.0. Now it is much simpler in PowerShell v3.0 with the new PSSession parameter of Import-Module.

Implicit Remoting Options

When you import the Active Directory cmdlets from a remote session the remote server type is important:

Domain Controller
- AD PowerShell Module is already installed.
- CredSSP is already enabled.
Member Server
- Requires AD PowerShell module to be installed.
- Requires CredSSP for Kerberos credential delegation.

If you use a Domain Controller for your remote server, then this is a piece of cake. Everything you need is already there, both the module and the security configuration. The only catch is that most folks aren’t willing to stand up a Windows Server 2012 DC in their production environment just yet. To get around this you can create a stand-alone 2012 DC in a parallel test forest and then create a trust.

Standing up a Windows Server 2012 member server in a production environment has less change control impact than a domain controller. If you choose to use a member server, then a few more configuration steps are required. Obviously you’ll need to add the RSAT feature for the AD PowerShell Module. Then you have to configure CredSSP on both the client and server to allow the Kerberos double hop.

What in the world is CredSSP?

Until now I haven’t needed the CredSSP feature in PowerShell. Here’s the problem. We use Kerberos for authentication from our local workstation to the intermediate remoting server, but then the remoting server is not allowed to pass our credentials to the server targeted by the cmdlet. This makes two hops. The AskDS blog has a classic article that explains this Kerberos scenario in much better detail (Understanding Kerberos Double Hop). The CredSSP feature allows the intermediate remoting server to pass our credentials to the target server.

Rather than dive into all the details I will refer you to the following resources which address this topic:

See the following PowerShell help topics for more information on CredSSP and implicit remoting:

help Import-PSSession -full
help Export-PSSession -full
help Enable-WSManCredSSP -full
help about_Remote
help about_Remote_FAQ
help about_Remote_Output
help about_Remote_Requirements
help about_Remote_Troubleshooting

Importing the module on Windows 7 using PowerShell 3.0

As you can see from our discussion so far, there are several possible configurations of client, remoting server, and target server. Let's explore the easiest configuration, a Windows 7 client with PowerShell v3 connecting to a 2012 DC. Here are the steps on the Windows 7 client:

Install PowerShell 3.0.
Enable remoting from an elevated PowerShell console.
Create a PSSession to a 2012 DC
Import the module from the remote session.
Use the new AD cmdlets.

Key Point: You can take a Windows 7 machine without the RSAT installed and use the AD cmdlets from a remote machine. You can import either the 2008 R2 AD cmdlets or the 2012 AD cmdlets depending on the OS of the server where you establish the PSSession.

Here is some demo code to explore the possibilities. I have highlighted the only two lines you really need to get this going:

 #Requires -Version 3.0            
            
# Run this script from Windows 7 with PowerShell v3.0 installed.            
# Modify this script with your own computer names and domain names.            
# Demo environment has:            
# CohoVineyard\CVDC1 (Windows Server 2012 DC)            
# CohoVineyard\WIN7 (Windows 7,PowerShell v3)            
# TailSpinToys\DC1 (Windows Server 2003 DC with ADWS)            
# Domains have a two-way trust.            
            
# Don't run the whole script at once.            
# Run it one line at a time using F8 in the ISE.            
break            
            
# Verify that your local PowerShell version is 3.0 or greater            
(Get-Host).Version            
            
# Create a new PSSession to the 2012 server            
# Pass appropriate credentials

$s = New-PSSession -ComputerName CVDC1 ` -Credential (Get-Credential CohoVineyard\Administrator)

             
            
# View your new session            
$s            
            
# View the list of available modules on the remote server session            
Invoke-Command -Session $s -ScriptBlock {Get-Module -ListAvailable}            
            
# Import the module using PowerShell v3.0 implicit remoting

Import-Module ActiveDirectory -PSSession $s

             
            
# View the list of modules now available in your local session            
Get-Module            
            
# View the local copy of the ActiveDirectory module            
# Notice the Description property tells you where it came from            
Get-Module ActiveDirectory | Format-List            
            
# View the cmdlets now available            
Get-Command -Module ActiveDirectory            
            
# Use one of the AD cmdlets            
Get-ADForest            
            
# Note that objects returned are Deserialized like any other PSSession            
Get-ADForest | Get-Member            
            
# Implicit remoting will rebuild the session if it gets dropped.            
# Notice the message displayed when restoring the session.            
Get-PSSession | Remove-PSSession            
Get-ADDomain -Server CVDC1            
Get-PSSession            
            
# Verify the ADWS service is running a second hop DC.            
Get-Service ADWS -ComputerName DC1.tailspintoys.local            
            
# From Win7 machine using imported 2012 DC cmdlets            
# To 2003 DC running ADWS in a trusted forest            
# Add parameter for credentials if necessary in your environment.            
Get-ADDomainController -Server DC1.tailspintoys.local            
            
# Create a user            
New-ADUser GoateePFE -Description "Script-a-holic" -Server DC1.tailspintoys.local            
            
# Verify new user            
Get-ADUser GoateePFE -Server DC1.tailspintoys.local            
            
# Remove user            
Remove-ADUser GoateePFE -Server DC1.tailspintoys.local -Confirm:$false            
            
# Now use a 2012 AD cmdlet against at 2003 DC running ADWS            
Get-ADReplicationSubnet -Filter * -Server DC1.tailspintoys.local            
            
# Clean up            
Get-Module ActiveDirectory | Remove-Module            
Get-PSSession | Remove-PSSession

This actually runs the cmdlets on the remote session and returns the results to your Windows 7 box as a deserialized object that looks pretty close to running the cmdlets natively. Deserialized objects are XML representations of the properties only. Read more about these in about_Remote_Output.

Note that you may need to use the credentials parameter to properly authenticate both your PSSession and your cmdlets. Experiment with these options to see what works best in your environment.

PowerShell v2 Style

Here is some example code using PowerShell v2 on Windows 7 connecting through a 2012 member server with RSAT installed. Since this is not a DC, we will need CredSSP already configured on the client and server as described in the links reference earlier.

 $t = New-PSSession -ComputerName cvmember1.cohovineyard.com ` 
        -Authentication Credssp ` 
        -Credential (Get-Credential cohovineyard\administrator)            
Invoke-Command -Session $t {Import-Module ActiveDirectory}            
Import-PSSession -Session $t -Module ActiveDirectory

Notice that it takes two lines for PowerShell v2 to import the remote module and import it into the local session. PowerShell v3 does this in one line with Import-Module –PSSession.

But wait… there’s more!

This trick is not limited to Active Directory cmdlets. You can use this same process to leverage any of the latest and greatest modules from Windows Server 2012: DNS, network, storage, shares, etc. Just remember that all of the commands will execute in the context of the remote server.

 $s = New-PSSession -ComputerName CVDC1            
Import-Module DNSServer,DNSClient,NetTCPIP -PSSession $s

Summary

The following bullets summarize the takeaways for this article:

You can use any version of the AD cmdlets against any OS DC running the AD Web Service.
The RSAT version determines the functionality of the cmdlets whether used locally or imported remotely.
The easiest way to run 2012 AD cmdlets from Windows 7 or 2008 R2 is to install PowerShell 3.0. Then you can import the newer module from a Windows Server 2012 machine where the AD module is installed.
To shortcut these additional configuration steps simply use a Windows 8 machine with RSAT to do your AD administration.

Downloads

Comments

Anonymous
September 25, 2013
Excellent post - lots of good detailed information. Thanks!
Anonymous
October 29, 2014
Welcome! Today’s post includes demo scripts and links from the Microsoft Virtual Academy event: Using PowerShell for Active Directory . We had a great time creating this for you, and I hope you will share it with anyone needing to ramp up their
Anonymous
November 20, 2014
Great Tips !!
Anonymous
November 24, 2014
Microsoft premier field engineer (PFE), Ashley McGlone, discusses the Active Directory PowerShell cmdlets.
Anonymous
January 19, 2015
Active Directory Description During Deployment.

다음을 통해 공유