Windows WDS and TFTP-сервер

Chainloading Windows Deployment Services

Windows Deployment Services (WDS) is a set of services and APIs to facilitate Windows operating system installation by using PXE, DHCP and TFTP to bootstrap WinPE, the Windows Preinstallation Environment. You can think of it as providing similar functionality to iPXE with server-side scripting, where clients are served boot configuration and images based on various criteria, such as hardware architecture.

This appnote is about chainloading WDS from iPXE in a straight-forward manner.

Configure the WDS TFTP service

The WDS TFTP service relies on a registry key HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/WDSServer/Providers/WDSTFTP/ReadFilter that controls which TFTP paths are mapped to the directory containing the various installation files defined by the RootFolder registry key in the same location.

RegEdit WDSTFTP Depending on the existing configuration, it is likely that additional patterns must be added to make iPXE and the WDS boot programs work correctly.

Make sure the following patterns are included in the ReadFilter list:

  • boot/*
  • boot\*
  • /boot/*
  • \boot\*
  • /boot\*

This allows all relavant combinations of forward and backward slashes, with or without a prefix slash. The last entry is particularly odd, but is actually used by the initial WDS network boot program once it has been chainloaded by iPXE, as seen in the example below.

After changing the ReadFilter list, reload the TFTP service to ensure it accepts the full list of patterns.

Chainload wdsnbp.com

Loading the initial WDS network boot program wdsnbp.com can be done either directly from the iPXE shell or via a menu entry. The only thing that needs to be modified is the DHCP next-server parameter, which will let wdsnbp.com know which server to communicate with.

Be sure to set DHCP options so that they are made available to the PXE NBP. For example, the next-server parameter can be set via netX/next-server.

Example iPXE commands to chainload wdsnbp.com:

The WDS boot process

Once wdsnbp.com starts, it initiates a session with the WDS server that was specified in the DHCP next-server parameter. The session protocol uses a combination of DHCP requests and responses and TFTP to provide the client with the appropriate boot loader (such as bootmgr.exe or bootmgfw.efi) and boot configuration data (BCD).

The wdsnbp.com program performs client architecture detection and reports it back to the server via the WDS session. This session protocol uses DHCP as an RPC service endpoint, and the data passed back and forth (such as architecture information) is encoded in DHCP option 250. Together with option 252 (used by WDS to indicate BCD file name) and the DHCP file field (pointing the client to the next network boot program), the DHCP+TFTP negotiation completes the WDS session.

Example boot process

  1. Client: iPXE requests TFTP /boot/x86/wdsnbp.com from ip.of.wds.server.
  2. Client: wdsnbp.com uses a direct DHCP request to ip.of.wds.server, with no option 250 nor 252 defined.
  3. Server: DHCP response:
    • filename: boot\x86\wdsnbp.com
    • option 250: 0b0101100400000001ff
    • option 252: \Tmp\x86{<GUID>}.bcd
  4. Client: wdsnbp.com uses a direct DHCP request to ip.of.wds.server:
    • option 250: 0d0208000e010001020006ff
  5. Server: DHCP response:
    • filename: boot\x86\wdsnbp.com
    • option 250: 0b0101100400000001ff
    • option 252: \Tmp\x86x64{GUID}.bcd
  6. Client: wdsnbp.com requests TFTP /boot\x86\wdsnbp.com from ip.of.wds.server. Note the use of slashes.
  7. Client: wdsnbp.com uses a direct DHCP request to ip.of.wds.server:
    • option 250: 0c01010d0208000e010001020006ff
  8. Server: DHCP response:
    • filename: boot\x64\pxeboot.n12.
    • option 250: 0b0101100400000001ff
    • option 252: \Tmp\x86x64{GUID}.bcd
  9. Client: wdsnbp.com requests TFTP /boot\x64\pxeboot.n12.
  10. Client: pxeboot requests TFTP /boot\x64\bootmgr.exe.
  11. Client: pxeboot requests TFTP \Tmp\x86x64{GUID}.bcd.
  12. Client: bootmgr.exe executes and reads the BCD.

Troubleshooting

WDS in Wireshark Due to the poor error reporting in the WDS boot programs, the go-to troubleshooting tool should be a network packet analyzer like Wireshark. Packets can be dumped using other tools like tcpdump or tshark before being loaded into Wireshark for analysis.

Here’s a Wireshark filter that shows only DHCP and useful TFTP packets by omitting TFTP opcode 3 (data packet) and 4 (acknowledgement):

Things to pay particular attention to:

  • The destination IP for TFTP and DHCP requests.
  • The TFTP request filename.
  • TFTP error codes from the WDS server.
  • DHCP options in the client requests and server responses.
  • The WDS event log in Windows.

TFTP download errors

Ensure that the DHCP next-server parameter is specified correctly in the iPXE commands. If it is not configured correctly, it should be evident from the network capture that either the first DHCP or TFTP request from wdsnbp.com is directed towards the wrong IP.

Make sure the WDS TFTP server’s read filter has mapped the relevant path names. Inspect the use of slashes in the DHCP packets to see how they are used, and check that the ReadFilter registry setting is configured appropriately.

TFTP loops

If either wdsnbp.com or pxeboot.n12 gets stuck in a request loop, it is likely that the initial TFTP download worked, but subsequent ones are failing. This can happen because iPXE uses forward slashes in the TFTP file path, while the WDS boot programs are prone to using a mix of forward and backward slashes.

Make sure the WDS TFTP server’s read filter has mapped the relevant path names. Inspect the use of slashes in the DHCP packets to see how they are used, and check that the ReadFilter registry setting is configured appropriately.

Alternatives

The upside of chainloading WDS from iPXE is that it provides a fully working and isolated WDS setup, while iPXE remains in control as the initial boot program with WDS supplied as just another choice amongst the variety of alternate boot options. WDS remains in full control of its own configuration.

A drawback with WDS is that it uses TFTP (although with extensions that allow larger receive windows), which is not nearly as fast as HTTP, especially if there is more than a few ms round-trip time between the client and server. This results in somewhat long loading times for large WIM images, particularly on links with medium to high latency.

A good alternative to the PXE mechanism of WDS is wimboot, a boot loader that takes over the roles of wdsnbp.com and pxeboot.n12. It lets you fetch all the relevant files over HTTP and hand over execution to bootmgr.exe. There is a drawback, however: Control over the dynamic BCD boot menu is taken away from WDS, as a static BCD file is served instead.

References

Windows 10 V1703: Fix for DISM error 0x800F081F

Microsoft’s Windows 10 Creators Update images contains a flaw. Broken manifest files are causing DISM to stall with error 0x800F081F. Here are a few details and a fix.

What’s broken?

After upgrading a system, some users are running a file system check, as discussed within my blog post Check and repair Windows system files and component store – to assure, that all files are intact. Users upgrading or installing Windows 10 Creators Update are facing an error after executing the following commands (see also Windows 10 Creators Update Troubleshooting – part 1). The error will be shown, after the 2nd command is executed within an administrative command or PowerShell window:

DISM.exe /Online /Cleanup-image /Scanhealth
DISM.exe /Online /Cleanup-image /Restorehealth

The screenshot shown below, has been taken from my German Windows 10 V1703. The /RestoreHealt command has been aborted with error 0x800F081F.

The reason for error 0x800F081F in Windows 10 Version 1703

DISM says, that the source to repair the corrupted file can’t be found. In normal circumstances, it’s possible to use an install DVD as a source. But if the install image also contains the broken files, it won’t help.


Advertising


DISM creates a log file dism.log at C:\Windows\Logs\DISM\ – but within my test environment I wasn’t able to detect the root cause (the file mentioned below was never reported). But a reader of my German blog left a comment pointing to a forum post. Within this english forum thread someone was able to detect the faulty file within the log file after executing dism … /scanhealth – it was the file:

Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~10.0.15063.0

that is shipped with a damaged MUM file (Microsoft Update Manifest, error CBS Corrupt MUM).

A  fix for error 0x800F081F in Windows 10 Version 1703

The fix removes all references to this file (probably left from Insider Preview program) from registry and from component store. References to component store may be found within the registry branche:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\

in subkeys:

Component Based Servicing\PackageIndex
Component Based Servicing\Package

To remove the registry entries, proceed the following steps.

1. Launch registry editor regedit.exe from an administrator account or use Run as administrator context menu command after searching for the file in taskbar’s search box.

2. Confirm UAC and navigate to the following registry keys.

3. Grant full access rights to the admin account and delete the entries using context menu command delete.

It’s probably a good idea to export the registry key into a .reg file using File/Export.

The first key is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex\Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~0.0.0.0

The 2nd key is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~10.0.15063.0

You can’t delete these keys, even, if you an administrator, because of missing rights. The following error will be shown.

Therefore use the following additional steps.

1. Right click the key in the left pane and select Permission (see).

2. Select on property page Permissions the group Administrators in Group- or user names.

3.  Check the Full control checkbox in column Allow (group Permissions for “Administrators” and click OK.

4. Then right click the registry keys mentioned above and delete them via context menu command Delete.

After deleting the two registry entries mentioned above, proceed another step and open Windows Explorer. Then navigate to folgender:

C:\Windows\Servicing\Packages

Delete the two .cat and .mum files named:

Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~*.*

via context menu command of via Delete button in Explorer’s menu bar. This requires administrative user rights.

Note the comment given below, mentions another key (probably in 64-bit-environments), if the fix given above doesn’t work.

After finishing the steps give above, try to check the system health using dism. As shown above, the system integrity check with dism shall be successful.

Разные тонкости при работе с Office365 и Exchange Online

Для начала: речь идет о подписке Office365 Business Premium, той самой, где можно почту своего домена размещать на Exchange Online от Microsoft. И именно с этим связаны несколько тонкостей, которые могут пригодиться при настройке всего вот этого вот.

  • Проблема: Не все желаемое есть в консоли управления Exchange Online, вот бы туда залезть через Powershell….

Решение: Есть такой способ! Читаем здесь

В моем случае решение было таким:

первой строкой задаем политику выполнения

второй — задаем переменную которую потом используем для аутентификации (появится окошко, где надо будет ввести логин-пароль учетки администратора от служб Office365 в формате admin@my-domain.ru)

третья строка — задаем параметры сессии и четвертая строка — собственно подключаемся.

  • Проблема: получатели вашей почты жалуются, что им приходит непонятный winmail.dat вместо письма, или winmail.dat — вместо вложения в письме.

Решение: Читаем здесь  и здесь

В моем случае, решение было таким: Сначала подключаемся к Exchange Online, затем выполняем две команды

первая команда — «выключает» параметр TNEFEnable для всех исходящих писем из нашего домена (что и требовалось!)

вторая команда — «включает» параметр TNEFEnable для писем внутри нашего домена (чтоб работал функционал календарей и т.п., для которых этот формат в общем то и нужен)

  • Проблема: пользователи жалуются что не могут отправлять письма с большими вложениями.

решение: Читаем здесь и здесь

В моем случае несмотря на уверения Microsoft о по умолчанию включенном лимите в 150 Мб, лимит был все таки 35 Мб, чтоб увеличить его, пришлось сделать шаги приведенные в первой ссылке (обошлось без Powershell). Учтите, только, что изменения применяются не мгновенно, в моем случае пришлось ждать пару часов.

 

 

 

Настройка автоответов в связке Outlook — Exchange

 

Задача: настроить автоматический ответ на приходящие письма. В нашем случае это был автоответ типа «Спасибо, ваше резюме будет рассмотрено в самое ближайшее время»

Дано: Microsoft Outlook + Microsoft Exchange 2007

Continue Reading

Неправильное отображение значков Windows7: решение

В одних случаях значки файлов и папок отображаются некорректно из-за неправильной настройки, в других – из-за устаревшего кэша. Рассмотрим некоторые варианты решений.

Отображение эскизов вместо значков

Чтобы в качестве значков видеофайлов и картинок отображались эскизы, выполните следующие действия:

1. Откройте Параметры папок.

2. На вкладке Вид снимите флажок Всегда отображать значки, а не эскизы.

3. Нажмите OK.

4. Откройте Панель управления (Вид: «Крупные значки») > Система.

5. В левом меню нажмите Дополнительные параметры системы.

6. На вкладке Дополнительно в разделе Быстродействие нажмите кнопку Параметры.

7. В открывшемся окне на вкладке Визуальные эффекты установите флажок Отображать эскизы вместо значков.

8. Нажмите OK.

Сброс кэша значков

Когда пользователь открывает какую-нибудь папку, Windows 7 кэширует значки всех хранящихся в ней файлов, папок и ярлыков (в целях увеличения скорости). Иногда при изменении значков и содержимого папок кэш не успевает сбрасываться и вид значков не меняется даже после нажатия кнопки F5. В таких случаях можно вручную сбросить кэш:

1. Откройте Параметры папок.

2. На вкладке Вид в разделе Скрытые файлы и папки установите Показывать скрытые файлы, папки и диски.

3. Нажмите OK.

4. Вставьте в адресную строку проводника Windows 7 адрес:

%userprofile%\AppData\Local

и нажмите Ввод.

5. В открывшейся папке удалите скрытый файл IconCache.db.

6. Перезагрузите компьютер.

После выполнения перезагрузки Windows 7 перестроит кэш и создаст новый файл IconCache.db, после чего значки будут отображаться корректно.

Примечание. Для каждой учетной записи кэш нужно перестраивать отдельно.

Post Navigation

 
Яндекс.Метрика