В начале этого сообщения приведу немного теории в вольном пересказе. Итак:

Windows Deployment Services (Службы развертывания Windows) поддерживают два варианта построения инфраструктуры:

• полная инфраструктура или сервер развертывания, а именно, установлены обе роли: Deployment Server и Transport Server –  такой вариант требует наличия AD/DNS, DHCP, и при нем обеспечивается удаленная загрузка клиентов по PXE и присутствуют оба компонента – PXE Listener (PXE прослушиватель) и PXE provider (PXE-поставщик);
• только транспортный сервер, который обеспечивает работу компонента отвечающего на запросы клиента (PXE Listener), а PXE provider, определяющий оптимальный ответ и отвечающий за поддержку передачи образов отстутствует, и его нужно конструировать отдельным порядком. Наличие AD, DNS, DHCP* в этом случае не является обязательным требованием.

Если вопрос конфигурирования полной инфраструктуры достаточно хорошо освещен в различных источниках и в сопровождающей документации по Windows Deployment Services, то вопрос настройки только транспортного сервера покрыт “легким полумраком”, а ресурс Microsoft TechNet “Использование транспортного сервера” вообще содержит весьма сомнительный совет: “Для транспортного сервера не требуется какая-либо настройка”.

Полная инфраструктура WDS имеет множество преимуществ перед транспортным сервером. Тем не менее, иногда возникают ситуации, когда необходимо решить задачу развертывания ОС с одиночного сервера по сети на десятки компьютеров одновременно без доступа к AD/DNS или при их отсутствии. Собственно такой сценарий и послужил “фитилем” для данной статьи в моем блоге.

Результат моих стараний  я прилагаю к данному сообщению. Он как раз и свидетельствует о том, что настройка транспортного сервера, все-таки, требуется.

Все выполненные мной действия я свел в один .cmd файл, подробно закомментировал его, и, в принципе, с минимальными правками он может быть применен в похожих ситуациях.

• В приведенной в листинге “пошаговке” присутствует настройка DHCP сервера. Я, несмотря на упомянутые выше лозунги, что для транспортного сервера ничего не нужно, считаю  присутствие DHCP сервера обязательным для того чтобы обеспечить загрузку удаленного клиента по PXE.

Листинг .cmd файла приведен ниже:

::
:: +———————————————————————————————————————
:: | Перед выполнением этого сценария на Транспортном сервере установите WAIK для Windows 7
:: | Данный сценарий должен быть запущен из-под Deployment Tools Command Prompt из состава WAIK
:: | в контесте учетной записи с административными правами
:: +———————————————————————————————————————-

:: Настраиваем сетевой интерфейс сервера развертывания на статику
netsh interface ip set address name=»Local Area Connection 2″ static 192.168.0.3 255.255.255.0

:: Устанавливаем роль DHCP сервера и конфигурируем DHCP scope
start /w ocsetup DHCPServer
sc config dhcpserver start= auto
start /w net start dhcpserver
:: DHCP scope
netsh dhcp server 192.168.0.3 add scope 192.168.0.0 255.255.255.0 TRSRV TRSRV
netsh dhcp server 192.168.0.3 scope 192.168.0.0 add iprange 192.168.0.100 192.168.0.150
netsh dhcp server 192.168.0.3 scope 192.168.0.0 set state 1

:: на всякий случай

start /w net stop dhcpserver
start /w net start dhcpserver

:: Устанавливаем роль Transport Server
:: можно по-новому:
rem start /w ocsetup Microsoft-Windows-Deployment-Services
rem start /w ocsetup Microsoft-Windows-Deployment-Services-Transport-Server

:: но в контексте servermanagercmd — информативнее
ServerManagerCmd -install WDS-Transport

:: Создаем и предоставляем в общий доступ нужные папки

:: Сначала создаем ресурсные директории для обеспечения PXE сервером
md e:RemoteInstallbootx86images
md e:RemoteInstallbootx64images

:: Потом каталоги для монтирования образов
md e:mount1
md e:mount2

:: и каталог Resource, в который будут складываться образы ОС
md e:resources

:: Устанавливаем необходимые разрешения на общую сетевую папку и NTFS разрешения
:: everyone — небезопасный вариант, но для примера сгодится
net share REMINST=E:RemoteInstall /GRANT:SYSTEM,FULL /GRANT:administrators,FULL /grant:Everyone,READ
icacls e:remoteinstall /grant everyone:(RX,RD)

:: Монтируем образы для x86 и amd64, добавляем в них то, что потом будет работать за PXE провайдера
:: wdsmcast нужна для входа в мультикаст сеанс, предлагаемый транспортным сервером
:: ImageX — для применения оттранспортированного образа
:: но главное — забираем контент для наполнения ресурсной директории PXE провайдера

