In part one of this series we looked at some of the basic aspects of the PowerShell environment. Let’s now look at the underlying mechanics on Exchange 2007 and 2010 servers. We will need to address some aspects separately due to the different mechanisms that are used between Exchange 2007 and Exchange 2010.
For part one please click here.
For part three please click here.
Let’s kick off by looking at the older and simpler of the two, Exchange 2007.
Exchange 2007 – Local PowerShell
In Exchange 2007 when you open the PowerShell window, the PowerShell snap-ins are loaded up directly into the PowerShell console. This can be easily seen in the PowerShell window by running Get-PSSnapin. Note the differences in the following screenshots where you can see that there are no Exchange specific snap-ins loaded in the first window, whereas these are visible in the second window.
The Exchange 2007 EMS (Exchange Management Shell) where the Exchange SnapIn is visible as:
Name: Microsoft.Exchange.Management.PowerShell.Admin
PSVersion: 1.0
Description: Admin Tasks for the Exchange Server
Exchange 2010 EMS showing no Exchange specific snapins loaded.
In Exchange 2007, the EMS creates a local session in which the Exchange cmdlets and non-Exchange cmdlets execute. Note that all Exchange 2007 cmdlets run in this local session even though the command being executed may impact a remote object.
Since Exchange 2007 does not have RBAC (Role Based Access Control – the permission model used in Exchange 2010 and Lync), administrators require access to the machine to start the EMS and also ACLs on the relevant objects (users, mailbox enabled users etc.) that they will manage. It is a challenge to craft the correct ACL so that an administrator, especially a delegated or junior administrator, has the correct level of permissions and to then maintain the correct structure over time due to changes in the environment (e.g. moving users or restructuring Active Directory).
Having to maintain a series of complicated ACLs for Exchange 2003/2007 on a multitude of objects has sometimes been lovingly called “ACL Spray”! Thankfully this is addressed in Exchange 2010 with RBAC, and you can read more about RBAC on this blog.
Exchange 2010 – Remote PowerShell
Exchange 2010 utilises a different mechanism to provide EMS access as it no longer uses a local PowerShell session and instead leverages a remote PowerShell session. This is possible since PowerShell 2.0 introduced a remoting feature. It is critical to understand that this remoting feature is the core of the Exchange 2010 administrative framework. The Windows Remote Management 2.0 (WinRM) service and the Web Services for Management (WS-Management) are the key ingredients that make remoting possible. Regular Windows administrators will typically leverage a fan-out remoting paradigm where their admin machine will reach out and touch multiple other machines. For Exchange 2010 the pattern is reversed as multiple admins will be connecting into a single Exchange server, which is the fan-in model. Since Exchange 2010 leverages remoting this is the reason why the system requirements state that WinRM and PowerShell 2.0 must be installed on both the server and any management workstations.
Note that the Edge server does not leverage remoting.
While WS-Management can be hosted in either IIS or directly in the WinRM service, Exchange 2010 provides its fan-in capabilities by hosting it in IIS. Using the ISAPI paradigm, a single process on the IIS host is used, rather than in the CGI model which would result in multiple processes. If you were to open the IIS manager on an Exchange 2010 server you would see the PowerShell Virtual Directory (vdir).
With it’s associated application pool:
Note the MSExchangePowerShellAppPool running in the security context of local system which is a requirement for RBAC to function.
The PowerShell IIS vdir works with WinRM to provide the listener for WS-Management requests, and then processes the request.
Connecting To A Remote Exchange 2010 PowerShell Session
In order to understand how we connect to a remote session we need to be clear exactly what exists on the local machine and Exchange server respectively. When the standard PowerShell console is opened on a machine, you are interacting in the local computer’s PowerShell runspace; this is the client-side session. This session contains only default PowerShell 2.0 cmdlets because no Exchange 2010 snap-in or module is loaded.
The Exchange 2010 cmdlets will become available after a remote session has successfully been established. This requires that a remote connection is made to an Exchange 2010 server via PowerShell 2.0 which successfully authenticates and then imports the server-side runspace.
Connecting to an Exchange 2010 server creates a remote PowerShell session that is called a PSSession. An established PSSession to an Exchange 2010 server can be seen here:
Note that the –AutoSize has been added to facilitate easier reading.
Since Exchange 2010 cmdlets are available via a remote session, these are not present in the local session, which is why the CommandType in PowerShell is shown as a function rather than as a cmdlet. The difference can be noted in the following screenshots.
Exchange 2007:
Exchange 2010:
Administrators must authenticate to the the WinRM instance that is hosted within IIS on the Exchange server. This can happen implicitly by using the logged on credentials to the domain, or explicitly by providing specific credentials. Note that this is a key step as only the cmdlets, and the specific cmdlet parameters, that a person has been granted access to will be displayed, i.e. RBAC will scope the results. In other words, if you do not have permission to use a cmdlet or a parameter then you will not even see it as an option. This is contained in a server-side runspace, which is then returned to the client-side session when it is represented as a PSSession object in memory. But before the cmdlets in the runspace can be used they must be imported via the PSSession. Once imported, the cmdlets can be used just like any other cmdlet. Importing the PSSession creates a PowerShell module that defines all the cmdlets that are available in the server-side runspace. The module is then loaded up into the local runspace and is shown in the below screenshots.
The Exchange 2010 imported Module piped to Format-List.
This module does not directly contain the actual cmdlets from the server-side runspace, rather the module contains functions that act as references to the server-side cmdlets. When one of these functions is executed, it passes the information needed to execute the cmdlet on the server, and the results are returned to the client-side session. This means that the Exchange 2010 cmdlets run implicitly in the session from which they were imported from. Administrators do not need to worry about this as PowerShell manages such aspects in the background.
Start Me Up
Now that we have looked at some of the plumbing that is used, what mechanisms does an administrator have to start the EMS? There are two ways that they can connect to an Exchange 2010 server using PowerShell:
- Automatic connection
- Manual connection
Both of these have their own pros and cons, so let’s take a look at them.
1. Automatic Connection
Typically Exchange administrators will use the EMS shortcut created automagically by Exchange setup. This shortcut will automatically connect to the nearest Exchange 2010 server. Note that this requires the workstation/server to be domain joined to the forest where Exchange 2010 is installed.
In the Exchange server Bin directory the following scripts are used with the EMS shortcut.
- RemoteExchange.ps1
- ConnectFunctions.ps1The RemoteExchange.ps1 script is responsible for multiple items that make the EMS different from a standard PowerShell window. Amongst other things it will:
- Increase the window width
- Load ConnectFunctions.ps1 script
- Create Exchange variables, $exbin, $exinstall, $exscript
- Defines functions, Get-tip, Get-ExCommand, Get-ExBlog, Get-ExBannerThe ConnectFunctions.ps1script defines the Connect-ExchangeServer and Discover-Exchange server functions which are available for administrators to use.The Connect-ExchangeServer function is used to establish a new PowerShell session to an Exchange 2010 server and imports an implicit client-side runspace from the server. This function simplifies the connection process by automatically discovering an Exchanger server or using one provided by an administrator. The EMS shortcut specifies the Auto parameter in its shortcut which causes Connect-ExchangeServer to automatically select the most appropriate Exchange server. If EMS is used on an Exchange server locally, it will try to connect to the local PowerShell vdir, and if the connection fails then try other Exchange servers as specified by the Auto function. The Auto function will attempt to connect to an Exchange 2010 server in the following preference
- CAS server in local site
- Non-CAS server in local site
- CAS server anywhere in the forest
- Non-CAS server anywhere in the forest
The New-PSSession is used by the ConnectFunctions.ps1 script in an attempt to connect to the determined server. The function displays a message identifying the server identified. If the connection succeeds and the new PSSession object is created, the function proceeds to import the runspace. If the automatic connection attempt were to fail, an error is displayed, and the function moves on to the next server in the list. Should all automatic connection attempts fail, the administrator is prompted to enter a server to connect to.
When a connection is successfully completed, the Connect-ExchangeServer function creates a PSSession object and stores it in memory. Once saved the implicit client-side session is created. The PSSession object will contain all the cmdlets, functions, aliases that RBAC will make available to the specified user, though they will not be available until they are imported from the PSSession and loaded up into the local PowerShell session using the implicit remoting module. Connect-ExchangeServer uses Export-PSSession cmdlet to generate an implicit remoting module which is then imported using the import-module
The above let us easily use the EMS in an simple manner so we get the familiar screen as shown here:
Pros of Automatic Connection
- Easiest method to connect
- Attempts to connect to different servers should the first choice be unavailable
Cons of Automatic Connection
- Management station to be joined to same forest as Exchange servers to be managed
- If the script files are missing then you will be unable to connect. This was reported by some customers upgrading from Exchange 2010 RTM to SP1.
2. Manual Connection
Though the general recommendation is that Administrators use the provided shortcut that is created when the Exchange Management Tools are installed, it is also possible to start the EMS manually. Manual connections still requires the same prerequisites as the EMS shortcut (i.e. WinRM 2.0 and PowerShell 2.0).
Since the connection is being made manually the RemoteExchange.ps1 script is not used so the functions, aliases and variables loaded by the script are not available. Because of these factors and the extra administrator overhead, the management experience is not as complete as the the automatic connection provided by the EMS shortcut.
Since this is harder why would we want to do this? We can connect to Exchange 2010 from a machine that is not joined to the same forest so it lights up remote management options. We also do not have to have the Exchange 2010 management tools installed on the local machine. Since Exchange 2010 is only available in x64, this allows x86 workstations to be used to administrator Exchange 2010.
Note that some additional aspects must be considered to allow connections from workstations that are not joined to the same forest. Domain joined machines can use integrated windows authentication, but this is not possible for workgroup machines that will have to explicitly provide credentials. The authentication must be enabled on the PowerShell vdir which is not configured by default.
Exchange 2010 EMS only allows secured and encrypted connections by default. For machines in the same forest, Kerberos authentication is used and EMS connects to port 80 TCP on the Exchange server. For untrusted domains or workgroup machines, HTTPS must be used for encryption which means that the remote machine trusts the certificate used on Exchange or the PSSession option to ignore certificate errors is set.
Pros of Manual Connection
- Can connect from non trusted domain/forests and workgroup machines
- Allows management from older management stations, or x86 based machines.
- Do not have to install Exchange Management tools
Cons of Manual Connection
- More administrative effort required
- User experience not as rich as with the shortcut
- Need to address encryption and authentication issues
Manual Connection Examples
Example #1: Same Forest
Here is a manual connection from a Windows 7 machine in the same forest as Exchange that does not have the Exchange 2010 Management Tools installed.
Firstly let us enter the credentials to the administrator account since we are logged on as a domain user account:
$Credentials = Get-Credential
Now that the credentials are saved, we can create a new session with those credentials:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<FQDN of Exchange 2010 server>/PowerShell/ -Authentication Kerberos -Credential $Credentials
Finally, we can import the session:
Import-PSSession $Session
Once the module has been imported, we have the capability to run all the Exchange tasks that we are permitted by RBAC.
Again note the title bar – this is the x86 PowerShell window that is used.
When the task has been completed the PSSession can be removed:
Remove-PSSession $Session
Note that Get-Mailbox no longer works since we do not have access to the remote server.
For the security conscious amongst us, you may have noted that the connection URL is HTTP rather than HTTPS in this scenario. This is because the workstation was in the same forest as the Exchange server so we could use Kerberos. Even though we connect to the /PowerShell vdir using HTTP, the connection is encrypted using Kerberos and data is not passed over the wire in clear text.
Ilse has a great write up on this over on her most awesome blog, I encourage you to subscribe to her RSS feed.
Example #2: Remote Forest
This is an example of a machine in a non-trusted forest connecting to Exchange in a separate forest.
Note the errors relating to the certificate. Since the certificate is not trusted we need to set the options in the PSSessionOption to skip the certificate checks.
Now that the certificate issue has been ignored, we can see the next issue, as the PowerShell vdir is not set to allow authentication by default.
Windows Integrated was then enabled on the vdir since it was not previously enabled. Note that Windows Authentication is now set to Enabled.
After enabling authentication we are able to connect and run cmdlets.
Hope you found this helpful. Let me know if you have any questions or comments.
For part one please click here.
For part three please click here.
Cheers,
Rhoderick
