Например, следующая команда копирует файлы архитектуры amd64 в каталог C:\winpe_amd64: For example, the following command copies amd64 architecture files to the C:\winpe_amd64 directory:

Сценарий создает структуру каталогов назначения и копирует все необходимые файлы для этой архитектуры. The script creates the destination directory structure and copies all the necessary files for that architecture. В предыдущем примере создаются следующие каталоги: In the previous example, the following directories are created:

Подключите базовый образ Windows PE (winpe.wim) в каталог \mount с помощью средства DISM. Mount the base Windows PE image (winpe.wim) to the \mount directory using the DISM tool. При подключении файла образа его содержимое распаковывается в папку, что позволяет вносить изменения напрямую или с помощью таких программ, как DISM. Mounting an image file unpacks the file contents into a folder so that you can make changes directly or by using tools such as DISM. См. приведенный ниже пример. See the following example.

Убедитесь, что отображается сообщение «Операция завершена успешно». Verify that «The operation completed successfully» is displayed. Примечание. Чтобы просмотреть подключенные в настоящее время образы, введите dism /get-MountedWiminfo. Note: To view currently mounted images, type dism /get-MountedWiminfo.

Выполните сопоставление общего сетевого ресурса корневому каталогу TFTP на сервере PXE/TFTP и создайте папку \Boot. Map a network share to the root TFTP directory on the PXE/TFTP server and create a \Boot folder. Обратитесь к документации сервера TFTP, чтобы определить корневой каталог сервера TFTP, а затем включите общий доступ к этой папке и убедитесь, что она доступна в сети. Consult your TFTP server documentation to determine the root TFTP server directory, then enable sharing for this directory, and verify it can be accessed on the network. В следующем примере имя сервера PXE имеет значение PXE-1, а общий доступ к корневому каталогу TFTP предоставляется с помощью сетевого пути \\PXE-1\TFTPRoot: In the following example, the PXE server name is PXE-1 and the TFTP root directory is shared using a network path of \\PXE-1\TFTPRoot:

Скопируйте файлы загрузки PXE из подключенного каталога в папку \boot. Copy the PXE boot files from the mounted directory to the \boot folder. Пример. For example:

Скопируйте файл boot.sdi на сервер PXE/TFTP. Copy the boot.sdi file to the PXE/TFTP server.

Скопируйте загрузочный образ Windows PE (boot.wim) в папку \boot. Copy the bootable Windows PE image (boot.wim) to the \boot folder.

(Необязательно) Скопируйте в папку \boot шрифты true type (Optional) Copy true type fonts to the \boot folder

Шаг 2: настройка параметров загрузки и копирование файла BCD Step 2: Configure boot settings and copy the BCD file

Создайте хранилище BCD с помощью bcdedit.exe: Create a BCD store using bcdedit.exe:

Настройте параметры RAMDISK: Configure RAMDISK settings:

Последняя команда возвращает идентификатор GUID, например: The last command will return a GUID, for example:

Скопируйте этот идентификатор GUID для использования в следующих командах. Copy this GUID for use in the next set of commands. В каждой приведенной команде замените «GUID1» своим идентификатором GUID. In each command shown, replace «GUID1» with your GUID.

Создайте новую загрузочную запись приложения для образа Windows PE: Create a new boot application entry for the Windows PE image:

Настройте параметры BOOTMGR (не забудьте заменить GUID1 в третьей команде своим идентификатором GUID): Configure BOOTMGR settings (remember to replace GUID1 in the third command with your GUID):

Скопируйте файл BCD на свой TFTP-сервер: Copy the BCD file to your TFTP server:

Теперь ваш сервер PXE/TFTP настроен. Your PXE/TFTP server is now configured. Можно просмотреть установленные параметры BCD с помощью команды bcdedit /store /enum all. You can view the BCD settings that have been configured using the command bcdedit /store /enum all. См. следующий пример. See the following example. Примечание. Ваш идентификатор GUID будет отличаться от приведенного ниже. Note: Your GUID will be different than the one shown below.

Если вы запустите процесс загрузки PXE, но получите сообщение об ошибке «Данные конфигурации загрузки для компьютера отсутствуют или содержат ошибки», убедитесь, что каталог \boot установлен в правильном корневом каталоге сервера TFTP. If you start the PXE boot process, but receive the error that «The boot configuration data for your PC is missing or contains errors» then verify that \boot directory is installed under the correct TFTP server root directory. В используемом здесь примере имя этого каталога — TFTPRoot, но сервер TFTP может быть другим. In the example used here the name of this directory is TFTPRoot, but your TFTP server might be different.

Сводка по процессу загрузки PXE PXE boot process summary

