Image may be NSFW.
Clik here to view.I want to take a minute and walk through the process a System Center Configuration Manager 2007 client goes through when processing Software Updates but before we get into that I'd like to explain how to find information specific to a particular update in the client side log files.  When viewing the logs on the client you need to reference the GUID that is assigned to each update. To view this GUID for all your updates you can go into the console and anywhere that updates are displayed in a list, right click on the column header (where it has Bulletin ID, Article ID, etc…) and select View –> Add/Remove Columns. You then have to select “Unique Update ID” in the left list and then select “Add”. Now select “Move Up” until the Unique Update ID is the first one in the list on the right. Now if you look at the console, you will see the GUID as the first column in the window, then find your update and you now have the GUID for that update. You can see the updated console display here:

Image may be NSFW.
Clik here to view.

Once you know the GUID for the update in question you can then relate this to the log entries that Software Updates creates. Sometimes they give you both the GUID and the Title of the update:

1. Update (Missing): Security Update for Windows XP (KB961501) (0d841d92-dcfd-42d0-99cc-da46abbfb86c, 101)  WUAHandler                6/16/2009 7:35:32 AM

Sometimes they only give you the GUID:

Update 1 (0d841d92-dcfd-42d0-99cc-da46abbfb86c) finished installing (0x00000000), Reboot Required? Yes            WUAHandler                6/16/2009 7:37:32 AM

And sometimes they like to hide the GUID in the string. You can find the GUID in this log entry by viewing the string after the “SUM_” section:

Update (Site_7B3DC51A-1366-4325-964D-0C375982148C/SUM_19986d1f-0652-4816-8d54-0add7d1d444c) Progress: Status = ciStateSubmitted, PercentComplete = 0, DownloadSize = 0, Result = 0x0

So the GUID for this update in this example is: 19986d1f-0652-4816-8d54-0add7d1d444c.

Now on to the process itself.

The Scanning Process:

The SCCM 2007 clients receive their WSUS settings as a local policy on the clients, so if there are any Group Policies that overwrite the local policy it causes issues with our scanning process. We get an error in the wuahandler.log stating that our policy has been overwritten by a higher authority as you can see here:

Group policy settings were overwritten by a higher authority (Domain Controller)

The registry keys where we set this can be seen in this exported registry file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"=http://WSUSServer.corp.com:80
"WUStatusServer"="http://WSUSServer.corp.com:80"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"UseWUServer"=dword:00000001

These are the only keys that need to be set on the client, if they have any others then you need to check and make sure that they do not have any WSUS policies being applied from a previous WSUS implementation. When the client first looks for the existence of the keys it checks only for the “WindowsUpdate” key and not the values themselves. If the key is found, it will do a gpupdate to make sure that we have the latest policy is applied to the client. If for some reason the gpupdate will not complete on the client, we stop processing updates on the client.

When we get a scheduler event that tells us to kick off a scan cycle, or when we initiate the scan manually using the client UI we then query location services looking for our nearest SUP so that we can scan against it. You can see that log entry in the locationservices.log here:

Current AD site of machine is ADSiteName LocationServices 8/18/2009 8:22:05 PM
Created and Sent Location Request '{5B457934-72DA-4070-A23A-7F5B05423206}' for package {72B140EF-F84E-4AE9-91E2-7F3863634AAB} LocationServices 8/18/2009 8:22:05 PM
Calling back with the following WSUS locations LocationServices 8/18/2009 8:22:06 PM
WSUS Path='http://WSUSServer.corp.com:80', Server='WSUSServer.corp.com', Version='696' LocationServices 8/18/2009 8:22:06 PM
Calling back with locations for WSUS request {5B457934-72DA-4070-A23A-7F5B05423206} LocationServices 8/18/2009 8:22:06 PM

We then send up several state messages of type 501 up to the site server with the current scan state. We then create a state message of Topic Type 500 for each of the updates that are applicable to the machine. You can see the log entries for a manual scan here from the statemessage.log file:

State message with TopicType 501 and TopicId {72B140EF-F84E-4AE9-91E2-7F3863634AAB} has been recorded StateMessage 8/18/2009 8:22:06 PM
State message with TopicType 501 and TopicId {72B140EF-F84E-4AE9-91E2-7F3863634AAB} has been recorded StateMessage 8/18/2009 8:22:06 PM
State message with TopicType 500 and TopicId b94927af-f480-461b-8fe8-464636c33253 has been recorded StateMessage 8/18/2009 8:24:26 PM
State message with TopicType 500 and TopicId f38d0fed-3fc3-411e-a028-2ecce50f2c07 has been recorded StateMessage 8/18/2009 8:24:26 PM
State message with TopicType 500 and TopicId 95511f7c-4ffd-40e3-85d6-385abbe423db has been recorded StateMessage 8/18/2009 8:24:27 PM
State message with TopicType 500 and TopicId ecb8b318-95c6-4f6d-aa45-b15557f70ce2 has been recorded StateMessage 8/18/2009 8:24:27 PM
State message with TopicType 501 and TopicId {72B140EF-F84E-4AE9-91E2-7F3863634AAB} has been recorded StateMessage 8/18/2009 8:24:27 PM

You can find the reference to the Topic Types here: http://technet.microsoft.com/en-us/library/bb932203.aspx

You can also see the scan being kicked off by the windows update agent or WUA, in the windowsupdate.log file in the root of the windows directory. You know the scan is being kicked off by SCCM by seeing the ccmexec line in the log file as you can see here:

2009-08-18 08:41:57:000 1300 db0 Agent ** START ** Agent: Finding updates [CallerId = CcmExec]

The WMI entries related to scanning are below:

Root\ccm\softwareupdates\WUAHandler\CCM_UpdateSource (WSUS Server we scanned against)
Root\ccm\softwareupdates\updatesstore\CCM_UpdateStatus (Compliance State for each patch)

The Evaluation Process:

Clients receive notification that they need patches through the following policy:

Root\ccm\policy\machine\actualconfig\CCM_UpdateCIAssignment

Each CI corresponds to a particular Deployment that is targeted at the client.

There are three ways that we can initiate an evaluation cycle:

1. Scheduler kicking it off due to an expired CI (Deployment) Deadline or we have met our recurring scheduled time frame

2. We receive a policy that has an assignment of patches that has an expired deadline, in other words there is a deployment targeted at the client and the deadline for the deployment is passed when we receive it

3. We manually kick it off through the Client UI

Once we meet one of these conditions we then kick off the Evaluation Cycle. First thing we do is kick off a scan so that we get the current scan data. We then check each of the assignment CIs that are in our policy. We call the CIAgent thread to tell us what patches are included in the assignment. We compare this list against all the ones that we have listed as applicable in WMI. We then call the SDMAgent to know what binaries are included in the patch package. We then call Patch Downloader who works with CAS (Content Access Service) to find out if the files for the particular package exist in the local cache. If not then we create a Content Transfer job and hand the request off to CTM (Content Transfer Manager). CTM then makes a location services request to find what DPs that are viewable to the client have that package residing on them. Once we get this list back CTM then passes the download processing off to the DTS (Data Transfer Service). DTS determines what transfer protocol it is going to use either BITS or SMB, depending on the list that is returned from the Location Services request. DTS periodically reports back to CAS with the download status of the package. Once complete it sends a completion notice to CAS. CAS then returns success to Patch Downloader who then calls the Updates Deployment Agent to start the installation process.

The Installation Process:

If the policy states that updates can only be deployed during maintenance windows then Updates Deployment checks with Service Window Manager to determine if there are any maintenance windows defined for this client. If not, it then calls WUA Handler and Execution Manager to kick off the installation. If the client does have maintenance windows defined then it will work with the scheduler to set a trigger for the start of the maintenance window. You should see an entry in the UpdatesDeployment log that looks like this:

No current service window available to run updates assignment with time required = 1800 UpdatesDeploymentAgent 8/3/2009 3:09:02 PM
No service window available to run updates assignment UpdatesDeploymentAgent 8/3/2009 3:09:04 PM
This assignment ({F65FFEE2-6869-43F3-B86A-B1D293FE0D1B}) will be retried once the service window is available. UpdatesDeploymentAgent 8/3/2009 3:09:04 PM
EnumerateUpdates for action (UpdateActionInstall) - Total visible updates = 13 UpdatesDeploymentAgent 8/3/2009 3:21:20 PM
CUpdateAssignmentsManager received a SERVICEWINDOWEVENT START Event UpdatesDeploymentAgent 8/3/2009 7:00:00 PM
Attempting pending install assignment UpdatesDeploymentAgent 8/3/2009 7:00:00 PM
Starting install for assignment ({F65FFEE2-6869-43F3-B86A-B1D293FE0D1B}) UpdatesDeploymentAgent 8/3/2009 7:00:00 PM

