Tips on Troubleshooting Using the Exchange Server Setup Progress Log


Here are some pretty useful tips straight from the Exchange Setup Test Team for using the Exchange Setup Log to troubleshoot Exchange Setup issues.


Tip #1: Most of the errors in the Setup Log are not really errors!


Yup, as silly as it sounds the vast majority of the “errors” in the log are actually expected return values from other Windows services that happen to come back to us in the form of an Exception, so it goes through Setup’s error handling processes. Most common is the “Error code 0XC0070424 (1060): The specified service does not exist as an installed service.” This error shows up every time Setup tries to start, stop, or use a service that isn’t installed (surprisingly, Setup does this a lot for reasons I won’t go into here). For example, Setup will always try to stop the Exchange Information Store service, even if it isn’t installed yet. When Setup does that, the Service Control Manager returns an exception, Setup catches the exception, detects this is an expected exception, and from Setup’s point of view having no service installed is as good as stopping the service, the error is safely ignored.


Here’s an example:


[13:43:33] Entering CAtomServices::ScStopAtomServices
[13:43:33]  CService::ScGetStatus (f:\titanium\admin\src\libs\exsetup\service.cxx:722)
           Error code 0XC0070424 (1060): The specified service does not exist as an installed service.
[13:43:33]  CService::ScIsStartedOrStopped (f:\titanium\admin\src\libs\exsetup\service.cxx:760)
           Error code 0XC0070424 (1060): The specified service does not exist as an installed service.
[13:43:33] === IGNORING PREVIOUS ERRORS === CServiceManager::ScStopService
(f:\titanium\admin\src\udog\setupbase\tools\svcmgr.cxx:537)
           The operation has completed successfully.


There are a number of other similar ignored error cases, such as trying to delete an Active Directory object right before creating it, or remove a file before we copy it. You get the idea.


There is one other “error” that I really want to mention because I constantly see postings in news groups with something to the effect of:


“My Exchange Setup failed! Here’s the error:
[09:42:28]  CComBOIFacesFactory::QueryInterface (f:\titanium\admin\src\udog\bo\bofactory.cxx:54)
           Error code 0X80004002 (16386): No interface.”


All this “error” indicates is that the Setup UI has been exited. That’s it. It’s at the very end of every Setup Log, including all successful Setups and most of the failed ones too. It is in no way a real error or helpful in figuring out what the actual error is (if there is one) and can be safely ignored.


I know it’s dumb that we record an “error” when you correctly exit the UI, but it has to do with the Setup manager code (not written by Exchange) that the Setup processes plug into.


Tip #2: Know what strings to search on to find your way around the Setup Log:




































Sections


Search string


What’s in there


Initialization


****** Beginning


This is at the start of the log for each instance of Exchange setup


Configuration summary


— ID:62227 —


Lots of useful general information here:  schema master DC identified, account running setup, install source directory, etc.


Pre-install on each component


is set to action


What action was set on each component, i.e. “install”, “remove”, “upgrade”, etc


Beginning action on each major component


— ID:62208 —


Prepare for file copy, build file queues, perform file copy, then configuration of the component (and its subcomponents, if any)


Skip to the bottom of file copy (server component)


Entering CAtomDW::ScSetup


This is where the real action starts to happen.  If you’re looking for a failure, chances are it happens during configuration.  Skip past the file copy with this string.


Completed action on each major component


— ID:62209 —


If a component started (62208), but didn’t finish (62209), you can bet it contains a failure.


Post setup


Entering CCompRoot::ScPostSetup


Mostly service management again


Tip #3: Use the retry button!
If you have a problem during setup, hit retry and let setup try the operation again.  Chances are if it failed the first time, it will fail again, but hitting retry will help highlight the failure in the log.  Now when you open the log, you know exactly what section to look for the error in—every thing from the “***** RETRYING THE FAILED OPERATION *****” on down—and don’t have to wade through the rest of the log.


Tip #4: Installing on a cluster
If you’re setting up on a cluster and want to make sure setup recognizes it as a cluster, when you get to the component selection page, open the setup log and look for the line near the end of the setup log “We have detected that setup is running on a cluster”


Tip #5: Quickly find fatal errors
You can search a setup log for “>>>>>>>>>”.  This string is prefixed to all fatal errors.


Tip #6: Translate those Setup prereq messages for easy posting and faster help!
Running Setup of a localized build of Exchange and hitting a prereq message or error? Want to get help easier and faster in newsgroups and DLs?


