The Out Of Band Management Support Team blog

Microsoft Enterprise Product Roadmap Webcast

J.C. Hornbeck — Thu, 19 Jan 2012 09:18:30 GMT

Please join us for a high level discussion into Microsoft software investments designed to cover most of the major product lines. This will be a 35,000 foot view into the following areas:

Windows Family
Virtualization
Office System
Unified Communications
IT Management
Security

This particular webcast is scheduled for Friday, January 20 at 1:00pm Pacific Time although others are scheduled as well. See this link for more information.

J.C. Hornbeck | System Center & Security Knowledge Engineer

Get the latest System Center news on Facebook and Twitter:

The Forefront Server Protection blog: https://blogs.technet.com/b/fss/
The Forefront Identity Manager blog : https://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: https://blogs.technet.com/b/isablog/
The Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

System Center Unlimited - All your favorite System Center posts, together in one central place

J.C. Hornbeck — Thu, 12 May 2011 10:05:49 GMT

If you’ve been following the blogging efforts of the System Center support and product teams for any length of time then you know we have quite a few different blogs based on the technology or product we focus on. For example, we have the App-V blog, the DPM blog, the ConfigMgr 2007blog, Nexus SC plus many many more, and we do that because sometimes maybe you want DPM info but don’t care about App-V (or vice versa), but what if you’re like so many of our customers and actually do use most of the System Center products together and you want an easier way to track all the content we publish? Well that’s a common request that we get so I decided to setup a single site that mirrors all of the feeds from our most popular System Center sites all in one place. Now by subscribing to a single site you can get all of your favorite System Center content pushed right to your desktop. Here are the feeds I’m mirroring:

I named this blog System Center Unlimited mainly because that’s kind of what it is, an unlimited view into the official System Center universe, so if this sounds like something you’d like then check it out at the link below and let me know what you think:

https://blogs.technet.com/b/systemcentertech

And don’t forget, you can still get all this same information by following me on Twitter or by becoming a fan on Facebook.

Enjoy!

J.C. Hornbeck | System Center Knowledge Engineer

The System Center Blog Aggregator app is now available on Android

J.C. Hornbeck — Tue, 10 May 2011 09:00:02 GMT

A few weeks back I announced the System Center Blog Aggregator app for Windows Phone 7 and today I wanted to let you know that it was now available for all you Android users out there as well. I won’t go into all the details as you can read that at the link above, but here are a couple screen shots to give you an idea of what it looks like. It’s essentially the same app except for the addition of the Nexus SC blog and the blog for Microsoft Server Application Virtualization. Look for the original Windows Phone 7 app to be updated shortly.

After you load and start The System Center Blog Aggregator you see the main screen that defaults to loading the Nexus SC System Center site:

From there you simply click the list button and you’ll see the option for all of our other blogs:

From there you can select and read any blog you like. So there you have it, an app that allows you to follow our content quickly and easily right on your Android phone. If you have an Android phone you should load up The System Center Blog Aggregator and check it out. It’s free after all so what do you have to lose? You can find it here.

Enjoy!

J.C. Hornbeck | System Center Knowledge Engineer

Quick Fix: Error 0x80090304 returned by InitializeSecurityContext when provisioning AMT devices in ConfigMgr 2007

J.C. Hornbeck — Tue, 22 Feb 2011 07:10:27 GMT

You find that you are unable to provision AMT devices in System Center Configuration Manager 2007 SP2 using an external certificate provided by VeriSign. However, using your Internal CA you find that you can successfully provision new machines. When attempting to provision an AMT device using your external certificate you receive the following error:

Error: Device internal error. This may be caused by:

1. SChannel hotfix applied that can send our root certificate in provisioning certificate chain.
2. incorrect network configuration(DHCP option 6 and 15 required for AMT firmware).
3. AMT firmware self signed certificate issue(date zero).
4. AMT firmware is not ready for PKI provisioning. Check network interface is opening and AMT is in PKI mode.
5. Service point is trying to establish connection with wireless IP address of AMT firmware but wireless management has NOT enabled yet. AMT firmware doesn't support provision through wireless connection.

Cause

This can occur if the AMT provisioning certificates does not meet one of the two following requirements.

