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

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

Consider the following scenario:

• You’re running Configuration Manager current branch, version 1511 through 1606, or version 1610 LTSB.
• Your old primary site was being used for client piloting.
• You perform site expansion.

In this scenario, the Configuration Manager Client Piloting Package fails. When this occurs, you receive a status message stating that Distribution Manager failed to access the source directory for Configuration Manager Client Piloting Package content. Additionally, the Distmgr.log file contains errors indicating that Distribution Manager cannot locate the source for PilotUpgrade and cannot process the snapshot of the package.

We have a new KB article that describes this issue as well as how to work around it. For more information please see the following:

3205797 – Client piloting package fails after site expansion in Configuration Manager (https://support.microsoft.com/en-us/kb/3205797)

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

We are happy to announce that that update 1612 for the Technical Preview Branch of Microsoft System Center Configuration Manager has been released. Technical Preview Branch releases give you an opportunity to try out new Configuration Manager features in a test environment before they are made generally available. For information on this month’s new preview features, please see the following:

Update 1612 for Configuration Manager Technical Preview Branch – Available Now!

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

Version 1610 of System Center Configuration Manager Current Branch (ConfigMgr 1610) contains many changes that are intended to prevent issues and improve features. A list of these changes and fixes is available in the KB article below, Keep in mind that this list is not comprehensive, however it does include the items that the product development team believes are the most relevant to most customers. Many of these changes are in response to customer feedback about product issues and ideas for product improvement. For more information regarding what’s been fixed and/or updated, please see the following:

3213269 – Summary of changes in System Center Configuration Manager current branch, version 1610 (https://support.microsoft.com/en-us/kb/3213269)

Please note that version 1610 is available as an in-console update to be installed at the top-most site in a hierarchy. For more information on installing the 1610 update, see Checklist for installing update 1610 for System Center Configuration Manager.

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

After you install the Convenience rollup update for Windows 7 SP1 and Windows Server 2008 R2 SP1 (3125574) and the System Center Configuration Manager client, the Software Metering Agent fails, and the following error message is recorded in the mtrmgr.log file:

Software Metering failed to start PrepDriver

This error can occur if you install rollup 3125574 before you install the System Center Configuration Manager client software. In that scenario, PrepDrv is not installed during the System Center Configuration Manager client setup process.

For a couple options on how to resolve this issue, please see the following:

3213242 – Software Metering Agent fails with “Software Metering failed to start PrepDriver” in mtrmgr.log (https://support.microsoft.com/en-us/kb/3213242)

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

An update is available to address important upgrade-related issues for System Center Configuration Manager current branch, version 1610. The issues described in the article below apply only to sites that were upgraded to version 1610 before December 20, 2016. The fixes for these issues are incorporated into the builds of version 1610 that are available from December 20, 2016 onward.

3124042 – Interoperability update for System Center Configuration Manager version 1610 (https://support.microsoft.com/en-us/kb/3124042)

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

You may find that after installing the Microsoft ADK 10 1607 on System Center Configuration Manager Current Branch 1602 (or later), the Apply Driver Package task will start failing when installing one of the drivers in the Driver Package. The failure is random and may not occur on the same driver every time, and occasionally the Apply Driver Package task may succeed.

If you encounter this problem, Microsoft Senior Support Escalation Engineer Frank Rojas has a great article that describes a few of the workarounds available. You can find Frank’s article here.

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

ConfigMgr CB ConfigMgr 1602

If you’re having synchronization problems with either WSUS or System Center Configuration Manager, here’s a friendly reminder that we have a great troubleshooter that will walk you through diagnosing and fixing some of the more common issues that may be encountered when sync fails. If you ever have these kinds of issues, there’s a good chance that this guide will show you how to fix them, and even if you don’t find the resolution to you exact problem, it offers some great resources and tips that will help get you pointed in the right direction. You can find this troubleshooter here.

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

Microsoft ConfigMgr 2012 R2 ConfigMgr current branch Windows Server software update point software update synchronization Microsoft update windows update

~ Rafid Ali

Hello Everyone, Rafid Ali here with another Configuration Manager support tip for you. I recently came across a scenario where a TestDbUpgrade was failing due to a custom database table which was created after adding custom hardware inventory classes in Configuration Manager 2012 R2 Service Pack 1. It was failing to execute Upgrade/TestDBupgrade to newer version 1606, and if you happen to run across this problem then hopefully this post will help.

Below are the error messages that were seen in ConfigMgrSetup.log when running the TestDBUpgrade:

12-08-2016 13:57:48.541    Configuration Manager Setup    4308 (0x10d4)    sql object tel_sum_scansourcewufb is not found. It will be created.

ERROR: SQL Server error: [42S22][207][Microsoft][SQL Server Native Client 11.0][SQL Server]Invalid column name ‘UseWUServer00’. : TEL_SUM_ScanSourceWufB   Configuration Manager Setup

Failed to execute sql command — Name         : TEL_SUM_ScanSourceWufB ~– Version      : 5.0.8412.1313 ~– Definition   : SqlObjs  ~– Scope        : CAS_OR_PRIMARY  ~– Object       : P  ~– Dependencies : <Detect>  ~– Description : SUM telemetry : Information of client Scan sources to know the usage of Windows Update for Business ~ ~ ~CREATE PROCEDURE TEL_SUM_ScanSourceWufB @Input NVARCHAR(MAX) = NULL  ~AS  ~BEGIN  ~ ~SET NOCOUNT ON ~If exists (Select ID from sysobjects where Name=‘WINDOWSUPDATE_DATA’ ) ~SELECT Count(InstanceKey) as MachineCounts ~      ,AUOptions00 ~      ,InstanceKey00 ~      ,NoAutoUpdate00 ~      ,UseWUServer00 ~  FROM WINDOWSUPDATE_DATA with (NOLOCK) ~  GROUP BY UseWUServer00 ,InstanceKey00, AUOptions00, NoAutoUpdate00 ~End             Configuration Manager Setup

ERROR: Failed to execute SQL Server script: Create SQL object tel_sum_scansourcewufb Configuration Manager Setup

Failed to create process of SetupWpf.exe. return value 1                   1/1/1601 12:00:00 AM           1992642571 (0x76C5500B)

There were similar errors for other columns as well for the same table.

Reason for the failure

ConfigMgr 1606 contains the table ‘WindowsUpdate_DATA’ in its database by default, as the Inventory Class ‘Windows Update’ is included as a default inventory class from version 1606 onwards. However, in ConfigMgr 2012 this was not a default inventory class. Because of this, many ConfigMgr 2012 users manually added this class from WMI (Win32Reg_SMSWindowsUpdate or Win32Reg_WindowsUpdate as per the requirement) to get the required data through Hardware Inventory. When this Hardware Inventory Class was added, it created the same table (WindowsUpdate_DATA) with the same columns names, such as ‘AUOptions00’, ‘InstanceKey00’, ‘NoAutoUpdate00’, ‘UseWUServer00’, etc.

Starting with version 1606, Upgrade Task automatically creates all the required objects which are not there by default in the older versions. We can see this by examining the ConfigMgrSetup.log file:

sql object tel_sum_products is not found. It will be created.

Saved hash for SQLText for SQL object tel_sum_products (SHA256:1C87D231C46ECCC0D559F1AA5B83A1A54FA4C445072285D17CBB84B4DA3BCE29)

INFO: SQL Server script: Create object tel_sum_products

sql object tel_sum_scansourcewufb is not found. It will be created.

*** [42S22][207][Microsoft][SQL Server Native Client 11.0][SQL Server]Invalid column name ‘UseWUServer00‘. : TEL_SUM_ScanSourceWufB

*** [42S22][207][Microsoft][SQL Server Native Client 11.0][SQL Server]Invalid column name ‘InstanceKey00‘. : TEL_SUM_ScanSourceWufB

*** [42S22][207][Microsoft][SQL Server Native Client 11.0][SQL Server]Invalid column name ‘AUOptions00‘. : TEL_SUM_ScanSourceWufB

*** [42S22][207][Microsoft][SQL Server Native Client 11.0][SQL Server]Invalid column name ‘NoAutoUpdate00‘. : TEL_SUM_ScanSourceWufB

Failed to execute sql command — Name         : TEL_SUM_ScanSourceWufB ~– Version      : 5.0.8412.1313 ~– Definition   : SqlObjs  ~– Scope        : CAS_OR_PRIMARY  ~– Object       : P  ~– Dependencies : <Detect>  ~– Description : SUM telemetry : Information of client Scan sources to know the usage of Windows Update for Business ~ ~ ~CREATE PROCEDURE TEL_SUM_ScanSourceWufB @Input NVARCHAR(MAX) = NULL  ~AS  ~BEGIN  ~ ~SET NOCOUNT ON ~If exists (Select ID from sysobjects where Name=’WINDOWSUPDATE_DATA’ ) ~SELECT Count(InstanceKey) as MachineCounts ~      ,AUOptions00 ~      ,InstanceKey00 ~      ,NoAutoUpdate00 ~      ,UseWUServer00 ~  FROM WINDOWSUPDATE_DATA with (NOLOCK) ~  GROUP BY UseWUServer00 ,InstanceKey00, AUOptions00, NoAutoUpdate00 ~End  ~~

In this case, Upgrade Task was able to create all of the above objects, like Stored Procedures ‘tel_sum_products’ and its corresponding tables and columns, however when it tried to create and execute object ‘tel_sum_scansourcewufb’, it failed because the same column names (‘AUOptions00’, ‘InstanceKey00’, ‘NoAutoUpdate00’, ‘UseWUServer00’, etc) already existed in the same table (WindowsUpdate_DATA).

You can verify this in your ConfigMgr 2012 R2 SP1 database as shown below.

If this table already exists in the ConfigMgr 2012 database, then it’s been created by custom hardware inventory classes as it’s not a part of the default database for ConfigMgr 2012 R2.

Resolution

In the ConfigMgr 2012 R2 SP1 console, go to Administration:

Next, go to Client Settings:

Select the Client Setting that you are using for Hardware Inventory. In my case it was ‘Default Client Settings’:

Click on ‘Set Classes’:

Select the Custom Inventory Class causing issues and delete it, as shown below.

After a short period of time, you will notice that the table corresponding to that class is deleted in the database. Once the table is deleted, make a healthy backup of Configuration Manager and proceed with the TestDBupgrade. At this point it should complete successfully. Once TestDBUpgrade is successful, you can then proceed with Configuration Manager site upgrade.

NOTE This issue is fixed in Configuration Manager version 1610 and up. Any future baseline builds after 1610 will not encounter this problem.

Rafid Ali, Support Engineer

Microsoft Enterprise Cloud Group

We are proud to announce that the current branch of Microsoft System Center Configuration Manager (version 1610) now supports macOS Sierra (version 10.12) with version 5.0.8466.1 or later of the Configuration Manager Mac client. You can download the latest Mac client for Configuration Manager here. For details on how to upgrade the Configuration Manager Mac client, see How to upgrade clients on Mac computers in System Center Configuration Manager. Please be aware that the version of the Mac client displayed in the Mac preference pane might be different than the version collected by hardware inventory and displayed in the Configuration Manager admin console.

In addition to the Mac client update, we have an update to System Center Endpoint Protection (SCEP) for Mac that includes support for macOS Sierra as well. It is available on the Volume Licensing Service Center (VLSC) at https://www.microsoft.com/Licensing/servicecenter.

J.C. Hornbeck, Solution Asset PM
Microsoft Enterprise Cloud Group

Applies to: Microsoft Intune, System Center 2012 Configuration Manager SP1, System Center 2012 R2 Configuration Manager

Support for System Center 2012 Configuration Manager SP1 and System Center 2012 R2 Configuration Manager RTM ended on July 12^th, 2016. Subsequently, support for these releases connecting to the Microsoft Intune service via hybrid MDM (e.g. managing mobile devices with Configuration Manager and Microsoft Intune) will end on April 10^th, 2017. After this date, hybrid MDM will stop functioning with these releases. Managed devices will essentially become unmanaged as the Intune Connector will no longer connect to the Intune service. No ConfigMgr data (policies, applications, etc.) will flow up to Intune and no managed device data will flow down to ConfigMgr until an upgrade takes place.

To avoid an interruption in service, customers currently using hybrid MDM with ConfigMgr 2012 SP1 or R2 RTM should upgrade to the Current Branch of ConfigMgr (recommended) or the latest supported service pack (R2 SP1 or 2012 SP2) for ConfigMgr 2012 prior to April 10^th, 2017.

Additional resources:

• Upgrade to System Center Configuration Manager (current branch)
• Planning to upgrade to System Center 2012 R2 Configuration Manager SP1
• Planning to upgrade to System Center 2012 Configuration Manager SP2

ConfigMgr 2012 R2