It seems that Microsoft is working toward a GUI-less management experience for many of its tools by giving PowerShell what some might consider the preferential treatment. I do not mean that the GUI is going away (yet), but simply that PowerShell is being more and more integrated into the server products being released.
For example, Exchange 2010 has a management console and a management shell. The management shell has piles of PowerShell command-lets that allow an administrator to manage Exchange. In addition, when performing actions in the management console, there is an icon on all property pages pointing to the management shell. If, for example, you change an alias for a user in the console and click the PowerShell button, a new text window pops up showing the PowerShell command that will be executed to make this change. While that option is extremely handy for looking at the code to determine how a setting might be modified, it still involves having the tools installed on a workstation or opening a remote desktop session into the Exchange Server.
How else can I handle Exchange?
You can create a remote session in PowerShell to provide access to the Exchange command-lets from whichever computer you happen to be on and manage it from the command line.Note: When I created this session, I was on my corporate network. For security purposes, I would recommend only using these command-lets when on the same network as the Exchange 2010 server you wish to manage.
Since I have been working a lot with functions and modules, I placed the session creation portion of this particular item in a module. This way, it is loaded by default when the module is called and just pops up asking me for logon credentials when I ask for the session. It saves having to retype the session or paste it each time I need it.
Create authentication credentials
PowerShell will natively try to authenticate with the logged on user's information, which for most things works just fine; however, there are times when you might want to specify an admin account for a task, since everyone logs on as a user until elevation is needed, right?
To do that, I create a variable to hold credentials:
$cred = get-credentialReal creative calling it $cred, but that way I know exactly what lands in there. When doing this, PowerShell will pop up what appears to be a logon box, as shown in Figure A. This box is merely a collection point for the variable. Actual authentication happens at the service that needs to authenticate you, in this case, Exchange. You can pass the collected credentials when creating the session so they will be used rather than having the creation fail because it cannot get what it needs with your logged on credentials or because it cannot prompt you.
Now, we can create a session to Exchange
To establish a session, we create a variable called $session and store a new session object in it.
$session = New-PSSession
As parameters for that session, we give it the configuration name of the service we are going to use during the session (in this case Microsoft Exchange) and we provide the URI for the session to connect to on the Exchange server.
When you look at the IIS settings for Exchange 2010, you might notice there is a PowerShell directory within the Exchange website. This directory is where we need to land to work with Powershell.
If we add the Configuration Name and Connection URI to the Session it will look something like this:
$session = New-PSSession -configurationname Microsoft.Exchange -connectionURI http://<servername>/PowerShell
Where <ServerName> is the NetBIOS name or FQDN of the Exchange server you are remoting into.
The last part of the session is to pass the previously created credentials so they can be used. So the whole line would look like this:
$Session = New-PSSession -configurationname Microsoft.Exchange -connectionURI http://<servername>/Powershell -credential $cred
If you have an environment where the Exchange server does not trust your computer, you can pass additional parameters to skip certificate checking; however, I have found this unnecessary when using a workstation in the same domain as Exchange.
The only thing we have done so far is create a variable holding the session information; entering a session comes next. To connect to Exchange, simply enter the following on the next line:
This will connect to Exchange and pull the command-lets down to your machine allowing you to use them as long as the session is open. You should see this happen as the items are imported, but to check for the command-lets, enter get-command after the import completes, and the list of command-lets should now include Exchange command-lets, although you will need to scroll to locate them.
When you are finished managing Exchange, I would recommend closing the session to the server. This will prevent someone else from accidentally causing problems on your Exchange server if you step away. To do this, you can close the PowerShell window or enter the following on the next line:
For those who have been working with Exchange 2010 for a while and want to do more with PowerShell, this can be a great first step, bringing the tools needed right to your work environment. The nice thing about it is that you can still work with profiles, variables, and more without needing to recreate them on the Exchange 2010 server.
Derek Schauland has been tinkering with Windows systems since 1997. He has supported Windows NT 4, worked phone support for an ISP, and is currently the IT Manager for a manufacturing company in Wisconsin.