SCCM Fix: Error 0x80070643 or 0x8024200b when installing Office 2003 Updates by using WSUS or SCCM

In our SCCM test environment we were installing this months Microsoft Security Updates and noticed on one test machine that all the Office 2003 Updates were failing. I hadn’t seen this before, so I started to do a little digging.

Knowing that SCCM really doesn’t do much but call the Windows Update Agent components, I first checked out the c:\windows\windowsupdate.log to see if there were any specific error messages relating to why these updates weren’t installing. What I noticed was the following:

Handler : MSI transaction completed. MSI: 0x80070643, Handler: 0x8024200b, Source: No, Reboot: 0

We basically have two exit codes here. The handler tells me that WUA passed this on to MSI and MSI returned exit code 0x80070643. Windows Update (which is the Handler in this case) is saying its exit code is 0x8024200b. Based on both of these exit codes, we have a failure. The actual code we care about is the first one because that’s what was returned to MSI. The second code is basically just a generic failure code.

By doing a search, I found that 0x80070643 relates to an issue with the Office Source Engine being disabled. Sure enough, on the machine we saw this issue happening on, it had the service disabled. Once we set it to manual, everything worked as normal. See http://support.microsoft.com/kb/903772 for more information.

So then I got to thinking, “How many machines in my environment have this service disabled? Our help desk could get flooded with calls.” But then I realized that if this really were a wide spread issue with this service disabled, we’d have a lot more issues in previous months with Office 2003 updates. But nonetheless, I was curious, so I made a query in SCCM to look for all machines with the Office Source Engine disabled. The query syntax is as follows:

select distinct SMS_R_System.NetbiosName from  SMS_R_System inner join SMS_G_System_SERVICE on SMS_G_System_SERVICE.ResourceID = SMS_R_System.ResourceId where SMS_G_System_SERVICE.Name = “ose” and SMS_G_System_SERVICE.StartMode = “Disabled”

How many machines came back with this service disabled? 4 (out of over 2000).

I think we’re OK :)

SCCM: Administrator Console Locked up, Frozen, Hosed, or Hung solution

Today I received an email from a tech who complained that the Configuration Manager administrator console we have installed on a Windows 2003 terminal server was hosed up. I’ve seen this happen in a few instances. I’m not entirely sure why the console just sits hung, but the solution that I’ve seen work most often is to delete the MMC related files in the user’s profile that get created after the console has been used. You want to delete the sms and/or adminconsole files (I think the sms file comes from the old SMS 2003 console).

You can find the files at the following path:

Windows 2003: C:\Documents and settings\userid\Application Data\Microsoft\MMC

Windows 2008: C:\users\userid\appData\Roaming\Microsoft\MMC

Once the files have been deleted, logoff and log back on and run the console. This should fix the issue.

SCCM: Software Distribution Fails with Error Code 1603 in Execmgr.log

Error code 1603 by definition is just a generic windows installer (MSIexec) fatal error code. Yesterday I was seeing this for a software package deployment. The interesting part of this was this was an application that was packaged for us by a third party vendor (a vendor that will remain nameless, but has created some poor packages for us in the past that allows me to write up blog posts like this explaining the solution to their packaging issues), and the application was actually installing on some machines but not all. In total, about 50% had successfully installed the application and the other 50% had failed. So it was a very peculiar push that piqued my interest.

After looking at the advertisement report, I noticed that most of the successful installs were from Windows 7 machines. The failures were coming from Windows XP. So that pointed me to setup a test XP machine and test the push on that platform.

Next I looked at the package and how it was created in SCCM (I personally didn’t set this up or work with the vendor on packaging it, so this was all new to me). I noticed that the install program was using a transform that the vendor had created as well as a requiring ISScript8 be run first before installing.

After doing some research, I came across a forum post that made reference to DCOM InstallShield InstallDriver Identity properties being set incorrectly. In my case, we were running this application with administrative rights and silently via SCCM. When a local administrator was logged on during runtime, the application would install fine. It would also install fine if no one was logged on. However if a user was logged on without admin rights, we’d get the 1603 error.

