Provisioning Microsoft Exchange accounts via NetIQ Identity Management (IDM) is a very common process. With IDM 4.0 you can now provision mailboxes to Exchange 2013. The big catch is that in order to provision to this version of Exchange you are required to go through the Windows PowerShell interface. Following the NetIQ AD driver documentation for IDM 4.0 you will be able to easily get everything set up. This means finding a server that you can install the following items:
IDM 4.0 Remote Loader (configured for the AD driver)
By default the remote loader and AD driver installed with the standard IDM installer doesn’t include Exchange 2013 support so be sure to apply all the necessary IDM engine and driver patches first.
Microsoft .NET 4.5
Microsoft Exchange Management Tools (for the proper version of Exchange)
Microsoft Windows Management Pack (installed by default on Windows 2008 Server R2)
NetIQ’s IDM PowerShell Service
However, before you start installing these components there are a few things you need to be aware of.
Whatever server you install the IDM PowerShell Service on will only be able to host the AD driver remote loader for the AD driver provisioning Exchange mailboxes. In many places it is customary to leverage a single server to host multiple remote loaders for multiple drivers however, if you want to use the IDM PowerShell Service on a server where multiple AD driver remote loaders are running this will not work. The AD.dll file used by remote loaders for AD drivers will automatically detect the presence of the IDM PowerShell Service and interact with it regardless of the driver’s configuration. This means that if you have multiple AD driver remote loaders running on the same server as the IDM PowerShell Service that there will be a conflict in the service due to the multiple driver inputs that will cause the IDM PowerShell Service to fail when trying to execute the proper PowerShell commands. The IDM PowerShell Service requires AD driver exclusivity on the remote loader server.
At the time of this article’s writing there is no option in the AD driver to specify a target Exchange server (see point 3 below for more on this). By default the IDM PowerShell Service will automatically poll the Active Directory domain the driver is connected to and search for an Exchange server. The service will automatically select the first Exchange server it finds within that target domain. That will be the Exchange server that the IDM PowerShell Service will attempt to execute the PowerShell cmdlets against.
Understanding how the IDM PowerShell Service selects an Exchange server by default helps us to understand a known issue with the IDM PowerShell Service. Because it is often very common for environments to have multiple versions of products if you are trying to use the IDM PowerShell Service to provision Exchange 2013 mailboxes in an environment that also has Exchange 2010 there is great potential for problems. The issue comes from when the IDM PowerShell Service searches the AD domain for an Exchange server. If the IDM PowerShell Service finds an Exchange 2010 server first then it will attempt to talk to that server which is problematic. Now NetIQ is aware of this issue and will be releasing a patch that will add a configuration property to the driver that will allow you to specify a target Exchange server. This will override the AD domain search and prevent the service from talking to unintended Exchange servers. Unfortunately there is not a release date for this patch yet but rumor has it that it could be released in late Sept. 2014.
Technically speaking packages are not required to leverage the IDM PowerShell Service using the driver’s out-of-the-box capabilities to provision mailboxes in Exchange 2013. In a single Exchange environment just install the components and create policies using the PSExecute attribute name along with the PowerShell commands and Bob’s your uncle! However, if you are running a mixed Exchange environment and/or need to target a specific Exchange server you will be required to “upgrade” the AD driver to include at least one package that will expose the new configuration option to specify the desired Exchange server. And again, that package/feature will be part of a future release AD driver patch from NetIQ that is expected to be released later this year.
When installing the IDM PowerShell Service be sure to use elevated privileges. The easiest way to do this is to run the Command Prompt “as Administrator”. Trying to run the install utility without elevated privileges will result in an error preventing the service from being installed and registered.
After installing the IDM PowerShell Service you can configure the service to run as either the local server account or as a specified user. By default the service will run as the local server account. Depending on how you prefer to have the service run you will need to grant the proper Exchange permissions in the target domain for either the machine or the user in order for the IDM PowerShell Service to properly execute the cmdlets. So just because the driver is configured to use a service account and that service account has the proper permissions doesn’t mean the Exchange cmdlets will work if the service is configured to use the local server account and that machine has not been given the required permissions.
Refer to the NetIQ AD driver documentation for more information about which permissions are required for each configuration option.
If you keep these things in mind then it should be pretty simple to configure Exchange 2013 provisioning within your environment. The main thing is making sure your IDM environment is properly patched and configured. The IDM PowerShell Service is stable and performs well when the conditions are correct. Troubleshooting though can be a bit more challenging when compared to drivers not leveraging this service.
There really isn’t much in the way of log files or output data that is generated by the IDM PowerShell Service so it is difficult to determine what is or isn’t working when an error is encountered. Sure the driver log will display the error returned from the service but it may not always provide specifics around the actual cause of the error. Of course the most common error is along the lines of “The cmdlet enable-mailbox could not be found or is missing…”. Typically this error is caused by a lack of Exchange permissions being granted to the account being used by the IDM PowerShell Service (see point 6 above) but can be caused by other issues too. You may also see this error if the IDM PowerShell Service is trying to talk to an invalid Exchange server as a result of its AD search (see points 2 & 3 above). And finally, you can see this error if you are trying to run the IDM PowerShell Service on a server that hosts multiple AD driver remote loaders (see point 1 above).
Essentially the issue is the same, the service is trying to talk to a server it lacks the proper permissions/access to execute the cmdlets. So the error in the driver log is accurate and valid but because the error can be caused by many different issues it is often difficult to tell what the actual cause is. The only way to resolve the issue is to just work through all of the various causes one by one in a trial and error fashion.
But rest assured that when you get it working it all works well. And sure, this may sound like a lot of caveats and catches but it is a lot better than the alternative, using the Scripting driver….