About Multicast, Unicast, Cluster IP and Dedicated IP in Windows NLB

Recently i did some testing with Windows Network Load Balancing (NLB) and i was faced with the question: What exactly is the difference between the two operation modes “unicast” and “multicast” and how does this thing with the dedicated IP address work? I found the post “Selecting the Unicast or Multicast Method of Distributing Incoming Requests“, which describes very well the unicast and multicast differences. In the following article i try summarizing this:

In unicast mode, the network adapter’s original (hardware) MAC address is overwritten with the multicast MAC address of the cluster.

In multicast mode, the network adapter’s original (hardware) MAC address is kept unchanged and an additional multicast MAC address is added.

How is the communication to the virtual cluster IP proceeding?

1. When a request is sent to the virtual cluster IP address, the ARP response returned from the cluster to the client contains either the unicast MAC address (“NLB MAC” in the figure), or the multicast MAC address (“MC MAC” in the figure) of the cluster, depending on the operation mode configured.

2. The client then continues the communication with the cluster via the returned MAC address. Depending on the MAC address type, the switch decides if the request is handled as multicast or unicast and distributes it to all cluster nodes, either using the spoofed unicast address or using the multicast address. The NLB algorithm is then responsible to manage, if a node responds to the request, or if the node drops it.

How NLB operates from the switch point of view is nicely described in the article “Catalyst Switches for Microsoft Network Load Balancing Configuration Example“. Read also “Identifying Ethernet Multicast” to understand, how a multicast MAC address differs from a unicast MAC address.

How is the communication to the dedicated IP proceeding?

When a request is sent to the dedicated IP address, the request is sent to the respective cluster node directly, bypassing any NLB algorithms. The ARP request from the client resolves the dedicated IP address with either the original hardware MAC address (“HW MAC” in the figure) or the virtual unicast MAC address of the cluster, depending on the operation mode used (see figure).

How is the NLB configuration reflected on the network adapter?

Enabling NLB for a network adapter results in the binding of the “Network Load Balancing” component to the selected NIC. The dedicated IP addresses configured in NLB is then set as the first IP address of the NIC, the cluster IP address is configured as the second IP address on the same NIC. When no dedicated IP address will be configured, the cluster IP will be the first and only IP.

About-Multicast-Unicast-Cluster-IP-and-Dedicated-IP-in-Windows-NLB

Advertisements
Posted in Windows Server | Leave a comment

Troubleshooting “AutoApplyDrivers” issues when deploying Windows 7 via SCCM 2012 R2

When deploying Windows 7 via SCCM 2007, everything works fine when using the “Apply Operating System Image” task with the following configuration:

Troubleshooting-AutoApplyDrivers_01

Using the same setup within an SCCM 2012 R2 environment, results in a failing task sequence at the task “Setup ConfigMgr Client” with the message “Exiting with code 0x80004005, Windows setup failed, code 31”.

The “setuperr.log” file created on the system drive (to be accessed via F8 console while still being in Windows PE) contains a message “AddDdriverPackageIntoDriverStore:Failed to install the driver package”, claiming a special inf file causing this issue. Disabling the affected driver in SCCM and starting the deployment again skips the problematic driver, but claims the same issue with the very next driver detected to be installed. At the end the task sequence is not able to complete successfully, until all matching drivers be disabled respectively the “AutoApplyDrivers” task has been disabled completely.

This blog, this Technet discussion and the Technet article which mentions:  The build and capture task sequence was updated to apply an operating system image instead of running Setup.exe for installation. You can still run Setup.exe for Windows 8 deployments by editing the task sequence in the task sequence editor.” pointed me to the right direction to workaround this issue. Obviously the deployment method using the unattended setup does not work with Windows 7 anymore, but works only with Windows 8.

So changing the “Apply Operating System Image” task to the following setting allows the task sequence to complete successfully in installing Windows 7 with all matching drivers from the SCCM database:

Troubleshooting-AutoApplyDrivers_02

Posted in System Center Configuration Manager | Leave a comment

Troubleshooting “The Managed Metadata Service or Connection is currently not available in SharePoint 2013”

When accessing the Managed Metadata Service Application from a Content Type Syndication Hub, the following error might occur when opening the Term Store Management Tool:

Troubleshooting_The-Managed-Metadataservice-or-Connection-is-currently-not-available_01

The error does not occur, when the Term Store Management Tool is opened from the central administration site.