Once the maintenance window trigger launches the client will look at the first patch that it is to install and see what the max run time is set to. It then takes that value and adds 15 min to it to allow for a reboot of the machine. If there is at least this long available until the expiration of the maintenance window, it will then install the patch. It will do this same calculation for each and every patch. By default the max run time for patches is set at 20 min and can be changed by bringing up the properties to the update in the console. If there is not enough time left in the maintenance window, it will then stop the install and wait until the next maintenance window is available.

Once the installation is completed we then pass off to the Update Store process who kicks off another scan so that we can update WMI with the latest state and then it creates the state messages that are sent up to the server with the updated installation compliance. There are five compliance states that a patch can be in on a client:

1. Installed
2. Needed
3. Not Needed
4. Soft Reboot (Reboot requested but we can still install other patches)
5. Hard Reboot (Reboot requested, we cannot install anything else until this is completed, not even other MSI installs)

On the Site server there is one more state and that is “unknown”. This state means that the server downloaded new metadata about a patch but that the client in question has not scanned for the patch and reported back to the site server with its compliance state.

You can see the entries in the logs for the installation status in the wuahandler.log like this:

1. Update (Missing): Security Update for Windows XP (KB961501) (0d841d92-dcfd-42d0-99cc-da46abbfb86c, 101)  WUAHandler                6/16/2009 7:35:32 AM 
2. Update (Missing): Cumulative Security Update for Internet Explorer 7 for Windows XP (KB969897) (38942b2d-e662-490b-8a67-d69bb73d28e3, 101)          WUAHandler        6/16/2009 7:35:32 AM
3. Update (Missing): Security Update for the 2007 Microsoft Office System (KB969679) (57adacc9-c673-40b7-a946-6671ab71ad23, 101)                WUAHandler        6/16/2009 7:35:32 AM 
4. Update (Missing): Security Update for Windows XP (KB970238) (723b4632-b686-45b3-8aa5-6e638e598657, 101)               WUAHandler                6/16/2009 7:35:32 AM

You can then see the completion status and if the patch requires a reboot later in the wuahandler.log file:

Update 1 (0d841d92-dcfd-42d0-99cc-da46abbfb86c) finished installing (0x00000000), Reboot Required? Yes            WUAHandler                6/16/2009 7:37:32 AM
Update 2 (38942b2d-e662-490b-8a67-d69bb73d28e3) finished installing (0x00000000), Reboot Required? Yes        WUAHandler                6/16/2009 7:37:55 AM 
Update 3 (57adacc9-c673-40b7-a946-6671ab71ad23) finished installing (0x00000000), Reboot Required? No           WUAHandler                6/16/2009 7:38:24 AM 
Update 4 (723b4632-b686-45b3-8aa5-6e638e598657) finished installing (0x00000000), Reboot Required? Yes        WUAHandler                6/16/2009 7:38:28 AM

We then send up the state message for the one that did not require a reboot as you can see here in the statemessage.log file:

State message with TopicType 402 and TopicId Site_7B3DC51A-1366-4325-964D-0C375982148C/SUM_57adacc9-c673-40b7-a946-6671ab71ad23 has been recorded StateMessage       6/16/2009 7:40:45 AM

We then can see after the reboot the entries in wuahandler.log where it finished the install:

Update (0d841d92-dcfd-42d0-99cc-da46abbfb86c) has finished the post reboot operation. HResult: 0x00000000.   WUAHandler                6/16/2009 7:44:44 AM\
Update (38942b2d-e662-490b-8a67-d69bb73d28e3) has finished the post reboot operation. HResult: 0x00000000.                WUAHandler                6/16/2009 7:44:44 AM
Update (723b4632-b686-45b3-8aa5-6e638e598657) has finished the post reboot operation. HResult: 0x00000000.                WUAHandler                6/16/2009 7:44:44 AM

We then see in the statemessage.log file where we send up the state message for the patches that did require a reboot:

State message with TopicType 402 and TopicId Site_7B3DC51A-1366-4325-964D-0C375982148C/SUM_0d841d92-dcfd-42d0-99cc-da46abbfb86c has been recorded   StateMessage       6/16/2009 7:46:58 AM
State message with TopicType 402 and TopicId Site_7B3DC51A-1366-4325-964D-0C375982148C/SUM_38942b2d-e662-490b-8a67-d69bb73d28e3 has been recorded StateMessage       6/16/2009 7:46:58 AM
State message with TopicType 402 and TopicId Site_7B3DC51A-1366-4325-964D-0C375982148C/SUM_bbf29408-fe2d-4adb-b9da-af6245b16e42 has been recorded  StateMessage       6/16/2009 7:46:58 AM

Additional Information:

If your Update Store in WMI on the client gets out of sync with what the server shows installed then you can run a script to resend a full compliance state using this link:

http://gallery.technet.microsoft.com/ScriptCenter/en-us/db05902e-dfa3-4401-87d6-1a93aea85642

Hope this helps,

Brian Shaw | Senior Support Escalation Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Just an FYI that we published a great whitepaper on how to implementing an effective Power Management strategy with System Center Configuration Manager 2007 R3:

The purpose of this white paper is to describe how Microsoft IT (MSIT) successfully deployed Microsoft System Center Configuration Manager 2007 R3 to provide a centralized power management solution to 165,000 physical client desktop and laptop computers across the enterprise. The paper shows how Microsoft IT leveraged System Center Configuration Manager 2007 R3 to implement a cohesive power management strategy that takes full advantage of the native power management features integrated into products such as Windows® 7, Windows XP, and Windows Vista®.

You can get all the details and download the whitepaper here.

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Looks like our very own Fei Xia on the ConfigMgr 2007 Sustained Engineering team wrote up a great blog post on how to expire Software Updates in System Center Updates Publisher and synchronize the expired updates in Configuration Manager 2007.  If you've ever struggled with this or wanted to know more about how it works then this one is for you:

System Center Updates Publisher (SCUP) helps users to publish their private updates to Windows Server Update Services (WSUS) and synchronize the updates in Configuration Manager 2007. Typically users synchronize these updates with WSUS by clicking "Run Synchronization" in the Configuration Manager console. This manual synchronization process does not synchronize the "Expired" flag from WSUS to Configuration Manager, so when you want to expire an update by using SCUP and then run the manual synchronization, the log (SMS\logs\wsyncmgr.log) would read "No changes made to the SMS database" as follows:

Image may be NSFW.
Clik here to view.

This behavior occurs because the manual synchronization process does not synchronize the expired flag for an existing update, which is only performed by the scheduled synchronization process. Use the following workaround  to synchronize expired software updates by using a scheduled synchronization.  

To continue reading see Fei Xia's post here.

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.I just wanted to let everyone know that we recently updated Knowledge Base article 925282 to include System Center Configuration Manager 2007.  In all honesty it always applied but before now we really didn't make that entirely clear, so if you've seen the article before the contents are largely the same it just now applies to the ConfigMgr 2007 as well.  Considering how many potential client install issues this article resolves you really should have it filed away for easy reference.

Enjoy!

KB925282 - How to troubleshoot Advanced Client Push Installation issues in Systems Management Server 2003 and System Center Configuration Manager 2007

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Looking to get a head start on System Center Configuration Manager 2012 (aka Configuration Manager vNext)?  If so then you'll be happy to know that nominations for the ConfigMgr 2012 Beta 2 Technology  Adoption Program (TAP) are now open.  Even if your organization applied for the Beta 1 TAP and didn't get accepted you should go ahead and complete the new Beta 2 TAP survey anyway.  This will ensure your nomination is reviewed with your latest status, deployment levels etc.

Interested but not sure what Microsoft's TAP is all about?  There's a pretty good description of the Technology  Adoption Program here.

You can find the nomination for the ConfigMgr 2012 Beta 2 TAP here.

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Newly created custom labels are present in the System Center Configuration Manager 2007 central site however they do not show up on child sites. You do not see any replication related issues in any of the logs and the AIKBMGR.LOG does not show that an attempt is being made to replicate these objects. You may also see a message similar to the following in the AIKBMGR.LOG:

0 changes in range [0x00000000043744F8-0x000000000265AC79]

Note that the left HEX value in the range above is greater than the HEX value on the right. Also, whenever you make a change and a new message is generated, the right HEX value changes but is still smaller than the left HEX value.

Cause