So I took a look at the InstallShield InstallDriver Properties from DCOMCNFG. To do this, follow the following steps:

From a command line (or start – run) type in dcomcnfg
Select Component Services
Expand Computers
Expand My Computer
Expand DCOM Config
Right click on InstallShield InstallDriver (in my case I had two of these)
Select Properties
Select the Identity tab

What SHOULD be selected here is The launching User. What I had selected was The interactive user. So by changing both InstallShield InstallDriver identities to The Launching User I was able to run the application successfully as the user which was a low rights account.

How to change the Installshield Installdriver Identity via VBScript

So I had the problem solved, but I needed a way to do this programatically. I basically needed to run ISScript first, then run a VBScript to change the Identity value, then run the application. The good news is that these options are all stored in the registry! The problem though is that they’re stored in GUID/AppID format, and with different versions of ISScript out there, there isn’t a consistent method to fix this. What this means for you is that you need to get the GUID/AppID yourself, luckily for you, you can get the GUID/AppID from within DCOMCNFG.

How to find the GUID/AppID from DCOMCNFG

To find the Application ID, repeat the steps I listed above to get to the Installshield InstallDriver Properties pane.

From a command line (or start – run) type in dcomcnfg
Select Component Services
Expand Computers
Expand My Computer
Expand DCOM Config
Right click on InstallShield InstallDriver (in my case I had two of these)
Select Properties
Under the General tab select the Application ID

Once you have the application ID, you can use the following VBScript to change the Identity of the Installshield InstallDriver. Note that if you only have one InstallDriver, you can remove the second path and the second deletevalue command.

const HKEY_CLASSES_ROOT = &H80000000
strComputer = “.”

Set oReg=GetObject(“winmgmts:{impersonationLevel=impersonate}!\\” &_
strComputer & “\root\default:StdRegProv”)

strKeyPath1 = “Appid\{INSERT APPLICATION ID HERE IN BETWEEN THE BRACKETS}”
strKeyPath2 = “Appid\{INSERT APPLICATION ID HERE IN BETWEEN THE BRACKETS}”
strStringValueName = “RunAs”

oReg.DeleteValue HKEY_CLASSES_ROOT,strKeyPath1,strStringValueName
oReg.DeleteValue HKEY_CLASSES_ROOT,strKeyPath2,strStringValueName

Once you’ve made the file, put it in the packagesource folder and make a new SCCM program using cscript nameofscript.vbs.

SCCM: How to Restore the All Systems Collection in SCCM/SMS

When I got into the office this morning an email came in from one of our technicians. The issue was that he couldn’t see the All Systems collection anymore and wanted me to put it back. Since I know I didn’t do this, I took a look at Status Message Queries to see what happened. I specifically looked at “Collections Created, Modified, or Deleted” to see who the culprit was and when the deletion happened. Once I figured out that yes, All Systems was in fact deleted, I ran the following VBScript (copy this text to a text file and save it as all_systems.vbs and run it on your site server):

strSMSServer = “.”
strParentCollID = “COLLROOT”
‘This example creates the collection in the collection root.
‘Replace COLLROOT with the CollectionID of an existing collection to make the new collection a child.

strCollectionName = “All Systems”
strCollectionComment = “This is the All Systems Collection.”
Set objLoc = CreateObject(“WbemScripting.SWbemLocator”)
Set objSMS = objloc.ConnectServer(strSMSServer, “root\sms”)
Set Results = objSMS.ExecQuery (“SELECT * From SMS_ProviderLocation WHERE ProviderForLocalSite = true”)

For each Loc in Results
If Loc.ProviderForLocalSite = True Then
Set objSMS = objLoc.ConnectServer(Loc.Machine, “root\sms\site_” & Loc.SiteCode)
End if
Next

Set newCollection = objSMS.Get(“SMS_Collection”).SpawnInstance_()

