Skip navigation

Category Archives: Exchange 2007




This procedure is for when you absolutely can’t do anything with your Exchange 2007 Server. This procedure will help when: 

  1. Exchange is not functioning
  2. Your restore hasn’t worked, or your backups are non-existant or unreliable
  3. Your databases are still intact
  4. You cannot uninstall or reinstall Exchange 2007 by normal means

One way to resolve this problem might be to try to mount your databases on another functioning Exchange 2007 server. Once you have mounted your databases on another server, you can then work on the non-functioning server by following the manually uninstall step below. 

A good article for mounting your databases on another server is available at the link below: 

But if you don’t have another Exchange 2007 server handy, you might like to consider the procedure below: 



Only consider the procedure below if you have exhausted all other avenues, including: 

  • Reviewing all servers in your network; the unavailability of DC’s, GC’s and DNS servers, or problems with DNS can lead to unpredictable problems with Exchange.
  • Restoring from backups
  • Escalating to Microsoft’s PSS if that is an option available to you

The procedure below was tested by myself in my Test Lab and so I can verify that it works. But every organization is different and so you should proceed with caution and at your own risk. You should revise the whole of this blog before proceeding.


Manually uninstall

Manually removing Exchange 2007 is not supported by Microsoft. If you take this path, Microsoft will likely not assist you should it go wrong. Microsoft would want you to remove Exchange 2007 from the control panel, but you have tried that and it has not worked. 

Before you follow this procedure, you will need to locate the Windows Installer CleanUp Utility. This was a utility that was primarily used to cleanup a failed Office install, but known to cleanup other Installer failures. Unfortunately, Microsoft has now removed it from their download sites – they had found that there were some situations where the Utility might damage other components.


Perform a search on the Internet for MSICUU2.exe. Take care to locate the right file – it’s a zipped exe with a size on disk of 352KB.


When you are ready, take the following steps:

1. Run setup /m:uninstall

You may find that if you were unable to uninstall Exchange 2007 from the Control Panel, you may not be able to perform the above step either. Don’t worry. Move on to step 2.

2. Stop and disable all the Exchange 2007 services

3. Use Registry Editor (Start->Run->Regedit) to remove these Exchange related registry keys:

  • HKLM\SOFTWARE\Microsoft\Exchange
  • HKLM\SYSTEM\CurrentControlSet\Services\MSExchange* (all the keys starting with “MSExchange”)
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Microsoft Exchange

4. Remove the entire Web Server role (don’t forget to reinstall afterwards as it’s a prerequisite for Exchange 2007!)

5. Remove the Exchange 2007 server from Active Directory using ADSIEdit. Action-Connect To. And then in the Configuration Settings window, select the Configuration context and click OK. See image below.

6. In ADSIEdit, expand Configuration through to CN=Services.

7. Expand Services. Expand CN=Microsoft Exchange. Expand CN=Your_Domain. Expand CN=Administrative Groups.

8. Expand CN=Exchange Administrative Group (FYDIBOHF23SPDLT)

9. Expand CN=Servers

10. Delete the target server. It will be of the form CN=<Server_Name>.to your domain CN=Domain. If you are unable to find your server listed as described, you may need to use LDP.EXE to firstly locate it.

11. Use Windows Explorer to delete:

  • C:\Program Files\Microsoft\Exchange Server
  • C:\ExchangeSetupLogs

12. Run the Windows Installer CleanUp Utility to remove all the Exchange related info from the installer database.

13. Remove the target server from any Exchange security groups.



Install Exchange 2007

Install Exchange 2007 by running setup normally. I would recommend that you install to the same service pack level as you had before your server disaster.

I came across a problem as I tried to install Exchange 2007 where I got an error as setup proceeded to Copy Exchange Files:


Error code is 1603. Last error reported by the MSI package is ‘Could not open key: UNKNOWN\Components\… Verify that you have sufficient access to that key, or contact your support personnel.

