Exchange 2007’s setup program includes the ability to reinstall the Exchange binaries on a failed server. I had to use this today to replace a server VM that was mangled by a problem with our SAN controller; through no fault of anyone except a certain large SAN company, the VM was corrupt and couldn’t be restored. I rebuilt the base OS image, gave it the same machine name, and fired up setup /m:recoverserver. That seemed to work OK, reinstalling the hub transport and mailbox roles. Then I got an unexpected error:
Client Access Role ……………………. FAILED
The AD Object for virtual directory ‘IIS://EXCHANGE/W3SVC/1/ROOT/Microsoft-Server-ActiveSync’ on ‘EXCHANGE’ could not be created. This may be happening because it already exists in Active Directory. Remove the object from Active Directory, then re-create it.
I couldn’t find any documentation on how to fix this. That’s an awfully generic error message. However, I eventually found the suspect object living in the configuration NC of my AD: cn=services, cn=Microsoft Exchange, cn=orgName, cn=Administrative Groups, cn=Servers, cn=serverName, cn=Protocols, cn=HTTP. So, I removed it. All done? Not quite.
See, once you run with /m:recoverserver, the setup code writes a flag in each role (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\roleName) that says “I’m in disaster recovery mode”. As long as that flag is present, you can’t install or remove server roles, so I couldn’t just run exsetup /m:install /r:clientaccess like you’d think. First, I removed the Action value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\ClientAccessRole. Next, I uninstalled the CAS role (which wasn’t really there anyway!), then I re-installed the CAS role. However, Exchange setup still thought the CAS role was installed, so it wouldn’t install it. I tried adjusting MSExchCurrentServerRoles for the server object, but I don’t think Exchange likes a value of “0”. Subsequent reinstalls complained that the Exchange Servers USG was missing. Rather than continue to tinker, I ended up removing the AD org object and reinstalling from scratch. I think the original virtual directory error is a bug, and I’m going to report it as such.
Update: this is now logged as bug 176356.