Sometimes the most challenging part of the Configuration Manager 2007/SMS 2003 deployment phase can be ensuring that the client successfully reports to the site server. We occasionally see these issues here in support, typically either as cases for clients not reporting after the client installation, or maybe where it’s noticed that the client count is decreasing from the collection.

When we look at the SMS/SCCM console collection, there is an entry for the client status that indicates either Yes or No. Assuming everything is installed and configured properly, a client installed on a system should automatically report as Yes, but sometimes that does not turn out to be the case. The reason could be that the client has not yet reported to the SCCM\SMS server, or it was reporting previously but has now stopped. Managing the client in the collection is a continuous task and for a healthy environment the client should be continuously reporting to the SMS\SCCM server.

There are various reasons why a client may not be able to report to even if the SMS\SCCM agent is installed on a machine. A few of these reasons are discussed below:

The first thing to check is whether the client is on the network, and if it’s not on the network, does the system even exist?  It’s possible that represents a stale record from AD.

Systems NOT on the network:  If the system is not actually on the network, check if it is shutdown, and if so if it’s been shutdown for long time.  If yes then first restart the system and then initiate the discovery cycle from the control panel agent properties action TAB.

Stale Entries:  When you use AD discovery, the DDRs are created for the computers that reside in the AD container that we have requested to be queried by the discovery process. If that container has the stale records for the resources, then client records may be created for systems that don’t actually exist, thus they will never report.

There is a Maintenance task that will clear the inactive records but if the discovery process runs again and the AD container still has these entries then they will simply show up again.

Resolution: For the stale records you need to make sure that the AD container is cleared of these stale records and scavenging is done for the computers container in AD regularly. Once this is done you can either make use of the maintenance task or you can create a collection for the NON SMS CLIENTS and then do a delete special to the collection so that the entries will be removed permanently from the SMS\SCCM database. Then a discovery can be run which will bring back only the active systems in the collection.

Once the agent is available on the network and the client is installed, the client goes through the following actions as part of the reporting process:

1. Client location services identify the site code and the MP it is supposed to connect to.
2. The client connects to the Management Point and downloads the policies.
3. Once the policies are downloaded it sends the heartbeat record to the server.
4. Once the server receives this heartbeat record these are converted in to DDR and processed.  This will set the client flag to 1 which will make the client status display as Yes in the console.
5. On a regular basis the agent will send the heartbeat and if no heart beat or inventory shows up for a length of time then the client flag will be marked as 0 by the client flag maintenance task, setting the client status to No.

So only if this process is completed and it continues to happen will the client remain reporting to the server.  This is why I said earlier that client management is a continuous task. There can be a variety of reasons why this process might fail, and I’ve outlined a couple of them below:

The Boundaries of the Agent are not specified in the site server

If the client is not assigned in the console or the client is unable to discover the site code, make sure that the AD site or the IP subnet is added in the boundary list. The server will only allow those clients within its boundary to download the polices, so if you have not specified the boundaries the client will not be authorized and the policies will not get downloaded. For boundary issues you can use this as a reference:

http://blogs.technet.com/kevinsul_blog/archive/2006/01/25/418088.aspx.

For the case of overlapping boundaries see http://blogs.technet.com/smsandmom/archive/2007/11/30/sms-2003-finding-overlapping-boundaries.aspx

In the client if you check the location services.log  (log location: C:\Windows\System32\CCM\Logs), you can get the information of the site assigned to it as well as the MP it is reporting to. If it is not able to report properly, you need to make sure that the agent can communicate over the network to the site server successfully.

Unable to get the site code

If the client is not able to get the site code, you need to check first the boundaries as above, and also verify that the site information is published in the AD. You can check the last part of the sitecomp.log after you start the site component manager which will say that the components like the MP, SLP etc successfully published or updated. If you are unable to see that and you get access denied errors, make sure that the computer account has read\write permission to the system container in AD. Make sure the permission is flowing to the objects within and the objects below. If you are not publishing the information in AD then you need to make sure that the SLP is configured and working.

For more information you can check Post-installation phase in the link:

http://support.microsoft.com/kb/925282

The client itself is not installed in the Agent

You can take a look at this article http://support.microsoft.com/kb/925282 which will give you a detailed explanation of how you can make sure that the client is installed and reporting successfully.

There is a name resolution issue in the Client.

Make sure that the client is able to communicate to the SMS\SCCM server using the FQDN as well as the NetBIOS name. Use Nslookup or ping to check the name resolution.  If you can’t ping the server using the FQDN then you will have problems.

The client is behind a firewall

If clients are behind a firewall, it may be restricting it from contacting the SMS site server. Check if the necessary ports are opened. You can check http://support.microsoft.com/kb/826852 to understand the port requirements.

There are systems in the collection that have multiple GUIDs.

If you suspect your clients may have multiple GUIDs refer to https://technet.microsoft.com/en-us/library/cc917513.aspx for information on how to resolve the issue.

MP not working as a result of which the policies are not getting downloaded

You first need to check to see whether the MP is working.  For that you will need to check the mpcontol .log (Log location: \SMS\logs in SMS and \program files\Microsoft Configuration Manager\logs in SCCM).  If it is showing a 200 OK status code then that means the MP is working.  For information on troubleshooting the MP you can use the Troubleshooting management point issues section at http://support.microsoft.com/kb/925282 or http://technet.microsoft.com/en-us/library/bb932118.aspx.

If the MP is working fine and the client is unable to contact and download polices, you will have an error on download in the policyagent.log file on the agent (Log location: C:\Windows\System32\CCM\Logs). Before checking this though, check if the locationservices.log has the correct MP information. If it doesn’t then check the resolution mentioned in the topic under Site Code and Boundaries above. If it does have the correct MP information, make sure that the BITS service is started on the client. You can try the following URLs to verify that this is working:

/sms_mp/.sms_aut?mplist">/sms_mp/.sms_aut?mplist">/sms_mp/.sms_aut?mplist">http://<servername>/sms_mp/.sms_aut?mplist

and

/sms_mp/.sms_aut?mpcert">/sms_mp/.sms_aut?mpcert">/sms_mp/.sms_aut?mpcert">http://<servername>/sms_mp/.sms_aut?mpcert

Client is unable to download policy

You may also have issues downloading policies if the client agent has WMI corruption.  If you suspect this to be the cause of your issue, if it is a XP client then follow these steps:

1. Uninstall the SMS/SCCM client agent. Use the ccmclean /all (Available in the SMS tool kit) command for SMS and cmsetup /uninstall for SCCM.

2. Troubleshoot or rebuild WMI. For troubleshooting WMI you can reference:

• http://support.microsoft.com/kb/875605
• http://technet.microsoft.com/en-us/library/cc180763.aspx
• http://blogs.msdn.com/wmi/archive/2009/03/13/let-s-troubleshoot-wmi-part-1-remoting-and-security.aspx

