SCCM: Collection Query to Find Machines Discovered via AD System Discovery in the last day without latest SCCM Client

In the final days I have with my current employer, I’ve been doing some client cleanup. As you may know, Active Directory System Discovery can make a mess out of your SCCM environment if AD isn’t kept clean. We have a lot of records in our DB that just don’t have the SCCM Client for a variety of reasons (not enough disk space, WMI is broken, etc).

The good thing about AD System Discovery though is that for each record it finds in AD, it’ll look to DNS to see if there’s a corresponding DNS record. If there is, it’ll create a DDR for that machine. So if you have a lot of junk in AD, and DNS scavenging is set to a reasonable amount of time, you should be seeing machines in your SCCM hierarchy that are actually on your corporate network.

So what I set out to do was look for all the machines that have reported back an AD System Discovery record within the last day (technically, the query below is referencing 23 hours) that doesn’t have the latest version of the SCCM client (or the client version is null). Here’s the query.

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 where ((DATEDIFF(hh, SMS_R_SYSTEM.AgentTime, getdate()) < 23) and AgentName = “SMS_AD_SYSTEM_DISCOVERY_AGENT”) and (SMS_R_System.ClientVersion < “4.00.6487.2000” or SMS_R_System.ClientVersion is null)

This gives me all the machines that I need to look into to fix. These are machines I wasn’t able to hit using Client Push installations, or at least I never got a successful client installation for them.

SCCM SCUP: How to Install Adobe Flash Player

With the new release of Flash Player 10.1 I’ve noticed in our environment that we were unable to install the Active X component for IE systems using the provided MSI file with SCUP. I’ve read in a few places that it’s best to utilize the .exe instead of the .msi that is provided by Adobe. So this evening I decided to do so.

Adobe has changed its command lines for flash 10.1 this go round. Originally I was using /s for a silent install but I noticed in Taskmgr that the .exe was sitting under the SYSTEM context doing nothing.

Appdeploy has an entry for Adobe Flash 10.1 that recommends to use -install for a silent install with the .exe form of installation. Once I added the -install switch, things worked just fine.

Now to figure out whether the mms.cfg file works still.

MS10-041 KB979909 .NET Framework 3.5 Service Pack 1 and for the .NET Framework 2.0 Service Pack 2 for Windows 2000, for Windows Server 2003, and for Windows XP Fails to Install

Sorry for the long title.

This past Tuesday Microsoft released a slew of new security patches. I won’t go into detail about all of them, but suffice it to say we’re seeing KB979909 become a pretty hairy thorn in our side.

We deploy all of our updates via SCCM. In my pilot testing I’ve noticed quite a few machines that come up with an error code of -2147023293 with a HexErrorCode of 80070643. This error basically means a fatal error during installation.

Microsoft’s recommendation on how to fix this is referenced here: however what I’m seeing in my environment is nearly a 10% failure rate on my pilot users. There’s no real easy way to fix this remotely, and my help desk will be busy for a couple of days fixing this issue for the amount of calls they’ll be receiving.

Other people are seeing the same problems. For the time being, we’re pulling the update until we see a better solution than uninstall all versions of .NET as the fix.

Below are links to other people experiencing the same problem with this update. Some are also seeing problems with KB982168, and KB979906.

If you’re having the same problem, post a comment below.

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 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 :)