In addition to my last post on this issue here, Windows 7 Service Pack 1 has brought with it only a minor change. The details in that post are still valid, with one minor exception.
In "Stage Two Prepare the WinPE Image" I referred to a hot fix package KB972831, which contained the WinPE module for 802.1x. This had to be added using DISM /add-package. Happily the Service Pack 1 AIK toolkit now contains the winpe-dot3svc.cab in the same location as the other three cabs (winpe-scripting.cab, winpe-wmi.cab, winpe-wds-tools.cab.)
This means that there is very little reconfiguration needed for introducing your SP1 image.
Tuesday 31 May 2011
SCCM and WDS
One of the most complained about problems on the SCCM technet message boards is when the PXE service point stops working. We have had this problem for some time now. The issue ranges from simply not starting after a reboot to not working at all after provisioning a new PXE service point. Our last PXE outage lasted about a month.
The problem is now that there are so many post on this issue, it is hard to find one with a workable solution. The first thing you should be aware of this blog from the Configuration Manager Support Team. This is the first place to go to when looking for solutions to your WDS and SCCM problems. As you will note, even they are constantly updating the information. The last update was on 6 January (or 1 June - depending how you read it) this year. The whole integration of SCCM and WDS is so complex, that even the people who created it are having a hard time.
And even after following the instructions in the above blog, you can still come up against a brick wall. For example: Simply uninstalling the SMS_PXE service point and the WDS server is not enough. You also need to delete the "remoteinstall" directory, or WDS will install and pick up the (probably wrong) settings when it is re-installed.
Another big issue is communications between the WDS server and the Database server. In the world of Windows Server 2008 R2, the firewall is switched on by default. Even with an SQL exception the WDS server can find itself blocked out of the Database. My solution there was to allow all traffic from the WDS server through to the SMS Database Server. My symptoms included the WDS services failing to load the SMS provider with 0x4005 error. As any persistent user of the Technet Forums knows, 0x4005 means 'access denied' in any application.
One of the best ways to figure out whether the issue is at the the WDS end or at the SCCM end, is to actually configure the WDS server as a WDS server. If you have already configured SCCM with a boot image and an OS image, it's really simple to do. After uninstalling and re-installing the WDS role, go ahead and configure the WDS server. Now before the server will start to server PXE, it needs a boot.wim and an install.wim. Having already configured the boot and OS images, you can simply pick them up from their source directories. Just pick up the boot.XXX0001A.wim files and drop them in a temporary directory on the WDS server. Rename the files boot.wim and install.wim. The fact that they are not configured for WDS use is neither here now there at this point. You just need to have both a boot and an install file in order for the WDS server to start servicing PXE requests. Using the WDS mmc console, add the boot file first, then add the install file. Now try to start the service and boot a client to PXE. If it works, your WDS installation is clean.
Following best practice, uninstall the WDS server as you did before, remembering to remove the remoteinstall directory, and then follow the instructions in the blog mentioned above. If you then have problems (even after setting a firewall exception for the WDS server on your SMS DB server) you are looking at a SCCM issue such as access by the WDS server's computer account to the database.
The problem is now that there are so many post on this issue, it is hard to find one with a workable solution. The first thing you should be aware of this blog from the Configuration Manager Support Team. This is the first place to go to when looking for solutions to your WDS and SCCM problems. As you will note, even they are constantly updating the information. The last update was on 6 January (or 1 June - depending how you read it) this year. The whole integration of SCCM and WDS is so complex, that even the people who created it are having a hard time.
And even after following the instructions in the above blog, you can still come up against a brick wall. For example: Simply uninstalling the SMS_PXE service point and the WDS server is not enough. You also need to delete the "remoteinstall" directory, or WDS will install and pick up the (probably wrong) settings when it is re-installed.
Another big issue is communications between the WDS server and the Database server. In the world of Windows Server 2008 R2, the firewall is switched on by default. Even with an SQL exception the WDS server can find itself blocked out of the Database. My solution there was to allow all traffic from the WDS server through to the SMS Database Server. My symptoms included the WDS services failing to load the SMS provider with 0x4005 error. As any persistent user of the Technet Forums knows, 0x4005 means 'access denied' in any application.
One of the best ways to figure out whether the issue is at the the WDS end or at the SCCM end, is to actually configure the WDS server as a WDS server. If you have already configured SCCM with a boot image and an OS image, it's really simple to do. After uninstalling and re-installing the WDS role, go ahead and configure the WDS server. Now before the server will start to server PXE, it needs a boot.wim and an install.wim. Having already configured the boot and OS images, you can simply pick them up from their source directories. Just pick up the boot.XXX0001A.wim files and drop them in a temporary directory on the WDS server. Rename the files boot.wim and install.wim. The fact that they are not configured for WDS use is neither here now there at this point. You just need to have both a boot and an install file in order for the WDS server to start servicing PXE requests. Using the WDS mmc console, add the boot file first, then add the install file. Now try to start the service and boot a client to PXE. If it works, your WDS installation is clean.
Following best practice, uninstall the WDS server as you did before, remembering to remove the remoteinstall directory, and then follow the instructions in the blog mentioned above. If you then have problems (even after setting a firewall exception for the WDS server on your SMS DB server) you are looking at a SCCM issue such as access by the WDS server's computer account to the database.
Subscribe to:
Posts (Atom)