3. Restart the system and install the agent.

Note: If the SMS\SCCM agent is installed on an exchange server or the DC, or any other application server, please contact Microsoft support to fix the WMI issue as rebuilding can create additional issues with other applications if not done correctly.

Server unable to process DDR

Once you find that the client is able to send the heartbeat data to the server, you next need to check on the server to see if these are getting processed successfully. Here are a few links relating to DDR processing errors:

• http://support.microsoft.com/kb/886124
• http://support.microsoft.com/kb/891584
• http://support.microsoft.com/kb/960634

Clients going to NO after it had reported

The first reason for this is that the heartbeat discovery is enabled and that the DDRs are not reaching the server.  The second is that Clear Install Flag is running. The following link will give you more information on this task:

http://technet.microsoft.com/en-us/library/bb694040.aspx

Hope that this information will be helpful - Happy troubleshooting,

Sudheesh Narayanaswamy | Support Engineer

When creating an Update List and downloading software updates for Visual Studio 2005 and 2008, some but not all of them may fail with the error "invalid certificate signature" in the confirmation page of the Software Updates Deployment Wizard. This is seen with System Center Configuration Manager 2007 and can happen for other large updates as well. The hotfix from http://support.microsoft.com/kb/938759 does not help in these cases.

Cause: This is a known issue with the Configuration Manager Console running on Operating System prior to Windows Vista, such as Windows XP and Windows Server 2003.  This is documented here:

http://technet.microsoft.com/en-us/library/bb932193.aspx under the heading "Downloading Large Software Update Files Might Fail"

Resolution: The workaround for now is to use Windows Vista, Windows Server 2008 or Windows 7 to run the Configuration Manager Console to download these larger updates.

Clifton Hughes | Senior Support Engineer

When you experience issues with your Windows Server 2008 Web Server (IIS) role, including 401, 403, or 500 errors in the IIS logs and MPControl.log, a Configuration Manager 2007 site system relying on the IIS system may also experience issues due to the various SCCM roles that rely on IIS functioning properly.

For various reasons it may ultimately be necessary to reinstall IIS in these situations, and listed below are the necessary steps that need to be taken to properly reinstall the Web Server (IIS) role on a Windows Server 2008 server that is hosting an SCCM 2007 site system.

1. Make sure that the server that IIS needs to be reinstalled on is strictly an SCCM 2007 site server and that you are not using any other applications, roles, or features that rely on IIS other than SCCM 2007 and any dependent applications or roles (such as WSUS or SQL Reporting Services). If the server is not strictly an SCCM 2007 site server, make sure that you will be able to reinstall those applications, roles, or features without losing settings, data, or functionality once IIS has been reinstalled. If you cannot do this or are unsure, do not proceed.

Please also note that while IIS is being reinstalled, the site server will be effectively down since no clients will be able to report up or retrieve policies. Any of the below roles that rely on IIS will also be down and not available, so ensure that the reinstall is done at a time when you can afford to have the server be down. This is usually not an issue though because usually when IIS needs to be reinstalled, it is not working properly and the server is effectively down anyways.

2. In the SCCM 2007 console under Site Settings - - > Site Systems, on the site server where IIS needs to be reinstalled, examine to see if any of the following roles that rely on IIS are installed:

• ConfigMgr distribution point
• ConfigMgr management point (MPSetup.log)
• ConfigMgr reporting point (rsetup.log & SMSReportingInstall.log)
• ConfigMgr software update point (SUPSetup.log)
• ConfigMgr server locator point (SMSSLPSetup.log)
• ConfigMgr fallback status point (SMSFSPSetup.log)
• ConfigMgr Reporting Services Point (SRSRPSetup.log)
• ConfigMgr state migration point (SMSSMPSetup.log)

If any of the above roles are installed, go into the properties of the role and make a note of the settings for the role.

For the ConfigMgr state migration point, make sure when noting the settings for the role to include where client state migration data is being backed up to before removing the role. As safety precaution, make sure to also note any encryption keys for any data that is currently on the state migration point. These keys can be obtained by going into the SCCM 2007 console and expanding the "Operating System Deployment" node, clicking on "Computer Association", right clicking on the associations, and selecting "View Recovery Information". Copy the name of the PC that the data is associated with, the user state store location, and the key.

Once you have noted the settings, uninstall any of the above roles EXCEPT for the ConfigMgr distribution point. DO NOT uninstall the ConfigMgr distribution point!

3.  Monitor the setup logs referenced in Step 2 and verify that all roles have been uninstalled successfully. The logs are normally found under C:\Program Files\Microsoft Configuration Manager\Logs, but can vary depending on your particular installation and environment.

4. If the server is also a ConfigMgr distribution point that uses BITS, in the properties of the ConfigMgr distribution point role, under the "General" tab, uncheck the option "Allow clients to transfer content from this distribution point using BITS, HTTP, and HTTPS (required for device clients and Internet-based clients)" to disable BITS and then click "Apply".

5.  If the server is also a ConfigMgr distribution point that is a multicast distribution point, in the properties of the ConfigMgr distribution point role, under the "Multicast" tab, uncheck the option "Enable multicast" and then click "Apply". Monitor the MCSetup.log to ensure that multicast is uninstalled successfully.

6.  If the server is also a ConfigMgr software update point and WSUS was installed on the server, uninstall WSUS either through the "Program and Features" Control Panel by selecting to uninstall "Microsoft Windows Server Update Services 3.0 SP1" or through Server Manager by removing the "Windows Server Update Services" role under the "Roles" node. Before uninstalling WSUS, make sure you have notate where the WSUS database is located. When uninstalling WSUS, make sure to specify NOT to remove the WSUS database.

7. If the server is also the SQL server for SCCM 2007, a ConfigMgr Reporting Services Point, and SQL Reporting Services Point was installed on the server, back up any custom reports and then uninstall SQL Reporting Services from the server via the SQL setup program.

8. In the "Programs and Features" Control Panel, uninstall "WebDAV 7.5 for IIS 7.0".

9. In Server Manager, under the "Features" node, remove the "Windows Process Activation Service" feature. Removing this feature will remove several roles and features that are dependent on this feature, including the "Web Server (IIS)" role and "BITS Server Extensions".

10. When prompted, restart the server.

11. When the server restarts and comes back up, log back in and rename the “inetpub” folder, usually found at the root level of the C: drive.

12. Follow the TechNet article on installing IIS in Windows Server 2008 to support an SCCM 2007 site system:

How to Configure Windows Server 2008 for Site Systems

13. If the server is also a ConfigMgr distribution point that uses BITS, in the properties of the ConfigMgr distribution point role, under the "General" tab, check the option "Allow clients to transfer content from this distribution point using BITS, HTTP, and HTTPS (required for device clients and Internet-based clients)." to enable BITS and then click "Apply".