В следующей таблице приведены основные сведения о процессе загрузки PXE-клиента. The following summarizes the PXE client boot process.

Understand PXE boot in Configuration Manager

This article describes basic processes of Preboot Execution Environment (PXE) boot in Configuration Manager, how they work, and how they interoperate with each other.

Original product version: В Configuration Manager (current branch), Microsoft System Center 2012 R2 Configuration Manager, Microsoft System Center 2012 Configuration Manager
Original KB number: В 4468601

Introduction

Preboot Execution Environment (PXE) boot in System Center 2012 Configuration Manager (ConfigMgr 2012 or ConfigMgr 2012 R2) and later versions enables administrators to easily access the Windows Preinstallation Environment (WinPE) across the network via PXE. PXE is an industry standard created by Intel that provides pre-boot services within the devices firmware that enables devices to download network boot programs to client computers.

Configuration Manager relies on the Windows Deployment Services (WDS) server role via the WDS PXE provider. In ConfigMgr 2012 and later versions, the SMS PXE provider (SMSPXE) registers with the WDS service and supplies the logic for the PXE client requests.

Before troubleshooting PXE-related problems in Configuration Manager, it’s important to understand the basic processes involved, how they work and how they interoperate with each other.

In all instances in this document, we are using System Center 2012 Configuration Manager R2 Cumulative Update 2 (ConfigMgr 2012 R2 CU2) and a remote site system installed on Windows Server 2012 with the Distribution Point (DP) role installed.

PXE service point installation

We will first look at the processes involved in the installation of the SMSPXE provider.

Installation is initiated by selecting the Enable PXE support for clients option on the PXE tab in Distribution point properties. When PXE support is enabled, an instance of SMS_SCI_SysResUse class is created.

In the WMI namespace Root\SMS\Site_RR2 (where RR2 is the site code of the site), the SMS_SCI_SYSResUse class contains all the site systems roles on the primary site server. You can run the following query in WBEMTEST to identify all the DPs on that site server:

Changing the properties of these roles via the SDK will alter the site control file and configure the DP. The IsPXE property name is a member of the props property and is set to 1 when the DP is PXE enabled.

The SMS Database Monitor component detects the change to the DPNotificaiton and DistributionPoints tables and drops files in distmgr.box:

The Distribution Manager component on the primary site server then initiates the configuration of the remote DP:

In the SMS DP Provider log on the remote DP, we can see the following information about the PXE installation, where initially the PxeInstalled registry key isn’t found:

The Visual C++ Redistributable is installed:

WDS is installed:

TFTP read filters are configured:

The REMINST share is created and WDS is configured:

On the remote DP, we can now see the following values added in HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\DP :

PxeInstalled and IsPXE are set to 1.

If we look at the remote DP’s file system, there is a new login C:\SMS_DP$\sms\logs :

The Distribution Point should now be PXE-enabled and ready to accept incoming requests.

Add boot images to a PXE-enabled DP

Whenever a new PXE-enabled distribution point is configured, there are additional steps that need to be completed to enable full functionality. One of these is that you must distribute the x86 and x64 boot images to the new PXE-enabled DP.

To do this, navigate to Software Library > Operating Systems > Boot Images > Boot Image (x86), and then right-click and select Distribute Content > Add the Boot Image to the PXE enabled DP. Repeat this process for Boot Image (x64).

Once this is done, Distribution Manager will start processing the request and initiate the distribution to the remote DP:

Package Transfer Manager (the DP is remote) then initiates sending of the content:

SMS Distribution Point Provider then deploys the WIM to the remote install directory:

SMSPXE discovers the new image:

Make sure that these boot images are configured to deploy from the PXE-enabled DP. Right-click the boot image and select Properties > Data Source, and then select Deploy this boot image from the PXE-enabled distribution point.

The PXE boot process

The example boot process described here involves three machines: The DHCP server, the PXE-enabled DP, and the client (an x64 BIOS computer). All are located on the same subnet.

You must make sure that the DHCP (67 and 68), TFTP (69) and BINL (4011) ports are open between the client computer, the DHCP server and the PXE enabled DP.

In the PXE boot process, the client must first acquire TCP/IP parameters and the location of the TFTP boot server. Once a device is powered on and completes the POST, it begins the PXE boot process (prompted via the boot selection menu).

The first thing the PXE firmware does is sending a DHCPDISCOVER (a UDP packet) broadcast to get TCP/IP details. This includes a list of parameter requests, and below is a sample network trace with the parameter list from a DHCPDISCOVER packet:

The PXE client then identifies the vendor and machine-specific information so that it can request the location and file name of the appropriate boot image file.