start /w Imagex /mountrw x86winpe.wim 1 E:Mount1

xcopy E:mount1WindowsBootPXE*.* E:RemoteInstallbootx86*.* /e
xcopy ….Toolsx86wdsmcast.exe e:mount1windowssystem32*.*
xcopy «….Toolsx86imagex.exe» e:mount1windowssystem32

start /w imagex /mountrw amd64winpe.wim 1 E:mount2

xcopy E:mount2WindowsBootPXE*.* E:RemoteInstallbootx64*.* /e
xcopy ….Toolsamd64wdsmcast.exe e:mount2windowssystem32*.*
xcopy «….ToolsAmd64imagex.exe» e:mount2windowssystem32

:: Демонтируем образы с сохранением изменений — wdsmcast и ImageX не помешают никогда
start /w Imagex /unmount E:Mount1 /commit
start /w Imagex /unmount E:Mount2 /commit

:: Заполняем REMINST загрузочниками
:: контейнер монтирования для RAM disk — boot.sdi
xcopy c:WindowsSystem32RemInstbootboot.sdi e:RemoteInstallboot*.*

:: теперь boot.wim — для загрузки WindowsPE на клиентах
start /w xcopy x86*.wim E:RemoteInstallbootx86Imagesboot.*
start /w xcopy amd64*.wim E:RemoteInstallbootx64Imagesboot.*

:: Настраиваем Transport Server PXE provider
SET REMOTEINSTALL=E:RemoteInstall
reg.exe add HKLMSYSTEMCurrentControlSetServicesWDSServerProvidersWDSPXE /v ProvidersOrder /t REG_MULTI_SZ /d WDSSIPR /f

:: Выставляем корневую папку для подтягивания ресурсов при удаленной загрузке клиента
reg.exe add HKLMSYSTEMCurrentControlSetServicesWDSServerProvidersWDSTFTP /v RootFolder /t REG_SZ /d %REMOTEINSTALL% /f

:: можно внести изменения в C:Windowssystem32wdssipr.dll.conf.ini
:: но это, как оказалось не играет роли
:: изменяемые параметры
:: X86BootImage=bootx86imagesboot.wim
:: и
:: X64BootImage=bootx64imagesboot.wim

:: Настраиваем Transport Server на работу с DHCP
:: Чтобы не было проблем с мультикастом — используем MADCAP
WDSUTIL /Set-TransportServer /ObtainIPv4From:DHCP

:: DHCP и Transport — на одном сервере, поэтому
reg add HKLMSYSTEMCurrentControlSetServicesWDSServerProvidersWDSPXE /v UseDhcpPorts /t REG_DWORD /d 0 /f
netsh dhcp server 192.168.0.3 add optiondef 60 PXEClient String 0 comment=»PXE support»
netsh dhcp server 192.168.0.3 set optionvalue 60 STRING PXEClient

:: Выполняем дополнительные настройки для DHCP, чтобы обеспечить загрузку бутявки
:: DNS нет, поэтому все по IP
netsh Dhcp server 192.168.0.3 Add Optiondef 66 «Boot Server Host Name» STRING «» comment=»TFTP boot server host name»
netsh dhcp server 192.168.0.3 set optionvalue 66 STRING 192.168.0.3 «»
rem ——-   netsh Dhcp Add Optiondef 67 «Bootfile Name» STRING 0 comment=»Bootfile Name»
netsh dhcp server 192.168.0.3 set optionvalue 67 STRING bootx86wdsnbp.com «»

:: Запускаем Transport Server
WDSUTIL /Start-TransportServer

:: Открываем поименованный мультикаст сеанс, в котором раздача начнется по условию кол-во клиентов=1
WDSUTIL /New-Namespace /FriendlyName:»mcast» /Namespace:»mcast» /ContentProvider:WDS /ConfigString:E:Resources
/NamespaceType:ScheduledCast /Clients:1

REM —Можно и вручную, если sheduled-cast
rem WDSUTIL /Start-Namespace /Namespace:mcast

:: +————————————————————————————————
:: | Нижеперечисленные команды запускаются на стороне клиента.

:: | Их можно свести в отдельный .cmd файл
:: | Они обеспечат получение и применение образа
:: +————————————————————————————————
rem wdsmcast /progress /verbose /transfer-file /server:dc /namespace:mcst /username:dcadministrator /sourcefile:install.wim /destinationfile:c:install.wim
rem imagex /apply c:install.wim 1 c:
rem del c:install.wim

exit

Принимаются конструктивные замечания и комментарии.

P.S. Информация, приведенная в данном сообщении, ориентирована на корпоративное окружение. Тем не менее, приведенные выше инструкции могут вполне быть использованы и сборщиками систем.