14. If the server is also a ConfigMgr distribution point that is a multicast distribution point, in the properties of the ConfigMgr distribution point role, under the "Multicast" tab, check the option "Enable multicast" and then click "Apply". Monitor the MCSetup.log to ensure that multicast is reinstalled successfully.

15. If the server is also a ConfigMgr software update point and WSUS was installed on the server, reinstall Microsoft Windows Server Update Services 3.0 SP1 either through the standalone install executable found at:

Windows Server Update Services 3.0 SP1

or through Server Manager by adding the "Windows Server Update Services" role under the "Roles" node. Make sure to reattach to the existing WSUS database as notated in Step 6.
Also make sure to properly choose between the Default Web Site or the Custom Web Site. This can be determined by looking at the properties of the "Software Update Component" in the ConfigMgr 2007 console under Site Settings - - > Component Configuration. Under the "General" tab, if the Ports being used are 80/443, then chose the Default Web Site. If the ports being used are 8530/8531, then choose the Custom Web Site.

16. If the server is also the SQL server for SCCM 2007, a ConfigMgr Reporting Services Point, and SQL Reporting Services Point was installed on the server, reinstall SQL Reporting Services from the server via the SQL setup program. If needed, the below guides will walk you through setting up Reporting Services in R2:

Configuring SQL Reporting Services

Below is the link for the full documentation for SQL Reporting Services in Configuration Manager 2007 R2:

SQL Reporting Services in Configuration Manager 2007 R2

Once reinstallation is complete, restore any custom reports that were backed up in Step 7.

17. In the SCCM 2007 console under Site Settings - - > Site Systems, on the SCCM 2007 site server where IIS was reinstalled, reinstall the site roles that were uninstalled in Step 2. For the ConfigMgr state migration point, make sure to restore the settings that were captured in Step 2.

18. Monitor the setup logs as referenced in Step 2 and verify that all roles reinstall successfully.

19. If the server is a ConfigMgr software update point, run a full synchronization by going under the "Software Updates" node, right clicking on "Update Repository", and choosing "Run Synchronization".

NOTES:

1. Removing the ConfigMgr reporting point role should not delete or affect any custom reports. The reports should still exist when the role is reinstalled.

2. Removing the ConfigMgr software update point role should not delete or affect any settings under Component Configuration - - > Software Update Point Component. It should also not affect any updates, packages, lists, or templates that have already been set up under the "Software Updates" node.. The settings, packages, lists, and templates should all still exist when the role is reinstalled.

3. Removing the ConfigMgr state migration point role should not delete or affect any data that has been saved to the state migration point. All backed up data should still exist when the role is reinstalled. However, settings are not restored to their original values so make sure to capture the settings before removing the role as described in Step 2. Additionally, as a safety precaution, make sure to back up any encryption keys and paths as described in the notes of Step 2.

4. Packages on Distribution Points should not be affected and you should not need to repush packages to the Distribution Points after reinstalling IIS as long as the ConfigMgr distribution point role is NOT removed, so please make sure that the role is NOT removed or uninstalled. Simply disabling and then later enabling BITS and multicast will rebuild the necessary virtual directories in IIS that the Distribution Point relies on.

Frank Rojas | Senior Support Engineer

Carol’s last update of the day (so far) is about how they updated the Configuration Manager Documentation Library for out of band management for SP2, including revisions to troubleshooting issues. According to Carol:

Some of these revisions are also applicable to Configuration Manager 2007 SP1, but we can't publish them with our monthly updates because of the new SP2 content.  Rather than waiting until SP2 is released, I'm including the revisions here that affect existing customers using out of band management in Configuration Manager 2007 SP1.

For all the details see http://blogs.technet.com/configmgrteam/archive/2009/08/13/updated-troubleshooting-information-for-out-of-band-management-sp1.aspx

J.C. Hornbeck | Manageability Knowledge Engineer

I thought of blogging this information as it took a little bit of time to identify the root cause of the issue and I didn’t see it documented publicly anywhere.  Hopefully if you run into the same issue this will help you find a quick solution.

Symptom: Patch installation fails with the following error:

ERROR: UpdateSearcher::Search() failed. 0x80248014 is the hresult value for the operation. Returning 32788 as the exit code SmsWusHandler

Cause: An invalid ScanPackageServiceID package in the registry was the culprit in this case.

Logs for reference which will help you easily identify the issue

Pathinstall.log
============
INSTALL FAILED: UpdateID = bfc87e4e-02a3-4739-8019-27eeef986f59, QNumber = 969682, Title = Security Update for Microsoft Office Excel 2007 (KB969682), ExitCode = 32788, Executable = C:\SYSROOT\system32\VPCache\CES00072\SmsWusHandler.exe /InstallFile:"C:\SYSROOT\system32\CCM\Cache\CES002BD.1.System\bfc87e4e-02a3-4739-8019-27eeef986f59\excel_b6c38982517a95896abd60b635495b2f3c732ecf.cab" /UpdateID:bfc87e4e-02a3-4739-8019-27eeef986f59  UpdatesInstallMgr        30-06-2009 09:29:44  3428 (0x0D64)

SMSWSUShandler.log
=================
WUS client version detected on the machine = 7.2.6001.788.           SmsWusHandler         
Searching for software updates now.   SmsWusHandler         
Search filter - Type='Software' SmsWusHandler         
Using the existing scan package service {ServiceID = 6f102c69-effc-4e17-b505-830a9e6b6b1e}    SmsWusHandler           
Scan Package serviceID being used for this search is {6f102c69-effc-4e17-b505-830a9e6b6b1e}   SmsWusHandler           
ERROR: UpdateSearcher::Search() failed.        SmsWusHandler
0x80248014 is the hresult value for the operation. Returning 32788 as the exit code.          SmsWusHandler           
~ ======= SmsWusHandler Terminating =======          SmsWusHandler         

This is how the registry looks like on the client machine:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\VPCache]
"ScanPackageServiceID"="5fb74640-bf1e-408d-97d0-cda888ed4cec"
“~AS_ScanPackageServiceID"="6f102c69-effc-4e17-b505-830a9e6b6b1e"

Resolution: You can fix the issue by following these steps:

1. Make a backup of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\VPCache.  This way you can always restore any changes you make.

2. Delete the registry key "~AS_ScanPackageServiceID" from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\VPCache

3. Restart the SMS Agent Host Service on the client machine, then rerun the advertisement on the client machine.

Once this is complete the install should complete successfully.

Balasubramanian Delli | Configuration Manager Technical Lead

We’ve seen this issue come up a couple times so I wanted to give it a mention here just in case you run into it.  The problem is that you may notice Software Deployments are not working for a small percentage of your Configuration Manager clients and you may notice that the status of the problem clients is Waiting on content. You may also notice that the affected clients are unable to automatically re-discover their site code in the control panel applet.

