Hyper-V host - slow internet browsing

After setting up Hyper-V on Windows 8 I noticed that when my Domain Controller VM was turned on(hosting AD, DHCP and DNS) my host PC would take a long time to surf the internet.

I did a speed test and, after making the initial connection, saw that my download/upload speeds were normal I realized that it must be because I was hitting the DNS of my "Internal" DNS host on the VM.

Quick fix -
Open your network connections and hit the "alt" button.  Open Advanced - Advanced settings like so:

Then move your External Virtual Switch adapter connection to the top of the priority list like so:

This should restore your host Internet surfing abilities to normal.

Bitlocker recovery key didn't get uploaded to Active Directory

For some reason a laptop did not upload it's encryption key to Active Directory after bitlocker was enabled. I can only assume that it had lost network connectivity somehow.

So I needed to find a way to get the key into Active Directory manually after bitlocker was enabled and most of my google searches were of no help.

This is what I have come up with -
Start with a cmd prompt (ran as an administrator)
Enter the following command: manage-bde -protectors -adbackup C: -id {recoveryGUID}


You might be asking yourself what is the recoveryGUID???
The volume GUID can be found by executing the following:

1. Right click the volume (ex. C: drive) that is bitlocker'ed and choose Manage BitLocker
2. Choose save or print recovery key again
3. Choose save to file
4. We are looking for the "Full recovery key identification".  That is the GUID of the volume that you selected and is also the "id" used with the manage-bde command above.  Make sure you include the brackets with the ID

That should be it, double check in AD to make sure that the information for the recovery key has been populated in the computer object.

Accidentally deleted "All Systems" Collection

*somehow* the All Systems collection had gotten deleted.  I didn't really think anything of it until our HelpDesk system was unable to use it's Asset Inventory function because it was polling the SMS00001 collection.

With some help from Chris Nackers blog I found this vb script which restored the collection with the appropriate collection ID -

'###Begin Code

strSMSServer = "ENTER SERVERNAME HERE" 
strParentCollID = "COLLROOT" 
'This example creates the collection in the collection root. 
'Replace COLLROOT with the CollectionID of an existing collection to make the new collection a child.

strCollectionName = "All Systems" 
strCollectionComment = "This is the All Systems Collection." 
Set objLoc = CreateObject("WbemScripting.SWbemLocator") 
Set objSMS = objloc.ConnectServer(strSMSServer, "root\sms") 
Set Results = objSMS.ExecQuery ("SELECT * From SMS_ProviderLocation WHERE ProviderForLocalSite = true")

For each Loc in Results 
If Loc.ProviderForLocalSite = True Then 
  Set objSMS = objLoc.ConnectServer(Loc.Machine, "root\sms\site_" & Loc.SiteCode) 
End if 
Next

Set newCollection = objSMS.Get("SMS_Collection").SpawnInstance_()

'Create new "All Systems" collection 
newCollection.Name = "All Systems" 
newCollection.OwnedByThisSite = True 
newCollection.Comment = strCollectionComment 
newCollection.CollectionID = "SMS00001" 
path = newCollection.Put_

'Set the Relationship 
Set newCollectionRelation = objSMS.Get("SMS_CollectToSubCollect").SpawnInstance_() 
newCollectionRelation.parentCollectionID = strParentCollID 
newCollectionRelation.subCollectionID = ("SMS00001") 
newCollectionRelation.Put_

'###End Code

Then all I had to do was add my customized query, that removes discovered apple devices, into the collection and do an update/refresh and presto (You could remove the "where" part of the statement to get it back to original) -

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client
from SMS_R_System
where SMS_R_System.Name not like "%AD"
and  SMS_R_System.Name not like "%AL"

Windows to Go for Windows 8 or Windows 8 Server (boot from USB)

I wanted to play around with Hyper-V on my laptop but didn't want to wipe Windows 7 to do it and I wasn't about to dual-boot.

Enter a cool new feature from the windows 8 family - "Windows to Go" .  Windows to Go allows you to install the Windows 8 family onto, that's right not from, a USB stick.

This process is the same for either Windows 8 (client) or Windows 8 Server

Tools used:

