Henrik Walther ha publicado este interesante articulo
Introduction
Exchange 2007 was the first Exchange version where the management architecture was based on Windows PowerShell (more specifically PowerShell 1.0). Actually, both the Exchange 2007 Management Console and Shell were built on top of the PowerShell engine bringing many benefits with it. Although it took some time, many Exchange administrators quickly learned to use the shell and therefore also optimized the operational efficiency within the organization.
Without surprise the management architecture in Exchange 2010 is also based on Windows PowerShell, but the new Windows PowerShell 2.0 version. PowerShell 2.0 includes a lot of improvements, and of course Exchange 2010 takes advantage of several of these. One of them is the new PowerShell Remoting feature, which uses WS-Management (aka WS-MAN or WinRM), which is a Windows Server 2008 and Windows Vista component with the task of making management of servers, devices and applications easier across the organization.
In this article I will explain what remote PowerShell is and how this new feature makes it possible to manage Exchange 2010 servers within an organization as well as across multiple Exchange 2010 organizations using the Exchange Management Console and Shell and Windows PowerShell 2.0 - all running from the same management server.
Note:
This article is based on an early beta version of Exchange 2010, so any information is subject to change with later builds of Exchange 2010.
What is Remote PowerShell?
In order to explain this, let us jump back to Exchange 2007. Although the Exchange 2007 Management Shell (EMS) allowed Exchange administrators to manage all Exchange 2007 servers within an Exchange organization from a single management server on which the Exchange Management tools were installed, the cmdlets actually ran in the host/process of the management server itself. The management server then established RPC connections to the Exchange servers that were manipulated.
In Exchange 2010, the management architecture is based on Remote PowerShell included with Windows PowerShell 2.0. Remote PowerShell provides an RBAC-based permission model making it possible to grant much more granular permissions (Exchange 2007 used ACLs), standard protocols that makes it easier to manage Exchange 2010 servers through firewalls, and explicitly separates “client” and “server” portion of the cmdlet processing. In addition, it uses WS-MAN which makes the integration with the Windows operating system more seamless.
The current public Exchange 2010 beta version includes both a local and a remote Exchange Management Shell, but this is only because all the cmdlets are in the process of being moved to the remote Exchange Management Shell version. So by the time we reach RTM, Exchange 2010 will no longer include a local Exchange Management Shell.
This means that no matter if you are administering an Exchange 2010 server using the local Exchange management tools installed on that server or a dedicated management server, you use the remote Exchange Management Shell (Figure 1). As mentioned previously, the public beta version of Exchange 2010 also includes the local Exchange Management Shell, so if necessary (there is still some cmdlet’s that do not work properly in the remote EMS) you can use this one as well.
Figure 1: Remote Exchange Management Shell
When launching the remote Exchange Management Shell, it connects to the local PowerShell virtual directory (Figure 2) created by the setup wizard in IIS, when the Exchange 2010 Management tools are installed on a machine.
Figure 2: PowerShell Virtual Directory in IIS Manager
When the remote EMS connects to the PowerShell vdir, any necessary cmdlets are imported from the server-side session (aka runspace) to the client-side session (Figure 3) or more specifically references to these cmdlets are imported. When the cmdlet references have been imported, you can start managing the Exchange 2010 server just like you normally do when using the EMS.
Figure 3: Creating PowerShell session and importing server-side cmdlets
Enabling Remote Exchange Management Rights for a User
By default the Active Directory account you used to deploy Exchange 2010 in your forest will be granted remote PowerShell management rights. If you want to grant this right to another AD account, you must use the Set-User cmdlet with the RemotePowerShellEnabled parameter. If I for instance wanted to grant this right to my own AD account, I would use the following command:
Set-User ‘Henrik Walther’ –RemotePowerShellEnabled $True
Figure 4: Granting Remote PowerShell management rights to a user
Connecting to a remote Exchange 2010 Server using the Remote Exchange Management Shell
If you want to connect to the PowerShell virtual directory on another Exchange 2007 server in the organization or in another Exchange organization, you use the New-PSSession and Import-PSSession cmdlets.
When establishing a new Exchange Management Shell session against a remote Exchange 2010 server, the interesting thing is that any commands you run from the shell on the local Exchange 2010 server actually are executed on the Exchange 2010 server, you just connected to.
Let us connect to a remote Exchange 2010 server in the same Exchange organization.
If the certificate installed on the remote Exchange 2010 server you wish to connect to is not trusted by the local machine, the first thing you must do is to either import the certificate or create a variable that skips certificate CA, CN, and Revocation checks. To create the variable type:
$SkipCertificate = New-WSManSessionOption –SkipCACheck –SkipCNCheck –SkipRevocationCheck
Figure 5: Creating skip certificate variable
Now create a new remote Exchange Management Shell session:
$Session = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri https://
Figure 6: Command to create new PowerShell session with implicit credentials
Note:
Since we are connecting to a local Exchange 2010 server in the forest, we use implicit credentials (Kerberos authentication).
With the remote Exchange Management Shell session created, let’s import it to the client-side session:
Import-PSSession $Session
Figure 7: Creating new remote Exchange Management Shell session and importing server-side cmdlets
Explicit credentials
If you wish to connect to an Exchange 2010 server in another Exchange organization, you should use explicit credentials, which means that you should first create a variable using:
$UserCredential = Get-Credential
Figure 8: Creating user credential variable
You can then create the remote Exchange Management Shell session using:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://
Figure 9: Command to create new remote Exchange Management Shell session with explicit credentials
Using the Exchange Management Console
Now that we have seen how to use the remote Exchange Management Shell to manage Exchange 2010 servers within an organization or across organizations, it is time to switch to the Exchange Management Console and show you how it is possible to manage multiple Exchange 2010 organizations from the same EMC.
So, let us open the Exchange Management Console. In the navigation pane, select Microsoft Exchange and then click Add Exchange Forest in the Action pane as shown in Figure 10. When the Add Forest windows appears, enter the credentials of the Administrator you want to use to connect to the other Exchange organization. Since we’re connecting to another on-premise Exchange organization, select Microsoft Exchange On-Premises.
Note:
You can use the Microsoft Exchange Online option to connect to an Exchange 2010 organization in the cloud. Currently, you can only connect to a tenant domain at Exchange Labs or Live@edu.
Now enter the URL of the remote PowerShell vdir you wish to connect to. Use the following format:
https://E2K10Server.domain.com/PowerShell/
Then click OK.
Figure 10: Adding an Exchange organization from another forest to the EMC
The remote Exchange organization will now be added to the navigation pane in the left side of the Exchange Management Console as shown in Figure 11.
Figure 11: Additional Exchange organization added to the EMC
You can now manage this organization as was it a local Exchange organization you were managing.
Note:
Since Exchange 2010 is still under development, please bear in mind that you may get some errors when doing specific management tasks against a remote Exchange organization.
Cross-Forest Mailbox Moves using the Exchange Management Console
Unlike Exchange 2007 you can now do cross-forest mailbox moves directly from the Exchange Management Console. The reason why I mention this in this article is because one of the requirements before you can move a mailbox to another forest via the EMC is that you must add the Exchange organization of the target forest to the EMC like we did in the previous section. When you have done so, you right-click on the user mailbox(es), you wish to migrate and select New Move Request in the context menu (Figure 12).
Figure 12: Creating a new Move Request
This brings up the New Move Request wizard shown in Figure 13. As you can see you must select the target forest in the drop-down menu.
Figure 13: Specifying the target forest the mailbox should be migrated to
I will not show you how to do the actual mailbox migration here as its outside the scope of this article, but if you begin playing with this feature, it is important to note that you must have migrated/replicated the AD user account to the target forest using ILM or another migration tool before you move the mailbox. As some of you know this is different from Exchange 2007, where it was not required to have the AD account in place in the target forest before migrating the mailbox.
Managing Exchange 2007 and 2010 Servers from the same Machine
Another thing that is quite cool, especially when talking Exchange 2007 to Exchange 2010 transitions in large organizations consisting of many thousands of users, is the fact that unlike Exchange 2003 to Exchange 2007 transitions, you can install both the Exchange 2007 and Exchange 2010 Management tools on the same machine. Yes you heard right. You simply install the Exchange 2010 prerequisites on the machine that is Windows PowerShell 2.0, WS-MAN and .NET Framework 3.5. When you have installed the prerequisites, you install the Exchange 2010 Management tools followed by the Exchange 2007 Management tools.
Note:
Please bear in mind that it is only the Exchange 2007 and 2010 Management tools that can coexist on the same machine. You should never try to install any of the other Exchange server roles on it.
Figure 14: Exchange 2010 Setup.exe Bootstrapper
Make sure you only select Management Tools on the Server Role Selection page (Figure 15).
Figure 15: Selecting Management Tools on the Serve Role Selection page
When Management Tools have been installed successfully, click Finish (Figure 16).
Figure 16: Exchange 2010 Management Tools installed successfully
Now launch the Exchange 2007 Setup wizard (Figure 17).
Figure 17: Exchange 2007 Setup.exe Bootstrapper
Make sure you only select Management Tools on the Server Role Selection page (Figure 18).
Figure 18: Selecting Management Tools on the Serve Role Selection page
When Management Tools have been installed successfully, click Finish (Figure 19).
Figure 19: Exchange 2007 Management Tools installed successfully
When the management tools have been installed, you can find them under All Programs in the Start Menu as shown below.
Figure 20: Where to find the management tools
It gets even better because you can actually run the management tools for each Exchange version simultaneously (Figure 21).
Figure 21: Exchange 2007 and 2010 Management consoles side by side
The interesting thing about this is you actually could create a custom MMC console including the management tools snap-in from both Exchange versions (Figure 22).
Figure 22: Exchange 2007 and 2010 Management console snap-ins in same MMC
Using Windows PowerShell 2.0
So far I have showed you how to manage Exchange 2010 using the remote Exchange Management Shell as well as the Exchange Management Console, but you know what? It is not even required to install the Exchange 2010 Management tools on a machine in order to manage Exchange 2010, at least not if you prefer to do so using the Shell. Remember I mentioned that when connecting to the PowerShell vdir on a remote Exchange 2010, the needed cmdlets would be imported to the client-side session/runspace?
If you like working from the shell the only required components on the machine from where you managed Exchange 2010 servers are Windows PowerShell 2.0 and WS-MAN and you are rolling.
Note:
At the time of this writing, the WS-MAN component can only be installed on Windows Server 2008 and Windows Vista, but I heard a rumor that the WS-MAN team are working on a version for Windows XP.
When you have installed WS-MAN and Windows PowerShell 2.0 on a machine, launch Windows PowerShell by clicking Start > All Programs > Windows PowerShell V2 (CTP3) > Windows PowerShell V2 (CTP3) as shown below.
Figure 23: Launching Windows PowerShell 2.0 (CTP3)
Figure 24: Windows PowerShell 2.0 (CTP3) shell
Again, we will now use the New-PSSession and Import-Session cmdlets. If the certificate installed on the remote Exchange 2010 server you wish to connect to is not trusted by the local machine, you must either import the certificate or create a variable that skips certificate CA, CN, and Revocation checks. To do so enter:
$SkipCertificate = New-WSManSessionOption –SkipCACheck –SkipCNCheck –SkipRevocationCheck
Figure 25: Creating skip certificate variable
Now create a new PowerShell session:
$Session = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri https://
Figure 26: Command to create new PowerShell session with implicit credentials
With the PowerShell session created, let’s import it to the client-side session/runspace:
Import-PSSession $Session
Figure 27: Creating new PowerShell session and importing server-side cmdlets
Figure 28: Importing the new PowerShell session to the client-side session/runspace
Explicit credentials
If you wish to connect to an Exchange 2010 server in another Exchange organization, you should use explicit credentials, which means you first should create a variable using:
$UserCredential = Get-Credential
Figure 29: Creating user credential variable
You can then create the PowerShell session using:
Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://
Figure 30: Command to create new PowerShell session with explicit credentials
Remote PowerShell Management Examples
Now let us try to get a list of the mailboxes in the Exchange organization using the Get-Mailbox cmdlet.
Figure 31: Listing all mailboxes in remote Exchange organization
Next let’s create a new mailbox.
New-Mailbox –Name ‘Test User 2’ –UserPrincipalName ‘Testuser2@exchangelabs.dk’
Press enter then specify the password for the user mailbox and press enter.
Figure 32: Creating a new mailbox in the remote Exchange organization
Okay let us now create a new distribution group and add the new test user to it.
New-DistributionGroup –Name ‘Test Distribution Group’
Figure 33: Creating a new distribution group in the remote Exchange organization
We add the user mailbox to the distribution group using:
Add-DistributionGroupMember –Identity ‘Test Distribution Group’ –Member ‘Test user 2’
Figure 34: Adding the new user mailbox to the new distribution group
Let us now verify the respective user mailbox was added to the distribution group:
Get-DistributionGroupMember –identity ‘Test Distribution Group’
Figure 35: Listing members of the new distribution group
These were just very simple examples, but you can, as mentioned, do much more complicated stuff. Actually, all the things that are possible using the Exchange Management Shell.
Disconnecting the Remote PowerShell Session
When you are finished managing the remote Exchange 2010 server or organization, you can disconnect the remote PowerShell session using the following command:
Remove-PSSession $Session
Alright this concludes this article. I hope you found it interesting.
0 comments:
Post a Comment