Troubleshooting:

The last time I saw this, we checked the properties of the affected client's resource in the Configuration Manager 2007 Console and it showed multiple subnets for these clients (e.g. 9.9.0.0 and 9.9.9.0).

The site boundary for these clients was entered as simply 9.9.0.0 on the Site server and these boundaries did not overlap with any other site.

We then found the following error in the CAS.log which seem to point to a boundaries issue:

ctm job suspended

We enabled verbose and debug logging in the registry on one of the affected clients and then created a new advertisement and a test collection to send it to.  When we did this we found the following in the LocationServices.log:

Discarding DP with SiteLocality 'FALLBACK'. Accepting only 'LOCAL' DPs. 10/30/2009 1:37:24 PM 164 (0x00A4)

The number of discovered DPs(including Branch DP and Multicast) is 0 10/30/2009 1:37:24 PM 164 (0x00A4)

When we tried to perform automatic site discovery on the client that was failing we saw this”

"LSGetAssignedSiteFromSLP : No site code returned from SLP"

"The number of discovered DPs (including Branch DP and Multicast) is 0"

Everything seemed to point to a Protected Distribution Point but there were none in this case.  It also seemed like it could be a boundary issue which was not obvious on the surface since the 9.9.0.0 boundary included all of the affected clients. Also this problem did not affect all clients in these subnets, only some.

Cause:

It turns out that this issue was nonspecific Site Boundaries in the site. 9.9.0.0 is not specific enough to allow the clients to find the site and/or find its Distribution Point servers. This is referred to as super netting, and this will not yield consistent results for your Configuration Manager clients.

Solution:

Once you add a specific 9.9.9.0 subnet and/or the 9.9.8.0 subnet (whichever applies), the clients in these subnets will be able to find their Site ID and Distribution Points without error, so the solution is to add the specific individual subnets to the Site Boundaries.

More Information:

This problem can also manifest itself in other ways such as when an AD Subnet is specified as 9.9.0.0 and the AD site is added as a boundary in SMS or Configuration Manager, then you also add some specific subnets as boundaries like 9.9.1.0 and 9.9.2.0.  This can also cause the same symptoms documented above.

The TechNet article below articulates the IP Subnet configuration recommendations of entering each IP subnet individually, however it does not indicate that super netting is not supported so I created this document to help shed more light on this issue since we have seen several cases with this issue.

http://technet.microsoft.com/en-us/library/bb633084.aspx

Hope this helps,

Clifton Hughes | Senior Support Engineer

Consider the following scenario:

• The management point role is installed on a site server that is running Microsoft System Center Configuration Manager 2007 Service Pack 1 (SP1).
• Many content location requests are sent to the management point when the requests contain multiple locations.

In this scenario, the memory usage of the Microsoft Systems Management Server (SMS) Agent Host service (Ccmexec.exe) keeps increasing.

There's a hotfix for this issue and you can read all the details and download it here:

KB973499 - A memory leak occurs when many content location requests are received by a site server that is running System Center Configuration Manager 2007 SP1

J.C. Hornbeck | Manageability Knowledge Engineer

I recently came across this issue and thought it might be worth a mention here.  If you have some really big packages and don't see any of your changes reflected on the Child Sites then this may be your issue.

Symptoms

Changes made to an SMS 2003 package/program properties for a large package (such as Office 2007) are not reflected on the Child Site.

The Distmgr.log on the Child Site server may show that Package XXX000xx is currently being processed, and it may stay in this state for days, and/or it does not update on the Child Primary Site's view of the package for several days.

It seems any change that is made to this packages properties is not getting updated although other packages and Site settings are getting replicated down to the Child Primary Site properly.  When looking at the distmgr logs on the child site you may see the same files trying to be processed for this problem package and not getting processed for some time, even days depending on the size of the problem package.

Cause

This can occur if the package that is being updated is being processed on the Child Primary Site to a remote Distribution Point (DP) share over a slow link, and this package is several GB in size.  The large size combined with the slow link  merely means that this processing will take a very, very long time.  This is why we were seeing the message “Package ID XXX0000XX is currently being processed.”  This indicates that the server is processing this package (not the pkg file that is currently in queue) and as a result is busy and not able to process the incoming change right now.

Resolution

Once you're in this situation the best resolution is patience.  Once the package processing from the Child Primary to the remote DP finishes, the package changes will be processed normally as expected.

More Information

If you can create a Secondary Site then this process would use a compressed file instead of raw copy to a DP at the remote location. You also have the option to use the Courier Sender method of updating the DP rather than doing this over the wire. Courier Sender allows software to be sent between SMS sites by CD or other media, rather than across the network. This is particularly useful in situations where the available network bandwidth is low or too expensive to use for the delivery of large packages.

For more information regarding methods of Software Distribution, see Chapter 5, "Distributing Software," in the Microsoft Systems Management Server 2003 Operations Guide:

http://www.microsoft.com/downloads/details.aspx?familyid=BD2B3619-4704-4C19-A00B-628E65F6F826&displaylang=en

Hope this helps,

Clifton Hughes | Senior Support Engineer

In your System Center Configuration Manager 2007 environment, you may find that a distribution point is not updating and a pck file may appear to be "stuck" or "locked" in the X:\Program Files\Microsoft Configuration Manager\inboxes\despoolr.box\received folder (where X: is the drive where ConfigMgr 2007 is installed) and the file is not able to be renamed or deleted even with the following services stopped:

• WMI
• SMSExecutive
• Component Manager
• BITS
• Antivirus

Cause

The file was locked by a service called dsmcsvc.exe which was from IBM Tivoli backup software (it was named TSM Scheduler in Services). It is possible other software could have a lock on the file as well, this is just one example.

Resolution

Using Process Explorer turn on the handles view (View menu, Lower Pane view, Handles) then from the Find menu, (Find Handles or DLL...) type in the file name that is locked (e.g. X:\Program Files\Microsoft Configuration Manager\inboxes\despoolr.box\received\filename.pck) and it should show you the service that has locked this file.  In this case we found it was locked by dsmcsvc.exe (IBM Tivoli backup software).  Stopping the TSM Scheduler service (dsmcsvc.exe) caused the packages to start processing again in the despoolr.log.

More Information

This problem could occur with other software locking a file and preventing a package from being updated.  Using Process Explorer is a useful way to determine what service has a lock on a file.

Hope this helps,

Clifton Hughes | Senior Support Engineer

You may want to use status MIF files for extended or custom reporting of the advertisement status by configuring the reporting properties of a mandatory advertisement to "Use these fields for status MIF matching", but if the resulting MIF file is generated by Windows Installer (using Windows Installer command line parameter "/M", for example "/M MIF" in the packages command line), the client might set the execution status to FailureNonRetry even if the exit code is within the list of Failure Retry Error Codes.

The list of Failure Retry Error Codes causing the Configuration Manager Client to retry the installation as well as the according client policies can be found:

