Share via

FIM 2010: How to Configure the Exchange 2010 RPS URI

  • Article

 

Introduction

The goal of this article is to explain the configuration of the Active Directory Management Agent (AD MA) so you can provision objects to Exchange 2010.

This article will not discuss the attribute flows for the Exchange attributes. It will focus on the Exchange 2010 RPS URI specification. You can configure this URI in the extensions tab of the AD MA connected to the domain hosting your Exchange environment.

Note

RPS URI stands for Remote PowerShell Uniform Resource Identifier.

The Exchange 2010 RPS is available on each server which has the Client Access (CAS) role of Exchange 2010 installed. Leveraging remote PowerShell it allows you to send commands to Exchange 2010 without the need for the Exchange Management tools.

Note

Provisioning towards Exchange 2007 requires the Exchange Management tools to be installed on the FIM Synchronization Server. Exchange 2010 does not have this dependency.

Client Access servers can be installed in various topologies. For redundancy they can be installed in a load balanced setup. In a load balanced setup one or more virtual names are chosen to access Client Access role components such as Outlook Web Access. The load balancing solution will then redirect clients to one of the nodes in the farm when accessing the virtual name.

One of the reasons to use a load balancing solution for Exchange 2010 CAS components can be redundancy. It completely makes sense to have your Exchange provisioning also benefit this redundancy. It's there anyhow, why not use it? Sadly there are some technical limitations.

 

Exchange 2010 RPS Requirements

The Exchange 2010 RPS feature is made available through the /powershell virtual directory (IIS). In order to properly access it, there are some requirements:

  1. Access it using HTTP
  2. Be authenticated using Kerberos

Use HTTP is pretty straightforward, however Kerberos authentication requires some explanation. Service Principal Names (SPN's) are a requirement for Kerberos authentication to take place. Every server has the HOST SPN registered on its computer account object by default. The HOST SPN is in fact an alias which includes many services. One of these services is HTTP. Otherwise said, when we access http://casservername.demo.com/powershell we can successfully be authenticated using Kerberos authentication without the need for any configuration changes.

On the other hand, if we use an alias like webmail and access http://webmail.contoso.com/powershell we will not be able to authenticate using Kerberos. This would involve registering http/webmail.contoso.com on an account in Active Directory. But because we are talking about an alias which is used to access 2 or more CAS servers, we'd have to set this SPN on a shared account: a service account. And that's where Exchange 2010 SP1 comes in. Starting from SP1 it's now supported to perform the changes required for Kerberos authentication to a name assigned to the CAS array. The process is explained here:

 

FIM 2010 Provisioning to Exchange 2010 (Pre SP1)

Before Exchange 2010 SP1 there was no way to properly Kerberos-enable the load balanced services. The only working way was to point the AD MA to a dedicated node in the load balanced farm:

 

 

And more specifically, the Exchange 2010 RPS URI had to be of the format: http://NetBIOSname.fqdn/powershell where NetBIOSname is the name of a CAS server.

 

FIM 2010 Provisioning to Exchange 2010 SP1 or later

Exchange 2010 SP1 introduced some changes which allow you to Kerberos enable the load balanced services. Now you can point the AD MA to the load balanced services using their virtual name. As such your Exchange provisioning will not be interrupted when a node is unavailable.

And more specifically, the Exchange 2010 RPS URI can be of the format: http://netbiosname.fqdn/powershell where VirtualName is the name of a load balanced service. Besides that the required configuration changes have to be performed on the Exchange side of things and the SPN's have to be registered for http/VirualName.fqdn.

Summary

 Depending on your exchange version you have the following options:

  1. Exchange 2010 pre SP1: http://casservername.demo.com/powershell
  2. Exchange 2010 SP1 or later: http://name-of-choice.demo.com/powershell

It's really important to follow these guidelines carefully. The difference between both is that before SP1 you really had to use the NetBIOS name of a Client Access Server whereas from SP1 and later you can choose a DNS alias to access your load balanced Client Access Servers.

 

 

 

Note

To provide feedback about this article, create a post on the FIM TechNet Forum.