1. The OID must be the correct OID specified by Intel: 'Server Authentication Certificate' with the Intel setup extension: 1.3.6.1.5.5.7.3.1, 2.16.840.1.113741.1.2.3

2. The OU field in the certificate must be properly defined. For example, in the certificate Subject, it must contain the FQDN of the server that will be the out of band service point and the OU string of "Intel(R) Client Setup Certificate". See the following link for more details:

https://social.technet.microsoft.com/wiki/contents/articles/requesting-an-amt-provisioning-certificate-using-a-windows-server-2008-ca.aspx

Note that because VeriSign does not support the Intel AMT provisioning OID, this certificate request uses the alternative method of supplying the OU attribute of "Intel(R) Client Setup Certificate". See https://www.symantec.com/connect/articles/intel-vpro-amt-out-band-remote-configuration-and-delayed-provisioning-best-practices

Resolution

To resolve this issue, verify that the OID is the correct OID specified by Intel. Alternately, ensure that the OU is correctly defined in the provisioning certificate supplied by VeriSign. If it is not, request a new provisioning cert with the correct OU defined.

Hope this helps,

Buz Brodin | Senior Support Escalation Engineer

Troubleshooting OOBConsole connectivity after an Intel vPro enabled device has been successfully provisioned in ConfigMgr 2007

J.C. Hornbeck — Thu, 17 Feb 2011 07:31:36 GMT

Just in case you somehow happened to miss the announcement, we made Windows 7 Service Pack 1 and Windows Server 2008 R2 SP1 available to MSDN and TechNet Subscribers as well as Volume License customers yesterday. I've been running it for a few days now here and so far I'm pretty impressed, although admittedly I'm probably a little biased. In addition to the standard hotfixes and whatnot, we added some cool virtualization specific features like Dynamic Memory and RemoteFX in Windows Server 2008 R2 SP1 so if you work with any kind of virtualization you'll definitely want to check that out.

But to get back to the real topic of this post, our own Buz Brodin wrote up some great troubleshooting steps you can use if you're experiencing OOBConsole connectivity issues after an Intel vPro enabled device has been provisioned in ConfigMgr 2007. Buz is one of our top AMT/OOB/vPro experts based out of our Charlotte, North Carolina office so if you ever had the chance to call in you very well may have spoken to him. Thanks Buz!

======

The following lists the steps needed and troubleshooting methods available for OOBConsole Connectivity AFTER an Intel vPro enabled device has been successfully provisioned in SCCM 2007.

For OOBConsole and HTTPS connectivity to work the following is required:

1. The IE registry change from article KB908209 must be set on the machine initiating the connection. For Windows XP and Windows Server 2003, the related hotfix needs to be installed first, then the registry key implemented. For newer versions of Windows or Windows XP and 2003 versions that have superseded the patch in KB908209, the registry key change STILL needs to be implemented.

For 32-bit computers

1. Click Start , click Run , type regedit , and then click OK .

2. In the left pane, locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl

3. On the Edit menu, point to New , and then click Key .

4. Type FEATURE_INCLUDE_PORT_IN_SPN_KB908209 , and then press ENTER.

5. On the Edit menu, point to New , and then click DWORD Value .

6. Type iexplore.exe , and then press ENTER.

7. On the Edit menu, click Modify .

8. Type 1 in the Value data box, and then click OK .

9. Exit Registry Editor.

For 64-bit computers

1. Click Start , click Run , type regedit , and then click OK .

2. In the left pane, locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl

3. On the Edit menu, point to New , and then click Key .

4. Type FEATURE_INCLUDE_PORT_IN_SPN_KB908209 , and then press ENTER.

5. On the Edit menu, point to New , and then click DWORD Value .

6. Type iexplore.exe , and then press ENTER.

7. On the Edit menu, click Modify .

8. Type 1 in the Value data box, and then click OK .

9. Exit Registry Editor.

Note: A reboot is not required.

2. Telnet must be installed on the machine initiating the OOBConsole connectivity. Telnet is installed by default in Windows XP and Windows Server 2003, however in newer versions of Windows (2008, Win7) Telnet must be manually installed.