Then try running Setup using an English version of Exchange. The messages will be captured in the Exchange Server Setup Progress log in English. Now you can copy and paste from the log into Google, newsgroups, or email, where it is often easier to get help if the messages are in English. Of course, you don’t have to translate into English, it works for any language that particular version of Exchange is localized into.


But wait, you don’t have other languages of Exchange available? Try using the free Eval version of Exchange downloadable from the net (just be sure not to actually install the Eval version!)


Note: This trick only works if you don’t have Exchange installed on that machine already. That’s because Exchange Setup requires you to run Setup using the same language as the Exchange that’s already there. You’ll get a prereq message telling you to use the same language if you try.


Tip #7: Why do we ignore error codes with regards to Device Update?


When we install Titanium, we see the following line w.r.t. Device Update:


[10:36:13] About to uninstall ASP.NET Device Update
[10:36:13] Process created … waiting (-1)
[10:36:14] Ignoring exit code 0x000645


One might wonder why we ignore the exit code. Well, that’s because we try to uninstall it regardless if it is present or not. In the above case, it’s not present. We don’t want to fail setup because of a Device Update Installation/Un-installation Failure.


When we install Exchange 2003 SP1, we see the following lines w.r.t. Device Update:


[11:14:03] About to uninstall ASP.NET Device Update 2
[11:14:03] Process created … waiting (-1)
[11:14:06] Ignoring exit code 00000000
[11:14:06] About to uninstall ASP.NET Device Update 3
[11:14:07] Process created … waiting (-1)
[11:14:07] Ignoring exit code 0x000645
[11:14:07] About to install ASP.NET Device Update
[11:14:07] Process created … waiting (-1)
[11:14:11] Ignoring exit code 00000000
[11:14:11] ASP.NET Device Update was installed


Here, we first try to uninstall Device Update 2, then uninstall Device Update 3 and then install Device Update 4. In the above case, there was no problem installing DU4 (see the bold italicized line).


However, in the case that Device Update 4 was installed already, we would ignore an error code and continue with setup. The MSIInstaller would throw an error saying it was already installed and we’d also see an Error in the Application Event Viewer, with Source of MsiInstaller whose description is:


Product: Microsoft .NET Framework 1.1 — Device Update 4.0 — This Device Update has already been installed.


– The Exchange Setup Test Team (Berg, BatwooAlex, Ted and others who we hope will keep participating on this blog!)

Comments (2)
  1. erich says:

    Great Article! ( Great Blog, too! )Thanks. I’m battling some strange errors in an Exchange2003 install and was looking for some background on deciphering the setup progress log.

    One important question I have is "Who is Cartman, and why should he ignore it"? :)

    I had these entrys in my setup progress log:

    [21:58:19] We always ask to show the page for this component in this mode – but Cartman should ignore it

    [21:58:19] This component is set to ignore

    Can you shed any light on this entry. Is Eric Cartman from South Park really involved in Exchange development? Thanks.

    Eric M. Haupt, MCSE 2000: Messaging MCSA 2003

    Sr. MS Exchange Engineer

    USinternetworking

    One USi Plaza

    Annapolis, MD 21401-7478

  2. bergberg says:

    If you can ignore all the stale Cheezy Poofs lying on the floor of his office you’ll find that Eric Cartman from South Park actually is a pretty decent developer.

    But seriously, Cartman is the in-house name for the setup manager program that Exchange uses. Cartman was developed by the Back Office team to handle the installation of multiple applications through just one interface. As one customer put it, "It’s a Setup to run setups." The idea was allow the customer to run a single Setup that would install a bunch of apps (also known as a "suite"). This way they only had to enter one Product Key, agree to one End User License Agreement, could do all their prereq checking at the same time, and Cartman would manage any cross app dependencies (you can’t install Office before installing the operating system). This is also why you see the Exchange components in a tree structure in the setup UI; the other braches would be other apps with their sub-components.

    So what does this have to do with that entry in the log? Well, in order to integrate into Cartman, Exchange Setup has to use the Cartman provided UI. Some UI pages we show, some we modify at runtime to hide unused text fields and buttons, some we suppress. When you choose to install an Exchange component, Setup is actually installing a bunch of components under the covers, some of which Cartman would expect us to show a UI page. However Exchange Setup might not need that page shown so we have to tell Cartman to ignore the request. That’s pretty much what you’re seeing there in the log.

Comments are closed.