This can occur if the column "KeyValue" is set to an incorrect HEX value for the column "KeyName" where KeyName is "Replication" in the AI_Generic table.

Resolution

To resolve this issue, follow the steps below:

1. Create a test custom label.
2. Open SQL Management Studio and connect to the central site's SQL server.
3. Run the following query on the Central Site's database:

select * from LU_Category_Local where type=2
4. Check the entry there for the custom label you just created. Note the value for the rowversion column for this entry.
5. Run the following query to correct the AI_Generic table.

Update AI_Generic Set KeyValue = '<HEX value from the first SQL query>' where KeyName='Replication'

6. Now, for each of the custom labels which need to be replicated from the central to the child site just add a description in their properties.
7. Once all the required changes have been made, wait for a couple of minutes and then restart the SMS Executive service.
8. Monitor the AIKBMGR.LOG and you should see messages similar to the ones below indicating successful replication of these objects:

Successfully replicated SMS Object Asset Intelligence batched data{00ff83ae-6df4-408f-ad4d-4f98ce7c5be2}, ReplVarFileName:D:\PROGRAM FILES\MICROSOFT CONFIGURATION MANAGER\inboxes\AIKbMgr.box\10x5bpkx.TMP
Successfully replicated to all sites. Object - ID= Asset Intelligence batched data{00ff83ae-6df4-408f-ad4d-4f98ce7c5be2} - Name= Asset Intelligence batched data{00ff83ae-6df4-408f-ad4d-4f98ce7c5be2}

Once you start seeing these messages in the log you can be sure that the custom labels are now getting replicated. In order to confirm this, just open the ConfigMgr 2007 console on the child site and refresh the custom labels section.

=====

For the latest version of this article see the link below:

KB2460008 - Asset Intelligence custom labels do not get replicated to child sites in System Center Configuration Manager 2007

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.If you're looking for some guidance and best practices on how to author and maintain high quality System Center Update Publisher (SCUP) catalogs then you're at the right place.  Our very own Jason Lewis has created an authoring guide that will answer just about every question you could have including:

"When should I modify my existing update or create a new one?"
"When should I remove an update from my catalog (and/or SCUP)"?
"Should I use prerequisite rules?"

And many more.

Jason Lewis is a Program Manager (PM) on the System Center Configuration Management Team at Microsoft and has been with the team for over 5 years so you're know you're getting this from a true SCUP expert.  For all the details and to download his authoring guide see the following:

SCUP Catalog Authoring Best Practices

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Looks like the latest downloadable update for the System Center Configuration Manager 2007 Documentation Library has been posted to the Microsoft download center. The September 2010 version is the newest downloadable update available and contains new material and fixes to documentation problems reported by customers since the last update was published for the March 2010 version. This version also includes the new documentation for Configuration Manager 2007 R3.

For all the details and a download link see the Configuration Manager Team Blog here.

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Let's say that you need to collect the BitLocker Drive Encryption status from the clients in your environment.  You have System Center Configuration Manager 2007 and you're already using Hardware Inventory, but how do you put it all together?  That's what I'll be discussing here.

First are the additions that are required to be made in the SMS_DEF.MOF and the CONFIGURATION.MOF files:

SMS_DEF.MOF:
------------------
[ SMS_Report (TRUE),
SMS_Group_Name ("Bitlocker"),
SMS_Class_ID ("MICROSOFT|Bitlocker|1.0")]

class Bitlocker : SMS_Class_Template
{
[SMS_Report(TRUE), key]
string          DeviceID;
[SMS_Report(TRUE)]
string          DriveLetter;
[SMS_Report(TRUE)]
uint32          ProtectionStatus;
};

CONFIGURATION.MOF:
-----------------------
#pragma namespace("\\\\.\\root\\cimv2")

[Union,ViewSources{"select * from Win32_EncryptableVolume"},ViewSpaces{"\\\\.\\root\\cimv2\\security\\MicrosoftVolumeEncryption"},
Dynamic,Provider("MS_VIEW_INSTANCE_PROVIDER")]
class Bitlocker
{
    [PropertySources{"DeviceID"},key]
    string          DeviceID;
    [PropertySources{"DriveLetter"}]
    string          DriveLetter;
    [PropertySources{"ProtectionStatus"}]
    uint32          ProtectionStatus;
};

Adding these sections to the respective MOFs and saving them should get things started. Once the clients go through their next policy cycle, they will populate this information into WMI. From here on, whenever the inventory cycle runs the information will be collected in the inventory XML and will get sent to the management point for further processing by the dataloader and added to the database for the respective client.  Once the information is in the database, it can be fetched via custom reports. Alternatively, you can also view this information in the resource explorer for the clients.

Most of the times things will not end at just collecting the information using the MOF edit. There will also be a need to get this information reported.  This is actually pretty simple and here are the steps you'll need to follow to accomplish this:

1. Create a new report and give it a name.

2. Choose the category you want to put it in and then click on Edit SQL Statement.

3. In the SQL Statement box type in the query below:

select sys.Name0, BL.DriveLetter0, BL.ProtectionStatus0 from v_GS_BitLocker BL Join v_r_system sys on sys.ResourceID = BL.ResourceID

Now, there are two things to remember here. One, the name of the table that is being queried for the BitLocker information and second the columns that need to be reported.

The table name will be v_GS_<name of the class in MOF>. For this example, the MOFs I've created above have the class name as BitLocker. This is why we have the view we are querying by the name v_GS_BitLocker.

If more information is desired in reports (which is rarely the case), it can be queried using a select query in SQL against the SCCM database to get all the columns of information which are present in the table.  For example:

select * from v_GS_BitLocker

That's it! Now you're ready to query and report BitLocker information from clients.

Vishal Gupta | Microsoft System Center support

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Please review all of the information in this post specific to your systems for any antivirus scan issues and workarounds.

Important: Some of the steps defined herein may increase your security risk. These steps may also make your computer or your network more vulnerable to attack by malicious users or by malicious software such as viruses.  We recommend the process below in order to enable programs to operate as they are designed or to implement specific program capabilities. Before you make these changes, it is your responsibility to evaluate the risks that are associated with implementing this process and to test in your specific environment. If you choose to implement this process, take any appropriate additional steps to protect your system. It is recommended that you follow this process only if it is absolutely required for your environment.

System Center Configuration Manager 2007:

If you have Microsoft System Center Configuration Manager 2007 (ConfigMgr 2007) installed and are running into the specific issues defined in the Knowledge Base articles below, you should consider excluding the folders/files defined in each:

KB900638 - Multiple symptoms occur if an antivirus scan occurs while the Wsusscan.cab file is copied

KB327453 - Antivirus programs may contribute to file backlogs in SMS 2.0 and in SMS 2003

KB922358 - Microsoft Systems Management Server 2003 Inventory Tool for Microsoft Updates cannot run when a McAfee antivirus program is installed on the same computer

KB924148 - A Systems Management Server (SMS) 2003 client computer stops responding when you try to perform a software update scan of the Inventory Tool for Microsoft Updates (ITMU) on a computer that is running SMS 2003

KB824722 - "Cannot Open the File to Verify the Signature" Appears in Despool.log

Inventory Tool for Microsoft Updates (ITMU):

If you are running ITMU then review the Knowledge Base articles below for issues with virus scan and their workarounds:

KB900638 - Multiple symptoms occur if an antivirus scan occurs while the Wsusscan.cab file is copied

KB922358 - Microsoft Systems Management Server 2003 Inventory Tool for Microsoft Updates cannot run when a McAfee antivirus program is installed on the same computer -

Windows Server Update Services (WSUS):

If you are running WSUS on your system then review the Knowledge Base articles below for issues with virus scan and workarounds:

KB900638 - Multiple symptoms occur if an antivirus scan occurs while the Wsusscan.cab file is copied

SQL Server:

If you have SQL Server installed on your system then consider using the guidelines as defined in the following Knowledge Base articles:

KB309422 - Guidelines for choosing antivirus software to run on the computers that are running SQL Server

KB250355 – Antivirus Software that is not cluster-aware may cause problems with cluster Services

Operating Systems (OS):

If you are running Windows Server 2003, Windows 2000 or Windows XP, review the following Knowledge Base article for virus scan exclusions:

KB822158 - Virus scanning recommendations for computers that are running Windows Server 2003, Windows 2000, or Windows XP

Internet Information Server (IIS):

If you have IIS installed on your system, use the following Knowledge Base articles for virus scan exclusion information:

KB817442 - IIS 6.0: Antivirus Scanning of IIS Compression Directory May Result in 0-Byte File

