Shawn Robinson's technical support journal

SCCM: PXE-E53: No boot filename received

2012-02-16T12:38:00.000-08:00

Another one that was unfortunate enough to not be on a virtual site. The report from operations was that the PXE clients weren't receiving boot files. I logged into the server and checked for the presence of the boot files in the RemoteInstall folder, and everything was in SMSBoot in both the x86 and x64 folders. Both of the boot wim files were also present, so it looked good from a distribution point standpoint. I took a look in the registry and noticed the WDSTFTP key was missing:

If TFTP isn't working, it would explain why the clients aren't receiving boot files. I restarted the Windows Deployment Services service and saw this error in the event log:

Searching on this one brought me to the blog at http://blogs.technet.com/b/stufox/archive/2008/07/31/configuration-manager-pxe-service-point-errors.aspx where the resolution was to reinitialize WDS with the wdsutil /initialize-server /REMINST:"D:\remoteinstall" command. (I changed it to E:\remoteinstall for our environment.)

Just need to get the site to test now...

SCCM - Another imaging problem!

2012-02-10T12:20:00.000-08:00

Here's a new one - luckily this one was easy to resolve.

SMS Site Component Manager detected that site system "<ComputerName>" is running the Microsoft Windows NT Server operating system version 5.2, which is not a supported operating system for this version of SMS

Here's a case where I was able to search on this and find a resolution fairly quickly. What happened is someone installed or modified a Windows 2003 distribution and checked the box to "Enable multicast" - which isn't supported until Windows 2008.

Once this was turned off, everything worked great.

SCCM - Stuck processing a package

2012-02-09T05:18:00.001-08:00

One of our sites appears to be "stuck" processing a package. In the status message viewer of the SMS_DISTRIBUTION_MANAGER component at this site, we keep getting message 2300 and 2301 repeating about once a minute for one package.

SMS_DISTRIBUTION_MANAGER messages 2300 and 2301

The first thing about this is that the "package ID" is a misnomer, since if I tried to search for package A1100124 in this case, it wouldn't appear to exist. This should actually say task ID since this is a task sequence. The operations staff not being able to find the package is the reason this was escalated to me, but since I'm working on it already I'll just resolve it.

When I look at the distmgr.log file on the site server, I get a little bit more information:

Failed to insert SMS Program ID 41821 because the referenced program A1100125-* is not present in the PkgPrograms table. Will try later.

For this one, I'm going to run a "preinst.exe /syncchild TNW" command from the central server. This appears to have resolved the issue for other people. If it doesn't fix it here, we'll have to detach and rejoin the site.

SCCM - Unable to image

2012-02-09T05:17:00.001-08:00

Another SCCM PXE problem for me to work on this morning. SCCM wasn't even supposed to be my focus, but I'm the only one with any SCCM experience so I'm filling in a gap until they get someone to manage this product full time. Unfortunately, this site hasn't been virtualized yet, so I won't be able to view any PXE boot screens to help my troubleshooting. The first thing I'll do is give the site a once over and see if there are any glaring problems.

The first thing I noticed was all these extra folders in the RemoteInstall directory. That's usually not a good sign that WDS and the PXE service point were installed correctly. I will follow the instructions in the Technet blog to properly reinstall these services.

http://blogs.technet.com/b/system_center_configuration_manager_operating_system_deployment_support_blog/archive/2011/10/14/troubleshooting-the-pxe-service-point-and-wds-in-configuration-manager-2007.aspx

I was able to get it reinstalled and those extra folders didn't show up, but the boot images are taking a long time to copy. I'll check on it later.

UPDATE:

The PXE service point was working fine after that, but the imaging process was still not working. The machine they were trying to reimage had an encrypted drive. I'll write up how this is dealt with in a later post.

SCCM - PXE-T04 Illegal operation error

2012-02-09T05:16:00.001-08:00

In my previous post I mentioned the missing MaximumBlockSize value being one of the things that clued me in that the setup wasn't completed successfully. In that case though, the missing TFTP root folder entry in the registry was the bigger issue that called for a remove and reinstall of WDS and PXE service point. In this post I'll go over what we see here when MaximumBlockSize isn't set correctly. This one was a pain to troubleshoot the first time because there wasn't much of use on this error when searching Google, and coming into this environment new without knowing all the history yet made it take longer than it should. If you're reading this post and are experiencing PXE-T04, this may not pertain to you but it's something you could check.

I loaded up a blank VM so I could get a look at what the field office is seeing when they try to reimage. Set it up to reimage, powered it on and this is what I got:

So what this turned out to be is a MTU setting in Windows being less than what WDSTFTP is expecting. WDSTFTP by default expects Windows to be working with a MTU of 1500, but let me take a look at what this server's MTU is set to be right now. To do that I run the following command on my PXE service point:

netsh interface ipv4 show subinterfaces