• Most others say that you have to download Windows AIK (1.8gb) just to make use of imagex.exe but I have spoken about gimagex.exe before.  It's just a GUI wrapper for imagex and works well if you don't really like to memorize a bunch of command lines to image systems and it's FREE!
• Either Windows 8 Consumer Edition ISO or Windows 8 Beta
• A tool like WinRar to extract the files from the ISO
• diskpart.exe

Hardware Required:

• At least a 16Gb usb thumb drive.  You are going to want to purchase a usb 3.0 drive if you have the slots available as this is booting windows from the USB key.

Steps:

1. Open command prompt and enter the following commands
1. List Disk - This will show you a list of the physical disks that you have plugged into your computer.  Make note of the number that is your USB key
2. Sel Disk 1 - where 1 is your USB stick
3. Clean - wipes the drive out
4. Create Partition Primary
5. format fs=ntfs quick label=Win2Go
6. active
7. assign
8. exit
2. Extract the Windows 8 ISO to c:\extracted\win8 (or wherever you are comfortable with)
3. Open gimagex.exe
4. Select the Apply tab at the top
5. Select the install.wim file from the extracted ISO - ie. c:\extracted\win8\sources\install.wim as the Source
6. Select the drive letter of your freshly formatted USB key as the Destination
7. Click Apply and wait :) 
1. 
   
8. Once gimagex Apply reaches 100% open a command prompt and enter the following command:
1. bcdboot f:\windows /s f:  - where f: is your usb key

That's it, your done!  Boot your computer off of your usb key and let setup complete.

Setting Local Admin account to not expire

So I was using this command - 

net user username password /expires:never /passwordchg:no /comment:"Desktop Support" /add

- to create the local administrator account during OSD but the password was still set to expire.

I guess I misunderstood the /expires:never switch.  This sets the account to never expire not the password.

So in addition to the aforementioned net user command I added a wmic command that sets the password to never expire:

wmic path Win32_UserAccount WHERE Name="username" set PasswordExpires=False

Running SCCM Console as another user

As a personal best practice I log into my main workstation with a user ID that does not have access to anything but my exchange mailbox and my personal network drive.  I had grown tired of shift right clicking to run as another user so I looked up how to always launch a shortcut as a different user.

What you would typically do is put c:\windows\system32\runas.exe /user:domain\user /savecreds before the link to the exe.  Since the SCCM admin console is an mmc snap-in it looks a little different.

This is what I ended up with - C:\Windows\System32\runas.exe /user:domain\user /savecreds "mmc \"C:\Program Files (x86)\Microsoft Configuration Manager Console\AdminUI\bin\adminconsole.msc""

Yes that extra floating \ is necessary.

gimagex - Error: Unable to mount image ???

I was trying to mount a wim image using gimagex and was getting this error - Error: Unable to mount image ???

I did some digging and found the following -