3. The USER account initiating the OOBConsole connection must be listed with the required rights in the Component Configuration\Out of Band Management Properties\Amt Settings\Amt user accounts, SCCM Admin Console interface. More information on this can be found here:

https://technet.microsoft.com/en-us/library/cc431399.aspx.

Note that after making changes here the clients provisioning data will also need to be updated. Right click the client or control/shift click multiple clients, select Out Of Band Management and select Update Provisioning Data in Management Controller Memory. The Amtopmgr.log will log this process and it should be fairly quick.

4. (Possibly Optional): Insure the Internal Subordinate and Root CA certs are in both Trusted Root and Intermediate CA stores on the client you are connecting to and the provisioning/oobconsole machine.

Troubleshooting:

The OOBConsole.log file logs information regarding connection attempts to AMT provisioned computers using the Out Of Band Management Console accessible through the collection view. This log is located in the AdminUI logs folder on the site server and can be used to troubleshoot connectivity errors. You can enable verbose logging using the following procedure:

1. Close the Configuration Manager Console and any open Configuration Manager Windows
2. In Windows explorer, navigate to the bin folder for Admin UI, usually in c:\Program Files\Microsoft Configuration Manager\AdminUI\bin
3. Locate the file oobconsole.exe.config, open it in Notepad
4. Locate the tag ""
5. Change the Value "Error" to "Verbose"
6. Save the changes

Future attempts to use the Out Of Band management Console will now log in the verbose mode. The procedure can be reversed to set logging back to the default mode. (set "Verbose" to "Error"). Some Oobconsole tasks will not function if the User Account that is connecting via Oobconsole has a Kerberos Token that is too large. This is an AMT/vPro limitation and is dependent on the version of AMT firmware the customer has in place. There is further information and a chart from Intel here:

https://communities.intel.com/community/openportit/vproexpert/blog/2009/03/23/kerberos-ticket-size-can-stop-you-from-connecting-to-vpro-systems-and-using-idersol?wapkw=(tokensz)

To view Token Size grab the Tokensz utility from here: https://www.microsoft.com/downloads/en/details.aspx?FamilyID=4a303fa5-cf20-43fb-9483-0f0b0dae265c&DisplayLang=en

Run with the current user logged on with the following parameters:

tokensz.exe /compute_tokensize.

Output at the bottom will show MaxToken = ####

To reduce Token Size, remove the user from some groups or use a fresh account that is not a member of so many groups. After doing this you may need to use KerbTray (from Microsoft resource kits) to flush the local Kerberos ticket cache.

Something important to note is that while Right Click/Power Control functions may work, you may find that Oobconsole functions do not. This is because Power Control uses TLS Authentication and OobConsole and the HTTPS web page uses Kerberos.

Intel has a Configuration Manager 2007 vPro Troubleshooting guide here as well: https://communities.intel.com/message/10377

Hope this helps,

Buz Brodin | Senior Support Escalation Engineer

FYI: Integration of TechNet Blog User Account with TechNet Forums Profile

J.C. Hornbeck — Wed, 26 Jan 2011 06:28:13 GMT

For those of you who sign-in to comment on the TechNet Blogs, there is a change coming on January 27^th 1:00 pm (PST) regarding user accounts and profiles. Please click here to read about this change.

If you have questions please leave a comment on the linked blog post so that the TechNet Blogs platform team can reply to you directly.

J.C. Hornbeck | System Center Knowledge Engineer

Troubleshooting the PXE Service Point and WDS in Configuration Manager 2007

J.C. Hornbeck — Wed, 05 Jan 2011 07:17:49 GMT

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

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
https://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
https://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
https://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
https://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 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
\Program Files\Microsoft Configuration Manger

64bit servers
\Program Files (x86)\Microsoft Configuration Manger\Logs

32bit or 64bit servers
\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.

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
https://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 "\\\SMSPXEIMAGES$" DP and then choose "Delete" (where 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 "\\\SMSPXEIMAGES$" DP and then choose "Delete" (where 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 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
\Program Files\Microsoft Configuration Manger
64bit servers
\Program Files (x86)\Microsoft Configuration Manger\Logs
32bit or 64bit servers
\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: \RemoteInstall
Share Name: REMINST

or

Windows Server 2003
You are sharing :\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
https://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
https://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
\Program Files\SMS_CCM\Log
or
%systemroot%\System32\CCM\Logs (usually C:\Windows\System32\CCM\Logs)

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

32bit or 64bit servers
\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= > Received DHCP Request smspxe
Executing LookupDevice(, 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= > 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= New client request. RequestID=. 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

A tool to verify that your AMT certificates are properly configured in ConfigMgr 2007

J.C. Hornbeck — Thu, 16 Dec 2010 08:02:28 GMT

This is an oldie but a goodie that I thought was worth a mention here. We originally published this last year but if you haven't seen or heard about it then it's worth a quick look.

=====

Microsoft's own Steve Rachui recently posted a great article on his blog about a tool he wrote that will verify that your provisioning and AMT client certificates in System Center Configuration Manager 2007 are properly installed and configured. Configuring certificates can be tricky so this should be a great tool to use if you’re troubleshooting an issue you suspect is cert related or if you’re simply setting it up for the first time. To learn more and to download the tool visit:

Tool to verify AMT certificates

Enjoy!

J.C. Hornbeck | System Center Knowledge Engineer

Need personalized help implementing a Microsoft product or solution? Our new ProAdvisory service may be for you

J.C. Hornbeck — Thu, 01 Jul 2010 06:56:18 GMT

I know this isn’t necessarily specific to OOB issues but I wanted to let you know of a new support offering that we're rolling out.

I am sure many of you have contacted Microsoft for support in the past and are aware of our various support offerings. We have Consumer support, Professional support and various levels of Premier and Alliance Support. Premier level support is based on hourly contracts, but is most likely not economically feasible for smaller businesses, which is where Professional level support comes in. Pro support as we call it has a set cost per incident, and the problem is worked until resolution for that one price.

However, all of this applies to what we call break-fix issues.

If a customer does not have something that is broken that needs fixing, but instead wants a walkthrough or assistance in getting something set up, we call that Advisory Services. For Premier customers, this is really not a big deal, as they already have hourly contracts and whether an hour is spent on break-fix or advisory is really only important on the bookkeeping end. However, for a small company or individual who uses Professional pay-per-incident support, there was really no good avenue for them to obtain advisory services.

That is where Pro Advisory Support comes in. We now offer advisory services on an hourly basis without having to have a Premier contract and working through Microsoft Consulting Services. The service is still in pilot, and only covers certain specific scenarios, but more are being added all the time. Each group has their own supported scenarios, and there are too many to list here, but this is a small sampling of what my group has to offer at this point:

· Monitoring agents in an untrusted domain or workgroup using Operations Manager 2007

This Advisory offering assists customers in deploying agents in untrusted domains or workgroups and configuring Operations Manager 2007 so that those agents can be successfully monitored.

· Installing System Center Data Protection Manager 2007

Assist customers with the initial installation of a Data Protection Manager 2007 Server, including requirement evaluation, installation of all prerequisites and both local and remote installations of SQL Server.

There are of course more than just these, dozens in fact, and more are being added as the documentation is completed. Keep in mind also that this is still just the pilot; when the service goes into full production we will have a great many more supported scenarios that you can get our assistance with.

You can get more information on the various scenarios that are available at the Pro Advisory web page:

https://support.microsoft.com/default.aspx?pr=advisoryservice

J.C. Hornbeck | System Center Knowledge Engineer

The Intel Core vPro Processor Management Pack for System Center Service Manager 2010 is now available

J.C. Hornbeck — Mon, 14 Jun 2010 06:23:48 GMT

The Intel Core vPro processor Management Pack for System Center Service Manager 2010 is used to provide end users of System Center Service Manager access to KVM Remote Control, IDE-Redirection and Power Control on clients enabled by Intel Core vPro processor. KVM Remote Control provides IT Professionals remote keyboard, video, mouse control of a client that is Intel Core vPro processor enabled. IDE-Redirection provides IT Professionals the ability to remote boot a client off a boot ISO image. Remote Power control allows IT Professionals to remotely and securely power up, power down, and perform power restart of the client independent of the operating system state.

For more information and to download the Management Pack visit this site.

J.C. Hornbeck | System Center Knowledge Engineer