This problem may have occurred as a consequence of using the Windows Installer Cleanup Utility. Hopefully you won’t come across this problem. But to keep this blog short, I describe how I resolved this problem on another blog: 



Test Database Integrity by using eseutil

If you have gotten to this stage then your Exchange Server has been restored. If this was a mailbox server, then you will be looking to see if you can restore your databases.

Before you can progress, you’ll want to be sure that your databases are OK by verifying its integrity. You can do this by following the steps below:

  1. Open a command prompt window.
  2. Navigate to Exchange’s binary folder (usually at c:\Program Files\Microsoft\Exchange Server\Bin)
  3. Type in the following: eseutil /mh  (see image below).



You will notice that, in the image above, the State is ‘Clean Shutdown’.

This indicates that the database in this instance had shutdown correctly before the disaster occurred. The chances of this database being restored to the newly recovered server are very good. If your result for any of your databases are anything other than a ‘Clean Shutdown’ then you will need to use eseutil to repair the database. A discussion on repairing the database using eseutil is beyond the scope of this post, but there is plenty of information on the Internet on this procedure. I include a recommended link at the end of this post. If you need to repair any database, I would recommend taking a copy of your database firstly.


Mounting the Database

Once you have verified that your database(s) are good, you might like to take the following steps to mount your database:

1. Create a brand new database in a temporary folder on a disk and name this database the same as the old database that you are recovering

2. Mount the database

At this point, you have mounted a new, blank, database on your server. This database has exactly the same name as the old database.

3. Set the database as being able to be overwritten by a restore

You are now preparing the new database to be swapped out for the old database of the same name.

4. Dismount the new database

5. Rename the new database to *.old.

6. Copy the original database to the new temporary location.

7. Mount the database

The original database has now been recovered.

8. Move the database back to its original location on disk

9. Repeat steps 1-8 for any other databases that need to be recovered.

10. Delete any temporary *.old database files that you have used.


Outlook Problems?

At this stage, you have now recovered your server and your databases. But if you start Outlook you might see the following message:

As far as Outlook is concerned, the original server is not reachable. This has likely happened because certain user attributes have changed, or have even been deleted.

You can use ADSIEdit to see where the problem is. Navigate to a user and examine the user’s properties (see image below).

The two attributes to check are homeMDB and homeMTA. They follow a form similar to these below:

CN=Mailbox_Database_Name,CN=Storage_Group_Name,CN=InformationStore,CN=Server_Name,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Domain_Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain_Name,DC=com

CN=Microsoft MTA,CN=Mailbox_Server_Name,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Domain_Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain_Name,DC=com

If your respective attributes are different or missing, you will need to edit and then replace them for each user. You can do this within ADSIEdit and it is not too onerous if you have only a few users to edit. You can also use ADSIEdit to get key users up and running.

If you have more than a few users, I believe that there might be a Windows PowerShell method to deploy these changes to an OU. It should be fairly straightforward to develop a script to make the changes too, but this is beyond the scope of this article.

I hope that this has helped you in some way.


Manually removing Exchange 2007.

eseutil repair options:





During a reinstall of Exchange 2007, I encountered this error:

This problem may have occurred as a consequence of using the Windows Installer Cleanup Utility.

The following details the steps I took to resolve this problem.


Error Message


Error code is 1603. Last error reported by the MSI package is ‘Could not open key: UNKNOWN\Components\… Verify that you have sufficient access to that key, or contact your support personnel.





1. Start regedit

2.Navigate to the key that is described in your error message.

It should be located under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components

It should be sub-keys under the key that you have navigated to that will have a problem. You may find that there is an error message as you click each of those sub-keys.

3. Return to the key that is described in your error message.

4. Right-click on it and select Permissions

5. Click on the Advanced button

6. In the resultant window, tick ‘Replace all existing inheritable permissions…’

7. Click OK.

If you do not get an error message at this stage, then you have likely resolved the problem.

8. Click on through to return back to the regedit main window