1. Make sure GImageX is closed. Open Regedit.
2. Navigate to "HKLM\Software\WIMMount\Mounted Images"
3. You should see a subkey with a long name like "374cf018-f245-442d-9544-d6a2092607e0". Delete this key. (Don't worry about deleting this key, it should have been removed anyhow)
4. Close Windows Explorer and reopen it. Delete the folder you used as your mount point (eg. "c:\mount"), then re-create it.
5. Restart GImageX and the image should open correctly again.

PXE Cache timeout

I had an issue with a laptop that was loaded using PXE/OSD and then needed to be reloaded half way through the process.  When I booted the laptop into PXE the second time I was receiving the error "No task sequence found, booting into the hard drive".

I was able to get the machine to boot back into PXE by restarting WDS but then it happened again.

I scratched my head for a bit and then hit google.

Apparently the default setting concerning PXE advertisements is to cache for 60 minutes and then expire.

With SCCM SP2 you can set the cache expiration in the registry:

• On an x86 server -
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\PXE
• On an x64 server -
• HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\SMS\PXE

Create (or modify) the DWORD value CacheExpire in seconds.  The default is 0 and that would set it to 60 minutes.  I chose 300 for 5 minutes.

WDS service fails to start

WDS (Windows Deployment Service) service had failed to start.  I had PXE boot working fine to kick off my Windows 7 deployments for about 2 months, I made a change to my boot image (to add trace32.exe for troubleshooting purposes) and then PC's were no longer able to PXE boot.

I tried a few things from links that I found on the internet but none of them were working.  I got desperate and removed the WDS role from my 2008 R2 SCCM server; rebooted; and reinstalled but that didn't change anything.

I stumbled across a link on Technet and thought... I will give this a shot - And it worked!

Specifically, I followed the section titled - "Reinstalling WDS and the PXE Service Point"

Troubleshooting the PXE Service Point and WDS in Configuration Manager 2007

This is a general guide on properly setting up and troubleshooting the 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: The specified file was not found.
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-M0F Exiting PXE RomPXE-E78: Could not locate boot server

However the error messages can vary depending on the PXE implementation on the client PC.

Another commons symptom is that the Windows Deployment Services Server (WDS) service will not start.

This guide is broken down to the following sections:

• Reviewing KB Articles of Known Issues
• Setting Up IP Helpers
• Co-hosting DHCP and WDS On The Same Server
• 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 to properly configure a working and operational ConfigMgr 2007 PXE Service Point. Refer to the appropriate sections as needed.

Reviewing KB Articles of Known Issues

Before beginning any troubleshooting on the PXE Service Point, review the following KB articles to see if any of the issues described in the following KB articles could be causing problems:

No Assigned Task Sequence when initiating deployments caused by duplicate SMBIOS GUIDs (System UUIDs) in System Center Configuration Manager 2007http://support.microsoft.com/kb/2591483

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 deploymenthttp://support.microsoft.com/kb/969113
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
The Windows Deployment Service cannot be started on a computer that has more than 20 logical processors and that is running Windows Server 2008 R2 or Windows Server 2008
http://support.microsoft.com/kb/2121690

The DNS Server service binds to all ports in the Windows Deployment Services port range on a server that is running Windows Server 2008 R2 or Windows Server 2008
http://support.microsoft.com/kb/977512

The Windows Deployment Service stops responding when you use a PXE service point on a computer that is running a System Center Configuration Manager 2007 SP1 or SP2 site server
http://support.microsoft.com/kb/976073

PXE service point role does not work if a DHCP server uses DHCP option 43 in a System Center Configuration Manager 2007 SP2 environment
http://support.microsoft.com/kb/2578865

Error message when Windows Deployment Service clients cannot obtain the boot image from a Windows Server 2008 R2-based WDS server: "PXE-E78: Could not locate boot server"
http://support.microsoft.com/kb/979720

Setting Up IP Helpers

If the DHCP server, the client PC, and the ConfigMgr 2007 server running Windows Deployment Services (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 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 TechNet article:

Configuring Your Router to Forward Broadcastshttp://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 same subnet or vlan as the client PC, they will not see or hear the PXE request broadcast from the client PC. The servers will therefore 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 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 below section "Co-hosting DHCP and WDS On The Same Server".

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 most cases it proceeds further down an incorrect path and ends up failing.

Co-hosting DHCP and WDS On The Same Server

One consideration when setting up a ConfigMgr PXE Service Point is if WDS and DHCP are going to reside on the same or different servers. Best practice is to host the WDS and DHCP services on two separate servers, but there should be no issues in hosting both services on one server. If WDS and DHCP are being hosted on different servers, no further action is needed so please proceed to the section "How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point".

However when WDS and DHCP are co-hosted on the same server, WDS needs a special configuration to listen on a specific port. This configuration is outlined in the following TechNet article under the section Windows Deployment Services (WDS) and DHCP --> PXE Service Point Configuration Item --> DHCP considerations.

Planning for PXE Initiated Operating System Deployments http://technet.microsoft.com/en-us/library/bb680753.aspx

According to the above article, the following two actions need to take place when WDS and DHCP are co-hosted on the same server:

1. The value UseDHCPPorts needs to be set to 0 on the registry key:
   
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE
   
2. The WDS command:
   
   WDSUTIL /Set-Server /UseDHCPPorts:No /DHCPOption60:Yes
   needs to be run on the server.

The one problem with the above recommendations is that in order to run the WDSUTIL command, WDS has to be first configured. This goes against the best practice of NOT configuring WDS when installing a ConfigMgr PXE Service Point. However, the two options being specified via the WDSUTILcommand, UseDHCPPorts and DHCPOption60, can be configured using alternate methods that do not require the WDSUTIL command, and therefore do not require WDS to be configured:

1. The UseDHCPPorts WDSUTIL switch is actually the equivalent of setting the registry key value:
   
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE!UseDHCPPorts
   to 0 as described in #1 above. Therefore using the UseDHCPPorts WDSUTIL switch is duplicated and not needed as long as the registry key has been manually set as described in the above above TechNet article. Please note that if WDS has not been installed, this registry key may not be present and therefore cannot be set until after WDS has been installed. Step 7 under the section "How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point" explains how to set this registry key.
   
2. The WDSUTIL DHCPOption60 switch is actually a setting that sets an option on the DHCP service, not the WDS service. Therefore instead of using WDSUTIL to set a DHCP option, an equivalent DHCP command can be used to set the same option. This approach allows the required DHCP setting to be set without configuring WDS and before WDS is even installed. This approach can be achieved via the netsh command as described in the following MSDN article:
   
   Configuring DHCP for Remote Boot Services http://msdn.microsoft.com/en-us/library/dd128762(WinEmbedded.51).aspx
   To summarize and shorten the netsh commands described in the above article, close any DHCP consoles that are open and then run following two commands from an elevated command prompt:
   
   netsh dhcp server \\<DHCP_server_machine_name> add optiondef 60 PXEClient String 0 comment=PXE support
   netsh dhcp server \\<DHCP_server_machine_name> set optionvalue 60 STRING PXEClient
   where <DHCP_server_machine_name> is the name of the DHCP/WDS server (without the brackets <>).
   
   The above two commands set up and enable DHCP Option 60 on a DHCP server. Normally DHCP Option 60 is not set up by default on a DHCP server. The first command sets up DHCP Option 60 but does not actually enable it. The second command actually enables DHCP Option 60.
   
   If after running the above two commands an option named "Unknown" is displayed in the DHCP console instead of "060 PXE Client", reboot the server. After the reboot the option should display correctly. This usually happens if a DHCP console was open when the above two commands were run.

If DHCP is ever moved to another server and removed from the server hosting WDS, the above actions need to be reversed. To reverse the above actions take the following two actions on the WDS server:

1. Set the value of the following registry key value:
   
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE!UseDHCPPorts
   to 1. This can be done by running the following command from an elevated command prompt:
   REG ADD "HKLM\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSPXE" /v UseDHCPPorts /t REG_DWORD /d 1 /f
   
2. From an elevated command prompt, run the following two commands to remove DHCP Option 60:
   
   netsh dhcp server \\<DHCP_server_machine_name> delete optionvalue 60 netsh dhcp server \\<DHCP_server_machine_name> delete optiondef 60 PXEClient 
   where <DHCP_server_machine_name> is the name of the DHCP/WDS server (without the brackets <>).
   
   In the above two commands, the first command disables DHCP Option 60, while the second one removes DHCP Option 60 completely. For this reason only the first command is truly needed. However if DHCP Option 60 needs to be removed completely, make sure to run BOTH commands in the above order. Only running the second command will leave an option named "Unknown" on the DHCP server.

How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point

The following section lists the steps to ensure that WDS and the PXE Service Point are installed properly on a server where WDS and the PXE Service Point have never been installed or where WDS and the PXE Service Point have been properly uninstalled based on the section "Reinstalling WDS And The PXE Service Point". If WDS and/or the PXE Service Point is currently installed OR has been previously installed on the server, please follow the instructions under the section "Reinstalling WDS And The PXE Service Point" first:

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. If WDS and DHCP are being co-hosted on the same server, please make sure to go over and take the actions in the section "Co-hosting DHCP and WDS On The Same Server". Please note that the registry key value that needs to be configured as described in the section "Co-hosting DHCP and WDS On The Same Server" will not be available until after WDS is finished installing in Step 5. Instructions on how to set this registry are in Step 7.
   
3. 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 theDeployment Server and Transport Server are installed.
     
4. If prompted to reboot after WDS has finished installing, reboot the server.
   
5. Once the server has restarted, DO NOT try to manually configure or start the WDS service.
   
6. If WDS and DHCP are on different servers, skip Step 7 and proceed to Step 8.
   
7. If WDS and DHCP are being co-hosted on the same server, run the following command from an elevated command prompt to set the required registry key when WDS and DHCP are co-hosted on the same server:
   
   REG ADD "HKLM\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSPXE" /v UseDHCPPorts /t REG_DWORD /d 0 /f
   In reinstall scenarios of WDS, make sure to rerun the above command as any uninstall of WDS may have reset the above registry key.
   
   If WDS and DHCP are on separate servers, DO NOT run the above command.
   
8. In the ConfigMgr 2007 Admin Console, navigate to
   
   "Site Management" --> <Site_Code> --> "Site Settings" --> "Site Systems"
   
   where <Site_Code> is the site code where the PXE Service Point server will reside.
   
9. 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".
   
10. 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.
    
11. In the "System Role Selection" of the wizard, check "PXE service point" and then click on the "Next >" button.
    
12. Review the "PXE Service Point Configuration" dialog windows and then click on the "Yes" button.
    
13. In the "PXE - General" window, configure the appropriate options as desired and then click on the "Next >" button.
    
    IMPORTANT! If ConfigMgr 2007 R2 or R3 is installed at the site and the option "Enable unknown computer support" does not appear on this page, DO NOT continue. This may be an indication that R2/R3 is not properly installed at the site. To check the status of R2/R3 being installed, in the ConfigMgr 2007 console navigate to "Site Database" --> "Site Management", right click on the site code, and then choose "Properties". The status will be listed under the "General" tab next to the field "R2 Installed"/"R3 Installed".
    
    If R2/R3 is not properly installed, this could cause the PXE Service Point not to answer PXE requests due to Unknown computer support not being set up properly. This can happen regardless if Unknown computer support is desired or not.
    
    To resolve the problem, cancel out of the "New Site Role Wizard", reinstall R2/R3 on the site server, and then start over at Step 8. If the site server is a child server, R2/R3 may need to be reinstalled on both the parent and child site servers.
    
14. In the "PXE - Database" window, change any options as needed. In most cases, settings should be left at their default in this window. Click on the "Next >" button.
    
15. Click on the "Next >" button and then on the "Close" button.
    
16. 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
17. Once the log directory has been located in Step 16, 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.
18. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Operating System Deployment" --> "Boot Images".
19. 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.
20. 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.
21. 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 Serverservice 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 (usually the same drive where ConfigMgr is installed).
22. 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.
23. 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 theWindows Deployment Services console is NOT necessary and should not be performed.
   
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 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. If WDS and the PXE Service Point have already been uninstalled, read through the below steps and actions to ensure that ALL of the steps have been followed to properly uninstall both components:

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. TheRemoteInstallfolder 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:
   
   1. 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.
      
   2. 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.
      
   3. 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"
        
   4. 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).
      
   5. 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.
      
   6. Once all of the packages have been deleted, check theRemoteInstall\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 uninstalled, open the Servicesconsole. 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). A reboot of the server may also help resolve the issue.
   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:
    
• If using Windows Server 2003, WDS is uninstalled via the Add/Remove Windows Components in the Add/Remove Control Panel.
  
• 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 uninstalled.
    
12. Once the server reboot completes and the server comes back up, locate the RemoteInstallfolder 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 foldersBootImages 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 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 appliedhttp://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 deploymenthttp://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.
   
   Please note that each time WDS and the PXE Service Point is reinstalled the value of this key is reset back to 0.

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.logwith SMS Trace/Trace32.exe. The SMSPXE.loglog 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 will provide additional information in the log and could assist in troubleshooting why a PC is not PXE booting. To enable debug logging on the PXE Service Point server for the SMSPXE.log , create the following registry key on the server. A value does not need to be created under the registry key:
   
   32bit Windows Server HKLM\SOFTWARE\Microsoft\CCM\Logging\DebugLogging 
   64bit Windows Server HKLM\SOFTWARE\Wow6432Node\Microsoft\CCM\Logging\DebugLogging 
   Once the registry key has been created, 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. smspxe
   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" is the server doing a self check on itself to ensure the PXE Service Point is up and responding. They can be ignored.
   
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 theRemoteInstall 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 anOperating System Image Package or an Operating System Install Package under theSMSPXEIMAGES$ 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 x86folders 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".