KB821749 - Antivirus software may cause IIS to stop unexpectedly

Summary of Exclusions for ConfigMgr 2007:

CAB and archived files exclusions:

· Exclude the Wsusscan.cab file from the antivirus scan. –OR-

· Exclude all .cab files from the antivirus scan. –OR-

· Exclude all archived files from the antivirus scan. –OR-

· Exclude the following items from the antivirus scan:

· The folder in which the Wsusscan.cab file is located.

· The path of the Wsusscan.cab file on the local computer.

Exclusion of <DriveLetter>:\<ConfigMgr Install Folder>\Inboxes\SMS_Executive:

The SMS_Executive service may stop responding to some threads. These include the following threads:

• SMS_Discovery_Data_Manager

• SMS_Status_Manager

• SMS_Replication_Manager

• SMS_Despooler

• SMS_Data_Loader

• SMS_Collection_Evaluator

If you experience the behavior described above or in this article (KB327453), use one or more of the following methods to reduce the file backlog:

• Exclude the <DriveLetter>:\<ConfigMgr install folder>\Inboxes\SMS_Executive Thread Name directory or the SMS_CCM\ServiceData directory from the virus-scanning process

• Make sure that the antivirus software is not configure for Real-Time monitoring.

• Remove the antivirus software, and then restart the server so that any remaining traces re unloaded and removed from memory.

Note: If you exclude the <DriveLetter):\<ConfigMgr install folder>\Inboxes directory from virus scanning or remove the antivirus software, you may make the site server and all clients vulnerable to potential virus risks. The client base component files reside in the <DriveLetter):\<ConfigMgr install folder>\Inboxes directory, therefore use these options only as a short-term troubleshooting step and not as a solution for this behavior.

Exclusion of %Windir%\SoftwareDistribution :

Review the issue described in KB922358 where the antivirus program is configured to scan the %Windir%\SoftwareDistribution folder on the computer on which the ITMU scan is run. In this case, when the antivirus program scans the .edb file the antivirus program locks the file. The result is that ITMU cannot access the .edb file. To workaround this issue please make sure that the antivirus program does not scan the files in the %windir%\SoftwareDistribution folder on any computer on which the Windows Update Agent is installed.

APPENDIX: ConfigMgr 2007 Antivirus Recommendations

It is recommended from a performance point of view that antivirus scanning be disabled on certain key non-executable items. As these items are non-executable they provide minimal risk on a server, where the number of non-trusted application should be negligible and the opening of files by user applications is also minimal. The key items include:

- ConfigMgr 2007 database data and log files (server-side)

- ConfigMgr 2007 log files (server-side)

- ConfigMgr 2007 transactional files (server-side)

- Windows Update Scan Catalog (client-side)

The following is a listing of the details of the above types of key items:

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Rushi Faldu | Senior PFE

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Just wanted to give you a quick heads up on a new Knowledge Base article for System Center Service Manager 2010 that we published last night:

=====

Symptoms

A change request in System Center Service Manager 2010 will remain with a status of "in Progress" and cannot be closed even if all activities have been completed.

Cause

The change request cannot be closed if there is an open change request in the "relationships" tab.  The open change request in the "relationships" tab is a dependency of the change request trying to be closed.  If this second change request shows the first change request in its own "relationships" tab then the two change requests will have a circular relationship and neither can be closed.

Resolution

The second change requests should be removed from the "relationships" tab of the change request to be closed.  If it does not change from "in progress" to "completed" after a few minutes, create a new manual activity and complete it.  The change request should then change status and can be closed.

For the latest version of the article see the link below:

KB2466715 - Service Requests with circular relationships cannot be closed in System Center Service Manager 2010

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Just a heads up on a new ConfigMgr 2007 Knowledge Base article we published this morning.  If you're using a ConfigMgr Task Sequence on a PC with multiple drives or partitions and it uses USMT 4 with hardlinking then you'll want to check this one out:

=====

Symptoms

Consider the following scenario:

1. A computer has two or more drives or partitions.
2. The User Profiles and the Windows directory are located on the first drive or partition (assume drive letter C:).
3. Second drive or partition has more available free disk space than the first (assume drive letter D:).
4. A Configuration Manager 2007 OSD Refresh Task Sequence that uses USMT 4 with hardlinking is run on the computer.

In this scenario the Capture User Files and Settings"/"Capture User State" task will succeed but the "Restore User State"/"Restore User Files and Settings" task will fail.

Viewing the SMSTS.log reveals the following errors:

Executing command line: osdmigrateuserstate.exe /apply /continueOnError:%OSDMigrateContinueOnRestore% TSManager
==============================[ OSDMigrateUserState.exe ]============================== OSDUSMT
Initializing from environment successful OSDUSMT
Trying to resolve package path for packageID - <Pacakage_ID> OSDUSMT
Successfully connected to "<Package_Location>\<Pacakage_ID>" OSDUSMT
USMT package path = '<Package_Location>\<Pacakage_ID>\' OSDUSMT
Initiailization succeeded OSDUSMT
EncryptionKey ENV var not found. This may be because Local state Store is used. OSDUSMT
Building Default USMT params successful OSDUSMT
Adding config files to user params successful OSDUSMT
Additional user defined options = "/hardlink /nocompress" OSDUSMT
Building user defined params successful OSDUSMT
Building USMT command successful OSDUSMT
Executing command line: "<Package_Location>\<Pacakage_ID>\<Arch>\loadstate.exe" "D:\_SMSTaskSequence\UserState/c /all /v:5 /l:"C:\Windows\CCM\Logs\SMSTSLog\loadstate.log" /progress:
"C:\Windows\CCM\Logs\SMSTSLog\loadstateprogress.log" /i:"<Package_Location>\<Pacakage_ID>\<Arch>\miguser.xml" /i:"<Package_Location>\<Pacakage_ID>\<Arch>\migapp.xml"  /hardlink /nocompress OSDUSMT
Process completed with exit code 38 OSDUSMT
USMT completed with exit code 38 OSDUSMT
USMT returned exit code (0x00000026). Look USMT log file loadstate.log for detail error message. OSDUSMT
Invoking ReleaseSource on USMTPackagePath <Package_Location>\<Pacakage_ID>\ OSDUSMT
OSDMigrateUserState finished: 0x80070026 OSDUSMT
Process completed with exit code 2147942438 TSManager
!--------------------------------------------------------------------------------------------! TSManager
Failed to run the action: Restore User Files and Settings.
Reached the end of the file. (Error: 80070026; Source: Windows) TSManager

Alternatively, if you are using a Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard you will see the following:

Executing command line: osdmigrateuserstate.exe /apply /continueOnError:%OSDMigrateContinueOnRestore% TSManager
==============================[ OSDMigrateUserState.exe ]============================== OSDUSMT
Initializing from environment successful OSDUSMT
Trying to resolve package path for packageID - <Pacakage_ID> OSDUSMT
Successfully connected to "<Package_Location>\<Pacakage_ID>" OSDUSMT
USMT package path = '<Package_Location>\<Pacakage_ID>\' OSDUSMT
Initiailization succeeded OSDUSMT
EncryptionKey ENV var not found. This may be because Local state Store is used. OSDUSMT
Building Default USMT params successful OSDUSMT
Adding config files to user params successful OSDUSMT
Additional user defined options = "/hardlink /nocompress" OSDUSMT
Building user defined params successful OSDUSMT
Building USMT command successful OSDUSMT
Executing command line: "<Package_Location>\<Pacakage_ID>\<Arch>\loadstate.exe" "D:\_SMSTaskSequence\StateStore /c /all /v:5 /l:"C:\Windows\CCM\Logs\SMSTSLog\loadstate.log" /progress:
"C:\Windows\CCM\Logs\SMSTSLog\loadstateprogress.log" /i:"<Package_Location>\<Pacakage_ID>\<Arch>\miguser.xml" /i:"<Package_Location>\<Pacakage_ID>\<Arch>\migapp.xml"  /hardlink /nocompress OSDUSMT
Process completed with exit code 38 OSDUSMT
USMT completed with exit code 38 OSDUSMT
USMT returned exit code (0x00000026). Look USMT log file loadstate.log for detail error message. OSDUSMT
Invoking ReleaseSource on USMTPackagePath <Package_Location>\<Pacakage_ID>\ OSDUSMT
OSDMigrateUserState finished: 0x80070026 OSDUSMT
Process completed with exit code 2147942438 TSManager
!--------------------------------------------------------------------------------------------! TSManager
Failed to run the action: Restore User State.
Reached the end of the file. (Error: 80070026; Source: Windows) TSManager

