Automation–Orchestrator and the Exchange PowerShell Activity
A question came up on an internal distribution list recently about how to create an Exchange Distribution List leveraging Orchestrator. Well, I did some investigation and in fact collaborated with Charles Joy on this because we were both curious. The setup and configuration is the trickiest part and you’ll have to do some configuration on more than just your Orchestrator infrastructure. The Exchange server will need to be modified to support this. I highly recommend taking this into the lab first so you know all the moving parts!
Let’s Dive In!
Step 1:Go Download the Integration Pack and Do Some Configuration
You’re going to want to make sure that all is followed to the letter on the following URL: https://technet.microsoft.com/en-us/library/jj614529.aspx. I also recommend after all configurations are done, doing a GPUPDATE /FORCE if you can on the Exchange and Orchestrator servers to update Group Policy and ensure all is up to date. This is probably the most important step (preparation) because if this isn’t done exactly right, you will get very frustrated later on .
Step 2: Ensure You Have an ID with the “Juice”
Ensure that the account you have defined in your Exchange Admin Connection (found under Options in the Orchestrator Designer) has enough rights to create a Distribution List for Exchange. See my very basic configuration shown below and I turned all validation off in my lab. I also used port 80 and did not use SSL. I can’t stress enough to make sure you are working with an account that has appropriate rights to do what you need or you’ll find yourself spending a bit of time wondering why things aren’t working.
Troubleshooting Note A way to validate rights for the service account you have created / been given would be to make the same connection to your Exchange server in a PowerShell session as you would be with Orchestrator using the same account you configured above. Then executing a simple command to validate you have rights.
Example
001 002 003 004 005 006 | $conn = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ex01.contoso.com/PowerShell/ -Authentication Kerberos -Credential (Get-Credential) Import-PSSession $conn Get-User #Don't forget to remove the session :) Remove-PSSession $conn |
You should get something like the below for output. If you get this, you know you have at least got a good connection – event better, next steps will leverage this last command (Get-User) to validate in connectivity in Orchestrator.
Step 3: Create a Basic Runbook
Create a simple Runbook to get the connection and rights tested out. Grab the “Run Exchange Management Shell CMDLET” activity out of the Exchange Admin list of activities, on the right pane within the Orchestrator Designer, and drop it into a basic Runbook. See below, I’m putting in the “Get-User” command in the Command Text box to do essentially what we did in step 2 but with Orchestrator this time. Ensure you change the option for Is Exchange Command to True to ensure you can successfully execute this command against the Exchange cmdlets.
Step 4: Test – Iterate – Test 
To get some basic testing going on and a successful Runbook execution put in a really basic script execution to ensure you have rights and can access the Exchange Server with that account you specified in the connection. Run it. My suggestion is to start simple and make sure you are doing queries instead of creations at least at the beginning so you don’t have to constantly go back in and remove what you’ve created.
Important Note Testing is not done in the Orchestrator test console for this. This activity leverages a PowerShell module on the Exchange server so in order to do proper testing, you need to have this checked in and executed from the Runbook Designer or it will fail (unless of course you have the necessary support installed on your system you are testing from).
Step 5: Validate Success as You Go.
You are looking for a “green” result showing some data coming back. If you get a red, and it shows “access denied”, check the user account. If it shows something on WINRM / PS Remoting, check step 1 above. You’re looking for Command Output Data within the returned results from the activity.
Step 6: Create your Test Distribution List
Add in a bit of PowerShell into your existing activity to test the creation of a statically named DL and then add a list of users to that successfully created DL. Example below, replace with stuff that exists in your environment.
001 002 003 004 | $DLGroup = "Dist4" $Members = @() $Members = "!ex" , "!sp" , "administrator" New-DistributionGroup –Name $DLGroup -Members $Members -OrganizationalUnit "contoso.com/rooms" |
Step “N”… : Go Nuts, Get Dynamic
Iterate on this and add logic to check for the existence of the DL and if it does exist add members instead of trying to create and add members, etc. Really depends upon what you are trying to accomplish. The other piece here is of course using dynamic data to populate this information instead of statically assigned data (use the power of Orchestrator and dynamic published data!). This can come in many forms (including directly from multiple AD groups, SQL, CSV, etc.). Trick here is ensuring you are putting in proper logic to make decisions since this automation is doing the work of your brain . In the below example I added a bit more rudementary checking to illustrate what I’m talking about. If the DL exists, just update the membership with the new array, otherwise create it and add members.
001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 | $DLGroup = "Dist4" $Members = @() $Members = "!ex" , "!sp" , "administrator" , "Jbritt" $DLExists = "" $DLExists = Get-DistributionGroup $DLGroup If ($DLExists) { Update-DistributionGroupMember –Identity $DLGroup -Members $Members -Confirm:$False } else { New-DistributionGroup -Name $DLGroup -Members $Members -OrganizationalUnit "contoso.com/rooms" } |
Keep in mind that if you wanted to Add a member instead of Update membership, you’ll likely want to use a foreach loop similar to below to process the array and potentially adding a try/catch for members that already exist.
001 002 003 004 | foreach($member in $members) { Add-DistributionGroupMember -Identity $DLGroup -Member $Member } |
That’s it! I hope that gave some decent guidance on the use of the Orchestrator PowerShell activity for Exchange. For more information and tips/tricks for Orchestrator, be sure to watch for blog posts in the Automation Track!
Till next time, Happy Automating!
Comments
- Anonymous
January 01, 2003
The comment has been removed - Anonymous
January 01, 2003
@dani kuci
According this this URL, basic is actually required to get this working with the Orchestrator integration pack.http://technet.microsoft.com/en-us/library/jj614529.aspx - Anonymous
January 01, 2003
The comment has been removed - Anonymous
January 01, 2003
Thank you for sharing. - Anonymous
January 01, 2003
@Ed (DareDevil57) - absolutely :) - Anonymous
June 16, 2013
The comment has been removed - Anonymous
April 15, 2014
Original post: http://blogs.technet.com/b/privatecloud/archive/2013/06/12/automation-orchestrator-and - Anonymous
May 05, 2014
Hi All,
I encountered a error/issue with establishing a connection to Exchange, and it took me a day to search the entire Internet to find a solution.
I have documented my solution on my blog (MiCloud) here: http://adinermie.wordpress.com/2014/05/05/orchestrator-2012-r2-exchange-admin-integration-pack-access-is-denied-error/, in case it will help anyone else. - Anonymous
August 07, 2014
本文是 Brad Anderson “ Windows Server 和 System Center 2012 R2 新增功能 ”精选系列文章的第九部分。这篇文章介绍了 Service - Anonymous
August 11, 2014
Jim,
Do you know if it is possible to configure the Exchange Admin IP to use kerberos instead of basic authentication? Or is basic authentication a requirement? - Anonymous
August 27, 2014
原文地址: http://blogs.technet.com/b/privatecloud/archive/2013/08/14/automation-service-management-automation