Today I ran into an issue where the Build And Capture hung on Downloading update 1. Some googling lead to a known issue in ConfigMGR 2007 SP2 and there is a patch to solve the issue.
http://support.microsoft.com/kb/2509007
Once I installed the patch Software updates were downloaded and installed to the capture computer. This issue seems to affect only Windows 7 captures and with software update packages containing more than 80 patches.
First time I ran in to this problem was in my new virtual test environment. The management point failed to install and MPSetup.log was reporting the WebDav settings were not correct. Looking at them in IIS Manager everything looked just like it should, everything was setup according to the prerequisite document on Technet.
I had to find the problem somewhere else, and I did. Apparently the settings in the GUI didn’t get written to Webdav_schema.xml, and someone was kind enough to document how to change them, so here is the link for future reference.
Every now and then I get the question about setting up your DHCP server for SCCM when the DHCP server doesn’t reside on the same host as the SCCM/WDS server.
So to get this working you need to set option 66 and option 67 in your DHCP server.
The options should be set to as following:
Option 66 (boot server host name): IP of your server, ex 10.0.0.1
Option 67 (bootfile name): SMSBoot\boot.sdi
There are many guides out there on this topic, but most don’t need or want to understand the inner workings of DHCP, they just want the filenames. So there you go.
Previously I used the SUP to deploy clients in our SCCM environment. This was a really easy way to deploy but sadly I had issues with patch-management. The group policy setting for WSUS kept interfering with ConfigMGR client so I had to look for a another way to deploy the client. After some discussion on Microsoft’s Technet Forums Kent Agerlund pointed me to a script written by Jason Sandys. This script really does the job and it’s well documented.
Usually when I install bare metal systems I have to wait over an hour for SCCM:s PXE to work on the newly imported computer. Before the Windows deployment services cache has expired that is. And the standard setting for that i 3600 seconds.
Sometimes you really don’t have the time to wait for the hour to pass by. I’ve found two ways to speed this up, if you know something I don’t please inform me in the comments.
This first one is NOT recommended in production environments. If however you use a test environment this is a nice way to speed up the PXE service once and for all.
On the server running PXE and Windows Deployment Services (WDS) open regedit and add the following key
HKLM\Software\Microsoft\SMS\PXE\CacheExpire
The type should be DWORD and the Value 300 for 5 minutes in decimal. Without this key the standard cache time is 3600 seconds as mentioned above.
This way is not in any way permanent. And it’s really easy when you need to get an install going quickly.
Just open services on the server running WDS and PXE service point. Find Windows Deployment Services and restart the service. Once restarted the cache is cleared and the bare metal system should go to PXE boot immediately instead of abortpxe.
Hope you found this useful and don’t hesitate to comment if you did.