The loadstate.log will also show the following errors:

<Date> <Time>, Status                [0x000000] Activity: 'MIGACTIVITY_TRANSPORT_SELECTION'
<Date> <Time>, Info                  [0x000000] Processing the settings store[gle=0x00000006]
<Date> <Time>, Info                  [0x000000] Opening hardlink store D:\_SMSTaskSequence\UserState
<Date> <Time>, Info                  [0x000000] Entering MigOpenHardLinkStore method
<Date> <Time>, Info                  [0x0802e2] User selecting transport(UNC Transport (class CUNCTransport) ) with initialization data(UNC: Path(D:\_SMSTaskSequence\UserState\USMT))
<Date> <Time>, Error                 [0x080000] HARDLINK: cannot find distributed store for c - 0694a57d-1506-4755-af10-782d0a5b1723[gle=0x00000002]
<Date> <Time>, Error                 [0x0802e3] SelectTransport: OpenDevice failed with Exception: Win32Exception: HARDLINK: cannot find all distributed stores.:There are no more files. [0x00000012] void __cdecl Mig::CMediaManager::SelectTransportInternal(int,unsigned int,struct Mig::IDeviceInitializationData *,int,int,int,unsigned __int64,class Mig::CDeviceProgressAdapter *)
void __cdecl Mig::CHardLinkHelper::Open(class UnBCL::String *)[gle=0x00000002]
<Date> <Time>, Error                 [0x000000] Unable to open store at D:\_SMSTaskSequence\UserState\USMT[gle=0x00000002]
<Date> <Time>, Info                  [0x000000] Leaving MigOpenHardLinkStore method
<Date> <Time>, Error                 [0x000000] Failed to select store. Path: D:\_SMSTaskSequence\UserState[gle=0x00000002]
<Date> <Time>, Warning               [0x000000] Internal error 23 was translated to a default error
<Date> <Time>, Info                  [0x000000] Failed.[gle=0x00000006]
<Date> <Time>, Info                  [0x000000]   An error occurred during store access[gle=0x00000006]
<Date> <Time>, Info                  [0x000000] USMT Completed at 2010/06/30:15:46:50.995[gle=0x00000006]

Alternatively, if you are using a Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard you will see the following:

<Date> <Time>, Status                [0x000000] Activity: 'MIGACTIVITY_TRANSPORT_SELECTION'
<Date> <Time>, Info                  [0x000000] Processing the settings store[gle=0x00000006]
<Date> <Time>, Info                  [0x000000] Opening hardlink store D:\_SMSTaskSequence\StateStore
<Date> <Time>, Info                  [0x000000] Entering MigOpenHardLinkStore method
<Date> <Time>, Info                  [0x0802e2] User selecting transport(UNC Transport (class CUNCTransport) ) with initialization data(UNC: Path(D:\_SMSTaskSequence\StateStore\USMT))
<Date> <Time>, Error                 [0x080000] HARDLINK: cannot find distributed store for c - 0694a57d-1506-4755-af10-782d0a5b1723[gle=0x00000002]
<Date> <Time>, Error                 [0x0802e3] SelectTransport: OpenDevice failed with Exception: Win32Exception: HARDLINK: cannot find all distributed stores.: There are no more files. [0x00000012] void __cdecl Mig::CMediaManager::SelectTransportInternal(int,unsigned int,struct Mig::IDeviceInitializationData *,int,int,int,unsigned __int64,class Mig::CDeviceProgressAdapter *)
void __cdecl Mig::CHardLinkHelper::Open(class UnBCL::String *)[gle=0x00000002]
<Date> <Time>, Error                 [0x000000] Unable to open store at D:\_SMSTaskSequence\StateStore\USMT[gle=0x00000002]
<Date> <Time>, Info                  [0x000000] Leaving MigOpenHardLinkStore method
<Date> <Time>, Error                 [0x000000] Failed to select store. Path: D:\_SMSTaskSequence\StateStore[gle=0x00000002]
<Date> <Time>, Warning               [0x000000] Internal error 23 was translated to a default error
<Date> <Time>, Info                  [0x000000] Failed.[gle=0x00000006]
<Date> <Time>, Info                  [0x000000]   An error occurred during store access[gle=0x00000006]
<Date> <Time>, Info                  [0x000000] USMT Completed at 2010/06/30:15:46:50.995[gle=0x00000006]

Cause

This problem occurs because the default path where the USMT 4 state store is to be saved as specified by ConfigMgr 2007 is on a drive or partition other than the one where the Windows directory and User Profiles are located. When using hardlinking, this could possibly cause the state store to either span multiple drives/partitions and/or actually reside on a drive/partition other than the drive specified in the path by ConfigMgr 2007. The reason for this is that when using hardlinking, the state store has to reside on the same drive/partition where the original data existed.

The state store location is stored in the variable OSDStateStorePath. The default value of this variable is another variable, _SMSTSUserStatePath. _SMSTSUserStatePath usually resolves to a subdirectory called UserState within the Task Sequence cache folder. The Task Sequence cache folder is automatically created by the Configuration Manager Task Sequence and placed on the root level of the drive with the most available free space and given the name _SMSTaskSequence. Similarly, when using MDT 2010/MDT 2010 Update 1 integration, the state store location is determined by the ztiuserstate.wsf script in the "Determine Local or Remote UserState" task. The ztiuserstate.wsf script also sets the value of OSDStateStorePath to a subdirectory within the Task Sequence cache folder, but to a subdirectory called StateStore.

If a computer only has one drive or partition, or has multiple drives or partitions but the first drive/partition has the most available free space, the Task Sequence cache folder will be created at the path C:\_SMSTaskSequence. The state store would then be saved within this folder in either the path C:\_SMSTaskSequence\UserState or C:\_SMSTaskSequence\StateStore.

However, if a PC has multiple drives/partitions and the first drive/partition is not the one with the most available free space, then the Task Sequence cache folder will be created on the drive/partition with the most available free space. Assuming that the drive/partition with the most available free space has the drive letter of D:, then the path where the Task Sequence cache folder would be created is D:\_SMSTaskSequence. The state store would then be specified to be in either the directory D:\_SMSTaskSequence\UserState or D:\_SMSTaskSequence\StateStore. Assuming that the drive/partition where the user profiles are located and Windows is installed onto is the first partition/drive with the drive letter of C:, then the state store will actually span multiple volumes and/or reside on a drive/partition other than the one specified in the state store path since some or all of the original data exists on C:.

This is a problem when using USMT 4 hardlinking with ConfigMgr 2007 because at least part of the hardlink state store is on a different drive/partition (D:) than Windows and the user profiles (C:). When a ConfigMgr 2007 OSD Task Sequence runs, at the "Apply Oeprating System Image" step, before the OS is applied to the hard drive, a recursive delete runs that wipes all contents of the drive minus a few protected folders. Normally the folder containing the state store and specified in the OSDStateStorePath variable is marked as one of the protected folders. However, if the state store spans multiple volumes, only the part of the state store that resides on the same drive/partition that is specified in the OSDStateStorePath variable is not wiped. The state store that resides on the OS volume is wiped, causing the problem.

This scenario will not cause the capture performed by scanstate.exe via the "Capture User State" task to fail because a hardlink state store that spans multiple drives/partitions is a supported scenario when using USMT 4 outside of ConfigMgr 2007. However, when the restore of the state store is attempted by loadstate.exe via the "Restore User State" task, loadstate.exe will report that state store is invalid since part of it has been deleted and it will exit with a failure. If the drive/partition where the user profiles were originally located has been formatted, wiped, or erased (usually via the "Format and Partition Disk" or "Apply Oeprating System Image" tasks) then there is no way to recover the original files and settings.

Resolution

To resolve the prople the state store has to be all saved to the same drive/partition where the Windows OS and User Profiles reside. This will cause the state store not to span multiple drives/partitions. To do this, the variable OSDStateStorePath has to be changed from its default value. When using MDT 2010/MDT 2010 Update 1 integration, the variable has to be redefined after it has been set by the "Determine Local or Remote UserState" task via the ztiuserstate.wsf script .

To ensure that the state store is saved to the same drive/partition where Windows is installed and the User Profiles are located, the environment variable SystemDrive can be used as part of the path that defines the variable OSDStateStorePath.

If MDT 2010/MDT 2010 Update 1 integration is not being used, the "Set Task Sequence Variable" task that sets the variable OSDStateStorePath needs to be modified:

1. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
2. Right click on the affected Task Sequence and choose "Edit".
3. Click on the "Set Local State Location" task. Ensure that the task is a "Set Task Sequence Variable" task that sets the variable OSDStateStorePath.
   Next to the "Value:" text field, change it from
   %_SMSTSUserStatePath%
   
   to
   %SystemDrive%\UserState
   

4. Click on the "OK" or "Apply" button to save the task sequence.

If the "Set Local State Location" task does not exist, look for a "Set Task Sequence Variable" task that sets the variable OSDStateStorePath, and then make the changes above.

If using MDT 2010/MDT 2010 Update 1 integration, then a new "Set Task Sequence Variable" task needs to be added after the "Determine Local or Remote UserState" task that redefines the variable OSDStateStorePath:

1. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
2. Right click on the affected Task Sequence and choose "Edit".
3. Click on the "Determine Local or Remote UserState" task and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task after "Determine Local or Remote UserState" task but before the "Request State Store" task.
4. In the newly created "Set Task Sequence Variable Task":
   • Next to the "Name:" text box, enter in:
     Set Local State Location
     
   • Next to the "Task Sequence Variable:" text box, enter in
     OSDStateStorePath
     
   • Next to the "Value:" text box, enter in:
     %SystemDrive%\StateStore
     
5. Click on the "OK" or "Apply" button to save the task sequence.

If in Step 3 the task "Determine Local or Remote UserState" does not exist or has been renamed, look for the "Run Command Line" task that runs the script ztiuserstate.wsf, and then follow the above steps.

Note:

• In the above two methods, the state store subdirectories are called UserState and StateStore. However the name of the state store can be whatever the user desires as long as it is within Windows naming conventions. The key point is to use the environment variable SystemDrive as part of the path to ensure that the state store is saved in the same drive/partition as Windows and the user profiles.

• Ensure that there are no "Format and Partition Disk"/"Partition Disk"/"Partition Disk 0" tasks in the Task Sequence that format and partition the drive/partition where the user profiles are originally located and where the state store is saved. If there are any such tasks, either disable them or make sure that they have conditions on them where they do not run if state store is saved locally on the hard drive.
  If a "Format and Partition Disk" task runs on the drive/partition where the user profiles are originally located and where the state store is saved, then all of the data and settings captured in the state store will be lost. Instead the "Apply Operating System Image"/"Apply Operating System" task will run a recursive delete of all files and directories on the drive/partition minus a few protected folders.
  The protected folders that are not deleted include the Task Sequence cache folder and the state store folder. The Task Sequence cache folder path is stored in the variables _SMSTSMDataPath , _SMSTSClientCache, and _SMSTSNewClientCachePathToCleanup and usually resolves to the path C:\_SMSTaskSequence. As mentioned earlier, the state store path is stored in the variable OSDStateStorePath. The protected folders that will not be wiped are stored in the variable _SMSTSProtectedPaths
  In the SMSTS.log, the recursive delete and wipe process that occurs during the "Apply Operating System Image"/"Apply Operating System" task is logged as something similar to the following:
  Wiping C:\                                                                                               ApplyOperatingSystem
  Set "C:\_SMSTaskSequence" to not be wiped                                             ApplyOperatingSystem
  Set "%OSDStateStorePath%" to not be wiped                                             ApplyOperatingSystem
  Set "%_SMSTSClientCache%" to not be wiped                                            ApplyOperatingSystem
  Set "%_SMSTSNewClientCachePathToCleanup%" to not be wiped                ApplyOperatingSystem
  Skipping C:\_SMSTaskSequence for wipe                                                   ApplyOperatingSystem
  Calculating expected free space.                                                                ApplyOperatingSystem
  Reporting deletion progress.                                                                      ApplyOperatingSystem
  Successfully wiped C:\                                                                              ApplyOperatingSystem

=====

For the latest version of the article see the link below:

KB2269650 - A System Center Configuration Manager 2007 SP2 Task Sequence may fail if the computer has multiple drives or partitions and USMT 4 with hardlinking is being used

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.When running a User Driven Installation (UDI) Task Sequence on an x64 (64-bit or AMD64) Windows 7 machine, it shows the following warning under User Data and Settings:

No valid Windows directory found, data and settings will not be captured

Image may be NSFW.
Clik here to view.

Cause

This can occur when your  64-bit image is configured as a 32-bit image in the UDI Wizard Designer.  When you add your image, the UDI Wizard Designer defaults to specifying a Windows 7 x86 (32-bit) image:

Image may be NSFW.
Clik here to view.

If using a 64-bit image you will need to change this to AMD64.

Resolution

Once you remove the x86 reference and added it back as AMD64 in the wizard it allows the Task Sequence to work as expected.

Image may be NSFW.
Clik here to view.

Clifton Hughes | Senior System Center Support Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Just a heads up on a new ConfigMgr 2007 Knowledge Base article we published this morning.  If you're pushing out Software Updates to Windows 7 or Windows Server 2008 R2 based clients then you'll want to be aware of this potential issue:

=====

Symptoms

System Center Configuration Manager 2007 clients running Windows 7 or Windows Server 2008 may reboot even though the Configuration Manager 2007 Software Updates deployment management settings are configured to suppress reboots on all clients.  By default the reboot will be scheduled for 3:00am but can occur at other times as well.

Cause

This can occur if the Configuration Manager clients have Automatic Updates enabled for the Windows Update client.  If an update is delivered to a client that has Automatic Updates enabled, the Windows Update agent may ultimately manage the reboot of that client depending on the schedule used.  By default, the Windows Update agent schedules updates to be installed daily at 3:00am. 

Resolution

To resolve this issue disable the Automatic Updates policy on the Configuration Manager client computers.  To do this, apply a Group Policy to disable Automatic Updates.  This setting is located in the following location:

Computer configuration>Administrative Templates>Windows Components> Windows update> Configure Automatic updates

Note that this policy does not prevent the Windows Update service from functioning, it merely disables the Windows Update agent behavior described above. This will allow only the Configuration Manager Client to manage updates and thus the reboot schedule.

It is also recommended that you disable the Action Center so that the user will not be prompted to configure Automatic Updates.  For information on configuring the Action Center see the following:

http://technet.microsoft.com/en-us/library/ee617161(WS.10).aspx

More Information

When Automatic Updates for the Windows Update agent and the Configuration Manager client are enabled on the same machine, both can manage the reboot for the client.  This assumes that the Windows Update agent is configured with the default install behavior and schedule.

When both the Configuration Manager client and the Windows Update agent are enabled you will see entries similar to the following in the Windowsupdate.log file:

2010-11-22          13:09:09:916       296        1ffc        Agent    **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates] windows update agent
2010-11-22          13:09:09:916       296        1ffc        Agent    *************

In the same log:

2010-11-22          14:03:46:064       2720       b84         COMAPI               <<-- SUBMITTED -- COMAPI: Search [ClientId = CcmExec]
2010-11-22          14:03:46:064       296        23d4      Agent    ** START **  Agent: Finding updates [CallerId = CcmExec] Configuration Manager Client
2010-11-22          14:03:46:064       296        23d4      Agent    *********

In this situation, if for example the Configuration Manager client installs an update that requires a reboot and it was suppressed, the update installation creates a registry setting in HKEY_LOCAL_MACHINE\System\Current Control Set\Control\Session Manager\FileRenameOperations with the name of the file that needs to be replaced on the following reboot. The Windows Update agent uses that registry key to define the OS status that will trigger the agent to be in a reboot pending condition.

In a case like this, if the Configuration Manager client is set to reboot the machine after a few days but the Windows Update agent is scheduled to install updates every day at 3:00am, the condition that is applied first after installing the update will be the behavior the OS will have.

The Configuration Manager client installs updates by Windows Update agent API but if machine has the Windows update agent enabled the agent itself will follow its own configuration settings.

Also note that if you sysprep a client machine to use as your base image, and Automatic Updates are enabled when the image is taken, all clients based on that image will retain the Windows Update configuration in the following location:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Windows Update\Auto Update\

The relevant values here are scheduleinstallday and scheduleinstalltime.

=====

For the latest version of this article see the link below:

KB2476479 - System Center Configuration Manager 2007 clients running Windows 7 or Windows Server 2008 reboot even though deployment management settings are configured to suppress reboots

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Just a heads up on a new ConfigMgr 2007 Knowledge Base article we published today.  If you do any work with query based collections, and who doesn't, then you'll want to check this one out:

=====

Symptoms

All systems show in a collection after removing the criteria from a query for a query based collection in System Center Configuration Manager 2007.

Cause

Removing the criteria in the query for a query based collection removes the from statement from the query and leaves only the select statement. This causes all systems to be added to a collection that may already have an OSD or other advertisement targeted to it.