1. In the Site Control File:

PROPERTY <Execution Failure Retry Count><REG_DWORD><><1008>

PROPERTY <Execution Failure Retry Interval><REG_DWORD><><600>

PROPERTY <Execution Failure Retry Error Codes><REG_SZ><{4,5,8,13,14,39,51,53,54,55,59,64,65,67,70,71,85,86,87,112,128,170,267,999,1003,1203,1219,1220,1222,1231,1232,1238,1265,1311,1323,1326,1330,1618,1622,2250}><0>

or

2. In Configuration Manager 2007 Clients in WMI Namespace "root\ccm\policy\machine\actualconfig", instance of class "CCM_SoftwareDistributionClientConfig".

In the following example, the client never re-tries to install the program even if the Windows Installer return code is in this list:

1. You configure the Schedule in Advertisement to "Rerun if failed previous attempt" (see TechNet (Configuration Manager): Advertisement Name Properties: Schedule Tab).

2. The Reporting properties of the package are configured to use a "MIF file name:" of MIF.mif.

3. The command line in package's program is something like "msiexec.exe /I "msipackage.msi" /QN /M MIF /L*v.

On a client, Windows Installer exits with return code 1618 which means "Another installation is already in progress. Complete that installation before proceeding with this install".  The return code 1618 is in the list of Failure Retry Error Codes but the client never re-tries to install the program.

In execmgr.log you will find:

"Execution is complete for program Install-Basic-with-MIF. The exit code is 1618, the execution status is FailureNonRetry"

The behavior is based on current design of SMS 2003 and Configuration Manager 2007.  In the case where a MIF file is used for status reporting, only the value of attribute "Status" within the MIF file is considered to determine the installation result.  In case that the value of attribute "Status" is "Failed", CCMEXEC sets the final execution status to "EXECUTION_FAILURE_NORETRY" (i.e. "FailureNonRetry").

In the example above, the MIF file created by Windows Installer does not contain the return code but the status is defined as "Failed".

Excerpt of the MIF file:

START COMPONENT
NAME = "WORKSTATION"
… … …
START GROUP
NAME = "InstallStatus"
ID = 2
CLASS = "MICROSOFT|JOBSTATUS|1.0"
START ATTRIBUTE
NAME = "Status"
ID = 1
ACCESS = READ-ONLY
STORAGE = SPECIFIC
TYPE = STRING(32)
VALUE = "Failed"
END ATTRIBUTE
START ATTRIBUTE
NAME = "Description"
ID = 2
ACCESS = READ-ONLY
STORAGE = SPECIFIC
TYPE = STRING(128)
VALUE = "Another installation is already in progress. Complete that installation before proceeding with this install."
END ATTRIBUTE
END GROUP
END COMPONENT

Comparison of the results of status message query "All Status Messages for a Specific Advertisement …" for identical MSI advertisements with/without a status MIF file shows that there is no additional information (beside the description of the return code) when using a MIF created by Windows Installer.

There are two configuration options to solve this issue:

1) Add a "Recurrence Pattern" to the Mandatory Assignment.

- This causes package/advertisement to re-run only on clients where it previously failed.

- On clients where a previous installation succeeded, installation will not be re-run and you will find the following in execmgr.log:

"CreateMandatoryRequestRecursively policy Install basic-msi no need to re-run"

2) For Windows Installer based installations, do not use MIF reporting.

- Change advertisement properties to "Use package properties for status MIF matching" (instead of "Use these fields for status MIF matching")

As the 1^st option causes an unnecessary increase of incoming client status messages (each client regularly checks the recurring advertisement and sends a status message) and as there is no gain of additional information when using status MIF reporting in conjunction with Windows Installer based installations, the 2^nd option is typically more feasible.

Armin Denzler | Senior Support Escalation Engineer

Here's a unique issue I came across the other day that I thought you might like hearing about.  In this case, we were unable to connect to a ConfigMgr 2007 Secondary Site server from Tools => Service Manager unless we were using a domain admin account.

When attempting to connect to the Secondary Site server in Service Manager we received the following error message:

ConfigMgr Service Manager

Error communicating with the specified ConfigMgr Site Server

This error can occur if the SMS Groups do not contain the proper Site Server computer accounts. 

You may also receive the following error when attempting to connect to the Secondary Site server in Service Manager if the logged on account is not a member of the Secondary Site Server's Local Administrators group:

ConfigMgr Service Manager

Access to the specified server has been denied. You might not have enough security rights to complete this operation

Cause

SMS Group membership and/or Local Administrator group membership configuration is not configured correctly.

Resolution

We found that the ConfigMgr Site Server Computer accounts were not added to the SMS_ groups correctly on the primary site server local groups.  To resolve this we did the following:

1. We added the Secondary Site Server Computer accounts to the Primary Site servers SMS_SiteSystemToSiteServerConnection_ABC and SMS_SiteToSiteConnection_ABC groups (where ABC is the ConfigMgr Primary Site code).
2. We added the Primary Site Server Computer accounts to the Secondary Site servers SMS_SiteSystemToSiteServerConnection_ABC and SMS_SiteToSiteConnection_ABC groups (where ABC is the ConfigMgr Secondary Site code).
3. The account that was being used to logon to the server was added to the Secondary Site servers Local Administrators group

Once we completed these three things the connection from the ConfigMgr Service Manager tool was successful.

In some cases you may want to see if it is possible to get this to work without the account being a local admin on the Secondary Site server, however, this does not work in all cases and the TechNet article below outlines this:

http://technet.microsoft.com/en-us/library/bb632332.aspx

Service Manager
In Configuration Manager 2007 Service Manager, you must have the Administer right on the primary site object to perform the following tasks:

• Query a service
• Stop a service
• Start a service
• Configure service logging

On a secondary site, you must be a member of the local Administrators group to perform these tasks.

Clifton Hughes | Senior Support Engineer

I've been out for a while due to the winter break so I'm still trying to get caught up on all the things I've missed, and part of that includes all the new Knowledge Base articles we published over the last few weeks.  There are far too many to discuss each one individually but I've got the list below if you want to peruse it real quick.  At least that way if you run into a similar issue maybe you'll remember you saw something about it here.

=====

KB976073 - The Windows Deployment Service stops responding when you use a PXE service point on a computer that is running a System Center Configuration Managr 2007 SP1 site server

KB978021 - The Distribution Manager that is in System Center Configuration Manager 2007 SP2 does not honor the "Number of retries" and "Delay before retrying (minutes)" retry settings

KB977176 - A "Run Command Line" task of a task sequence object in System Center Configuration Manager 2007 SP1 does not work on a 64-bit client

KB978022 - Memory leak in System Center Configuration Manager 2007 SP2 if the distribution point role is enabled

=====

J.C. Hornbeck | System Center Knowledge Engineer