The DHCP server and the PXE-enabled DP then send a DHCPOFFER to the client containing all of the relevant TCP/IP parameters.

In the example DHCP offer below, it doesn’t contain the server name or boot file information because this is the offer from the DHCP server rather than the PXE enabled DP.

The client then replies with a DHCPREQUEST once it has selected a DHCPOFFER. This contains the IP address from the offer that was selected.

The DHCP server responds to the DHCPREQUEST with a DHCPACK that contains the same details as the DHCPOFFER. The server host name and the boot file name are not provided here:

At this point, we still don’t have the boot file information, however now the client has an IP address. Next, the PXE client sends a new DHCPREQUEST to the PXE-enabled DP after receiving a DHCPOFFER from the earlier DHCPDISCOVER broadcast.

The PXE-enabled DP sends a DHCPACK that contains the BootFileName location and the WDS network boot program (NBP).

Downloading the boot files

After the DHCP conversation completes, the client will start the TFTP session with a read request:

The server responds with the tsize and then the blksize. The client will then transfer the file from the server.

The size of these blocks is the blksize, and in this case it’s set to 1456 bytes. The blksize is configurable on Windows Server 2008 and later versions. See Operating system deployment over a network by using WDS fails in Windows Server 2008 and in Windows Server 2008 R2.

Here we can see the end of the DHCP conversation and the start of the TFTP transfer:

When the WDS network boot program (NBP) has been transferred to the client computer, it will be executed. In our example, it starts by downloading wdsnbp.com . The NBP dictates whether the client can boot from the network, whether the client must press F12 to initiate the boot and which boot image the client will receive.

NBPs are both architecture and firmware specific (BIOS or UEFI). On BIOS computers, the NBP is a 16-bit real-mode application, therefore it’s possible to use the same NBP for both x86-based and x64-based operating systems.

In our case (an x64 BIOS machine), the NBP is located in the following directory on the PXE enabled DP: \\remotedp\c$\RemoteInstall\SMSBoot\x64

The files perform the following functions:

PXEboot.com — x86 and x64 BIOS: Requires the end user to press F12 for PXE boot to continue (this is the default NBP).

PXEboot.n12 — x86 and x64 BIOS: Immediately begins PXE boot (doesn’t require pressing F12 on the client).

AbortPXE.com — x86 and x64 BIOS: Allows the device to immediately begin booting by using the next boot device specified in the BIOS. This allows for devices that should not be booting using PXE to immediately begin their secondary boot process without waiting for a timeout.

Bootmgfw.efi — x64 UEFI and IA64 UEFI: The EFI version of PXEboot.com or PXEboot.n12 (in EFI, the choice of whether or not to PXE boot is handled within the EFI shell and not by the NBP). Bootmgfw.efi is the equivalent of combining the functionality of PXEboot.com , PXEboot.n12 , abortpxe.com and bootmgr.exe .

wdsnbp.com — x86 and x64 BIOS: A special NBP developed for use by Windows Deployment Services that serves the following general purposes:

• Architecture detection
• Pending devices scenarios

Wdsmgfw.efi — x64 UEFI and IA64 UEFI: A special NBP developed for use by Windows Deployment Services that serves the following general purposes:

• Handles prompting the user to press a key to continue PXE boot
• Pending devices scenarios

The NBP downloads the operating system loader and the boot files via TFTP, which include the following:

• smsboot\x64\pxeboot.com
• smsboot\x64\bootmgr.exe
• \SMSBoot\Fonts\wgl4_boot.ttf
• \SMSBoot\boot.sdi
• \SMSImages\RR200004\boot.RR200004.wim

A RAMDISK is created using these files and the WinPE WIM file in memory.

The client boots from the RAMDISK.

WinPE boot

Once WinPE has booted, the TS boot shell is initiated from the SMS folder that’s included in the WinPE image (this folder is injected into the boot WIM when it’s imported into Configuration Manager). You can see this process logged in SMSTS.log that’s located under X:\Windows\Temp\SMSTS\ .

To access this login WinPE, enable the command prompt on the boot image. To do this, right-click Boot Image > Properties > Customization, and then check Enable command support (testing only). You can then access the command prompt by pressing F8 in WinPE.

Here is the initial TS boot shell process:

Followed by the Task Sequence Manager boot strap:

Once TSPXE is loaded, it downloads the TS variables using TFTP:

At this point, TSPXE locates the Management Point (MP) and downloads policy before presenting the user interface for the user to select the optional Task Sequence:

Lastly, the collection and machine variables are downloaded and the Welcome Page is activated:

More Information

For more information about troubleshooting PXE boot issues, see the following articles: