Sunday, July 27, 2014

Exchange 2010 (SP3) - Migration - some remarks about SCPs (service connection points)

Introduction

What follows is not a step in the migration process to Exchange 2010 but rather some remarks concerning a possible (and essentially hypothetical) issue with Service Connection Points (SCPs). Unless some bizarre factor alters the normal state and order of the SCPs, there is nothing that needs to be done at this level. For details, read what follows...


***

Will the simple installation of Exchange 2010 in an Exchange 2007 environment affect the users?

This is an important question.  Besides interruption of normal business operations, we want to avoid the distraction of popups indicating something is wrong with "some certificate".

One concern voiced somewhere (I do not recall exactly where) was the creation of a SCP (Service Connection Point) record for the new Exchange 2010 server in Active Directory.

Note: what follows concerns domain members that can access Active Directory locally or "onsite". The process is different for remote clients (users accessing their email from home or on the road).

***

When Outlook (since version 2007) attempts to connect to Exchange, it will first consult a domain controller and seek a SCP that indicates the URL of a client access server with autodiscover services. These services will configure the connection to the client mailbox automatically. This is the process we can observe when we open Outlook for the first time.

I wrote "URL" but the autodiscover "URL" is defined with the Set-ClientAccessServer cmdlet and the -AutoDiscoverServiceInternalUri parameter, for example:

Set-ClientAccessServer -Identity "CAS1" -AutoDiscoverServiceInternalUri "https://mail.contoso.com/autodiscover/autodiscover.xml"

Remark the Uri at the end of the -AutoDiscoverServiceInternalUri parameter. By default, the name of the CAS would be in the position of "mail". If we follow best practices, we would replace it (as in the above example) with a term like "mail". Moreover, the associated record in DNS (not to be confused with the SCP record - these are totally different concepts) would designate some sort of load balancer that forwards client requests to one of two or more Client Access Servers. 

When a new Exchange Client Access Server is installed, a SCP record is created for it in Active Directory.

That SCP object (record) can be found here:

CN=Name of Exchange server,CN=Autodiscover,CN=Protocols,CN=Name of Exchange  server,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=organization Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com

For example:



We can right-click on the folder with the servername, select "Properties", and see the SCP details under the Attribute Editor tab.

By default, the “serviceBindingInformation” attribute designates the CAS with an URL like this:

"https://ex-server-1.contoso.com/autodiscover/autodiscover.xml"

In theory, these default settings could hypothetically cause the following problem if the SCP of the new Exchange 2010 server was selected.

If the certificates used to validate the server do not include the name of the server itself, an error message will display, stating that the name of the server does not match the name (or names) on the certificate. This causes confusion for the user and calls to the help desk. Users could opt to trust the certificate without understanding the possible implications. In this case, we know the server is one of our servers and can be trusted. In general, however, it is a security risk to interact with servers whose identity cannot be validated.

In practice, it appears that this scenario should never occur since the client should select the "first" SCP record (if there is more than one).

Note: we assume that the first SCP record has been configured as appropriate with the Set-ClientAccessServer cmdlet as mentioned above, something like "mail" instead of "CAS1" (and with a corresponding record in DNS pointing to a load balancer).

So I examine the location indicated above (either ADSIEdit or Active Directory Sites and Services - with the "Show Services Node" option - can be used).

I have two servers: EX1 (the Exchange 2007 server) and EX13-1 (the Exchange 2010 server):




Next, I must expand the respective folders to reach the SCP:




Once again, we right-click on the folder with the servername, select "Properties", and see the SCP details under the  "Attribute Editor" tab:




OK, the folder for EX1 is above the folder for EX13-1. Can we conclude that the SCP record contained in this folder is the "first" SCP record?

Other sources state that the "oldest" SCP record will be selected, or the SCP record that was "created first".

So I compare the "whenCreated" value of each of the SCP records. As we can see (last entry in the screenshot above), the SCP record for EX13-1 was created on 7/9/2014. The SCP for EX1 was created before that date.

***

Finally, I have observed from experience that clients apparently do select the oldest SCP record since no error message is displayed when they access their email. This is true even before I change the client access URLs on the Exchange 2010 server so they match the names on the certificate used to validate access.

***

In conclusion, simply installing Exchange 2010 should have no effect on normal business operations.


EDIT

After having tested this, I confidently installed Exchange 2010 in a production environment. The plan was to import and enable a UCC/SAN certificate that evening. However, we had to concentrate on the resolution of a problem with an update and thought we could safely wait to install the certificate.

What happened the next morning?

Certificate warnings for users when they opened Outlook...

We installed the certificate immediately and the warnings no longer displayed when users opened Outlook.

I'm not sure why this happened. I suspect that, although the oldest SCP record is selected (there seems to be consensus on this), the autodiscover information may include references to all or any one of the servers, without distinction.

I ran the autoconfiguration test (press Ctrl, right-click on the Outlook icon in the taskbar) and the references to the Exchange 2010 server were for OWA and OAB (everything else - EWS, UM, etc. - was for the Exchange 2007 server).

Lesson learned: import and enable the UCC/SAN certificate as part of the installation process of Exchange 2010.

No comments:

Post a Comment