Microsoft Exchange is a system that is ideally suited for automation. It’s in almost every environment. It has it’s own add-on to PowerShell that makes it easy to write scripts to handle tasks. And most of the tasks that administrators perform after setup are rote tasks that are easily automated such as setting up mailboxes and adding IP addresses to a receive connector.
Why vCenter Orchestrator?
Exchange already contains a robust automation platform with the PowerShell-based Exchange Management Shell. This platform makes it easy to automate tasks through scripting. But no matter how well these scripts are written, executing command line tasks can be error-prone if the end users of the scripts aren’t comfortable with a command line. You may also want to limit input or provide a user-friendly interface to kicking off the script.
So what does that have to do with vCenter Orchestrator? Orchestrator is an extensible workflow automation tool released by VMware and included with the vCenter Server license. It supports Windows Remote Management and PowerShell through a plugin.
Start By Building a Jump Box/Scripting Server
Before we jump into configuring Orchestrator to talk to Exchange, we’ll need a Windows Server that we can configure to execute the scripts that Orchestrator will call. This server should run Windows Server 2008 R2 at a minimum, and you should avoid Server 2012 R2 because the Exchange 2010 PowerShell cmdlets are not compatible with PowerShell 4.0.
You will need to install the Exchange management tools on this server, and I would recommend a PowerShell IDE such as PowerGUI or Idera PowerShell Pro to aid in troubleshooting and testing.
Orchestrator and Exchange
As I mentioned above, Orchestrator can be used with PowerShell through a plugin. This plugin uses WinRM to connect to a Windows Server instance to execute PowerShell commands and scripts. In order to use this plugin, Orchestrator needs to be configured to support Kerberos authentication.
When I was testing out this combination, I was not able to get the Exchange Management Shell to load properly when using WinRM. I think the issue has to do with Kerberos authentication and WinRM.
When you use WinRM, you’re remoting into another system using PowerShell. In some ways, it is like Microsoft’s version of SSH – you’re logging into the system and working from a command line.
The Exchange cmdlets add another hop in that process. When you’re using the Exchange cmdlets, you’re executing those commands on one of your Exchange servers using a web service. Unfortunately, Kerberos does not work well with multiple hops, so another to access the remote server is needed.
Another Option is Needed
So if WinRM and the Orchestrator PowerShell plugin don’t work, how can you manage Exchange with Orchestrator? The answer is using the same remote access technology that is used for network hardware and Unix – SSH.
Since Exchange is Active Directory integrated, we’ll need an SSH server that runs on Windows, is compatible with PowerShell, and most importantly, supports Active Directory authentication. There are a couple of options that fit here such as the paid version of Bitvise, FreeSSHd, and nSoftware’s PowerShell Server.
There is one other catch, though. Orchestrator has a built-in SSH plugin to support automating tasks over SSH. However, this plugin does not support cached credentials, and it runs under whatever credentials the workflow is launched under. One of the reasons that I initially looked at Orchestrator for managing Exchange was to be able to delegate certain tasks to the help desk without having to grant them additional rights on any systems.
This leaves one option – PowerShell Server. PowerShell Server has an Orchestrator Plugin that can use a shared credential that is stored in the workflow. It is limited in some key ways, though, mainly that the plugin doesn’t process output from PowerShell. Getting information out will require sending emails from PowerShell.
You will need to install PowerShell Server onto your scripting box and configure it for interactive sessions.
Configuring the Exchange Management Shell for PowerShell Server
PowerShell Server supports the Exchange Management shell, but in a limited capacity. The method that their support page recommends breaks a few cmdlets, and I ran into issues with the commands for configuring resource mailboxes and working with ActiveSync devices.
One other method for launching the Exchange Management Shell from within your PowerShell SSH session is by using the following commands:
'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'
'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange-Modified.ps1'
|Note: It may be possible to use the method outlined by Derek Schauland in this TechRepublic article in place of modifying the EMS script. However, I have not tested this with technique with Orchestrator.|
Putting It All Together
Earlier this month, I talked about this topic on vBrownbag, and I demonstrated two examples of this code in action. You can watch it here.
One of the examples that I demonstrated during that vBrownbag talk was an employee termination workflow. I had a request for that workflow and the scripts that the workflow called, so I posted them out on my github site. The Terminate-DeactivateEmail.ps1 script that is found in the github repository is a working example.