The MTU on Local Area Connection is set to 1320, and without setting the MaximumBlockSize in WDSTFTP to 1292 or less (to account for the 20 byte IPv4 header and 8 byte UDP header) I'm going to get the PXE-T04 error. So how here's how to fix this:

First off, if you're running Windows 2008 R2 on your PXE service point, get this hotfix from Microsoft - http://support.microsoft.com/kb/2517669.

Next, open the registry and navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSTFTP

and create a new DWORD value named MaximumBlockSize and set it to an appropriate value for your MTU. In our case, we used a value of 1280 (hex 500), but during testing of this originally I did find I could set this to 1292 and it would work. 1293 is when it started to break because of the 28 byte overhead. The reason why 1280 was decided on escapes me at the moment. Here's the registry key now in place:

And here's the client on my next test:

Everything's good now!

SCCM - ProxyDHCP service did not reply to request on port 4011

2012-02-09T05:14:00.001-08:00

So this issue seemed like it would be a simple fix since this has been resolved several times over on the web. One possible issue I found was that if both the x86 and x64 boot images are not present on the distribution point that this can happen. Operations already tried reinstalling WDS/SCCM PXE and pushed everything again before this became my issue.

Since I'm half a country away from where this is happening, and the PXE errors occur prior to Windows being loaded, I'll use vSphere to access an empty virtual machine at that location that will do nothing but attempt to find an OS via PXE.

So the first thing I want to do is take a look at the DHCP server that shows up in this boot sequence. I opened up the Scope options and see that the 060 PXEClient is configured, which tells me this machine is functioning as both the distribution point and DHCP server for this office. By the way - the clients in this office are on the same subnet as the DHCP server, so the other PXE related scope options are not required in this environment.

Another requirement when setting up a PXE service point on a DHCP server is to configure the registry setting that tells PXE to not use the DHCP ports, so I'll check that now. This value is found in HKLM\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSPXE if you need to find it yourself, and you want to ensure the UseDhcpPorts value is 0 (which it is in my case).

So let me do a sanity check and make sure both boot images are in fact present on this distribution point. I was told this was done already, but the "trust but verify" motto has served me well in the past. I'll take a look in the registry to see the location that WDSTFTP is configured to use to serve boot images.

Well that doesn't look right - the RootFolder value is missing. The MaximumBlockSize value is missing too, which is important for our environment for another reason and I might elaborate more on that in a future post. This tells me that something wasn't configured correctly when this was installed. I'm going to use the Technet blog and do one more reinstall of this, paying attention to the parts where it says make sure the logs state everything is finished before moving on.

http://blogs.technet.com/b/configurationmgr/archive/2011/01/05/troubleshooting-the-pxe-service-point-and-wds-in-configuration-manager-2007.aspx

So after I reinstalled WDS/PXE I opened up the registry and check for my missing values:

This looks better! Now I'm just waiting for my boot images (both x86 and x64) to replicate back to this DP and I can test.

Still getting that error, so more investigation is needed. Let me make sure my boot images are present.

Both images are there (in the interest of preserving some bandwidth, I'll omit the screenshots showing the .wim files in the folders, but A1100002 is our x64 boot image and A11000B9 is our x86 boot image. Let me check for the actual boot files...

Nothing is there, so there must be a problem extracting those files out of the .wims. I need to look through some log files now.

Log Name:      Application
Source:        WDSServer
Date:          2/9/2012 11:17:26 AM
Event ID:      772
Task Category: WDSServer
Level:         Error
Keywords:      Classic
User:          N/A
Computer:
Description:
An error occurred while trying to create the UDP endpoint for WDSPXE provider on interface 10.202.38.206:67. This can happen if the network interface was disabled or changed, or some other application is already using the port. The provider will not be able to receive requests on this interface.

Oops! I forgot to reset the UseDhcpPorts back to 0 after the reinstall so WDS didn't start. Once I corrected that, I restarted the WDS service. I go back into the boot file directory to see if it's still empty:

This looks better now. So once again I try to image my VM.

Looks like everything is working!

Why I created this blog

2012-02-09T05:11:00.000-08:00

This journal is as much for me as it is for anyone else who might happen to read it when trying to solve their own problems. I recently started a new job where I'm supporting a 20,000+ user environment over around 100 offices, and there never seems to be a day without a fire that needs to be put out somewhere. It's challenging because there are quirks to some of the designs here which aren't necessarily "best practice", but I've inherited them so I'm having to deal with them. On top of that, there's a major upgrade effort across the enterprise which is handled by a different team, (I'm part of a "design" team as opposed to the "implementation" team,) and every once in a while they might miss a step and I'll have to track it down. I'm sure many of you have noticed that when searching the Internet for solutions to problems, you might come across threads in message boards where someone has the exact same issue you're experiencing, but they never post what the resolution was in the end. My plan is to post from start to finish what's been going on so that won't be the case if you find my blog on your searches.

Thanks for reading!