I see this issue every once in a while and thought it might make for a good tip.  If you're running into errors trying to integrate MDT and ConfigMgr 2007 then this one's for you.

Issue

When trying to integrate MDT with a System Center Configuration Manager 2007 console via the option "Configure ConfigMgr Integration" on a Windows Vista or newer OS (Windows Vista, Windows 7, Windows Server 2008, Windows Server 2008 R2), the following error may occur:

Copied binaries to <ConfigMgr_Install_Path>\AdminUI\Bin
Copied extention files to <ConfigMgr_Install_Path>\AdminUI\XmlStorage\Extensions
Successfully connected to WMI namespace \\MASTER\root\sms
Located the provider for site <Site_Code> on server MASTER
Validated site server and site code.
Unable to compile <ConfigMgr_Install_Path>\AdminUI\Bin\Microsoft.BDD.SCCMActions.mof, rc = 3

Operation completed with warnings or errors.  Please review the output above.

Cause

This issue is caused because ConfigMgr Integration needs to be run as an administrator.

Resolution

Right click on "Configure ConfigMgr Integration" and choose "Run as administrator".

Frank Rojas | System Center Support Escalation Engineer

When attempting to deploy Windows Server 2008 x64 SP2 (KB948465) as a Software Update via System Center Configuration Manager, the update may not be offered as applicable to some Windows Server 2008 64-bit machines.

Cause

When you are running an x64-based version of Windows Vista or of Windows Server 2008 on a computer that has multiple Intel x64 processors of a certain kind, or has an Intel x64 multi-core processor, certain known issues were encountered when applying SP2 so detection logic was added that blocks Service Pack 2 on these machines.

Resolution

For computers that meet this description, you need to have update KB973879 installed. This detail is noted in the following Knowledge Base article:

KB948343 - Windows Vista and Windows Server 2008 service packs are not available for installation through Windows Update

"Computers that have certain multiple processors need to have update 973879 installed for Service Pack 2 for Windows Vista and for Windows Server 2008 to be offered

