Thursday, August 28, 2008

MS DPM & DCOM Launch Permission

Recently we’re evaluating the MS Data Protection Manager short for MS DPM. In the POC phase of the project we’re able to remotely deploy the DPM client to the test machines. Sample snapshots has been created and everything seem to be worked just right.
But when we try to restore from the VSS we uncounted some error which generate some of these system events :-

This is the event log from the DPM server

This was generated when we tried to manage the remote client from the DPM Console

Looking at the event source, it was generated by DCOM, so we checked the permissions on the DCOM Configuration Manager è DCOM Config :-

=> Microsoft Volume Shadow Copy Service software provider
=> MSDPM Agent Coordinator Service
=> MSDPM Task Executor Application

1. Click on Start menu, select Run and type in dcomcnfg
2. Go to Component Services è Computers è My Computer è DCOM Config

3. Check to ensure that local and remote launch permission for the 3 DPM related services to have SELF & SYSTEM account in it

4. Check to ensure that the MS DPM Client hostname are part of the DCOM user group for the MS DPM Server
5. Reboot the MS DPM client machines and that should fix the DCOM error mentioned above

The Case of Windows 2003 SP2 Installation Failure

MS announces EOS of Windows 2003 Server with SP1 April 2009. So it is about time for the company I work for start to plan for an upgrade to SP2. We have around 1300 servers to be patched with combination of x86 and x64. I was part of the early involvement team to drive for this change and working with our engineering team for proliferation world wide.

We encountered this same exact error where SP2 failed to install with a very specific error code from update.exe

“Service Pack 2 Setup canceled.
Update.exe extended error code = 0xf00d
Update.exe return code was masked to 0x643 for MSI custom action compliance.”


Screen thru the svcpack.log, setupapi.log & spuninst.log and MS KB searches, this could due to the permission or antivirus with online scan for I/O.


We invoked the upgrade process using the local administrator account and that pretty much ruled out that it was due to permissions. But to be sure we checked on the local security policy on what exactly local administrator can and can’t do (with policy pushed from AD).

After that we reverted the change by restoring the mirrored disk and try it from scratch again. This time we disabled the VirusScan Enterprise 8x “On Access Scan” feature and proceed with the SP2 setup again and the update.exe error didn't went away but this time it reported more error with 0x490 on possibly all the inf files under the C:Windows\inf directory.


Below is part of the svcpack.log file error messages in C:\Windows

SetupVerifyInfFile failed with error 0x490 for c:\windows\inf\netwlbsm.inf of device ROOT\MS_WLBSMP\0000
SetupVerifyInfFile failed with error 0x490 for machine.inf of device ROOT\RDPDR\0000
SetupVerifyInfFile failed with error 0x490 for machine.inf of device ROOT\RDP_KBD\0000
SetupVerifyInfFile failed with error 0x490 for machine.inf of device ROOT\RDP_MOU\0000
SetupVerifyInfFile failed with error 0x490 for machine.inf of device ROOT\SYSTEM\0000
SetupVerifyInfFile failed with error 0x490 for machine.inf of device ROOT\SYSTEM\0001
SetupVerifyInfFile failed with error 0x490 for c:\windows\inf\machine.inf of device ROOT\SYSTEM\0001 SetupVerifyInfFile failed with error 0x490 for machine.inf of device ROOT\SYSTEM\0002
SetupVerifyInfFile failed with error 0x490 for disk.inf of device SCSI\DISK&VEN_HP&PROD_LOGICAL_VOLUME&REV_2.58\5&12B8725B&0&040
SetupVerifyInfFile failed with error 0x490 for disk.inf of device SCSI\DISK&VEN_HP&PROD_LOGICAL_VOLUME&REV_2.76\5&12B8725B&0&040

This time the error message tell some informative hint where update.exe unable to verify the inf files and a quick search on the log enteis from Process Monitor suggested that licdll.dll is throwing the problem. KB912354 from MS outlined that this can be easily fixed by reregister the problematic dll by regsvr32 licdll.dll but this is not enough to fix the problem we faced in this server.

We proceeded to download the KB912354 and from MS Premier site to replace the dll and then performed the following steps to recovered the server and get SP2 installed :-

  1. Patch KB912354 & reboot the system
  2. Net stop cryptsvc
  3. ren C:\Windows\System32\Catroot2 oldcatroot2
  4. Net start cryptsvc
  5. Reinstall SP2



The Case of Digitally Signed Network Communications

It has been a while I did not post anything here due to the work load, tight schedule and some traveling. Couple of days back I was asked to help in one of the project where they can't fix the network drive mapping under DOS automation environment after PXE boot from Altiris.

No network error was generated in the Windows Event Log for that host server and limited information from the DOS prompt after unsucessful "net use"......

Initially my though was it could due to he HANDLE leak which addresses ubder KB936087. So I launched the Process Explorer from Microsoft SysInternals and nothing seem to be suspicious. Next thing I have in mind to to give kernrate (you can down the kernrate from MS website, which is a very useful tool to trouble memory leak related issue) a try and see what I can get from there but I did not find anything abnormal either.

After some thought and "googling" around I decided to give Process Monitor a try and if procmon can get something useful or some indication on what went wrong with the host system. Beside the default filtering which built into prommon, I added a new filter to specifically look at the registry and processes related to "MS Network" and found that everytime I try to "net use" to map a drive it read the registry value which tie to the policy named "Microsoft Network : Digitally sign communications (always)" set to Enabled.

This is the common issue where you have this enabled, DOS and Win9x client will have problem map the shared drive from the host system. I proceeded to disabled this policy which pushed by the DC and forced a Group Policy refresh by "gpupdate /force". I was lucky that this will help to refreshed the local policy without a reboot.

"net use" again from the DOS client under the automation envirmonment after PXE boot and it worked !