The ULS log on the WFE server logs the following message:

Failed to get term store for proxy ‘Managed Metadata Service Application Proxy’. Exception: System.Security.SecurityException: Requested registry access is not allowed.

The MSDN blogs titled “SharePoint Error: The Managed Metadata Service or Connection is currently not available. The Application Pool or Managed Metadata Web Service may not have been started.” and “ The Managed Metadata Service or Connection is currently not available” discuss this issue also. Although this pushed me into the right direction, it did not solve the issue in my case.

Further investigations on this issue resulted in the finding, that the registry key HKLM\Software\Microsoft\office Server\15.0 did not have the right permissions. In fact, the permissions for the “WSS_Admin_WPG” and “WSS_WPG” were completely missing. This in contrast to the TecNet article titled “Account permissions and security settings in SharePoint 2013”, which states these permissions are needed.

Executing the following PowerShell command helped to solve the issue, adding all permissions needed:

Initialize-SPResourceSecurity

Troubleshooting_The-Managed-Metadataservice-or-Connection-is-currently-not-available_02

Posted in SharePoint | 2 Comments

Configure a KMS service to activate Windows 8 and Windows Server 2012

1. Install the update related to the KB “2691586

Note: This is required only, when the KMS will run on a Windows Server 2008/R2 machine, it is not required on Windows Server 2012. Note also, that Windows Server 2003 is not supported to act as a KMS for Windows 8/Server 2012 activation.

2. Install a new KMS key, execute:

slmgr /ipk [KMSKEY]

3. Activate the new KMS key, execute:

slmgr /ato

4. Restart the Software Protection Service, execute:

net stop sppsvc && net start sppsvc

5. Verify the result, execute:

slmgr /dlv

6. Create a DNS SRV record named “_VLMCS._tcp” using a port number of 1688 and referring to the FQDN of the KMS host.

Note: Only one Windows product key can be installed on a KMS host at a time. A KMS host key can activate multiple products, depending on the “key type”, like e.g. “VOLUME_KMS_2012_C”. Please refer to this technet article for an overview which KMS keys match to products they activate.

While only one Windows product key can be installed at a time, an Office product key can be added additionally to a Windows product key. To do so, the Microsoft Office 2010 KMS Host License Pack needs to be installed on the KMS host.

To verify the status of the office KMS key, execute:

slmgr /dlv bfe7a195-4f8f-4f0b-a622-cf13c7d16864

Posted in Windows Server | Leave a comment

Trigger/Push Software Installations remotely on SCCM Clients

Targeting software deployments in SCCM works by assigning advertisements/deployments to SCCM collections. SCCM collections can then be populated with target computers by using Active Directory groups containing the respective computers, which will then be added dynamicly to the collection by a SCCM query, after the Active Directory Security Group discovery has run on SCCM side. Then, with the next machine policy retrieval on the SCCM client, the client will recognize its membership in the collection and install the program which has been advertised/deployed to this collection.

This means in other words, the time delay between adding a comptuer to a software deployment group in Active Directory, till the software will be effectively installed on the target computer,  is as big as the sum of the three schedule intervals: The Active Directory Security Group Discovery, the Collection Membership Update and the Policy Retrieval on the client.

For an immediate execution,  a software installation can be triggered programmatically by using a temporay direct collection membership of a computer:

Directly add the target computer to the software distribution collection

$targetClientName = "<TARGETCLIENTNAME>";
$collectionName = "<COLLECTIONNAME>";
$objComputer = Get-WmiObject -query "SELECT ResourceID FROM SMS_R_SYSTEM WHERE NETBIOSNAME LIKE '%$targetClientName%'" -Namespace "ROOT\SMS\site_CO1";
$resourceID = $objComputer.ResourceID;

$searchFilter = "Name = '$softwareName'";
$objCollection = Get-WmiObject SMS_Collection -computer . -Namespace "ROOT\SMS\site_CO1" -filter $searchFilter;
$objCollectionRuleDirect = [WmiClass]"\\\\.\ROOT\SMS\site_CO1:SMS_CollectionRuleDirect";
$objCollectionRuleDirect.properties["ResourceID"].value = $resourceID;
$objCollectionRuleDirect.properties["ResourceClassName"].value = "SMS_R_System";
$objCollectionRuleDirect.properties["RuleName"].value = $targetClientName;
$collectionInParams = $objCollection.GetMethodParameters("AddMembershipRule");
$collectionInParams.collectionRule = $objCollectionRuleDirect;
$objCollection.InvokeMethod("AddMembershipRule", $collectionInParams, $Null);

