Author Archives: Acherepov

Проверить работоспособность NTP-сервера из Windows

Сделать это можно утилитой w32tm

 w32tm /stripchart /computer:SERVERNAME /dataonly /samples:5 

В результате отправляются 5 NTP-запросов на сервер SERVERNAME

Ответ получим примерно такой:

Tracking 10.10.7.5 [10.10.7.5:123].
Collecting 5 samples.
The current time is 14.02.2018 16:16:13.
16:16:13, +00.0310803s
16:16:15, +00.0398755s
16:16:17, +00.0287343s
16:16:19, +00.0301553s
16:16:21, +00.0322173s

WDS-сервер и TFTP-error 13

С некоторых пор при попытке установки образа через WDS-службу стала вываливаться ошибка не доходя даже до этапа выбора диска для установки.

На стороне клиента это выглядит как зависание и последующая ошибка на экране загрузке boot.wim

На стороне сервера в журналах WDS это проявляется примерно так:

The Following Client failed TFTP Download:
Client IP: 10.10.1.3
Filename: \Boot\x64\Images\boot.wim
ErrorCode: 13
File Size: 291959795
Client Port: 9956
Server Port: 53793
Variable Window: true

Причина: обно из последних обновлений Windows неожиданно включило опцию «Enable Variable Window Extension» во вкладке TFTP в настройках WDS-сервера.

Решение: выключить опцию (снять галочку) «Enable Variable Window Extension» во вкладке TFTP в настройках WDS-сервера.

Боже храни Интернет и пошли кару небесную QA-инженерам Microsoft!

Не устанавливаются обновления Windows Update с ошибкой 800f0831

Иногда при установке обновлений Windows происходят ошибки, и иногда они влияют не только на одно конкретное обновление, но и начинают мешать в дальнейшем.

Ниже набросаю чеклист, для борьбы с этим неприятным явлением с примерами из моей практики

Симптом: не устанавливаются обновления Windows Update с ошибкой 800f0831. Это касается не всех подряд обновлений, а какой-то части из них. Проблемы с установкой могут тянуться месяцами, без особого влияния на сервер в целом.

  1. Проверьте логи CBS, они расположены тут:
    C:\Windows\Logs\CBS\CBS.log
    Обычно в них можно найти строку с упоминанием о проблеме поиском вхождения «, Error» (В нашем случае это: Failed to resolve package ‘Package_1103_for_KB4462926~31bf3856ad364e35~amd64~~6.3.1.5’ [HRESULT = 0x800f0831 — CBS_E_STORE_CORRUPTION]). Часто там ссылаются на ранее некорректно установленное обновление, или побитое хранилище. Запоминаем виновника торжества (в нашем случае это KB4462926 Конкретная часть Package_1103 — нам не принципиальна. Все равно удалять\лечить будем все KB целиком)
  2. Пробуем установить разные обновления по отдельности, каждый раз проверяем CBS-лог, убеждаемся, что проблема именно в этом самом криво установленном обновлении
  3. Идем на http://catalog.update.microsoft.com и скачиваем интересующее нас обновление из первоисточника
  4. Распаковываем его из MSU до *.cab (можно обычным 7-zip, например)
  5. Дальше начинаем играться разными методами. Какой именно сработает — сложно предсказать
    1. Перенастраиваем источник обновлений на глобальный Windows update (отключаем от WSUS если он используется)
    2. Удаляем в WSUS запись для этого сервера (если он тянет обновления именно с WSUS). Это нужно, т.к. при настройке на WSUS могут некорректно отрабатывать ключи /Online в утилите DISM. Подробнее тут
    3. Пробуем полечить хранилище с помощью команд
      DISM /Online /Cleanup-Image /CheckHealth (проверяет «флаг состояния хранилища». время выполнения 10-20 сек)
      DISM /Online /Cleanup-Image /ScanHealth (собственно сканирует само хранилища на предмет онаружения в нем ошибок. Время выполнения 10-20 мин)
      DISM /Online /Cleanup-Image /RestoreHealth (пытается полечить хранилище. время выполнения 10-20 мин)
    4. Часто вышеприведенные команды не дают результата, поэтому идем далее. Пробуем удалить битое обновление командой DISM /online /remove-package /packagepath:E:\Distrib\KB4462926\unpack\Windows8.1-KB4462926-x64.cab Используем именно ключ /packagepath с полным путем к распакованному обновлению
    5. Если после удаления «битого обновления» нормальные все равно продолжают на него ругаться, что ж попробуйте заново установить это битое обновление. И тут есть нюанс: если просто жмакнуть на MSU файл, система ругается что обновление для нее неподходящее и не ставит его. А вот если запустить команду
      DISM /online /add-package /packagepath:E:\Distrib\KB4462926\unpack\Windows8.1-KB4462926-x64.cab то обновление нормально добавляется в хранилище.

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.

Post Navigation

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