Remotely Use the Exchange 2010 PowerShell Cmdlets
Summary: Learn how to remotely use the Exchange 2010 Windows PowerShell cmdlets in this article written by two authors and Exchange experts.
Hey, Scripting Guy! I have Microsoft Exchange 2010 installed on our network, and I would like to be able to use Windows PowerShell to manage it. In the past, I had to open up a Remote Desktop connection (RDP) on the Exchange Server, and then open the special Microsoft Exchange Windows PowerShell console. Is there an easier way to do this in Exchange 2010? It seems like RDP is an awful heavy footprint just to run a few Windows PowerShell commands.
— SJ
Hello SJ,
Microsoft Scripting Guy Ed Wilson here. Today, we have two guest bloggers and excerpts from their new book, Microsoft Exchange Server 2010 Best Practices. Siegfried Jagott works as a principal consultant and team lead for the Microsoft Messaging and Collaboration team at Siemens AG, located in Munich, Germany. He is part of the Siemens central architecture team that works closely with Microsoft to plan future enhancements of not only Windows and Exchange but also other products such as System Center Virtual Machine Manager (SC VMM).
Siegfried has been involved in Microsoft technology adoption programs since Exchange 2000 and has been working with Microsoft Exchange since Exchange Server 4.0. In the past 15 years, he has been involved in planning, designing, and implementing some of the world’s largest Windows and Exchange infrastructures for various international customers, including Siemens itself. Besides this, Siegfried is a frequent writer for various international magazines such as the Windows IT Pro Magazine and speaks at conferences about Windows-related and Exchange-related topics.
He is author of Microsoft Exchange Server 2010 Best Practices from Microsoft Press and the Microsoft course MOC 10135: Configuring, Managing, and Troubleshooting Microsoft Exchange Server 2010. He is also the co-author of two more Windows-related and Exchange related books.
Joel Stidley has been working in the IT field for more than 15 years, and he has been a computer fanatic for much longer. Joel has been working with Microsoft Exchange since the initial Exchange Server 5.0 beta release. He has also lead an engineering team to create a shared Exchange 2000 hosting platform before Microsoft released guidance on how to do so. Since the release of Exchange 2000 Server Service Pack 3, he has participated in the Microsoft Exchange JDP and TAP programs. In more than 10 years with Terremark Worldwide, he has filled a number of key roles, including the technical lead for creating and operationalizing the company’s Infinistructure™ virtualization platform. Currently, he is the principal systems architect, where he works with a variety of existing and future technologies related to virtualization, directory services, storage, and messaging. He also is a Microsoft MVP, blogger, and author of several other technical books.
The cover of the Exchange Server 2010 book is shown in the following image.
The book is full of cmdlets for Exchange 2010 and provides a useful resource if you need to script Exchange 2010. However, it also comes with an overview of how Windows PowerShell 2.0 works in Exchange 2010.
The main difference between Exchange 2007 with Windows PowerShell 1.0 and Exchange 2010 with Windows PowerShell 2.0 is that the Exchange snap-in is not loaded locally when you open the Exchange Management Shell (EMS). Instead, Windows PowerShell connects to the closest Exchange 2010 server using WinRM, performs authentication checks, and then creates a remote session for you. The following image shows the process used to log into EMS in Exchange 2010.
When you run EMS, the following process happens in the background before you can use it:
1. When EMS is opened, a new remote Windows PowerShell session is established with IIS on the remote server. IIS will authenticate the user at this time.
2. The WSMan virtual directory (or Windows PowerShell vdir) is contacted on the server and given the authenticated user’s information.
3. The Exchange RBAC Unmanaged Authorization module is contacted to verify that the logon process can continue. It then contacts Active Directory to authorize the user. If successful, WSMan is instructed to continue the process. If authorization is unsuccessful, WSMan is instructed to terminate the process.
4. WSMan passes the user’s principal information to the Windows PowerShell fan-in provider. A fan-in provider allows many connections to a single service. The Windows PowerShell fan-in provider allows IIS to call Windows PowerShell.
5. Windows PowerShell hands off the user principal information to the registered authorization module (the Exchange RBAC Managed Authorization module), which analyzes the connecting user’s RBAC definitions against Active Directory, and then builds the initial session state for handoff back to Windows PowerShell. The initial session state contains the cmdlets and parameters that will be exposed to the connecting user.
6. The Exchange RBAC Managed Authorization Modules sends this information back to Windows PowerShell via their initial session state interfaces.
7. A client runspace is created on the server within the IIS worker process, and Windows PowerShell configures implicit remoting proxies to be handed back to the client.
8. The runspace is returned and imported using the Import-PSSession operation on the client.
Note: If you have the Exchange Management tools installed, you can attempt to load manually the Exchange snap-ins into a local Windows PowerShell session; unfortunately, this is not supported. For information about manually connecting a remote EMS to an Exchange server, see Connect Remote Exchange Management Shell to an Exchange Server.
Windows PowerShell 2.0 for Exchange 2010 for Beginners
Whenever I teach an Exchange administrator about Windows PowerShell, I tell him to recognize two very basic cmdlets because these two cmdlets allow retrieving all cmdlets available: Get-Command and Get-Help.
Using Get-Command
With hundreds of possible cmdlets, narrowing your search for the appropriate cmdlet can be a little overwhelming. Thankfully, the Get-Command cmdlet can be used to find commands or cmdlets. For example, if you want to search for all commands that include the word Restore, just run the Get-Command *Restore* cmdlet.
You can also use the Get-Command cmdlet and specify the -Verb or -Noun parameter. To retrieve a list of all cmdlets that include Database in them, you can run the Get-Command -Noun *Database* cmdlet. The Get-Command cmdlet will return any registered cmdlet. To narrow your search to Microsoft Exchange cmdlets, you can use the Get-ExCommand cmdlet in the same way you use the Get-Command cmdlet.
Using Get-Help
Each Exchange cmdlet also has help information available. The cmdlet that retrieves help for other cmdlets is Get-Help. To obtain help about Get-MailboxDatabase, run Get-Help Set-MailboxDatabase. Some common parameters are available when getting information about Exchange cmdlets: -examples, -detailed, and -full.
The -examples parameter displays only examples for using the cmdlet. The –detailed parameter shows a more detailed version of the default help, and -full provides the full help content.
Note: If your administrative workstation has Internet access, you can also specify the -online parameter to view the latest version of help online.
Exchange Management Shell Quick Reference Card of the Exchange Server 2010 Best Practices Book
In our Book Exchange Server 2010 Best Practices published by Microsoft Press, the best comes last. I’ve added a couple of free documents to the O’Reilly website. One you might like best is the Quick Reference Card for Exchange Management Shell (EMS) that explains the most common cmdlets used for Exchange 2010. It includes not only the very basic structure of Windows PowerShell, but also includes the cmdlets and variables of Windows PowerShell in a handy two-sided printout that sometimes are hard to remember.
SJ, that is all there is to using the Exchange Management Shell. Guest Blogger Week will continue tomorrow when we will talk about managing SharePoint 2010 searches. Our guest blogger will be Corey Roth.
We invite you to follow us on Twitter and Facebook. If you have any questions, send email to us at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson and Craig Liebendorfer, Scripting Guys
Light
Dark
0 comments