FIM 2010 R2: Provisioning Coexisting Exchange using PowerShell MA
Introduction
One of the most common Forefront Identity Manager (FIM) scenarios is to automate provisioning of user accounts in an Active Directory domain. During this provisioning process, you might be asked to create a Microsoft Exchange Mailbox. Using your Active Directory Management Agent (ADMA), you can provide information about your Exchange environment. ADMA can be configured to provision mailboxes for different Exchange versions. You can choose Exchange 2007 or Exchange 2010/2013. For more details about how to use your ADMA to provisioning Exchange mailboxes, please check the link below.
http://technet.microsoft.com/en-us/magazine/ff472471.aspx
In this article, we will discuss a challenging Exchange Mailbox provisioning scenario, which you can come across.
This client has an active directory domain, and two versions for Exchange are running. One is Exchange 2007, and the other is Exchange 2013. The client has FIM configured to provision Exchange 2007 mailboxes. As they are migrating to Exchange 2013, they want FIM to start provisioning Exchange 2013 mailboxes. However, new users in some office locations will still get Exchange 2007 mailboxes, until they are ready for Exchange 2013.
The Challenge
As mentioned earlier, FIM will provision mailboxes based on the user's office location. For example, a new user that works in the New York office will get an Exchange 2013 mailbox, whereas a user in London office will get an Exchange 2007 mailbox.
ADMA can be used to provision to one Exchange version only. Any attempt to provision to an Exchange mailbox that has different version than the one in the MA properties will result in an error in FIM or an incorrect setup of the mailbox.
Also, FIM Service is not installed in this environment. We will not be able to execute custom action workflows.
Moreover, Exchange 2007 mailbox provisioning is different than Exchange 2013 mailbox provisioning in two ways:
- Exchange 2007 mailbox provisioning uses the Exchange Management Console, so it has to be installed on the Synchronization Service machine, and it uses Exchange 2007 Recipient Update Service (RUS). On the other hand, Exchange 2013 utilizes Remote PowerShell (RPS).
- There is an additional attribute that will need to be set for Exchange 2013 provisioning. This attribute is msExchHomeServerName.
Finally, creating two Active Directory Management Agents that point to the same forest is not a good practice. In essence, ADMA1 will be configured to provision Exchange 2007 mailboxes for new users. ADMA2 will be configured to provision Exchange 2013 mailboxes. It will create more complication than it will address the challenge.
The Solution
The solution will consist of three parts:
- How to identify what version of Exchange that needs to be provisioned based on Office Location?
- How to provision new accounts in each mail system?
- How to plan for future office location migration to Exchange 2013?
We will utilize a configuration file. This file will be used to identify what version of Exchange to be provisioned based on Office Location. The table below shows an example of the configuration file.
OfficeLocation |
ExchangeVersion |
homeMDB |
msExchHomeServerName |
New York |
2013 |
<value for homeMDB> |
<value for msExchHomeServerName |
London |
2007 |
<value for homeMDB> |
|
Dubai |
2007 |
<value for homeMDB> |
|
This configuration file will be checked during the provisioning code in FIM. If ExchangeVersion for this user equals 2013, then provision a an Exchange 2013 mailbox using ADMA. If ExchangeVersion equals 2007, then create a normal AD user account with no mailbox and set a value for extensionAttribute14.
01.if (exVersion == "2013")
02.{
03. csentry = ExchangeUtils.CreateMailbox(ADMA, dn, sAMAccountName, homeMDB);
04. csentry["msExchHomeServerName"].Value = msExchHomeServerName;
05. csentry["mailNickname"].Value = sAMAccountName;
06.}
07.else if (exVersion == "2007")
08.{
09. //Create a normal account
10. csentry = ADMA.Connectors.StartNewConnector("user");
11. csentry["extensionAttribute14"].Value = exVersion;
12.}
Creating the user without a mailbox will now allow us to provision the appropriate Exchange 2007 Mailbox for users. To address the Exchange 2007 scenario, we will utilize the PowerShell Management Agent. Using this MA, we will import user accounts that don't have an email and their extensionAttribute14 equals "2007". I will share my PowerShell script an explain it in a later post.
When there is a new user in PowerShellMA for Exchange 2007, FIM will join it with a Metaverse object. Then, it will update some of the attributes. This update operation will execute the cmdlet Enable-Mailbox on that user.
Note
After the user gets a mailbox, the next import run on PSMA for Exchange 2007 will delete the user from the connector space. I will explain how and why I'm doing so in my later post.
The diagram below illustrates the provisioning process for new accounts:
Future Migration of Office Locations
As new office locations are ready for Exchange 2013, all we need to do is update the configuration file. We need to change the ExchangeVersion from 2007 to 2013. Also, we need to provide a value for msExchHomeServerName.
To minimize overhead from doing import, sync and export on PSMA, we are checking the number of export changes. If there are no changes, then we will not run any further profiles for the PSMA.
Conclusion
This approach to addressing a co-existence scenario between two Exchange version minimizes deployment efforts. We will not need to use the FIM Service. It also makes migrating new office locations to 2013 easier.
The Active Directory Management Agent (ADMA) will be used to provision Exchange 2013 mailboxes. PowerShell Management Agent (PSMA) will enable 2007 mailbox for new AD accounts that don't have a mailbox.