Resolution

If you need to modify an existing query based collection, delete the existing query and create a new one instead.

=====

For the latest version of this article see the link below:

KB2471057 - All systems inadvertently targeted for an advertisement after modifying a collection in System Center Configuration Manager 2007

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

I'm still working through the backlog of new Knowledge Base articles we're pushing out and thought I'd give you a heads up on another new ConfigMgr 2007 article we published this morning.  This one describes a scenario where you get "MSI: Configuration Manager Client is not installed" trying to install the client:

=====

Symptoms

Attempts to install the System Center Configuration Manager 2007 client may fail with the following error messages in the ccmsetup.log:

MSI: Configuration Manager Client is not installed. ccmsetup 12-11-2010 16:26:12 3264 (0x0CC0)
Installation failed with error code 1603 ccmsetup 12-11-2010 16:26:12 3264 (0x0CC0)

If you check the client.msi.log you may notice the following lines:
MSI (s) (54:74) [16:26:11:416]: Checking in-progress install: install for same configuration.
MSI (s) (54:74) [16:26:11:416]: Suspended install detected. Resuming.

Cause

This can occur if a previously failed installation of the Configuration Manager client left behind an IPI installer file (.ipi) in the %systemroot%\installer directory on the target computer.

Resolution

Search for *.ipi files in the %systemroot%\installer directory on the target computer and temporarily move them to a different folder.  Next run the setup of the client installation again and it should complete successfully.

=====

For the latest version of this article see the link below:

KB2467702 - Installation of the System Center Configuration Manager 2007 client fails with the error "MSI: Configuration Manager Client is not installed"

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Here's another KB we published this morning.  This one talks about an issue where creating an MDT based task sequence fails with An error occurred when loading the task sequence and logs a 0x80041002 error in TaskSequenceProvider.log:

=====

Symptoms

After clicking the Finish button when attempting to create an Microsoft Deployment Toolkit (MDT) task sequence, the task sequence may fail to create with the following error:

An error occurred when loading the task sequence

The TaskSequenceProvider.log may also show errors similar to the following:

Failed to load class properties and qualifiers for class BDD_UsePackage in task sequence. 0x80041002 (2147749890) TaskSequenceProvider 11/18/2010 8:28:12 AM 1204 (0x04B4)
Failed to load node Use Toolkit Package from XML into WMI 0x80041002 (2147749890) TaskSequenceProvider 11/18/2010 8:28:12 AM 1204 (0x04B4)
Failed to load children steps for node "Execute Task Sequence" from XML 0x80041002 (2147749890) TaskSequenceProvider 11/18/2010 8:28:12 AM 1204 (0x04B4)
Failed to load children steps for node "" from XML 0x80041002 (2147749890) TaskSequenceProvider 11/18/2010 8:28:12 AM 1204 (0x04B4)
Failed to load XML for the task sequence into WMI 0x80041002 (2147749890) TaskSequenceProvider 11/18/2010 8:28:12 AM 1204 (0x04B4)

Cause

This error can occur if the MDT WMI classes are not properly registered.

Resolution

To resolve this issue follow the steps below:

1. Close all of your remote and local SCCM admin console sessions.

2. Log on to your Configuration Manager server and select Start -> All Programs -> Microsoft Deployment Toolkit -> Configure ConfigMgr Integration.

3. In the Configure ConfigMgr Integration wizard, select “Remove the ConfigMgr custom action definitions” and then click next to remove all the definitions.

4. Re-run Configure ConfigMgr Integration again, and select “Install the ConfigMgr extensions”

Once you do this try creating the Task Sequence again.  It should now complete successfully.

More Information

This error occurs because the BDD_* WMI classes have not been correctly registered under the \root\SMS\site_<sitecode> namespace in WMI.

=====

For the latest version of this article see the link below:

KB2468097 - A System Center Configuration Manager 2007 MDT Task Sequence fails with "An error occurred when loading the task sequence"

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Here's another KB we published this morning.  This one talks about an issue where attempting to reinstall a System Center Configuration Manager 2007 secondary site fails when attempted via the primary site console:

=====

Symptoms

You issue an instruction to uninstall a System Center Configuration Manager 2007 secondary site from the primary site console.  After doing so you notice on the secondary site server that the uninstall process completed properly but when you then try to reinstall the secondary site on the same server using the primary site's console it gets stuck showing install pending on the primary site console.  On the secondary site in the file SMS_BootStrap.ini, you will also notice that it mentions the purpose as DEINSTALL.

Cause

After the secondary site gets uninstalled, it should ideally send a notification back to its primary site informing it that the deinstallation was successful. If for any reason this notification does not reach the primary site, it will not know about the deinstallation being completed. When this happens, when we then try to install the secondary site on the same server again it will first try to uninstall it. This is why the instruction sent to the server in the SMS_BootStrap.ini file is DEINSTALL.

Resolution

To resolve this situation, browse to the hman.box on the primary site server. You will find a file there by the name of delsite.lkp. This file contains entries for each of the secondary sites that are set for deinstallation. Open this file in notepad and depending on the scenario, you may want to remove just the entry or delete the file itself (as this contains the deinstall instructions for all secondary sites which were initiated from this primary site).
Example:
[N18]
Key=D78A1B1BEC3887B3D8A01115F4C47E81D3FC982D24
[N23]
Key=43083D44ABB3D3FF48B58208228245849D852665B3
[N04]
Key=FDCC2C92FF4D5071C02D8C6818AFA9702A3CF6E4F4
[N01]
Key=CF269DF522B1B3D07D165B9054903762EED279BEB1
If the site we're trying to install has the site code N01, you would remove the entry for only N01 and the rest of the file remains the same. So for this example, after removing the N01 entry, the information contained in this file would be:
[N18]
Key=D78A1B1BEC3887B3D8A01115F4C47E81D3FC982D24
[N23]
Key=43083D44ABB3D3FF48B58208228245849D852665B3
[N04]
Key=FDCC2C92FF4D5071C02D8C6818AFA9702A3CF6E4F4

More Information

The hierarchy manager is the component which handles all hierarchy changes including install and uninstall of secondary sites assuming it is initiated from the primary site. In the case above, we will remain stuck in the deinstall loop because when the setup tries to uninstall the secondary site on the destination server it will fail as there are no secondary site components currently installed there. In cases of actual failures, this will work and is the actual purpose of this process.

=====

For the latest version of this article see the link below:

KB2469993 - Reinstall of a System Center Configuration Manager 2007 secondary site fails when attempted via the primary site console

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.The System Center Configuration Manager 2007 product team just released a couple new support statements you'll probably want to be aware of regarding Windows Storage Server 2008 R2 and Microsoft SQL Server 2008 SP2.  I won't steal all of their thunder here but you can read their announcement in it's entirety here.

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.Here's another KB we published this morning.  This one offers a general discussion on hotfix installation in System Center Configuration Manager 2007:

=====

Summary

A System Center Configuration Manager 2007 (ConfigMgr) hotfix will affect one or more separate roles within the distributed environment.  Possible roles include:

·         Primary Site Server
·         Secondary Site Server
·         Remote Administrator Console
·         Remote Provider
·         Client

This article is designed to provide general guidance as it relates to ConfigMgr hotfixes.  For details on a specific hotfix refer to its accompanying Knowledge Base (KB) article at http://support.microsoft.com.

Hotfix Basics

Regardless of the affected roles, only a single bundle is released.  The bundle, when distributed via Microsoft Customer Service and Support (CSS) or directly via the Knowledge Base article (KB article), will be packaged using the Microsoft Hotfix Self-Extractor.

The name of this executable file will be:

<FixID>_<Language>_<Platform>_zip.exe

Note that the FixID value is an internal reference number separate from the KB article ID. 

420401_ENU_i386_zip.exe is one example.

The platform identifier is not relevant for a ConfigMgr SP2 or higher hotfix; the same file will extract on both 32-bit and 64-bit platforms.

The self-extracting file can be run on any machine and will display a prompt to choose a location to extract the contents which will be the actual hotfix bundle.

With the release of Service Pack 2 (SP2) for ConfigMgr, this bundle is a Windows Installer .MSI file.  Prior to SP2 the bundle was built using Update.exe.
The .MSI is named according to the following convention:

<Product>-<Affected Service Pack >-<KB Article ID>-<Language>.MSI

For example, SCCM2007-SP2-KB2263826-ENU.MSI is the ConfigMgr 2007 post SP2 English version of the fix from KB2263826. Some early post-SP2 hotfixes also contained an x86 identifier in the name, but this was not relevant as the x86 file worked on either platform.