Looks like our very own Bhaskar Krishnan has written a great post on troubleshooting some of the frequently encountered issues relating to client content download problems in System Center Configuration Manager 2007.  It outlines the scenario, then takes you through how to track the various processes involved from when the client downloads policy to when the client installs the software, such as:

• Tracking the Advertisement on the Client
• Tracking the Content Location Request on the Client
• Tracking the Content Location Response on the Management Point
• Identifying the Client Boundary and How this Affects Content Location and Download
• Tracking the Content Download
• Troubleshooting BITS

If you haven't had a chance to read through this yet then you'll definitely want to put it on your to-do list:

http://blogs.technet.com/configmgrteam/archive/2010/01/14/troubleshooting-client-content-download-in-configuration-manager-2007.aspx

J.C. Hornbeck | System Center Knowledge Engineer

Purpose:

This post is intended to explain how client approval works when a Mixed Mode Configuration Manager 2007 site is configured to automatically approve clients in trusted domains and to offer insight into how to troubleshoot scenarios where this is not working as expected.  The configuration is shown below:

The short version:

1. The new client performs a CCM_POST to CCM_System_WindowsAuth on the MP.
2. The MP responds with a 401 as the request is anonymous and contains no security data.
3. The client requests a Kerberos ticket for http://MP_FQDN from Active Directory (e.g. http://SCCMMP.Contoso.com).
4. On obtaining the Kerberos ticket, the client performs another CCM_POST including the security data.
5. If the MP accepts the ticket then the client is authenticated and is considered to be trusted.
6. Whether the client is trusted or not, the MP executes the spUpdateClientRegistration stored procedure to update the database. If the client has authenticated properly, both the @ApprovalMethod and @IsIntegratedAuth parameters will be set to 1. If not, they are both set to 0.
   

Technical details:

The following is from data obtained in my lab during a successful test where a client in a child domain (Child.A2003.VM.local) was automatically approved by the MP in Child’s parent domain (A2003.VM.local). Relevant details:

• Client is WK02-020-51W.Child.A2003.VM.local with IP address 192.168.20.102
• The DC for the Child domain is DC03-020-52S with IP address 192.168.20.10
• The MP is SMS4-120-52S.A2003.VM.local with IP address 192.168.120.20
• The DC for the A2003 domain is DC02-110-61E with IP address 192.168.110.10

The IIS log shows:

2009-05-20 19:35:11 W3SVC1 192.168.120.20 CCM_POST /ccm_system_windowsauth/request - 80 - 192.168.20.102 ccmhttp 401 2 2148074254
2009-05-20 19:35:13 W3SVC1 192.168.120.20 CCM_POST /ccm_system_windowsauth/request - 80 CHILD\WK02-020-51W$ 192.168.20.102 ccmhttp 200 0 0

Code 2148074254 or 0x8009030E means SEC_E_NO_CREDENTIALS

MP_RegistrationManager.log shows:

MP Reg: DDR file written to E:\SMS\inboxes\auth\ddm.box\regreq\A8Z82CVO.RDR

Network Monitor shows:

Client issues the CCM_POST with no security information, starting in frame 4:

The MP responds with the HTTP 401 in frame 10:

The client requests a Kerberos ticket for the HTTP SPN of the MP from the Child domain DC in frame 13:

The Child DC refers the client to the A2003 domain DC in frame 14:

The client then makes the same Kerberos request to the A2003 DC in frame 15:

The A2003 DC responds with a Kerberos ticket in frame 16:

The client reissues the CCM_POST, with security information, in frame 17:

The MP responds with an HTTP 200 in frame 25:

SQL Profiler shows the MP executing spUpdateClientRegistration with values of 1 (True) for the relevant parameters so the client is set to Approved in the database (with parameters inlaid):

exec spUpdateClientRegistration (@SiteCode) "2P4", (@SMSID) "GUID:EEAF9390-94EB-43AE-A0DE-F374E3E7E03B", (@CSMSID) NULL, (@Identity) NULL, (@DeviceID) NULL, (@Certificate) 0x308201E03082014DA0030201020210C25D7C383E3CB6AE466BE10C22ACF3AE300906052B0E03021D05003025311530130603550403130C574B30322D3032302D353157310C300A06035504031303534D533020170D3039303531393139333434375A180F32313039303432363139333434375A3025311530130603550403130C574B30322D3032302D353157310C300A06035504031303534D5330819F300D06092A864886F70D010101050003818D0030818902818100BAEB59B8B0ECB451AB82FECF42791740BB3704BD00705126D3DA0FB7618B53955CFF142534B09ACDB97B6B8E42D10663453EA6C35A0BC30A3A83F3381B507A4D051C884E9789DC827223C1C92D0C4712458DAF96A8F15CABE2AB14ED9755A89034657CCB96A7086DFB92E928C35626F08F6A3FA451206850CEC0FC8EC671E09F0203010001A317301530130603551D25040C300A06082B06010401823765300906052B0E03021D050003818100A7A603A7E7AFB19E7518F62F5D4153FA3926AA8348D9EFCB9EC4C03AB991202CB2496B48489C6E6AB48E673ECA6DBED3A4EC7FBE1D3BB70682338FC5E4A86BCEBC4702EDBB41F060AD54117707AFCD0A2FC8AF17DF9E71F1206FBCE9295237322029956D2AA652B41F1258D617BBC4D07410F01CC40042D33BA97511F2B2DDCA, (@Thumbprint) 0xE824658E489FDBB6481ED7788E74877FB9DBCF0B, (@EncKey) 0x308201E13082014EA00302010202106866F6C06283B38644D10B448CFAE966300906052B0E03021D05003025311530130603550403130C574B30322D3032302D353157310C300A06035504031303534D533020170D3039303531393139333434385A180F32313039303432363139333434385A3025311530130603550403130C574B30322D3032302D353157310C300A06035504031303534D5330819F300D06092A864886F70D010101050003818D0030818902818100BC71E0923FBF50300A40C479CBCE5F49D20597C00873C5F6ED16538A41FF5FA54B402905DB424D95B1D67FFFD6245204E4B5FD6A751087BAFD6846FA1272E6F0405EEB647020BB8DFD2E78516C263ECE8831E17CD230C5637AA83AE222B900530977A57F390AD6542C344AB6DD6F8D7ED8CAED76A3F700ED0250ED64481C9D550203010001A318301630140603551D25040D300B06092B0601040182376502300906052B0E03021D0500038181008D63DEC508A14404372B3BEE2AD35D8B44C7C6E2AA8B81A9FA8280D416FFAB67DDDA1F37B981523DA6EEBF66CDE9F7C501412D1438E0FC490C022BC4CA854EFAA975D49182A3300C76577B4BE15B5FCB0014C36E0C418EE98F13AF6264E69C0DCFFFADD1D0800400A15630FA6C023B989D341F33E197885001601CFFC015AA0B,(@EncThumbprint) 0x6B186E7BC2B86B059FAE5E431C6C6CE40A943F3C,(@KeyType) 1, (@PublicKey) 0x06020000002400005253413100040000010001009FE071C68EFCC0CE50682051A43F6A8FF02656C328E992FB6D08A796CB7C653490A85597ED14ABE2AB5CF1A896AF8D4512470C2DC9C1237282DC89974E881C054D7A501B38F3833A0AC30B5AC3A63E456306D1428E6B7BB9CD9AB0342514FF5C95538B61B70FDAD326517000BD0437BB40177942CFFE82AB51B4ECB0B859EBBA, (@ValidFrom) "2009-05-19 19:34:47.000", (@ValidTo) "2109-04-26 19:34:47.000", (@AgentType) 0, (@SMBIOSID) NULL , (@MACAddress) NULL , (@HardwareID1) "2:D4D8AD1963DA464FC3EE60E5212310036AB9EDEC", (@ISVProxyID) NULL , (@AlwaysInternet) 0, (@InternetEnabled) 0, (@Force) 0, (@ApprovalMethod) 1, (@ResolutionMethod) 0, (@IsIntegratedAuth) 1, (@Version) "4.00.6221.1000", (@NetbiosName) "WK02-020-51W", (@FQDName) "WK02-020-51W.Child.A2003.VM.local", (@ManualConflictResolution) 0

