If you would like to read the other parts in this article series please go to:
- Automating Multi-Tenancy in Exchange Server 2010 SP2 (Part 1)
- Automating Multi-Tenancy in Exchange Server 2010 SP2 (Part 2)
- Automating Multi-Tenancy in Exchange Server 2010 SP2 (Part 3)
- Automating Multi-Tenancy in Exchange Server 2010 SP2 (Part 4)
- Automating Multi-Tenancy in Exchange Server 2010 SP2 (Part 5)
Creating the Active Directory
Now, that we got the idea of how the Orchestrator works it becomes easier to assembly all pieces together. I could create a single task with all cmdlets in a single place; however, I decided to go for a more methodical approach.
Do you still remember the script that we created in our last article? Well that is going to be key for us, let’s copy and paste the code related to Active Directory and as you can see everything that is in bold is the Domain variable that we created in our first object in Orchestrator.
Import-Module ActiveDirectory
New-ADOrganizationalUnit AndersonPatricio.ca -ProtectedFromAccidentalDeletion $False -ErrorVariable ADError
Set-ADForest apatricio.local -UPNSuffixes @{Add=”AndersonPatricio.ca“} -ErrorVariable ADError
Our job is to copy and paste the Active Directory code portion into a Run .NET Script activity and then replace the AndersonPatricio.cafor the subscribed data, the final result will be similar to Figure 01.
Figure 01
Let’s make sure that we link the two objects in our Runbook, and we can rename objects as well. Rename the Run .Net Script to Active Directory and the result will be similar to the one shown in Figure 02.
Figure 02
If we run the Runbook right now we are going to receive a prompt asking for the Domain and Short-Name. As soon as we type in the details, we will have the process completed with a new Organization Unit and UPN based on our automation.
Automating the Exchange domains…
We could have all tasks to create Domains and Address Lists on the same activity but again let’s use a different activity just for the Exchange domain (let’s say everything related to Organization/Hub Transport level). Create a Run .Net Script. The new activity should be configured as PowerShell in the type field, and the script code should be the two lines shown below. Make sure to replace AndersonPatricio.ca with your Published data from Initialize Data activity.
Note:
Make sure to perform the change to reflect your Active Directory FQDN on the second cmdlet in the –RecipientContainer switch.
New-AcceptedDomain -Name “AndersonPatricio.ca”-DomainName “AndersonPatricio.ca”
New-EmailAddressPolicy -Name ‘AndersonPatricio.ca‘ -RecipientContainer ‘yourdomain.local/AndersonPatricio.ca‘ -EnabledPrimarySMTPAddressTemplate ‘SMTP:@AndersonPatricio.ca‘ -IncludedRecipients ‘AllRecipients’
The Run .Net Script should be similar to the one shown in Figure 03.
Figure 03
Creating the Address Lists
Let’s drag and drop a new Run .Net Script activity and rename it to Address Lists, and create a link between the previous activity and this new one.
Since this section has more code, please make sure that you replace all YourDomain.Fqdn, AndersonPatricio.ca with your Domain published variable and AP by your short-name subscribed variable.
New-AddressList -Name “AP – All Users” -RecipientFilter {(RecipientType -eq ‘UserMailbox’)} -RecipientContainer “YourDomain.Fqdn/AndersonPatricio.ca“
New-AddressList -Name “AP – All Groups” -RecipientFilter {((RecipientType -eq “MailUniversalDistributionGroup”) -or (RecipientType -eq “DynamicDistributionGroup”))} -RecipientContainer “YourDomain.Fqdn /AndersonPatricio.ca“
New-AddressList -Name “AP – All Contacts” -RecipientFilter {((RecipientType -eq “MailContact”) -or (RecipientType -eq “MailUser”))} -RecipientContainer “YourDomain.Fqdn /AndersonPatricio.ca“
New-AddressList -Name “AP – All Rooms” -RecipientFilter {(Alias -ne $null) -and (RecipientDisplayType -eq ‘ConferenceRoomMailbox’) -or (RecipientDisplayType -eq ‘SyncedConferenceRoomMailbox’)} -RecipientContainer “YourDomain.Fqdn /AndersonPatricio.ca“
New-GlobalAddressList -Name “AP – Global Address List” -RecipientFilter {(Alias -ne $null)} -RecipientContainer YourDomain.Fqdn/AndersonPatricio.ca
New-OfflineAddressBook -Name “AP – Offline Address Book” -AddressLists “AP – Global Address List” -GlobalWebDistributionEnabled $True
New-AddressBookPolicy -Name ‘AndersonPatricio.ca‘ -GlobalAddressList “\AP – Global Address List” -OfflineAddressBook “\AP – Offline Address Book” -RoomList “\AP – All Rooms” -AddressLists “\AP – All Contacts”,”\AP – All Groups”,”\AP – All Users”
Make sure that you replace all static content by dynamic subscribed data and your script should be something similar to Figure 04 below.
Figure 04
We are almost there, we configured all the Run .Net Script activities and the Runbook should look like Figure 05.
Figure 05
By default, a regular account will not be able to see a Runbook and to assign permissions we should follow these steps:
- Logged on the Orchestrator Runbook Designer
- Right-click Runbooks and then click Permissions
- Add the user/group to the list and assign Read and Write permission
Here you have to decide if you want the new user to access all Runbooks or just a specific one. If it’s all Runbooks continue on the same window and perform the change. If it is in a specific Runbook ask permissions on that specific location and follow the same steps:
- Choose either the Runbook global level or a specific Runbook
- Make sure that you are on the Permissions window
- Select the desired user and click the Advanced button
- Select the user from the list and click Edit…
- Select Publish (Allow column) and click OK three times
Before releasing to production, rename the Runbook to New_Tenant to make it more appealing. Now, to release it to production we need to click Check In and after that the end-user will be able to see and run the Runbook.
End-User testing…
Now that the user has access to the web console, he or she can click New_Tenant and then click Start Runbook. A new page asking for the well-known Domain and Short-Name will be displayed. Type in (don’t use tabs!) and click Start and that is it! A new tenant will be added to your organization with 2 pieces of information – just two clicks. Wasn’t that hard, right?
By the way, when we select a Runbook, a summary of the Runbook will be displayed and the user can see even the definition (the actual activities) by clicking View Definition (Figure 06).
Figure 06
I would like to mention one last piece of information to confirm what we stated in the last article about permissions on the Orchestrator service account. Now that everything is being created automatically let’s see what is going on under the hood in our Exchange Server. First and most important note is that all those Exchange cmdlets are using the Orchestrator Service Account and we confirm that information using Search-AdminAuditLog as shown in Figure 07.
Figure 07
Analyzing the Runbook from Orchestrator Design
We are happy that our secretary is able to add new customers in a single click (ops… my mistake, in 2 clicks) and just to be safe we can check out some of the features available on the Orchestrator Console to control how the published Runbooks are working in our environment.
In Figure 08, you will notice that the icon of a checked in Runbook is different where the Runbook on the left is checked out and the highlighted is checked in. In addition, when we select a Runbook on the console we can see 4 (four) tabs that show the historic information about the runs, audit (related to changes in the Runbook), and in the Log tab we can see if the current Runbook is being executed.
Figure 08
If you want to have more information about a specific job, just double click it and all activity status of each activity component of that automation will be displayed (Figure 09).
Figure 09
Cleaning up a Tenant (or a failed one) from our Exchange organization …
During your testing you may forget something, so if you need to clean up a failed tenant these are the main steps and if you don’t have the items listed just skip to the next task and you should be fine.
- Remove Organization Unit using Active Directory Users and Computers
- Remove the UPN using Active Directory Domains and Trusts
- Remove the E-mail Address Policies (Organization Configuration / Hub Transport / E-mail Address Policies tab)
- Remove the Accepted Domains (Organization Configuration / Hub Transport / Accepted Domains tab)
- Remove the Address Book Policy (Organization Configuration / Mailbox / Address Book Policies tab)
- Remove the Offline Address Book (Organization Configuration / Mailbox / OfflineAddress Book tab)
- Remove the Address Lists (Organization Configuration / Mailbox / Address Lists tab). You will be able to remove using Exchange Management Console only the Address Lists not the Global Address List.
- Remove the Global Address List using Exchange Management Shell
Remove-GlobalAddressList “<Short-Name> – Global Address List”
You may be wondering… and the answer is yes, you can automate it if you wish to.
What else can improve what we have done so far?
We just scratched the surface when the topic is Orchestrator and Exchange, just for this current scenario we could improve the following attributes:
- We could get the current e-mail of the new customer and send a message to him with his domain information, perhaps adding a small PDF with an Introduction guide
- Orchestrator is able to work with Databases (Access and SQL) we could adapt the runbook to record the customer on a table and then we could have more information on the system
- We can automate the process to create Mailboxes, Distribution Groups, Contacts where the secretary fills out the basic information with domain and creates everything (add the object to the right Organization Unit, defines the UPN and assign the proper Address Book Policy).
Besides the improvements listed above, we also need to take care of the following key points:
- Backup your System Center Orchestrator Runbooks
- You can reduce the privileges of your Orchestrator Service Account
Conclusion
In this final article of our series about multi-tenancy using automation we went over the last steps required to automate the process.
If you would like to read the other parts in this article series please go to:
- Automating Multi-Tenancy in Exchange Server 2010 SP2 (Part 1)
- Automating Multi-Tenancy in Exchange Server 2010 SP2 (Part 2)
- Automating Multi-Tenancy in Exchange Server 2010 SP2 (Part 3)
- Automating Multi-Tenancy in Exchange Server 2010 SP2 (Part 4)
- Automating Multi-Tenancy in Exchange Server 2010 SP2 (Part 5)