‘Create new “All Systems” collection
newCollection.Name = “All Systems”
newCollection.OwnedByThisSite = True
newCollection.Comment = strCollectionComment
newCollection.CollectionID = “SMS00001”
path = newCollection.Put_

‘Set the Relationship
Set newCollectionRelation = objSMS.Get(“SMS_CollectToSubCollect”).SpawnInstance_()
newCollectionRelation.parentCollectionID = strParentCollID
newCollectionRelation.subCollectionID = (“SMS00001”)
newCollectionRelation.Put_

‘Add the Query Rule
Query = “SELECT * FROM SMS_R_SYSTEM”
Set objQueryRule = objSMS.Get(“SMS_CollectionRuleQuery”).SpawnInstance_
objQueryRule.QueryExpression = Query
objQueryRule.RuleName = “AllSystems”
newCollection.AddMembershipRule objQueryRule

The collection was remade and all the objects are there like they should be. Now I need to lock all collections down so our techs don’t delete them anymore.

SCCM: Collection Query to get all machines who haven’t rebooted in X amount of Days

Here’s a query that I use to see all machines who haven’t rebooted in 7 days. You can change the 7 to however many days you want.

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where DATEDIFF(DD, SMS_G_System_OPERATING_SYSTEM.LastBootUpTime, GETDATE()) > 7

SCCM: How to Determine Content Download to Cache Issues

Over the past couple of days I’ve been fighting with an application that a 3rd party vendor packaged for us. The package in question is an MSI that calls numerous other files. In total, the package has over 3000 files and is about 180 MB in size.

Issue

The issue that was reported to me was that the content was not downloading. My datatransferservice.log, my CAS.log, and ContentTransferManager.log all looked good. The client found a local DP to download the content from. However when I looked at my cache folder, I saw that only a couple of MB of data was downloaded and it never increased in size.

So I figured BITS was the culprit here. Unfortunately there’s no good logging for BITS without doing some nasty logmon stuff. The good news is that BITSAdmin is a great utility (at least for now, according to BITSAdmin on a Windows 7 box they reference new BITS Related powershell cmdlets which I didn’t find all that particularly useful).

In order to see what jobs are currently downloading, type in:

bitsadmin /list /allusers

This will give you output similar to the following:

