Infrastructure

Exchange 2003 SP2 Install Fails because of MSXML

Colin Bowern — Sat, 28 Jan 2006 02:11:00 GMT

While building a new Exchange 2003 server I was installing Service Pack 2 and came across an interesting issue:

Setup failed while installing sub-component Exchange ActiveSync with error code 0xC0070643 (please consult the installatoin logs for a detailed description). You may cancel the installation or try the failed setup again.

Digging into the installation logs I see it's trying to install MSXML:

[18:52:22] Calling MSXML installer with command line: "msiexec /i msxml3.msi /q reboot="ReallySuppress""
[18:52:22] Process created ... waiting (-1)
[18:52:23] Process has exited with 0x000643
[18:52:23] The command

msiexec /i msxml3.msi /q reboot="ReallySuppress"

failed, returning error code 1603 (Fatal error during installation.). -- ID:31136 -- ScCreateProcess (f:\tisp2\admin\src\libs\exsetup\hiddenw1.cxx:1821)
Error code 0XC0070643 (1603): Fatal error during installation.

The event logs subsequently tell me:

Event Type: Error
Event Source: MsiInstaller
Event ID: 1013
Description:
Product: Microsoft XML Parser -- Your system has newer version of MSXML3 SP5 than the version you are attempting to install. Setup will quit.

Well, duh! I have MSXML3 SP7 installed. It appears that someone didn't quite figure out that yes in fact new versions of dependent component do in fact come out and that it's nothing to error out over. I wish all the product groups would expose a service like the MSDN Product Feedback center. I can't be bothered to open up a PSS case just to report this. So here's my workaround for anyone else that comes across this:

Get a copy of the Windows Installer package for the version of MSXML 3 you have installed.
Place a copy inside Exchsrvr\bin
Rename the existing msxml3.msi to msxml3.msi.backup
Make a copy of the latest version MSXML Windows Installer file and rename it to msxml3.msi. This will leave you with msxml3.msi and msxml3sp?.msi (in my case msxml3sp7.msi).
Click Retry on the error and it should continue as planned.

Hope that helps. One of these days we'll get these things right.

Removing the WMIISLog Folder (not)

Colin Bowern — Thu, 26 Jan 2006 17:28:00 GMT

Most server administrators separate their content from their system data (at least I think they do :) ). Content that grows will from time-to-time get by the monitoring process and bring a server to a halt because there is insufficient space on the sytem drive to continue.

As I built up another test server image I had a desire to delete the c:\wmpub\wmiislog folder which Windows Media Services leaves behind. From explorer you can't delete this folder because it is in use. But what is using it? After a quick search with Sysinternals Process Explorer I found that winlogon.exe is the culprit.

But why? A search of the internet has revealed no published rational behind this. Being a fan of keeping things in order there doesn't appear to be any purpose behind the folder so I'm nuking it. To make this happen I first had to close the handle using Process Explorer (right click on the handle, “Close Handle”) and then remove the folder.

The bad news is that upon reboot the folder reappeared. Hopefully we'll see this change in the next release of Windows Server.

You'd think they would have it fixed after 10 generations?

Colin Bowern — Fri, 20 Jan 2006 23:22:00 GMT

So it's time to actually deploy a real anti-virus vendor here at the office. We've run out of our free one year trial of CA e-Trust. So we closed our eyes, and of the vendors which support all of the stuff we need (ISA Server, SharePoint, Exchange, Windows) we threw darts. Symantec got the dart and what a ride it has been.

First was the challenge of testing the client installation. Got to love the developers for forgetting that processes can hang and the user needs to be informed during installation. As it turns out, Symantec Anti Virus and ISA Server 2004 Firewall Client can potentially clash - the result being an unexplained hang in the installation (underneath the savinst.exe process is toast). So I've got that fixed and now it's on to trying to get LiveUpdate to see the real world.

Next problem requires me to disable the Windows Firewall on each of the desktops - not a recommendation I would expect from a security vendor, but we continue. Finally with the client installed it looks like it's time to install the server product. We'll be venturing into that world this weekend.

But first before I break open the box it turns out Symantec has no support for ISA Server 2004 - the product I received only supports ISA Server 2000. Hello, retro? Why don't we just install Proxy Server 2.0 for all it matters. The kicker is that I did research the product specs and I overlooked that they were very vague about system requirements with “Microsoft ISA Server, SP1“ as their requirement.

So the fun continues and I'm sure I'll have many more items to share on the joys of antivirus deployment. Maybe I should start a blog on poor user experience design.