Interesting Issue: E2k3 Cluster setup.exe prompts for 5.5 Site credentials
Exchange 200x clusters install in two separate phases: In the first phase, the administrator runs SETUP.EXE on the CD. The Exchange binaries are copied from the CD to the local harddrive, some IIS bindings are created, miscellaneous local-to-the-node stuff happens. A number of things are read from the AD, but little (if anything) is actually written to the AD in this step. After all nodes of the cluster have this first step run, the administrator moves on to the second phase. In the second phase of the install, the administrator fires up the Cluster Administrator interface (CluAdmin) and creates a system attendant resource. During this second phase, the Exchange Virtual Server (EVS) is created in the AD -- lots of writing to the AD.
The important takeaway from all this is that we don't create an Exchange server object in the configuration container during the first part of the setup process on Exchange 200x cluster, only during the second part.
And that leads to a minor difference between Exchange standalone servers and Exchange clusters. Since running SETUP.EXE on a non-clustered server will basically combine the two cluster setup phases into one big SETUP run, you have to make lots of decisions in the SETUP interface. I'm going to focus on the decision you have to make about what Admin group the server will join (if you have more than one). In a non-clustered server, you have to decide this from within the SETUP program -- BEFORE it ever copies the binaries.
Exchange Clusters, however, prompt you for that decision only during the creation of the System Attendant Resource. But it's important to note that underneath the covers, Exchange Setup still needs to have an Admin Group selected. It needs this even though it's not actually going to use it for anything but filler during this first phase of setup. What it appears to do is select the first Admin Group in the organization, alphabetically.
This can be confusing because if you read through the Exchange Server Setup Progress.Log file, it will imply that setup will be installing this cluster into some random AG in your org -- most likely one you don't want it installed into! But remember, it's not actually going to install it into the AG. Selecting the AG is a part of the phase 2 setup process.
Long story short -- if for whatever reason, the Exchange 200x setup (phase 1) on a cluster stops and prompts you for 5.5 credentials to join an Admin Group *AND* all the fields are blank and unchangeable, you now have the advantage. Knowing that it's simply trying to read the first alphabetical AG from the AD and is evidently failing in some way (permissions, problems talking to the 5.5 server directly, etc), an easy workaround might be to simply create a pure E2k/E2k3 AG through ESM and name it so it will be the first alphabetical AG in your org! Cluster will then read THAT AG instead, and voila, you're past the prompt and no worse for it.
Comments
- Anonymous
February 16, 2004
The comment has been removed - Anonymous
February 16, 2004
Misha -
You make a very valid point about complexity and diagnosis, and it's an area I sense we struggle very hard with. Technology is constantly becoming more and more capable, and so supporting it becomes likewise more difficult.
As pain points are encountered, either the product group or PSS put together diagnostic tools that can be used to more rapidly diagnose the problems. Similarly, many third-party vendors produce tools that can assist with various aspects of the server maintenance and problem diagnosis.
I get the feeling that it's very much a desire of MS to provide transparency in product function to our customers, while at the same time protecting MS intellectual property, etc. It's a delicate balance, and these blogs at blogs.msdn.com are an example of that balance.
If you encounter specific pain points while resolving a problem, by all means please send email to mswish@microsoft.com, bring them to the attention of your PSS engineer the next time you're calling in about something, or post them here. MS is definitely watching these blogs and as a PSS engineer myself, I can tell you we're all about trying to make the product easier to support! :)
Thanks for your comment!
Evan - Anonymous
April 08, 2004
How would you recommend providing recovery for an entire data centre. We have a cluster in a data centre, with SRDF available to mirror data / logs to a remote site. How can we recover using the data at the DR site if we can't use setup with disasterrecovery switch ?
do you have any recommendations ? - Anonymous
April 08, 2004
Pete - sounds like you are interested in geospan cluster (geocluster, geographically dispersed cluster, etc) solution. You may want to have a look at the Windows 2003 Geographically dispersed clusters whitepaper at: http://www.microsoft.com/windowsserver2003/techinfo/overview/clustergeo.mspx
Also, here's a great case study on Geocluster success with Exchange 2003: http://www.microsoft.com/resources/casestudies/CaseStudy.asp?CaseStudyID=14580
Note that Geoclustering is pretty serious, and can be quite expensive. If you have SRDF mirroring in place to your remote site already, you're probably almost there. If you find that geoclustering is NOT for you for some reason, you still have a few options:
1) You're willing to bring up another cluster in the DR site (note that you can even have a single-node cluster pre-loaded with Exchange, just waiting to create the network name and create the System Attendant resource...). In this case, simply make sure your original AD is available, create the Network Name to exactly match the original server's NN, and then make a new SA resource dependent on the NN. This will link back into the existing AD Exchange Virtual Server object and you'll be ready to restore the databases directly.
2) Or, if you want to use a non-clustered server, you can follow KB.323016 (http://support.microsoft.com/?id=323016) to get back into the data in the DR site.
Evan - Anonymous
April 09, 2004
Evan,
Thanks. The solution we are looking at for the production site is a 3+1 cluster. Our storage vendor currently only supports geocluster in a 2 node setup which is kind of limiting. We do have the budget to set up another cluster in the Disaster Recovery data centre which we could bring up in the event of a disaster (we have an 8-12 hour SLA). Would we need to delete stuff out of the AD before we recreate the SA ?
Thanks again for your help - these blogs are really good
Pete - Anonymous
April 09, 2004
> Would we need to delete stuff out of the AD before we recreate the SA ?
Nope, in Exchange 2003 cluster when you create a system attendant resource dependent on a network name for which there is already an existing Exchange Virtual Server object in the AD, it will link back into that object and no further changes will be required for the AD -- it's essentially a "/disasterrecovery" switch without the switch...
Evan - Anonymous
April 09, 2004
Evan,
thanks - sounds sensible. We are going into proof of concept testing on this in a few weeks so I will let you know how we get on
thanks again
pete - Anonymous
April 18, 2004
The comment has been removed - Anonymous
April 18, 2004
Pete -
Not sure if there are plans to incorporate this DR option in future documentation. That said, it works just fine and I've used it in test a number of times. If you're working with MS folks, please feel free to have them email me internally and perhaps we can sort out their concerns.
Also can't speak for how Doubletake does it -- again the only clustering solutions MS can support are those on the HCL. These other solutions may work just fine, but it would change your support options a bit as the vendor would need to be your primary source of support.
Just to be clear, I don't see how the option#1 I described will give you the ability to do testing without affecting your production environment. #2 might, but that would still require a bit of work in the test environment to get it prepped.
Can you clarify your question a bit more and perhaps I can help out a bit?
Thanks!
Evan - Anonymous
April 18, 2004
The comment has been removed - Anonymous
April 18, 2004
Pete -
It should be fairly easy and non-destructive to test, so long as you end up discarding the SRDF replica. Before I would rely on this as a solution, I'd set it up in a lab (SRDF not required) and verify that deleting the SA on the "production" (in the lab) cluster and recreating it on the "remote" (in the lab) cluster is sucessful. Once you've verified in test that you can move these resources between the two clusters without affecting the AD (still in the lab), you may be ready to move on to production.
I can't think of any reason why this wouldn't be a supported solution by MS (there's even an event logged to tell you how to fix it if the SA is deleted -- same result), but you'll want to work with your direct MS support folks to make sure they're sold...
Evan - Anonymous
April 18, 2004
Evan,
Thanks. We should have the resources to look at this next week (the kit is in the truck on its way to the test lab as I speak). We should be able to test this without affecting the plan. I will be speaking to the local MS guys tomorrow and will mention our chat (if you are ok with that) and suggest that they email you.
Regards
Pete - Anonymous
April 20, 2004
By way of follow up on this to anyone watching for a response -- internal discussions were had and it was determined that although there's no known reasons why this wouldn't work, it's not a recommended solution (proper Geoclustering to the remote location is the recommended solution in this scenario). It's also not a fully tested solution by the Exchange clustering team, so it can't be called officially "supported".
Translation -- like a lot of things it'll probably work fine, but use at your own risk. If you're spending those kind of "availability $$" on your solution, best bet is to use something officially "supported"...