Update the collection membership of the respective collection

$objCollection.RequestRefresh();

Remotely execute the appropriate client actions on the target computer

# //*** Connect to SCCM client WMI name space ***\\
$SCCMClient = [wmiclass] "\\$targetClientName\root\ccm:SMS_Client";

# //*** Show all available action methods (just as informational note) ***\\
# $SCCMClient | Get-Member;

# //*** Show all available Agent GUIDs (just as informational note) ***\\
# get-wmiobject CCM_Scheduler_ScheduledMessage -namespace root\ccm\policy\machine\actualconfig | select-object ScheduledMessageID, TargetEndPoint | where-object {$_.TargetEndPoint -ne "direct:execmgr"}

# //*** Trigger actions ***\\
try{
   # //*** Trigger "Machine Policy Evaluation and Update Cycle (Download Machine Policy)" ***\\
   $SCCMClient.TriggerSchedule("{00000000-0000-0000-0000-000000000021}");
   # //*** Trigger "Machine Policy Evaluation (Apply Machine Policy)" ***\\

   $SCCMClient.TriggerSchedule("{00000000-0000-0000-0000-000000000022}");
   # //*** Trigger "Software Updates Deployment Evaluation Cycle" ***\\

   $SCCMClient.TriggerSchedule("{00000000-0000-0000-0000-000000000108}");
   # //*** Trigger "Discovery Data Collection Cycle" ***\\
   $SCCMClient.TriggerSchedule("{00000000-0000-0000-0000-000000000003}");
}
catch{
   $_.Exception.Message;
}

Remove the direct collection membership of the computer

$collectionInParams = $objCollection.GetMethodParameters("DeleteMembershipRule");
$collectionInParams.collectionRule = $objCollectionRuleDirect;
$objCollection.PSBase.InvokeMethod("DeleteMembershipRule", $collectionInParams, $Null);

To ensure that the procedure of remotely accessing a SCCM client works, the following prerequisites must be fulfilled:

1. The account executing this actions must  have granted the DCOM “Launch and Activation permissions”. This is true, when the user is a member of the “Distributed COM Users” group on the target machine.

Alternatively, the DCOM permissions “Remote Access”, “Remote Launch” and “Remote Activation” for the appropriate user can be granted explicitely by using Group Policy:

Section: Computer Configuration\Windows Settings\Security Settings\
Local Policies\Security Options"

Policy: DCOM Machine Access Restrictions in Security Descriptor Definition 
Language (SDDL) syntax" (to allow "Remote Access")
Policy: DCOM Machine Launch Restrictions in Security Descriptor Definition 
Language (SDDL) syntax" (to allow "Remote Launch" and "Remote Activation")

2. Remote Management must be enabled as an exception on the client firewall, which can be configured by using Group Policy:

Section: Computer Configuration\Administrative Templates\Network\
Network Connections\Windows Firewall\Domain Profile\

Policy: Windows Firewall: Allow inbound remote administration exception

3. The user must be granted the “Remote Enable” access right on the target system for the CCM node of the WMI namespace. This can be configured from the properties of Computer Management –> Services and Applications –> WMI Control (see screenshot).

Security settings on WMI namespace

The WMI security can also be set programmatically using a VBScript, as described in detail in this  MSDN blog:

'//*** Set WMI "CCM" namespace permissions ***\\

strSD = array(<SECURITYDESCRIPTOR>)

set namespace = createobject("wbemscripting.swbemlocator").connectserver(,"root\CCM")
set security = namespace.get("__systemsecurity=@")
nStatus = security.setsd(strSD)

The correct <SECURITYDESCRIPTOR> value can be retrieved directly from the WMI namespace by exporting the current security descriptor of the object, after configuring the security as wanted:

wmic /namespace:\\root\ccm  /output:sd.txt path __systemsecurity call getSD

This puts the security descriptor into a text file, where it can be fond as like “SD = { … }”. From there it can be cut and pasted into the script as a value for the strSD variable (copy the SD value without the curly brackets).

Note: The prerequisites will also be fullfilled by only implementing point 2., when the user executing the action is member of the local administratiors group.

Additional note: To programmatically run a SCCM program, which is already advertised to a client and appears already in Run Advertised Programs:

