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

System Requirements:

  • Exchange Server 2003, SP2
  • Windows 2000, 2003 Server

The Problem:

When attempting to install Exchange Server 2003 Service Pack 2 (SP2) you receive the following error message:

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

The installation halts at a retry prompt or aborts and continues the installation normally.

More Information:

Microsoft basically screwed up in their version number catching during scripting and testing of the SP. If you have followed my Windows patching guides on HPC:Factor, your Exchange 2003 SP2 install will by default experience this issue; not because I screwed up, but because Microsoft clearly don’t think any of you ever update anything other than the half-hearted list generated by Windows Update.

Credit for the time on this one goes without me stealing the lime-light to the ‘SBS Diva‘, but her explanation for the issue is incorrect. The issue isn’t Shavlik’s, it’s Microsoft’s.

After a little digging, I discovered that the Exchange 2003 RTM shipped with MSXML Core Service 3.0 SP2. This is understandable, as Windows 2000 SP3/SP4 with Internet Explorer 5.01 SP3/SP4 lacks this module (Internet Explorer 6.0 SP1 ships with SP3). However, Service Pack 2 for Exchange Server ships with MSXML Core Service SP5, Service Pack 7 (SP7) was released a month later.

The Exchange SP Installer is simply expecting to find a lower version of MSXML for the Exchange ActiveSync system (SP2/3/4). If it encounters the same or higher version, the installer errors out believing the installation to have erroneously failed, when in reality it was just badly written.

The Fix:

Just as stated by SBS Diva, if you purge the version check (which is done against the Windows Installer versioning, not the file version) backup and then delete the key for MSXML 3.

MSXML 3.0 SP5 – [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\45D60EC31B272B44BA064E72E78CE04F]
MSXML 3.0 SP7 – [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\E83E246D42D0C684A9D23E61DD96F6B4]

There is no MSXML 3.0 SP6.

 

Vignette 1: If you do perform a visual search of HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products, ensure that you are not deleting MSXML 4.0, 5.0 or 6.0 related entries. It is also possible for MSXML 2.x to be installed on the system (though unlikely unless your install is as old as Windows 2000 itself)

Vignette 2: The Exchange SP2 installer is going to leave the system *thinking* that it has SP5 installed on it. If you started on SP5, fine, but if you were on SP7, you should put the hive back again or reinstall SP7. For SP5 users, I recommend installing SP7 after Exchange is up and running. The Exchange SP installation process does not devolve the MXSML level back to SP5.

Error: Activex componet can not create object: “WScript.Shell” when running WScript application

System Requirements:

  • Windows 95, 98, 98SE, Millennium
  • Windows NT 4.0, 2000, XP, 2003, Vista

The Problem:

When you run a .vbs file with a call to CreateObject(“WScript.Shell”) the script/application terminates with the follow error message:

ActiveX componet can not create object:”WScript.Shell”
Code: 800A01AD

The script then exits

More Information:

Your Windows Scripting Host has a mis-registered control. If you have just Installed Microsoft Internet Explorer <anything>.<anything> chances are the install went wrong. Check the install log in %SystemRoot% and check for failures.

I would recommend reinstalling IE properly to be safe, but chances are the problem will still be there afterward (it was with this particular muse and MSIE 7.0).

The fix is very simple however (assuming that your error is down to Windows Scripting Host and not bad programming; you are on your own on that one).

From cmd, or from a .bat run:

regsvr32 dispex.dll
regsvr32 jscript.dll
regsvr32 scrobj.dll
regsvr32 scrrun.dll
regsvr32 vbscript.dll
regsvr32 wshcon.dll
regsvr32 wshext.dll
regsvr32 wshom.ocx

I recommend that you start with wshom.ocx and test . No reboot is required for shell initiated .vbs files. If the problem is with IIS, you should restart the IIS Administrative and WWW services.

Be sure that you are using WScipt 5.6 (Unless running Vista or XP with IE7). You can download the latest release here:

Recycle Bin Woes: Chomping at the Bit

System Requirements:

  • Windows NT 3.51, 4.0, 2000, XP, 2003

The Problem:

Yes, I admit it, I have hard disks running in my current servers which have been with me almost as long as I have – that either says something about how old I am, or how tragic I am; probably the latter actually.

Ever since I got fed up with it all back in 1999 and had a 9x cull, everything – and I mean everything on my home network has run some form of NT or another, be it 3.51, 4.0, 2000, XP or 2003; even Longhorn (I’m still not calling it “that”).

Having suffered some major server related setbacks in the last week, the short version of a very long and depressing story has been that I’ve needed to reinstall a large number of servers, including two here at home. One of them is a nice cost SCSI320 RAID array that has just been rebuild, but server 3, with its numerous ATA disks, that’s a different story.