Troubleshooting:

Standard troubleshooting of these issues should include:

1. Checking the duplicate GUID report to see if the problem client’s GUID is present. If so, run CCMDelCert on the problem client to force a new GUID to be generated and see if that resolves the issue.
2. If duplicate GUIDs do not apply then step through the following:
   1. Delete the problem client from the central site console and let the delete cascade to child sites, as appropriate.
   2. Set the SMS Agent Host service to manual on the client and reboot it.
   3. Start a network capture on the client (NetCap, NetMon 3.x, Ethereal, etc).
   4. Set the SMS Agent Host service back to Automatic and start it.
   5. Initiate a Discovery Data Collection Cycle via the Control Panel applet.
   6. If the client is re-inserted into the database as not approved then collect the network capture (and all relevant IP details) with the IIS log and MP_RegistrationManager.log from the MP to which the client reports directly for review.
3. If the network capture shows the client does get a Kerberos ticket then the IIS log should contain a Win32 error code indicating why the MP rejected it.
4. If the client does not get a ticket then the response from the DC in the capture should detail why. Kerberos logging on the client, per KB262177, may add some useful information to the System Log in Event Viewer as well. Since Directory Services supports Kerberos, they may be engaged for assistance in determining why no ticket was acquired.

Note: The MP_RegistrationManager.log does not contain much detail by default. Enabling Verbose and Debug CCM logging will add some extra entries which may be helpful.

Known reasons why this will fail:

Duplicate GUIDs:  Duplicate GUIDs can cause a myriad of client data integrity problems including client approval issues. If only a subset of the clients are impacted by the client approval failure then duplicate GUIDs should be investigated.

The HTTP SPN is registered under a user account:  Normally, there is no HTTP SPN for a server so the HOST SPN, which should always be on the computer object, is used in obtaining the Kerberos ticket. If web based services, such as SQL Reporting Services, are running under user context on the MP, and the HTTP SPN is linked to that user account, the Kerberos ticket obtained by the client will be for the same user. When presented to the MP, which runs as Local Service (System), it is rejected because it is linked to the wrong user.

The solution for this is to delete the HTTP SPN from the user object, move the web service running as the user to a different web site using a different port and create a new HTTP SPN to refer to the new port. For example, for a new web site using TCP port 81, the new HTTP SPN, created under the user object in AD, would be similar to:

HTTP://SCCMMP.Contoso.com:81

Reference http://msdn.microsoft.com/en-us/library/aa480609.aspx which states:

SPNs are only created for the HOST service and all built-in services use the HOST SPN. However, this implementation is transparent because built-in names act as an alias to the HOST service unless they have been specifically mapped to a Windows account.

And also:

When you use Windows Integrated Security, both Internet Explorer and IIS use the HTTP SPN to request service tickets and to process a request. As a result, when you use a domain user account in IIS 6.0 as the process identity, you must map the host-based HTTP SPN to the domain account that is used by the service.

Client and MP in different domains only share an external trust:

As is noted above, Kerberos is required for the client to authenticate to the MP. While Kerberos *may* work across an external domain trust, it is not supported. It is only supported across a forest trust between two Windows Server 2003 mode (or higher) forests.

Reference http://technet.microsoft.com/en-us/library/cc773178(WS.10).aspx which states:

When two Windows Server 2003 forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests.

Anything else that causes Kerberos to fail:

Kerberos can fail for many reasons including time skews in the environment; DNS name resolution failures, etc. Generally, network capture data will show why it is failing though Kerberos logging per KB262177 can also be helpful.

More Information:

General information on Client Approval can be found at http://technet.microsoft.com/en-us/library/bb694193.aspx.

Keith Thornley | Senior Support Escalation Engineer

I recently ran into this issue a couple days ago and didn't see a whole lot documented on it so I thought I would do a quick write up here.  If you're trying to upgrade some of your site servers to SP2 and run into an issue, this should get you going again pretty easily.

Note: This article describes making changes to the primary site database.  Before making changes in SQL Management Studio to the database, make sure to create a backup of your ConfigMgr 2007 Primary Site/Database. The process in this post has not been officially tested and is posted as is with no guarantee. This solution did work for me and it should also work for you, just make sure to back up your Primary site/database to be safe.

Issue

ConfigMgr2007 SP2 Setup on some Secondary sites failed due to insufficient disk space. Once we freed up enough disk space, we needed to get setup for SP2 restarted, preferably without having to copy the source files to the Secondary Site server and manually upgrading.  Since the setup failed to even start due to disk space issues on the Secondary Site server, it got stuck in an Upgrade status and did not resume setup automatically even after freeing up the disk space on the server.

Resolution

We found that manually copying the ConfigMgr SP2 source files to the server and running setup worked to get the Secondary Site upgraded, but if there are a lot of servers with the issue this can become quite time consuming.  Since we did not want to have to perform this manual process on each server where disk space was already an issue, we devised the following solution:

Using SQL Management Studio at the ConfigMgr 2007 Primary Site database, we opened the dbo.Sites table and modified the Secondary Sites Status column from 5 to 1.

The Sites table in the Primary Site database will have entries for each site including the Secondary sites.  In the database there is a Status column where the current status will be defined as 1, 2, 3, 4, or 5 :

• SITE_STATUS_ACTIVE 1 Site is active & normal
• SITE_STATUS_PENDING 2 Being installed
• SITE_STATUS_FAILED 3 Failed install
• SITE_STATUS_DELETED 4 Delete has been initiated
• SITE_STATUS_UPGRADE 5 Upgrade in progress