9. Close regedit


If the registry fix did not work and you still found that clicking the sub-keys off of the main key mentioned in the error message, resulted in another error, then it is time to try Safe Mode.

I found that when I entered Safe Mode and started working on the server directly, I found that I still could not modify those sub-keys whilst logged in as Administrator.

Fearing that there was now something wrong with my Administrator login, I looked to use an alternative admin login. But before I did that, I tried adding the Administrator account to the Server Operators group.

And on logoff/logon I was able to finally modify the permissions on those sub keys.

Reboot to get out of Safe Mode.

You should now be able to run the Exchange 2007 setup.

I hope that this has helped you in some way.

Did it work for you? If it didn’t, there are a couple of other things you could try:

  1. Reset the security database
  2. Reset permissions with SubInACL utility

I haven’t detailed these methods, mainly to keep this blog short. But if you ‘d like me to detail these, let me know!



Reset the security database

Download the SubInACL utility

The Background

I wanted to add the CAS and Hub server roles to an Exchange 2007 mailbox server in my Test Lab. I already had another server that was performing Hub and CAS roles but I wanted to later decommission that so that I could install an Exchange 2010 Hub and CAS server.

So it was important that I install another CAS and Hub server firstly. I could then route all connections from one server to another, and then carry on with the decommissioning of the server.

Key error messages and symptoms

Error: Process execution failed with exit code -1.


When I went to run setup to install the new roles onto the existing mailbox server, I was faced with the following error message from within the setup screen:

Client Access Role install Failed

Error: Process execution failed with exit code -1.

Now, if you are here because you have experienced the same error message then I am not so sure that I have an exact answer for you because my Exchange Server developed more problems that I had to deal with. They are chronicled elsewhere (or soon will be) in my blog.

But I’m pretty certain that this problem originally stems from a problem with my DNS and a network configuration change I made to the same server.


I couldn’t find much when I researched the exit code -1 error.

But this mailbox server had two network cards in it – but with only one card active. The other was disabled. The server wasn’t going to be a mailbox server for long – I had plans within the Test Lab for there to be two Hub servers and two CAS servers, both with dual network cards so they could straddle the internal network and the network associated with my router.

To cut a long story short, I did two things:

  • I inadvertently had two Name Servers in DNS with the same IP address, where one of the servers no longer existed.
  • I enabled the second network card with that same IP address.

My network had been running well for over a year with the error in DNS. I had just been lucky in that all the computers were accessing the existing server.

I left the enabled network card running for a day with no problems.

I next Terminal Service’d into the mailbox server to install the new roles, and I was getting the Exit Code -1 error. Looking next at the server itself, the network icon had a red x next to it. But I couldn’t get into the Network and Sharing Center to look at the settings. In the end, I had to restart the server in Safe Mode to regain access to the adapter settings. There I found that, inexplicably, the default gateway was missing from one of the network cards. I remember too that one of the DNS entries had a IP address too.

I replaced the settings with the correct values and rebooted, and the server came up with networking functioning again. I was able to continue trying to install the new roles, although I would come up against more problems that would lead to the loss of the server.

Here is where I hope that my experience will help you. I only did the first step of the two steps that I think might have resolved the Exit Code -1 error.

1. Resolve the empty gateway setting.

Multiple default gateways are always a tricky thing. You’ll get an error from Microsoft about it:



I think I may have clicked ‘No’ inadvertently and this led to a blank gateway.

2. Check DNS.

I wasn’t aware at the time that I had a DNS problem so didn’t check at this early stage in time. Check your DNS now, looking for any IP addresses that you are using as DNS servers. Check that the IP addresses aren’t being used elsewhere in DNS.

I think that in installing the new roles, the Exchange setup queried the DNS settings on one adapter and, with them being incorrect, was unable to progress with the install. It’s my guess that, with one of the gateways missing, Exchange couldn’t query for any other correct Name Servers.

But what do you think? Did this help you?

Best wishes…