Thinking long and hard about it, I can conclude that at least two of the disks would have originally started life as FAT Volumes, and has been slave drives under 98, Millennium, NT4, 2000 Professional, XP Professional, 2000 server and now 2003 server. In between there have been numerous file system changes, back and forward from one to the other through the native conversion tools, or by the modern marvel that is Partition Magic.

The point is, the volumes have had a lot of work done on them, many partition dimension changes, many file system changes and last and not least, many operating system changes. So when it came down to a little impromptu data reorganisation when server 3 was retired from Intranet duties, imagine my surprise when Windows was reporting a completely empty 60GB NTFS partition as using well over 3GB of disk space.

All file systems will have some degree of overhead involved in storing their configuration information, NTFS partitions in particular will always have a certain overhead reserved for the on-disk MFT store. However on a 60GB partition this should be around 95.7MB (100,396,572 bytes) depending upon cluster size. So where has the data gone?

The Fix:

Tragically, this little delight is down to the way in which Windows tracks the recycle bin index for any given volume and every given user account on the system. Every user on the computer is assigned and identified by a GUID value by the SAM when the operating system is installed and when the user account is created. Such a GUID looks like:

S-1-5-21-1377080574-1904069225-4148753390-500

Note the ending value of 500, which means this account is almost certainly the system Administrator account in this example.

For each GUID on the system a MFT wrapper is created under the super hidden folder <drive>:\RECYCLER which contains the file system entries for everything that user holds in the recycle bin.
The meaning for this is clear, Windows maintains a per-user recycle bin schema, not a per system. Therefore each user account can populate the recycle bin with whatever information that user deletes, and it remain hidden on the disk.

The trouble is when a volume gets old, the GUID’s easily become stale as operating systems are reinstalled, Active Directory is added and removed, disk’s are moved between systems and the file systems themselves are altered.
In the case of this particular volume, well over 3GB of data was trapped in the recycle bins of a rather large number of long dead user accounts, which unintelligently Windows and successive operating system reinstallations has never picked up upon.

There are two ways to deal with this, the first of which I am not going to go into much detail on.

  1. You can wipe out stray GUID entries from the RECYCLER folders by seizing ownership of the RECYCLER folder and literally deleting the wanted GUID’s. Remember though, the system will let you delete the information from any user account that is currently not loaded. You can check the GUID’s off against the HKU hive in the registry to be certain if they exist.
  2. The second way, and the way that I am advocating is to pull all the data off of the volume and perform a format using Disk Manager. The logic is very simple, not only does it wipe out everything from the disk, and perform a thorough bad sector check/retest & repair, it also will upgrade and reconstruct the NTFS / MFT on the volume.

The volumes in question in my example were all NTFS from NT 4.0, where as the standard has been updated through 2000, XP and 2003 with additional features such as Shadow Copy support and native OS level Indexing service support. I therefore am at pains to imagine what sort of state the MFT on the volume was in with all the in-place bolt-on’s added by successive Windows releases, not to mention MFT file fragmentation. Formatting the volume will therefore naturally clean the entire nightmare up quite eloquently.

URLScan 2.5 has a Broken Display Icon in the Add/Remove Programs list under Windows 2000 / XP

System Requirements:

  • Windows 2000
  • Windows XP
  • Internet Information Services 5.0
  • Internet Information Services 5.1

The Problem:

This is nothing more than a cosmetic faux pas by Microsoft which bugs me, so if like me you cannot stand disarray in your Add / Remove Programs, this is the (largely pointless) fix for you!

URLScan 2.5 is an updated version of the HTTP filter released to add something resembling some security control to Microsoft Internet Information Services 4.0, 5.0 and 5.1 – by version 6.0 they have supposedly got security down to a fine art…

When the installer was built someone at Microsoft made a mistake in the uninstall routine strings for Add / Remove programs and as a result, the URLScan 2.5 entry looks thus:

Add / Remove Programs faux pas for URLScan 2.5

The error technically exists under NT 4.0 and IIS 4.0, however as NT 4.0 doesn’t draw icons in Add / Remove Programs, the fix is not going to make any difference anyway.

The Fix:

… I told you it was trivial.

The fix is, however, as equally trivial as the problem. Pull up Regedit and travel to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\IisUrlScan

Alter the value of the DisplayIcon string from:
C:\WINNT\system32\inetsrv\urlscan\urlscan.exe,1

to read:
C:\WINNT\system32\inetsrv\urlscan\urlscan.exe,0

Hit F5 in Add / Remove Programs and there you have it, a working Icon.