973879 (http://support.microsoft.com/kb/973879/ ) You receive a "Stop 0x0000003E" error message when you try to install Windows Vista Service Pack 2 or Windows Server 2008 Service Pack 2 on a computer that has certain multiple processors"

Some users have noticed an additional issue when attempting to install KB973879. In these cases, the installation fails with, “The update does not apply to your system.” 

This can occur if Microsoft Security Update KB971486 is already installed on the same machine.  We are working to release a new version of KB973879 with updated detection logic to allow it to be installable when KB971486 is installed but in the interim we have the following workaround:

1. Remove KB971486
2. Install KB973879
3. Configure a Software Update deployment for the client.
4. After SP2 installs, re-install KB971486.

Note: A special thanks to Mike Johnson for documenting this issue.

Hope this helps,

J.C. Hornbeck | System Center Knowledge Engineer

When attempting to add an Install Software item in a System Center Configuration Manager 2007 Task Sequence, the Program drop-down list under Install a single application may be empty.  Clicking Apply results in a Task Sequence Editor Please select a program dialog and the item cannot be saved.

This behavior may occur if Allow users to interact with this program is selected on the Environment tab of the program's properties dialog.  Since the Task Sequence always executes in the system context, it is not possible to use this option.  In some rare cases, there may be problems with the objects properties in WMI that may need to be modified directly as well.  The resolution section below covers both cases.

Resolution

In most cases, unchecking Allow users to interact with this program from the program's properties dialog will resolve this issue.  This setting is located in the Configuration Manager Console under Site Database\Computer Management\Software Distribution\Packages\<Package Name>\Programs\<Program Name>\Properties.  Once the selection has been unchecked, return to the Task Sequence editor and click on Browse... to re-select the package.

If unchecking the Allow users to interact with this program option does not resolve the issue, or if the setting is already unchecked, you may need to manually edit the object for the package in WMI.  Use these steps to resolve this issue:

1. Click Start, Run, then type wbemtest.
2. Click Connect and type root\sms\site_<SITECODE> in the Namespace field (where <SITECODE> is the 3-letter site code of your site).  Click Connect.
3. Click on Query... and type select * from SMS_Program.  Click Apply.
4. In the Query Result dialog, double-click the entry for the package you are trying to add.
5. In the Properties list, locate ProgramFlags  and double-click on it to bring up the editor.
6. Record the current value and then replace it with 135307264.
7. Click on Save Property.  This will close the dialog.
8. Click on Save Object to close the package entry.
9. In the Task Sequence editor, click on the Browse... button, select any other package, click OK, then click Browse... again and navigate to the package you wish to deploy.

Mark Stanfill | System Center Senior Support Escalation Engineer

Note: There is an updated version of this guide over at the Configuration Manager OSD Support Team Blog. For the latest version, please visit the below article:

Troubleshooting the PXE Service Point and WDS in Configuration Manager 2007

=====

This is a general guide on properly setting up and troubleshooting the System Center Configuration Manager 2007 (ConfigMgr 2007) PXE Service Point. 

Common errors that are seen at the PXE boot screen when the PXE Service Point is either not configured properly or experiencing problems are the following:

PXE-E53: No boot filename received
PXE-T01: File not found
PXE-E3B: TFTP Error - File not Found
PXE-E55 Proxy DHCP Service did not reply to request on port 4011
PXE-T04: Access Violation
PXE-E36: Error Received from TFTP Server
PXE-M-F Exiting PXE Rom

However the error messages can vary depending on the PXE implementation on the client PC.  Another common symptom is that the Windows Deployment Services Server (WDS) service will not start.

To resolve these issue and to prevent them from occurring in the first place, follow the guide below  This guide is broken down to the following sections:

- Setting Up IP Helpers

- How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point

- Reinstalling WDS And The PXE Service Point

- Testing The PXE Service Point

- Monitoring And Troubleshooting The PXE Boot

The guide is written in chronological order of the actions that need to be taken properly get a ConfigMgr 2007 PXE Service Point working and operational. Refer to the appropriate sections as needed.

Setting Up IP Helpers

If the DHCP server, the client PC, and the ConfigMgr 2007 server are running WDS and the PXE Service Point are all on the same subnet or vlan, please proceed to the section "How To Properly Install and Set Up The PXE Service Point". Otherwise, if either the DHCP server, the client PC or the ConfigMgr 2007 server is running WDS and the PXE Service Point are on separate subnets or vlans, which is usually the case in most environments, the first step to take before trying to install and configure the PXE Service Point and WDS is to set up IP Helpers on the routers. How to do this varies depending on the router hardware manufacturer but the general overview is outlined at the below link:

Configuring Your Router to Forward Broadcasts
http://technet.microsoft.com/en-us/library/cc732351(WS.10).aspx#Updating

For further information on how to properly configure IP Helpers on the routers, please contact the hardware manufacturer of the router.

IP Helpers are necessary because the PXE request generated by the client PC is a broadcast that does not travel outside of the local subnet or vlan. It only stays within the local subnet or vlan. If the DHCP server and/or the WDS/PXE Service Point server are not on the subnet or vlan as the client PC, they will not see or hear the PXE request broadcast from the client PC and therefore will not respond to the PXE request. To have the PXE request broadcast transverse between subnets or vlans, the PXE request broadcast needs to be forwarded by the router to the DHCP and WDS/PXE Service Point servers so that they can properly respond to the client PC's PXE request.

An alternative to using IP Helpers is setting DHCP Options on the DHCP server, specifically DHCP Options 60 (PXE Client), 66 (Boot Server Host Name), and 67 (Bootfile Name). However, DHCP Options can be problematic and may not work reliably or consistently. Furthermore the use of DHCP Options to control PXE requests is not supported by Microsoft. Therefore the only recommended and supported method of PXE booting client PCs that are on a different subnet than the DHCP or WDS/PXE Service Point servers is the use of IP Helpers.

For additional information regarding DHCP Options not being recommended or supported please see the below articles:

Using DHCP Options 60, 66, and 67
http://technet.microsoft.com/en-us/library/cc732351(WS.10).aspx#Using

PXE clients computers do not start when you configure the Dynamic Host Configuration Protocol server to use options 60, 66, 67
http://support.microsoft.com/kb/259670

The only exception where a DHCP Option needs to be used is when DHCP and WDS reside on the same server. In this instance, DHCP Option 60, and only DHCP Option 60, needs to be set. DHCP Options 66 and 67 should still NOT be set in this scenario. For more information, please see the section "Windows Deployment Services (WDS) and DHCP" in the following article:

Planning for PXE Initiated Operating System Deployments
http://technet.microsoft.com/en-us/library/bb680753.aspx

It is IMPERATIVE that before continuing that it has been verified that the routers have IP Helpers configured AND that the DHCP server does NOT have DHCP Options 60, 66, or 67 configured. Not meeting both of these criteria will cause the PXE Service Point not to work correctly. When checking DHCP options, make sure to check options at both the server and scope levels.

In certain instances, configuring DHCP Options 60, 66, and 67 may make it appear that the PXE boot process is proceeding further along than before these options were configured, but in reality it just proceeds further down an incorrect path, ends up giving different error messages, and ends up failing.

How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point

The following section lists the step to ensure that that a NEW instance of the PXE Service Point is set up and configured properly. If Windows Deployment Services (WDS) and/or the PXE Service Point has been previously installed, even if it never worked, follow the instructions under the section "Reinstalling WDS And The PXE Service Point" instead:

1. If needed, make sure that IP Helpers have been configured. Additionally, make sure that DHCP Options 60, 66, 67 have NOT been configured. See the section "Setting Up IP Helpers" for additional information.

2. Install, but DO NOT configure, Windows Deployment Services (WDS) on the server that will host the PXE Service Point.

• If using Windows Server 2003, WDS is installed via the Add/Remove Windows Components in the Add/Remove Control Panel.
• If using Windows Server 2008 or newer, WDS is installed via Roles in Server Manager. When installing in Windows Server 2008 or newer, make sure that both the Deployment Server and Transport Server are installed.

3. If prompted to do so after WDS has finished installing, reboot the server.

4. Once the server has restarted, DO NOT try to manually configure or start the WDS service.

5. In the ConfigMgr 2007 Admin Console, navigate to "Site Management" --> <Site_Code> --> "Site Settings" --> "Site Systems".

6. If the server where the PXE Service Point is going to be installed already exists under "Site Systems", right click on the server and choose "New Roles".  Otherwise right click on "Site Systems" and choose "New" --> "Server".

7. In the "General" page of the wizard, make sure that the NETBOIS and FQDN name of the server are correct and then click on the "Next >" button.

8. In the "System Role Selection" of the wizard, check "PXE service point" and then click on the "Next >" button.

9. Review the "PXE Service Point Configuration" dialog windows and then click on the "Yes" button.

10. In the "PXE - General" window, configure the appropriate options as desired and then click on the "Next >" button.

11. In the "PXE - Database" window, change any options as needed. In most cases, leave settings at their default in this window. Click on the "Next >" button.

12. Click on the "Next >" button and then on the "Close" button.

13. On the server where the PXE Service Point is being installed, navigate to the ConfigMgr 2007 site server log location using Windows Explorer. Usually the log location will be under one of the following paths:

• 32bit servers
  <drive_where_ConfigMgr_is_installed>\Program Files\Microsoft Configuration Manger

• 64bit servers
  <drive_where_ConfigMgr_is_installed>\Program Files (x86)\Microsoft Configuration Manger\Logs

• 32bit or 64bit servers
  <drive_where_ConfigMgr_is_installed>\SMS

14. Once the log directory has been located in Step 13, open the log file PXESetup.log using SMS Trace/Trace32.exe.  Monitor this log and verify that the PXE Service Point installed correctly. It may take a few minutes for the installation to start and finish successfully. If this is the first time the PXE Service Point is being installed on the server, it may take a few minutes for the PXESetup.log to appear and be created.

Once installed correctly, the last lines in the log should be "pxe.msi exited with return code: 0" and "Installation was successful." Verify that the line is for the current date and time frame.

In some circumstances, the last lines will read "pxe.msi exited with return code: 3010" and "Installation was successful, but a reboot is required." If this is the case, make sure to reboot the server before continuing.

Do NOT proceed until confirmation has been received in the PXESetup.log that installation has been successful.

15. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Operating System Deployment" --> "Boot Images".

16. If BOTH the x64 and x86 Boot Images are not already on any standard Distribution Point (DP), make sure to put both Boot Images on at least one standard DP. Monitor the "Package Status" node and ensure that both the x64 and x86 Boot Images properly install on the standard DP.

17. Place BOTH the x64 and x86 Boot Images on the SMSPXEIMAGES$ DP on the server where the PXE Service Point was created. Monitor the "Package Status" node and ensure that both the x64 and x86 Boot Images properly install on the SMSPXEIMAGES$ DP.

18. Once the Boot Images have installed on the SMSPXEIMAGES$ DP, open the Services console on the PXE Service Point server and ensure that the Windows Deployment Services Server service has started. Additionally make sure that the RemoteInstall folder has been created on the root level of the one of the drives of the server.

19. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Operating System Deployment" --> "Task Sequences". Right click on each Task Sequence that will be deployed via PXE and choose "Properties". Click on the "Advanced" tab and ensure that the option "Use a boot image:" is checked and that an appropriate boot image for that Task Sequence is selected.

20. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Software Distribution --> "Advertisements". Right click on each Advertisement for Task Sequences that will be deployed via PXE and choose "Properties". Under the "General" tab make sure that the option "Make this task sequence available to boot media and PXE" is checked.

Notes:

1. When the PXE Service Point is installed, it will automatically configure WDS and create the RemoteInstall folder. Once configured, the PXE Service Point installation will then automatically start the WDS service. For this reason, manual configuration of WDS in the Windows Deployment Services console is NOT necessary and should not be performed.

The only exception to this rule is when DHCP and WDS reside on the same server. In these cases, consult the section "Windows Deployment Services (WDS) and DHCP" in the following article:

Planning for PXE Initiated Operating System Deployments
http://technet.microsoft.com/en-us/library/bb680753.aspx

2. Once the PXE Service Point has configured and started WDS, the Windows Deployment Services console will still show a yellow exclamation mark and display the message "Windows Deployment Services is not configured". This is normal and does not indicate a problem. No action or configuration should be taken in the Windows Deployment Services console.

3. Regardless of the architecture of the Windows OS being deployed, it is IMPERATIVE that BOTH the x86 and x64 Boot Image are on BOTH a standard DP and the SMSPXEIMAGES$ DP. Make sure to verify that this has been done.

4. Do NOT place any other types of packages other than Boot Images in the SMSPXEIMAGES$ DP. Placing any other type of packages in the SMSPXEIMAGES$ DP, especially OS images, may cause WDS not to work correctly.

Reinstalling WDS And The PXE Service Point

In certain scenarios, especially ones where WDS and the PXE Service Point were initially installed or configured incorrectly, the best course of action is to uninstall the PXE Service Point and WDS, delete all previous configurations, and then reinstall:

1. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Operating System Deployment" --> "Boot Images".

2. Under each Boot Image, click on the "Distribution Points" node. On the right hand panel, right click on the "\\<Server_Name>\SMSPXEIMAGES$" DP and then choose "Delete" (where <Server_Name> is the name of the server where the PXE Service Point and WDS is being reinstalled). If the Boot Image is installed on the standard DP, it is NOT necessary to also delete the Boot Image from the standard DP.

3. Under each Boot Image that was deleted, monitor the "Package Status" node under the Boot Image to ensure that the Boot Image is removed from the SMSPXEIMAGES$ DP. To verify, check the "Package Status" node under the first "Package Status" node. Once the Boot Image has been successfully deleted from the DP, "Source Version", "Targeted", and "Installed" will all be 0.

4. Make sure that no other packages are on the SMSPXEIMAGES$ DP. To check if there are any other packages on the SMSPXEIMAGES$ DP, on the server where the PXE Service Point is being uninstalled, navigate to the folder RemoteInstall\SMSImages\SMSPKG. The RemoteInstall folder will be on the root level of one of the drives of the server. If the folder is empty, all packages have been removed. If the folder contains subfolders, there are additional packages on the SMSPXEIMAGES$ DP that need to be removed:

a. To determine which packages are on the DP, copy down the folder names. The folder names correspond to the Package ID of the package that is on the DP.

b. In the ConfigMgr 2007 Admin Console, navigate to "System Status" --> "Package Status". On the right hand panel all of the packages in the environment will be listed. On the far right last column the Package ID will be listed. Match up the Package ID obtained in Step 1
with the Package Name.

c. Based on the Package Name obtained in the Step 2, locate the package under one of the following nodes in the ConfigMgr 2007 console:

•  
  • "Computer Management" --> "Software Distribution" --> "Packages"
  • "Computer Management" --> "Operating System Deployment" --> "Operating System Images"
  • "Computer Management" --> "Operating System Deployment" --> "Operating System Install Packages"
  • "Computer Management" --> "Operating System Deployment" --> "Driver Packages"
  • "Computer Management" --> "Software Updates" --> "Deployment Packages"

d. Under each package, click on the "Distribution Points" node. On the right hand panel, right click on the "\\<Server_Name>\SMSPXEIMAGES$" DP and then choose "Delete" (where <Server_Name> is the name of the server where the PXE Service Point and WDS is being reinstalled).

e. Under each package that was deleted, monitor the "Package Status" node under the package to ensure that the package is removed from the SMSPXEIMAGES$ DP. To verify, check the "Package Status" node under the first "Package Status" node. Once the package has been successfully deleted from the DP, "Source Version", "Targeted", and "Installed" will all be 0.

f. Once all of the packages have been deleted, check the RemoteInstall\SMSImages\SMSPKG folder on the server where the PXE Service Point is being uninstalled and and ensure that it is empty.

5. On the server where the PXE Service Point and WDS are being deinstalled, open the Services console. Locate the "Windows Deployment Services Server" service, right click on it, and select "Stop". If the service is already stopped, proceed to Step 6.

6. In the ConfigMgr 2007 Admin Console, navigate to "Site Management" --> <Site_Code> --> "Site Settings" --> "Site Systems".

7. Under "Site Systems", click on the server where the PXE Service Point is being uninstalled.  On the right hand panel right click on "ConfigMgr PXE service point" and choose "Delete". In the "Confirm Delete" dialog box, click on the "Yes" button.

8. On the server where the PXE Service Point is being uninstalled, navigate to the ConfigMgr 2007 site server log location using Windows Explorer. Usually the log location will be under one of the following paths:

• 32bit servers
  <drive_where_ConfigMgr_is_installed>\Program Files\Microsoft Configuration Manger

• 64bit servers
  <drive_where_ConfigMgr_is_installed>\Program Files (x86)\Microsoft Configuration Manger\Logs

• 32bit or 64bit servers
  <drive_where_ConfigMgr_is_installed>\SMS

9. Once the log directory has been located in Step 8, open the log file PXESetup.log using SMS Trace/Trace32.exe. Monitor this log and verify that the PXE Service Point uninstalled correctly. It may take a few minutes for the deinstallation to start and finish successfully. Once uninstalled correctly, the last line in the log should be "SMSPXE deinstall exited with return code 0", "Deinstallation was successful.", and "Removing PXE Registry." Verify that the lines are for the current date and time frame.

If the deinstall of the PXE Service Point never kicks off, check the sitecomp.log on the parent site server to determine why it was not able to start the deinstall. In most cases it is due to file in use issues, which usually can be resolved by stopping the WDS service (Step 5).

Do NOT proceed until confirmation has been received in the PXESetup.log that deinstallation has been successful.

10. Uninstall Windows Deployment Services (WDS) on the server:

a. If using Windows Server 2003, WDS is uninstalled via the Add/Remove Windows Components in the Add/Remove Control Panel.

b. If using Windows Server 2008 or newer, WDS is uninstalled via Roles in Server Manager.

11. Reboot the server where WDS and the PXE Service Point were just deinstalled.

12. Once the server reboot completes and the server comes back up, locate the RemoteInstall folder on the root level of each of the drives of the server. If it exists on the drive, rename the RemoteInstall folder (i.e. RemoteInstallOld). On most servers, only one of the drives will have a RemoteInstall folder. However if multiple instances of the RemoteInstall folder exist, make sure to rename each instance.

If when renaming the RemoteInstall folder you receive one of the below messages:

Windows Server 2008/Windows Server 2008 R2
This folder is shared with other people
If you rename this folder, it will no longer be shared.
Folder: <drive_letter>\RemoteInstall
Share Name: REMINST

or

Windows Server 2003
You are sharing <drive_letter>:\RemoteInstall\SMSIMAGES as SMSPKEIMAGES$. The folder will not be shared after you move or rename it. Are you sure you want to continue?

go ahead and make sure to click on either the "Continue" or "Yes" button.

13. On the server where WDS and the PXE Service Point were uninstalled, delete the folders BootImages and PXEBootFiles under %systemroot%\Temp (usually C:\Windows\Temp). It may be necessary to take ownership of the folders and their subfolders to successfully delete the folders. In some circumstances, it may be necessary to also navigate down the folder hierarchy and take ownership from the bottom up.

14. Reinstall WDS and the PXE Service Point using the instructions in the section "How To Properly Install and Set Up A New Instance of A PXE Service Point".

Testing The PXE Service Point

Once WDS and the PXE Service Point have been installed and configured, test the PXE Service point to see if it is working. Take the following measures to ensure the best testing environment:

1. To eliminate problems with Unknown Computer Support, advertise the Task Sequence to a collection that has known existing clients. If necessary, use the Computer Association node to manually create a client record. For best results, create the record based on the SMBIOS GUID (System UUID) of the PC and NOT the MAC address.

2. To eliminate certain issues that can occur with mandatory assignments, do not add a mandatory assignment to the advertisement of the Task Sequences. Instead the Task Sequence advertisement should be completely optional.

3. Verify the properties of the advertisement and ensure that under the "General" tab the option "Make this task sequence available to boot media and PXE" is checked.

4. Verify the properties of the Task Sequence and ensure that under the "Advanced" tab the option "Use a boot image:" is checked and that a boot image assigned under this option.

5. Refer to the below two KB articles regarding the SMS PXE Cache:

Client machines may fail to boot into PXE if System Center Configuration Manager Service Pack 2 has been applied
http://support.microsoft.com/kb/2019640

Operating system deployment fails in a System Center Configuration Manager 2007 SP1 environment if you deploy a different operating system to a client within one hour of a previous deployment
http://support.microsoft.com/kb/969113

During testing is suggested to set the value of the CacheExpire key to 60 (60 seconds = 1 minute). This will minimize PXE booting issues being caused by the SMS PXE cache. The default of the CacheExpire key is either 0 or 3600, both which are 3600 seconds (1 hour). After testing is complete, the value of this registry setting will need to be determined based on environmental conditions.

Monitoring And Troubleshooting The PXE Boot

The single greatest troubleshooting tool in figuring out why a PXE boot is not working on a client PC is monitoring the SMSPXE.log. The log should be monitored live with SMS Trace/Trace32.exe while a PXE boot is attempted on the client PC. When monitoring the SMSPXE.log, the log should show in real time exactly what is occurring.

1. While attempting a PXE boot on a client PC, perform a live monitor of the log SMSPXE.log with SMS Trace/Trace32.exe. The SMSPXE.log log can be found under the MP/client logs of the ConfigMgr site server hosting the PXE Service Point. The location of the MP/client log files is usually under one of the following paths:

32bit servers
<drive_where_ConfigMgr_is_installed>\Program Files\SMS_CCM\Log
or
%systemroot%\System32\CCM\Logs (usually C:\Windows\System32\CCM\Logs)

64bit servers
<drive_where_ConfigMgr_is_installed>\Program Files (x86)\SMS\CCM\Log
or
%systemroot%\SysWow64\CCM\Logs (usually C:\Windows\System32\CCM\Logs)

32bit or 64bit servers
<drive_where_ConfigMgr_is_installed>\SMS_CCM\Log

2. Monitoring the SMSPXE.log should show the activity in the log when the actual PXE request is occurring. If no activity is occurring, this is usually indicative of one of the following problems:

• The WDS service has not started or is not running
• The PC is on a separate subnet or vlan from the WDS and DHCP servers and IP Helpers have not been properly set up
• DHCP Options 60, 66, or 67 have been configured

3. Enabling debug logging on the SMSPXE.log could assist in troubleshooting why a PC is not PXE booting by giving additional information about the PXE request.  To enable debug logging on the PXE Service Point server for the SMSPXE.log , modify the following registry key on the server to a string value of "True" (without the quotes):

32bit Windows Server
HKLM\SOFTWARE\Microsoft\CCM\Logging\DebugLogging!Enabled

64bit Windows Server
HKLM\SOFTWARE\Wow6432Node\Microsoft\CCM\Logging\DebugLogging!Enabled

Once the change has been made, restart the server for the changes to take effect.

4. Lines in the SMSPXE.log that show PXE requests that contain all Fs as the MAC address similar to the below line can be ignored:

MAC=FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF SMBIOS GUID=<SMBIOS_GUID> > Received DHCP Request smspxe
Executing LookupDevice(<SMBIOS_GUID>, FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF) smspxe
CDatabaseProxy :: LookupDevice succeeded: 0 0 0 0 smspxe
MAC=FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF SMBIOS GUI=<SMBIOS_GUID > > Device not found in the database. smspx
MAC=FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF SMBIOS GUID=<SMBIOS_GUID > New client request. RequestID=<Request_ID>. smspxe

These PXE "requests" are just the server doing a self check on itself to ensure the PXE Service Point is up and responding.

5. The error in the SMSPXE.log:

Failed to read PXE settings.
The system cannot find the file specified. (Error: 80070002; Source: Windows) smspxe

can be ignored and is not relevant. It does not indicate that there are any problems.

6. If the following messages appear at the PXE boot screen:

TFTP Download: smsboot\x86\abortpxe.com
PXE Boot aborted. Booting to next device...

or

TFTP Download: smsboot\x64\abortpxe.com
PXE Boot aborted. Booting to next device...

it is indicative that the PXE Service Point and WDS are installed and configured correctly and working as expected. The above error messages occur when an advertised Task Sequence is not found for the PC that is being PXE booted. The PXE Service Point then responds appropriately and sends a PXE abort.

The problem is usually associated with how the Task Sequence is advertised and targeted to the PC. Usually in these scenarios the following message will show up in the SMSPXE.log for the PXE request:

ProcessDatabaseReply: No Advertisement found in Db for device smspxe

7. The SMSPXEIMAGES$ DP is actually a share pointing to the SMSIMAGES folder within the RemoteInstall folder. ConfigMgr places the Boot Images in this share so that the Boot Images are available to WDS for PXE booting. In total there should only be four folders within the RemoteInstall folder as follows:

SMSBoot
SMSIMAGES
SMSTemp
Stores

If additional folders exist in the RemoteInstall folder, such as:

Boot
Images
Mgmt
Templates
Tmp
WdsClientUnattend

this is an indication that WDS has been manually configured at some point. The best course of action at this point is to reset the installation of WDS by reinstalling the PXE Service Point and WDS as described in the section "Reinstalling WDS And The PXE Service Point".

8. ConfigMgr uses the Boot Images in the RemoteInstall\SMSIMAGES folder to extract Boot Files from the Boot Images. In addition to the Boot Images, these Boot Files are also needed by WDS to successfully complete a PXE boot. These Boot Files are placed in the SMSBoot folder under the RemoteInstall folder. The process of extracting the Boot Files can be seen by monitoring the SMSPXE.log while the WDS service is restarted. If errors appear in the log during this process (besides the error described in Step 5 above), the best course of action is to reinstall the PXE Service Point and WDS as described in the section "Reinstalling WDS And The PXE Service Point".

9. The RemoteInstall\SMSIMAGES folder will contain a subfolder called SMSPKG, which will then contain subfolders for each Boot Image that has been added to the SMSPXEIMAGES$ DP. Each subfolder under the SMSPKG folder will have the name of the Package ID of the Boot Image.

If any subfolder exists under SMSPKG that is not the Package ID of a Boot Image, they should be removed from the SMSPXEIMAGES$ DP via the ConfigMgr 2007 Admin console. Only Boot Images should be added to the SMSPXEIMAGES$ DP. No other type of packages should be added to the SMSPXEIMAGES$ DP. This is especially true with Operating System Image Package or an Operating System Install Package (Windows OS source files). Having an Operating System Image Package or an Operating System Install Package under the SMSPXEIMAGES$ DP will cause issues with WDS.

Instructions on how to remove additional packages from the SMSPXEIMAGES$ DP are provide above in Step 4 under the section "Reinstalling WDS And The PXE Service Point". However make sure not to remove the Boot Images as outlined in the instructions.

10. The RemoteInstall\SMSBoot folder should have three folders listed under it, one for each architecture type - ia64, x64, and x86. The ia64 folder will be empty since ia64 is not an officially supported platform for ConfigMgr 2007 OSD. However, both the x64 and x86 folders should have the following files in them:

abortpxe.com
bootmgfw.efi (x64 only)
bootmgr.exe
pxeboot.com
pxeboot.n12
wdsnbp.com

If the folders are missing, empty, or missing files, then BOTH the x64 and x86 Boot Images may not have been placed in the SMSPXEIMAGES$ DP. If both the x64 and x86 Boot Images have been placed on the SMSPXEIMAGES$ DP and the folders still do not exist, are empty, or are missing files, then there may be another problem occurring. The best course of action is to reinstall the PXE Service Point and WDS as described in the section "Reinstalling WDS And The PXE Service Point".

Frank Rojas | System Center 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
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode

I have had a couple of cases recently that involve running a task sequence from the Run Advertised Program (RAP) Control Panel applet which has a large number of software package installation steps (usually over 200).  What happens in these cases is that you will see timeout errors in the cas.log and execmgr.log on the machines in question. These errors resemble an issue where the content is not available on the Distribution Point (DP) but in each case it was reported that the task sequences could be successfully run within WinPE which indicates that this content is actually present on the DPs in question.

If you run into this specific scenario then you can change the UIContentLocationTimeoutInterval variable in the site control file from the default of 120 seconds to a value much greater such as 15-30 minutes.  The UIContentLocationTimeoutInterval variable is a property in the root\ccm\Policy\Machine namespace that has a default value of 120 seconds (2 minutes) but this may not long enough for a task sequence with a large number of software installation steps.  In these cases I have found that if I increase this to a higher value (e.g. 900 seconds or 15 minutes) then the problem no longer occurs when running this from within the RAP. 

To do this complete the following steps to edit the site control file:

1. Stop the smsexec service on the site server
2. Edit the site control file and change the following to a higher value:

PROPERTY <UI Content Location Timeout Interval><REG_DWORD><><120>

3. Restart the smsexec service and make sure you update policy on the client.
4. You can check the value on the local client using wbemtest and connecting to root\sms\policy\machine.

Once complete, the Task Sequence should now complete successfully.

For testing purposes, you can compile the following MOF file on a client to update the actual policy on a single machine. This is optional and serves only to verify that this is in fact the issue you’re encountering:

1. Open wbemtest on the machine you want to test.
2. Open the root\ccm\Policy\Machine namespace.
3. Navigate to ccm_softwareDistributionClientConfig.
4. Select UIcontentLocationTimeoutInterval
5. Select instances.
6. Double click the instances of UIcontentLocationTimeoutInterval.
7. Click Show MOF. 

This should look something like the mof.txt file attached.

8. Edit this file and change the line below to a value such as 900

UIContentLocationTimeoutInterval = 120;

9. Add the following line to the top of the mof file (see the attached file as an example)

#pragma namespace("\\\\.\\root\\ccm\\policy\\machine\\actualconfig")

10. Save this file as a .mof file and move this to the machine that you want to test.
11. Open a CMD prompt and run the following:

Mofcomp.exe mof.mof

12. Check to make sure this value has been changed in WMI using the steps outlined above.

Sample file:

Hope this helps,

Luke Ramsdale | 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
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode
The System Center Essentials Team blog: http: http://blogs.technet.com/b/systemcenteressentials
The Server App-V Team blog: http: http://blogs.technet.com/b/serverappv

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