Here are 2 useful queries which will allow you to create separate x86 and x64 Windows 7 SCCM collections which will come in handy when your pushing out programs that are architecture specific.

Windows 7 x86

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_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId where (SMS_R_System.OperatingSystemNameandVersion like “%Workstation 6.1%” or SMS_R_System.OperatingSystemNameandVersion like “%Windows 7%”) and SMS_G_System_COMPUTER_SYSTEM.SystemType = “x86-based PC”

Windows 7 x64

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_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId where (SMS_R_System.OperatingSystemNameandVersion like “%Workstation 6.1%” or SMS_R_System.OperatingSystemNameandVersion like “%Windows 7%”) and SMS_G_System_COMPUTER_SYSTEM.SystemType = “x64-based PC”

We came across an issue today with a certain update being pushed out via SCCM “Security Update for Microsoft .NET Framework 4 (KB2416472). Basically the downloading of the file was stuck at 66%.

I then looked for this update in my update list in the SCCM console, i came across the update and went into the properties of it. On the content tab i noticed that all the update was not downloaded.

So i then went back to software updates and searched for the update in my update repository and then i re-downloaded the software update into my Updates deployment package.

I then went back into the properties of the update and could see on the content information tab that all 3 components were downloaded.

The next step was to update the Distribution Point so that it picked up the newly downloaded files. By going to distribution points under your update deployment package and choosing update distribution points and waiting for the source version of your package to update (Check via package status)

I then rebooted a client with the issue and then the update sprang into life

We stumbled across an issue recently where all of a sudden we couldn’t RDP from windows 2003/XP machines to Windows 2008/Vista machines. The first thing we dis was run a Resultant set of policy on a windows 2008 machine applying NLA and the setting was being applied by local policy.

An SCCM agent was installed recently on all machines in the environment , so our next port of call was to pursue this route. So we started to look through the SCCM console and stumbled across the setting which was causing the issue.

The Setting is configured in the below location in the SCCM console.

• Site Database > Site > Client Agents > Remote Tools Client Agent > Remote Desktop

As you can see above NLA is enabled, so if you uncheck this, you’ll see your issues fade away

I have a SCCM server installed on site to deal with client and server machine patching. After the last patch Tuesday I noticed that the windows updates under Software Updates had not been synchronized with the latest updates. To dig deeper into this I navigated under System Status – Site Status – <<site name>> -Component Status and noticed that the SMS_WSUS_SYNC_MANAGER component was in a warning state. By right clicking and selected Show Messages – All i was able to see a bit more information:

The entire description is as follows:

SMS WSUS Synchronization failed.

Message: Thread was being aborted.

Source: Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WSyncAction.WSyncAction.SyncUpdates.

Seems strange that the thread was being aborted so I decided to have a look at the good old Application event viewer to see what was going on at a similar time. I found that the SMS_SITE_BACKUP component was running a split second after the SMS_WSUS_SYNC_MANAGER component which was causing the SMS_SITE_VSS_WRITER component to stop the SMS services as part of preparing for backup (wow that’s a lot of components in one sentence!)

I then changed the schedule start after property for this back up component task by navigating to Site Management – <<Site Name>> – Site Settings – Site Maintenance – Tasks – Backup ConfigMgr Site Server Properties and set the Schedule to run at a time that doesn’t conflict with the synchronization (just an hour later than it was).

This solved the issue and updates are synchronizing happily again now

Hopefully this can save you some valuable troubleshooting time!