If a hotfix is released as a general update and made available for download from the Microsoft Download Center it will be in the .MSI format; the hotfix self-extractor is not used.

The KB article for a given hotfix will list the applicable roles.  If you attempt to install a hotfix on a machine that does not contain one of those roles you would see the message:

This hotfix doesn’t match the installed role of Configuration Manager 2007

International environments and localized hotfixes

Hotfixes will be available in the localized server languages, or in the case of clients in one of the two International Client Packs (ICPs).   An ICP version of a hotfix only affects the client binaries but will still be applied to the site server.  Once an ICP has been installed on a site it also changes the version number.  The end result is that ICP versions of hotfixes will need to be applied for those clients in the future.  To confirm the ICP version of a site server check the Full Version  value in the following registry key:

Software\[Wow6432Node]\Microsoft\SMS\Setup\

The value should be in the format of 04.00.XXXX.YZZZ

Where XXXX is the build number (6487 for ConfigMgrSP2), Y is the service pack number, and ZZZ the QFE version.

QFE versions are 000 for ENU or other localize language, 400 for ICP1 and 700 for ICP2.  So for ConfigMgrSP2 ICP1 the version would be 04.00.6487.2400 and ICP2 is 04.00.6487.2700.

For more information refer to Supported Localized Languages and Tasks for International and Multi-Language Configuration Manager Clients.

Non-client Hotfix Installation (SP2)

With the exception of a ConfigMgr client, the hotfix .MSI file should be installed directly to the machine housing the applicable role.  This includes Administrator Console machines and remote Provider servers.

In the case of a hotfix that applies to both primary and secondary sites, it is possible the same files will not be updated on the secondary site.   This is only done when a hotfix contains a file that isn’t applicable to a secondary site, such as dataldr.dll, and is usually referenced in the KB article.

Remote site systems, such as a remote Management Point or State Migration Point, are updated by installing the hotfix on their respective site server.

Some components on a site server or remote site system will be reinstalled depending on the roles to be updated.   Progress can be tracked using the <ConfigMgr Install Folder>\Logs\sitecomp.log file.  This is a process similar to performing a Site Reset.  All components that are installed on a server housing the affected role will be reinstalled.

For example, take a case where SiteServer1 has the Management Point installed and RemoteServer1 has the State Migration Point (SMP).  A hotfix affecting only the SMP will result in that component being reinstalled on RemoteServer1, with no direct impact to running components on SiteServer1.

Administrator customizable files, such as sms_def.mof or AdminConsole.xml may be replaced by some hotfixes.  When this happens it should be noted in the KB article, and the files will be backed up to %Windir%\$NTUninstall<KB Article ID>\,e.g., C:\Windows\NtUninstallKB955262$\.  Any changes made by the administrator will need to be merged from the backup to the file supplied with the hotfix and then tested.

Any required database updates are applied by running an update.sql file automatically as part of the installation process.  This file will also be placed in the <ConfigMgr Install Folder>\Logs\<KB Article ID>\ folder.

The reset of site components and running of the update.sql script can be bypassed using the switched noted below.

Other actions taken during the hotfix installation will be captured in the %temp%\MSI*.log file created during installation. Separate logging for the MSI file can be accomplished via global Windows Installer Logging policies, or directly via the command line as noted below:

msiexec.exe /I <Product.msi> /L*v <logfilename> [/Quiet] [NODBUPGRADE=1] [NOSITERESET=1] [NOADVCLIPACKAGE)=1]

Where:
/Quiet: Unattended installation mode; no UI
NODBUPGRADE=1: Will not run the update.sql script to update the database/
NOSITERESET=1: Will not perform site reset; this could result in remote site systems not updating until manually reset at a later time.
NOADVCLIPACKAGE=1: Won’t launch the wizard to automatically create a package & program to update clients.

Once a server hotfix has been deemed relevant to a given operating environment, we recommend applying the hotfix to all site servers to maintain consistency once you have completed testing and confirmed it resolved the issue.  Targeting the servers can be done via inventory based collections using file details from the KB article, or other methods as needed in your environment. 

Non-client Hotfix Installation (Pre-SP2)

Prior to the release of SP2, Configuration Manager 2007 hotfixes were built using Microsoft’s Update.exe technology instead of Windows Installer.   The primary functional difference was that if a hotfix contained a SQL script (update.sql) it would have to be run manually against the site database server.

Client Hotfix Installation

A Configuration Manager Client hotfix is comprised of a Windows Install Patch (.MSP) file which will update the necessary binaries when applied to a client.

This file is contained within the original hotfix .MSI file, which in turn must be installed on a site server.  The .MSI will move the client patch to the \<Configuration Manager Install Folder>\client\<platform>\hotfix\KBxxxxxx\ folder on the site server.

In addition it will by default launch a wizard to guide you through the creation of a package and program to distribute the patch to client machines.  This is recommended but can be skipped by using the NOADVCLIPACKAGE switch noted previously.

NOTE: If the wizard is bypassed, the following command line should be used:

msiexec.exe /p <patchname.msp> /L*v %TEMP%\<logname.log> /q REINSTALL=ALL REINSTALLMODE=mous

e.g. msiexec.exe /p sccm2007ac-sp2-kb2261172-x86.msp /L*v %TEMP%\sccm2007ac-sp2-kb2261172-x86.msp.LOG /q

Note the REINSTALL=ALL REINSTALLMODE=mous parameters are required.

When defining the remaining program properties the following parameters should also be set:

Run with Administrative rights

Run Minimized

After Running: Program Restarts Computer; this is needed to ensure that any status MIF files are collected after a restart of the client service (ccmexec.exe).  No actual restart of the computer should occur.

Note: In either case – using the wizard or manually creating the command line – any parameters previously sent to the client.msi file should be resupplied for the patch.

For example if the Fallback Status Point (FSP) and Server Locator Point (SLP) were originally supplied during client installation, the patch command line should be modified to include those.

Modifying the previous example this would be: msiexec.exe /p <patchname.msp> /L*v %TEMP%\<logname.log> /q REINSTALL=ALL REINSTALLMODE=mous FSP=SMSFP01 SMSSLP=SMSSLP01where SMSFP01 and SMSSLP01 are the names of the FSP and SLP respectively.

Do not attempt to install a patch file directly on a client.   Applying the patch file directly to a client is not supported and may prevent future hotfixes from properly installing.   It also prevents you from specifying any of the additional command line parameters required.

In addition it is not supported to apply the patch directly to the client.msi file (slipstream).  This too may cause unexpected issues on the client and prevent future servicing.

If a hotfix needs to be applied during the initial installation of the ConfigMgr client, this can be accomplished using the PATCH= installation property.  For more information refer to http://support.microsoft.com/kb/907423; while written for Systems Management Server 2003 the article also applies to ConfigMgr 2007.

Further details associated with the wizard will be noted in a text file copied to the <ConfigMgr Install Folder>\Logs\<KB Article ID>\ACReadme.txt file on the site server.

The wizard launched from the .MSI will create a package a program, but will not create a query or collection for use in distributing the hotfix.  Possibilities for creating these include querying inventory data for specific file versions, or building queries based on client component versions.  File version data is documented in the File information section of the KB article.  Client component versions can be seen via hardware inventory data or manually checking the properties in the client control panel applet.  Components may include the CcmFramework, CCMPolicyAgeny,SMSInventory or others.  Refer to the ACReadme.txt file that is bundled with client side hotfixes for a more complete list of components.

Below is an example of a query that assumes the CCM Framework component was updated to version 4.00.7487.2012 by a hotfix.  This query could then be used as the basis for a collection to target the hotfix.

select * from SMS_R_System
inner join SMS_G_System_SMS_ADVANCED_CLIENT_STATE
on SMS_G_System_SMS_ADVANCED_CLIENT_STATE.ResourceID = SMS_R_System.ResourceId
where SMS_R_System.ClientType = 1
and SMS_G_System_SMS_ADVANCED_CLIENT_STATE.Name = "CcmFramework"
and (SMS_G_System_SMS_ADVANCED_CLIENT_STATE.Version < "4.00.6487.2012"

In summary, a hotfix .MSI file should be run on the affected computer except in the case of a client.  In that scenario the .MSI file must be run on a site server, and the .MSP file then distributed to affected clients.Summary

This article will be updated with additional information as needed to reflect any version specific changes or other details related to applying Configuration Manager 2007 hotfixes.

=====

For the latest version of this article see the link below:

KB2477182 - System Center Configuration Manager 2007 Hotfix Installation Guidance

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.