Based on the above information, we changed the status back to 1 for the sites that failed , and then started another upgrade from the ConfigMgr 2007 Admin Console.  This allowed us to re-trigger the SP2 upgrade without having to copy the files locally to each server and running setup manually.

Clifton Hughes | Senior System Center Support Engineer

When running a SCCM 2007 SP2 Task Sequence with a "Capture User State" task that utilizes USMT 4, files are properly captured and restored but settings may not be. The SMSTS.log will not show any errors, however the scanstate.log will show the following error:

<Date> <Time>, Info                  [0x000000] Downlevel Manifests folder is not present. System component settings will not be gathered.

Settings that may not be captured include printers, mapped network drives, and wallpaper.

Cause

In order for USMT 4 to capture settings correctly via scanstate.exe, it needs access to the DlManifests folder that is part of the USMT 4 binaries. Scanstate.exe looks for the DlManifests folder in the current working directory instead of the directory where scanstate.exe was run from. If the location where scanstate.exe runs from is not the same as the working directory and/or if the working directory does not contain the DlManifests folder, then scanstate.exe will not have the ability to capture settings.

When scanstate.exe is run manually outside of an SCCM 2007 Task Sequence, the working directory usually matches the directory where scanstate.exe runs from. However, when scanstate.exe is launched using an outside process, such as an SCCM 2007 Task Sequence via the "Capture User State" task, the working directory may not match the directory where scanstate.exe is run from.

In the case of Configuration Manager 2007, the working directory for both 32bit and 64bit Windows OSs is:

%windir%\System32

Since this is not the location that scanstate.exe was launched from and/or that the DlManifests folder is located, scanstate.exe does not find the folder and it fails to capture settings.

Resolution

To work around the issue, add a task in the Task Sequence that copies the DlManifests folder from the USMT 4 package to the default working directory used by SCCM 2007 OSD Task Sequences:

1) In the SCCM 2007 Admin Console, under the "Computer Management" -->"Software Distribution" --> "Packages"node, right click on the USMT 4 packages and choose "Properties".

2) Click on the "Data Source" tab and ensure that the "Source directory" field is pointing to the root level of the USMT folder. It should not be pointing to either the x86 or amd64 folders. Only one package should be necessary for both x86 or x64 deployments. If the "Source directory" field is pointing directly to either the x86 or amd64 folders, correct this by pointing the source directory one level up to the root of the USMT folder. If corrections are necessary, after making the correction, make sure to update (not refresh) the Distribution Points that the USMT 4 package is on.

3) In the SCCM 2007 Admin Console, under the "Computer Management" -->"Operating System Deployment"--> "Task Sequences"node, right click on the affected Task Sequence and choose "Edit".

4) Immediately before the "Capture User State" task, add a "Run Command Line" task.

5) In the newly created Run Command Line task:

a) Click on the "Package" checkbox, then click on the "Browse" button of the "Package" option and select the USMT 4 package.

b) Check the option "Disable 64-bit file system redirection".

c) In the "Name:" field, type in:

Copy DlManifests folder to working directory

d) In the "Command Line:" field, type in:

xcopy /e .\%PROCESSOR_ARCHITECTURE%\DlManifests\*.* %windir%\system32\DlManifests\*.* /Y

6) Click on the "Apply" button to save the Task Sequence.

To resolve the issue when using an MDT 2010 standalone Task Sequences, please see KB977565:

Network drives and network printers are not migrated when you use Microsoft Deployment Toolkit 2010 with the User State Migration Tool (USMT) 4.0 - http://support.microsoft.com/kb/977565

Note: Special thanks to  Alexey Semibratov for identifying the root cause of this issue.

Frank Rojas | System Center Support Escalation Engineer

The Configuration Manager writing team is very excited to announce the release of the following Configuration Manager 2007 SuperFlows:

• Software Updates Synchronization SuperFlow: Provides the detailed dataflow for the software updates synchronization process, additional resources related to software updates synchronization, and troubleshooting information.
• SuperFlow for Configuring Software Updates: Provides detailed steps that help you to plan for and configure software updates at a site. This SuperFlow also includes troubleshooting information and additional resources that you can use to learn more about configuring software updates in Configuration Manager 2007.
• Software Update Deployment SuperFlow: Provides information that helps you to prepare for and deploy software updates after you configure the software updates infrastructure and synchronize software updates.
• SuperFlow for Creating SRS Report Models in Configuration Manager 2007: Provides detailed steps that you can use to create a SQL Server Reporting Services report model in Configuration Manager 2007.

A complete list of the Configuration Manager SuperFlows and links to the download location for each is available at: http://go.microsoft.com/fwlink/?LinkId=183297.

What is a SuperFlow?

The SuperFlow interactive content model provides a structured and interactive interface for viewing documentation. Each SuperFlow includes comprehensive information about a specific Configuration Manager 2007 dataflow, workflow, or process. Depending on the focus of the SuperFlow, you will find overview information, steps that include detailed information, procedures, sample log entries, best practices, real-world scenarios, troubleshooting information, security information, animations, or other information. Each SuperFlow also includes links to relevant resources, such as Web sites or local files that are copied to your computer when you install the SuperFlow.

Source

J.C. Hornbeck | System Center Knowledge Engineer

After upgrading to SCCM 2007 SP2, AD discovery methods will fail to bind across external trusts. When the failure occurs, the ADSysDis.log will contain entries similar to this:

ERROR: Failed to bind to AD Object LDAP://DC02-140-52S.LITWARE.COM/CN=COMPUTERS, error=An operations error occurred.~~ -- Extended Error --- LDAP Provider : 00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece.

ERROR: Failed to enumerate directory objects in AD container LDAP://DC02-140-52S.LITWARE.COM/CN=COMPUTERS

STATMSG: ID=5204 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_AD_SYSTEM_DISCOVERY_AGENT" SYS=SMS4-120-52S SITE=2P4 PID=1340 TID=308 GMTDATE=Thu Dec 17 18:31:10.528 2009 ISTR0="LDAP://DC02-140-52S.LITWARE.COM/CN=COMPUTERS" ISTR1="An operations error occurred.~~ -- Extended Error --- LDAP Provider : 00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0

The failure occurs because of a change made in Service Pack 2 which makes the product more secure by requiring authentication for AD binds. As discovery is performed by the site server System account, authentication on the network requires Kerberos which is not supported across external trusts.

You can use one of the following methods to work around this new behavior:

- Use Windows 2003 or higher forest trusts instead of external trusts, as Kerberos is supported across them.

or

- Install a primary site server in the trusted domain to perform discovery there. This server can leverage an address configured with a user name and password, which works with NTLM, to forward the data to the original site server in the trusting domain.

Keith Thornley | Senior Support Escalation Engineer