BITSADMIN version 3.0 [ 7.5.7600 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.

BITSAdmin is deprecated and is not guaranteed to be available in future versions of Windows.
Administrative tools for the BITS service are now provided by BITS PowerShell cmdlets.

{19A1D938-E1E9-437F-882E-1BFAABB707CB} ‘CCMDTS Job’ ERROR 146 / 3805 4752558 / UNKNOWN
Listed 1 job(s).

Notice how in this picture I have the following line:

{19A1D938-E1E9-437F-882E-1BFAABB707CB} ‘CCMDTS Job’ ERROR 146 / 3805 4752558 / UNKNOWN

This is no good. This basically means there’s an error somewhere in the transfer job.

Before we get into the next step of the solution, you must first understand what an SCCM distribution point is. An SCCM DP is simply a glorified web server. If you look at the Datatransferservice.log file on any of your SCCM clients, you’ll see a lot of URLs that look like the following:

http://DOMAIN:80/SMS_DP_SMSPKGF$/CEN00119/System32/Redist/MS/System/msvcrt.dll

What your client is basically doing is grabbing the files from these URLs and storing them into your local cache directory underneath the package ID.

So back to BITS. Since we saw an error in our bitsadmin /list /allusers, we need to find out exactly what that error is. The following command will show just that:

bitsadmin /info {19A1D938-E1E9-437F-882E-1BFAABB707CB} /verbose > c:\bits2.txt

So what this command is doing is giving us the information about the failed BITS job that we saw before. The verbose command gives us the status of each file in the job. We then pipe this out to a file. Inside of that file, we see the following:

BITSADMIN version 3.0 [ 7.5.7600 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.

BITSAdmin is deprecated and is not guaranteed to be available in future versions of Windows.
Administrative tools for the BITS service are now provided by BITS PowerShell cmdlets.

GUID: {19A1D938-E1E9-437F-882E-1BFAABB707CB} DISPLAY: ‘CCMDTS Job’
TYPE: DOWNLOAD STATE: ERROR OWNER: NT AUTHORITY\SYSTEM
PRIORITY: LOW FILES: 146 / 3805 BYTES: 4752558 / UNKNOWN
CREATION TIME: 5/12/2010 11:31:04 AM MODIFICATION TIME: 5/12/2010 11:33:18 AM
COMPLETION TIME: UNKNOWN ACL FLAGS:
NOTIFY INTERFACE: REGISTERED NOTIFICATION FLAGS: 11
RETRY DELAY: 60 NO PROGRESS TIMEOUT: 2419200 ERROR COUNT: 147
PROXY USAGE: NO_PROXY PROXY LIST: NULL PROXY BYPASS LIST: NULL
ERROR FILE:    http://DOMAIN:80/SMS_DP_SMSPKGF$/CEN00119/Program Files/Hummingbird/Connectivity/9.00/HostExplorer/SDK/Samples/OHIO/Visual C++ Samples/HEOhioSample/MyTabCtrl.cpp -> C:\Windows\system32\CCM\Cache\CEN00119.1.System\Program Files/Hummingbird/Connectivity/9.00/HostExplorer/SDK/Samples/OHIO/Visual C++ Samples/HEOhioSample/MyTabCtrl.cpp
ERROR CODE:    0x80190194 – HTTP status 404: The requested URL does not exist on the server.

ERROR CONTEXT: 0x00000005 – The error occurred while the remote file was being processed.

DESCRIPTION:
JOB FILES:

The above shows exactly what the issue is. a HTTP status error of 404 indicates that the file cannot be found on the server. In my case, the package that I am troubleshooting has two + signs for the Visual C++ Samples folder. In this case, if I try to visit that URL (which you can do in normal situations) you get a 404, which confirms the error BITS is reporting.

To fix this issue, you need to change the path so that this folder doesn’t have any special characters. In ansi, a + sign is the equivilent to a 0x2B (i.e. %2B for a URL string), however the way SCCM handles this poor. I’m not sure if this is a bug, or just by design. The vendor was the one responsible for this pathing, but I can see where some apps will have folders for their SDK that would include C++ example code.

In any event, it took 2 days to figure this one out, but thankfully I did. Luckily, the users don’t need the SDK files :)

Related External Links

Related External Links

SCCM: Program failed (download failed – content mismatch) for advertisement failures

Today I was noticing on a few of our advertisements that all of our machines in the collection had received the “Program failed (download failed – content mismatch)” failure message. Upon receiving this error message, I came across a blog post by Matthew Boyd that referred to the following:

Binary Differential Replication – If this is enabled in the package configuration, some packages seem to fail. I’m assuming that they can’t handle this kind of replication and several of the files become corrupt, creating a hash mismatch. This can be turned off by opening up the package properties, going to the Data Source tab, and unchecking Enable binary differential replication. This wasn’t my problem because I hadn’t enabled binary differential replication.

Hidden Files – Apparently, if the package source contains hidden files, SCCM may not calculate the correct hash for the package and clients could encounter an error. I found a quick way to check this using the command line:

  1. Open up a command window in the root director that contains your package source files.
  2. Type Dir /S /A:H and hit enter. Depending on the package, you may be presented with several directories with multiple hidden files.
  3. Trying to remove the hidden attribute on all the files with the GUI would be tedious, so just use this command instead: attrib -H /S
  4. Update Distribution Points

For my environment, BDR has never been an issue with content mismatches. So for the specific package I was working on I looked at my package source and sure enough there were some hidden files in the source.

So my next step was to look at my entire package source folder and I noticed that there were a lot of packages that had some hidden files. I went through their advertisement reports and sure enough, these packages also had content mismatch failures.

Thanks to Matthew for posting the tip.

Related External Links