%windir%\system32\windowspowershell\v1.0\powershell.exe -Command "& {(New-Object -comobject UIResource.UIResourceMgr).ExecuteProgram('<PROGRAMNAME>', '<PACKAGEID>', 1)}"
Posted in System Center Configuration Manager | Leave a comment

Import SCCM Computer Information and MAC Addresses programmatically from Active Directory

To run a bare metal OS deployment in SCCM, the respective computer/MAC address information need to be available in the SCCM database. A possible solution to populate the SCCM database with this computer/MAC address information could be to use Active Directory. When using Active Directory as a source, the idea is to to pre-stage the computer account in ADS, while maintaining also the “netbootGUID” attribute.

Creating the computer account and adding the netbootGUID attribute can be done manually via the ADUC console and the attribute editor, or programmatically using PowerShell. The netbootGUID attribute in Active Directory contains data of the type octed string, whereas the MAC address value must be converted accordingly before it can be used:

Convert a MAC address into a GUID and then into an octed string

## Create a GUID based of the MAC address, then build an octet string from the GUID, which can be used in the LDAP search filter
$macAddress = "<MACADDRESS_WITHOUT_SEPARATORS>";
$octetNetbootGUID = "";
[GUID]$objNetBootGUID = "00000000-0000-0000-0000-$macAddress"
($objNetBootGUID.ToByteArray() | foreach { $octetNetbootGUID = $octetNetbootGUID + '\' + $_.ToString('x2') }) -join '';
$octetNetbootGUID;

Once the computer account has been created in Active Directory, a scheduled task can take care to search Active Directory and import new computers to the SCCM database periodcally:

Search Active Directoy to find new computers with a netbootGUID value

## Search ADS to find computers having set a value for the netbootGUID attribute and have been changed recently
$domainController = "<DC>";
$todaystamp = get-date -uformat 20%y%m%d;
$todaystamp = $todaystamp + "000000.0Z";
$ldapRoot =[string]"LDAP://$domainController:389/DC=domain,DC=TLD";
$directoryEntry = New-Object System.DirectoryServices.DirectoryEntry($ldapRoot);
$searcher = New-Object DirectoryServices.DirectorySearcher($directoryEntry);
$searcher.PageSize = 1000;
$searcher.filter = "(& (|(netbootGUID=*) (whenchanged>= "+ $todaystamp + "))";
$results = $searcher.findall();
foreach ($item in $results){
    $netBIOSName = $item.properties.name;
    $netBIOSName = [STRING]$netBIOSName;
    $netBIOSName;
}

Convert the byte array value of the netbootGUID attribute into a string

$objAdComputer = Get-ADComputer -Filter {(name -eq "COMPUTERNAME"); 
$byarrNetBootGUID = $objAdComputer.netbootguid;
$netBootGUID = [STRING]$byarrNetBootGUID ;
$arrNetBootGUID = $netBootGUID.Split();
$macAddressRaw = [Convert]::ToString( $arrNetBootGUID[10 ],16) + ":" + [Convert]:: ToString($arrNetBootGUID[ 11],16 ) + ":" + [Convert]:: ToString($arrNetBootGUID[ 12],16 ) + ":" + [Convert]:: ToString($arrNetBootGUID[ 13],16 ) + ":" + [Convert]:: ToString($arrNetBootGUID[ 14],16 ) + ":" + [Convert]:: ToString($arrNetBootGUID[ 15],16 );

## Verify raw MAC address, adding a leading "0" where it has been skipped
$arrMacAddress = $macAddressRaw.Split(":" );
$macAddress = "" ;
for ( $i=0 ; $i -le $arrMacAddress.length- 1; $i ++){
       if ( $arrMacAddress[$i].length -ne 2){
              $arrMacAddress[$i] = "0" + $arrMacAddress[$i ];
       }
}
$macAddress = $arrMacAddress [0] + ":" + $arrMacAddress[1] + ":" + $arrMacAddress[2 ] + ":" + $arrMacAddress [3] + ":" + $arrMacAddress[ 4] + ":" + $arrMacAddress[5 ];
$macAddress = $macAddress.ToUpper();

Query the SCCM database for a computer with a specific NetBIOS name and get the MAC address

## Query SCCM database for a record with a specific netbios name and return the MAC address
$cmSiteCode = "CCM";
$netBIOSName = "<NETBIOSNAME>";
$objComputer = Get-WmiObject -query "SELECT NetbiosName, MACAddresses FROM SMS_R_SYSTEM WHERE NETBIOSNAME LIKE '%$netBIOSName%'" -Namespace "ROOT\SMS\site_$cmSiteCode";
$arrMacAddressesCCM = $objComputer.MACAddresses;
$macAddressesCCM = [STRING]$arrMacAddressesCCM;

Create a computer with a specific name and MAC address in SCCM and add the computer to a specific collection

Since SCCM 2012, this step can be completed using only one PowerShell command:

Import-CMComputerInformation -Computername $netBIOSName -MacAddress $macAddress -CollectionName "All Computers";

Due to the lack of the pretty PowerShell CMD-lets from SCCM 2012, the code to be used in SCCM 2007 is a little bit more:

## VARIABLES
$cmSiteServer = "." ;
$cmSiteCode = "CCM" ;
$cmWmiNameSpace = "\\" + $cmSiteServer + "\ROOT\SMS\site_" + $cmSiteCode ;
$cmCollectionID = "CCM00001" ;
$macAddress = "11:22:33:AA:BB:CC" ;
$netBIOSName = "COMPUTERNAME" ;

## Create and configure a SCCM "Site" object
$cmWmiClass = "SMS_Site" ;
$objCmSite = [ WmiClass]( "$($cmWmiNameSpace ):$cmWmiClass ");

## Create and configure a SCCM "Collection" object from the target collection
$cmWmiClass = "SMS_Collection" ;
$collectionFilter = "CollectionID = ' $cmCollectionID'";
$objCmCollection = Get-WmiObject $cmWmiClass -Computer $cmSiteServer -Namespace "ROOT\SMS\site_$cmSiteCode" -filter $CollectionFilter;

## Add computer to SCCM
$objSiteInParams = $objCmSite .PSBase. GetMethodParameters("ImportMachineEntry");
$objSiteInParams. MACAddress = $macAddress;
$objSiteInParams. NetbiosName = $netBIOSName;
$objSiteInParams. OverwriteExistingRecord = $true;
$objCmComputer = $objCmSite .PSBase. InvokeMethod("ImportMachineEntry", $objSiteInParams, $Null);

## Create and configure a SCCM "CollectionRuleDirect" object
$cmWmiClass = "SMS_CollectionRuleDirect" ;
$objCmCollectionRuleDirect = [ WmiClass]( "$($cmWmiNameSpace ):$cmWmiClass ");
$objCmCollectionRuleDirect. PSBase.properties ["ResourceClassName"]. value = "SMS_R_System";
$objCmCollectionRuleDirect. PSBase.Properties ["ResourceID"]. Value = $objCmComputer.ResourceID;

## Add Computer to SCCM collection
$objCollectionInParams = $objCmCollection.PSBase .GetMethodParameters("AddMembershipRule" );
$objCollectionInParams. CollectionRule = $objCmCollectionRuleDirect;
$objCmCollection.PSBase .InvokeMethod("AddMembershipRule" , $objCollectionInParams , $Null );
Posted in System Center Configuration Manager | Leave a comment

Troubleshooting SCCM OS deployment

When staging a client using SCCM OS deployment, there may be different issues preventing the deployment to complete successfully. The list below shows the solutions for some of the frequently occurring issues:

Error Message: No error message, Windows PE is just rebooting automatically.

Error occurrence: Stop directly after PE-load, before password authentication.

Possible Cause: The NIC driver of the respective hardware may be missing in the boot image.

Solution: Add the respective NIC driver to the boot image.

Error Message: Failed To Download Policy (Code 0x80004005)

Error occurrence: Stop in Windows PE, after password authentication but before the task sequence selection.

Possible Cause: The PXE certificate stored in the SCCM site database may have been expired or may be missing at all. Time settings of the computer (BIOS) may be incorrect.

Solution: Add a new or renew the existing PXE certificate assigned to the respective distribution point in the SCCM site settings. Verify that the BIOS time matches the current time.

Error Message: Failed with the error code 0x80070002

Error occurrence: 1. Stop at “Auto Apply Drivers”, network connection is lost (ipconfig in F8-console of PE shows no IP address)
or 2. Stop at “Apply Operating System Image”.

Possible Cause: 1. A non PE compatible NIC driver has been applied by the “Auto Apply Drivers” action, which causes a network disconnection or 2. Package sources cannot be downloaded from a distribution point, e.g. due to authentication issues.

Solution: 1. As a workaround, the “Auto Apply Drivers” section in the task sequence can be disabled for the affected HW model, e.g. by using a condition. Please refer to this blog post for more details about this issue and proposals for a solution or 2. Verify the credentials of the network access account. In case of SCCM 2012, check the virtual IIS directory “SMS_DP_SMSPKG$”, if it is enabled for Windows Authentication.

Error Message: Failed with the error code 0x80004005. Windows setup failed code 31

Error occurrence: Stop during “Setup ConfigMgr Client” action, after the “Auto Apply Drivers” action.

Possible Cause: This issue may occur after adding new drivers to SCCM, while one of the drivers may cause issues with Windows setup after being auto applied.

Solution: Identify the incompatible driver in the SCCM driver store and disable it. In the most cases such a driver can only be installed via a separate package instead of using “Auto Apply Drivers”.

Error Message: Failed with the error code 0x00000001

Error occurrence: Stop after unattended setup part of Windows (Windows base OS installation has already been completed), directly after the reboot when the “Setup ConfigMgr Client” action has re-run. Network connection is lost (ipconfig in F8-console of PE shows no IP address).

Possible Cause: NIC driver of the respective hardware may not be available for the installation in Windows, or the “Auto Apply drivers” action has not run at all in the task sequence.

Solution: Add the respective NIC driver to the SCCM driver store and include it in a package. Make sure that “Auto Apply Drivers” in the task sequence will run for the respective hardware.

Error Message: 1. There are no task sequences available for this computer
or 2. No error message, but the Computer gets a name conflicting with another SCCM record.

Error occurence: 1. Stop directly after the PXE password dialogue or 2. OS deployment completes successfully, but the computer has a wrong computer name which conflicts with the name of another SCCM record.

Possible Cause: There may be duplicate SMBIOS GUIDs (System UUIDs) for a record in the SCCM database, which conflicts with the SMBIOS GUID of the system being currently set up. Although this GUID should always be unique, there are obviously possible cases where it isn’t maintained correctly.

Solution: As a workaround, you can create a registry value named “BannedGuids” on the PXE service point, containing a list of known duplicate GUIDs. This instructs the PXE service to skip the SMBIOS GUID lookup during the PXE boot and to fall back to MAC only lookup, when a known duplicate GUID is presented to the PXE service:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\
Providers\WDSPXE]
 Value: BannedGuids
 Type: REG_MULTI_SZ
 Data: <DUPLICATE_SMBIOSGUID>

To identify the SMBIOS GUID locally on a running system, the following command can be used:

wmic csproduct get uuid

When the registry value is set, the smspxe.log reports the following (note that “GUID=” has no value and “GuidCount=” has a vlaue of “0”)

MAC=<MACADDRESS> SMBIOS GUID= > Device found in the database. 
MacCount=2 GuidCount=0

See also this Microsoft KB for more detailed information about this issue.

Please note, that this solution does indeed work to ignore the SMBIOS GUID during PXE boot via WDS, but later when SCCM runs a second lookup to determine all available task sequences for the affected computer, the SMBIOS GUID is used again, uncared of the “BannedGuids” registry value. In this case, the smsts.log file reports the following:

Setting wizard error: There are no task sequences available for 
this computer.

As a conclusion, from my point of view there is no alternative solution available as solving the problem on the hardware itself.

Error Message: No error message, PXE boot loops when downloading the boot loader or PXE boot is not starting at all.

 Error occurence: PXE is trying to TFTP download “pxeboot.com” in a loop:

troubleshooting-sccm-os-deployment_01

or

troubleshooting-sccm-os-deployment_02

The log file “smspxe.log” logs “Device has been accepted” several times without any further progress or error message (PXE loop) or it stops after logging “Device found in the database” (PXE not starting). The folder “D:\RemoteInstall\SMSBoot” is missing or the x64 resp. x86 sub folders are empty or incomplete with missing files. As a result, “C:\Windows\Temp\PXEBootFiles” is also missing or contains no (PXE loop) boot loader files.

Possible Cause: The standard x86 and x64 boot images may not have been replicated to the PXE point.

Solution: Replicate the standard boot images, restart the WDS service on the affected PXE server and check if the files in the mentioned folders do appear.

Posted in System Center Configuration Manager | Leave a comment