Exchange 2007 CCR Delegated Setup – Unsupported Way ?

Griffon

Introduction

Working in a centralized administration model where your infrastructure has a main site and remote locations, you will probably need to delegate some of the tasks to your local administrators in order for them to perform their day to day jobs. 

Recently, we had to perform installations of  Exchange 2007 CCR clusters in those remote sites.  Hopefully, Microsoft is providing more than enough information about performing a Delegated setup of an Exchange 2007 Cluster.  We have developped our implementation guide based on the information found on technet (look here).

To summarize, in order to perform the delegated setup, you need to go through 4 steps :

  • Step 1 : You need to create your “Windows Cluster”. Basically, you configure your 2 windows nodes and form the initial cluster group
  • Step 2 : You need to create a new Cluster Group that will represent your Clustered Exchange.
  • Step 3 : The Enterprise admins needs to delegate rights to provision the cluster to the local admin site.
  • Step 4 : The final step consists of performing the installation of the Exchange Cluster Server    

This procedure works great ! No Doubt !  But the customer came to us asking if it was possible to perform the installation of the Exchange Server (a cluster) without going through step 2. In the beginning, we were quite surprised by the request. But then, this would make sense.  Microsoft claims that the clustering configuration of Exchange is simpler and that an Exchange administrator shouldn’t open the Cluster administration console. 

At first, we thought that this should be feasible with no glitches and we were quite confident that this would be an possible way to perform the installation.

The First Try (Hmm multiple Tries !)

So, we decided to setup a small test lab and perform a delegated installation of Exchange 2007 CCR.  We had to perform the setup more than once. We had the famous error “service cannot be started in a timely manner (to resolve the issue, look here)

  

After checking that everything was configured to perform a succesful installation,  we decided to give another try.   So far, no luck, the setup failed again.  The message error was something similar to the following  :  Error of unknown type occurred while performing exsetdata operation; the original error code was 0xc103fd2c.  After some search on google, I’ve found the same error code and a possible workaround to the issue (look here)

This blog didn’t really solved my problem. After double checking, there were no Duplicates records for the Exchange Object.  I started to wonder if it was really possible to setup a delegated Clustered Exchange without creating the Cluster Group for the Exchange Object (CMS).  On the other hand, I was wondering which kind of information the creation of the Exchange Cluster Group would be passed to the Exchange setup routine.  In my mind, there was no link or correlation between creating the Exchange cluster group and the setup of the Clustered Exchange.  So, I decided to take a deep dive into the Exchange Setup Log Files (This log is providing really a lot of useful information)  

 

  It took me some time before noticing the following lines in the Log Files (see screenshot above)

 [2] Leaving ScGetExchangeDsConfigFromDs
[6/27/2010 8:50:39 PM] [2] Server object already exists in the AD
[6/27/2010 8:50:39 PM] [2] Actual arguments passed to create EVS do not match existing server object in AD
[6/27/2010 8:50:39 PM] [2]  ScSetupExchangeVirtualServer (f:\08.02.0176\sources\dev\admin\src\udog\exsetdata\exsetds.cxx:2013)
           Error code 0XC103FD2C (64812): One or more of these parameters: Administrative Group, Routing Group, Administrative Group containing Routing Group, Install path, and Data path did not match the existing Active Directory object. Please use Exchange System Manager to retrieve the correct parameters for this operation.

Eureka !  Some of the arguments did not match the exiting Active Directory Object.  So what !  I had to dig a liltte bit more and came up with this procedure.

The Unsupported Procedure ??

Notes & Disclaimer !!

Use this procedure at your own risk ! I do not know if this is a supported procedure ! Moreover, we had to develop this procedure for a really specific environment where security was really tight and were delegated users had really the minimum rights needed to perform their day to day jobs.  

Finally, we would recommend you to follow the instructions provided by Microsoft for the delegated setup of the Exchange server.  If you do not want your local admin site to play and configure the Exchange Cluster Group, you can (as an option) try to develop a small script that would perform the configuration for the user.  The only information to be passed would be CMS Name and IP address of the Exchange Cluster.

We will briefly explain what we did in order to allow a local site administrator to perform the installation of the Clustered Exchange server without the need to create the Exchange Cluster Group. In the future, I hope I’ll be able to post a small video about this procedure.  Let’s Go !!

Step 1 : The local admin site install and configure the two nodes needed for the CCR Exchange Cluster

Step 2 : The local admin site (or the cluster team) perform the installation of the “Windows Cluster (no Exchange Cluster Group)

Step 3 : Enterprise Administrators create the Computer Object representing the future Exchange CCR Server in Active Directory. They need to ensure that the local admin site can join this object to the domain. They also create the Exchange Group that will be delegated the right to perform the setup and ensure that the appropriate account are members of this group. I have added the cluster server account in this group.

Step 4 : Enterprise Administrators provision the Exchange Objects using the /newprovisionedServer switch

 

Step 5 :  Check in your Exchange Console that the Exchange Server Objects have been provisioned accordingly

 

Step 6 : Check that the provisionned Exchange Server (2 nodes + Cluster Object) are members of the Exchange Server Group and the Exchange Domain Install Server group.  The provision switch should perform this action but in some cases this is not happening. Worst checking because if you don’t you will get an error message stating that you do not have enough rights to perform the installation

Step 6 : Create A and PTR for the Clustered Exchange Object in your DNS 

Step 7 :  Check your Exchange prerequistes before trying to install your exchange and update your host file if needed to avoid problems with non starting services ( look here)

Step 8 : This is what we have changed in order to have the installation working. This is where the magic is.   Using Adsiedit, browse to the Configuration Node -> Services-> Microsoft Exchange…->Administrative Groups -> Servers. There you can see your Exchange Servers.  In my case, the 2 nodes NMBX1 & NMBX2 and also the pre-staged Cluster Computer object for the Exchange Cluster EXCLU1

 

Step 9 : Enterprise Admins have to right-click on the future Cluster Exchange object and in the attributes, update the following attributes

  •  
    •  
      • Attribute : msExchDataPath                           Value = C:\Program Files\Microsoft\Exchange Server\Mailbox
      • Atrribute : msExchInstallPath                       Value =  C:\Program Files\Microsoft\Exchange Server\Mailbox
      • Attribute: msExchHomeRoutingGroup      Value = CN=Exchange Routing Group (DWBGZMFD01QNBJR),CN=Routing Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=MAILME,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=MyTEst,dc=Com
      • Attribute msExchServerSite                           Value=CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=MyTEst,dc=Com

Note : Replace these values with the values that fits your organization !! 

Step 10 :  The local site administrator should be ready to perform the installation of the CCR Exchange server with no need to go through the Cluster admin console

 

Final Words

After all, that was not so difficult to reach our goal.  I’ve performed so far 3 installations using this procedure and that was working (almost immediately – forgot prerequisites pfff…). 

 Again, I do not know if this is a supported way or if I really need to perform all these operations but it works for me !  If I do not update these values, i’m not able to perform the Installation of the CCR Exchange Server as requested by the customer (i.e delegated setup of CCR but no creation of the Exchange Cluster Group).

Finally, note again that the Microsoft procedure is working and it’s recommended. But if your customer ask you to simplify further the Delegated Setup procedure (for the Local Site Admin), you can try to use this one (at your own risk).  And let me know if it’s working for you

I’ll try to post a small video demonstrating this procedure

Till next time

see ya

Leave a Reply