Фон
Я пытаюсь развернуть образ рабочего стола с помощью последовательности задач SCCM и PXE. PXE-сервер - это виртуальная машина Server 2016 Hyper-V. На нем установлены роли сервера сайта SCCM и DP. Это удаленный сервер филиала, подключенный к серверу первичного сайта через VPN типа "сеть-сеть". Это новый сайт (то есть офисный сайт, а не сайт SCCM), который был запущен менее месяца назад. Когда этот сервер SCCM был впервые настроен на месте, создание образов отлично работало как для виртуальных, так и для физических машин.
Версия SCCM сервера первичного сайта - 5.00.8692.1000, сборка 8692.
SCCM DP находится в серверной VLAN, у которой есть SVI на основном коммутаторе. Клиент, который я пытаюсь создать, представляет собой виртуальную машину Hyper-V в VLAN сборки, которая также имеет SVI на том же коммутаторе. На коммутаторе нет списков ACL. Весь трафик может маршрутизироваться между двумя VLAN без прохождения через брандмауэр - это довольно просто. VPN-соединение типа "сеть-сеть" настроено так, что вся подсеть (10.20.0.0/16 и 10.21.0.0/16) помечается как интересный трафик с каждой стороны, и туннель VPN успешно устанавливается между этими двумя подсетями (а также некоторыми другие подсети с устаревшими серверами).
В VLAN сборки SCCM у меня есть 3 помощника IP - первые два предназначены для двух серверов DHCP, третий помощник IP указывает на сервер PXE - SCCM DP.
Эта проблема
И вот здесь все становится странно. У меня есть две тестовые виртуальные машины для Windows 10, по одной на любом из двух хостов Hyper-V. Тот, что находится на хосте Hyper-V, противоположном PXE-серверу, не получает IP-адрес от DHCP - давайте пока проигнорируем это. Тот, который использует тот же хост Hyper-V, что и сервер PXE, получает загрузку DHCP и PXE. Однако, когда Windows PE загружается и сообщает «запуск сетевых подключений» или что-то подобное, она перезагружается. Итак, я вижу экран-заставку Win PE с моим настраиваемым фоновым изображением, а затем он перезагружается перед выбором последовательности задач. На этом этапе мне удалось набрать F8, и я вижу, что у него есть IP-адрес в правильной подсети с правильными настройками шлюза и DNS. Однако, если я попытаюсь проверить связь с чем-либо, даже с шлюзом, я просто получаю сообщение «Превышено время ожидания запроса» (см. Изображение). Также коммутатор не может проверить связь с виртуальной машиной.
Командная строка с данными IP и пингом
Когда я заглядываю в журнал smsts.log, я вижу ошибку «Невозможно загрузить файл переменной PXE. Код выхода = 14. Будет повторяться «затем, наконец,» Ошибка PxeGetPxeData с кодом 0x8004016c. К сожалению, я не могу скопировать туда журналы, так как у меня нет подключения к сети, поэтому я сделал снимок экрана, чтобы поделиться здесь.
Я зеркально отразил порт и захватил пакеты с помощью wirehark ... После того, как все прошло, я получаю это при попытке пинговать:
No. Time Source Destination Protocol Length Info
52 23.358377 10.21.6.16 10.21.6.1 ICMP 74 Echo (ping) request id=0x0001, seq=24/6144, ttl=128 (no response found!)
Frame 52: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0
Interface id: 0 (\Device\NPF_{6DE772D9-E6E3-4680-AF4F-E95F725E7CFD})
Interface name: \Device\NPF_{6DE772D9-E6E3-4680-AF4F-E95F725E7CFD}
Interface description: Ethernet 3
Encapsulation type: Ethernet (1)
Arrival Time: Aug 16, 2019 09:35:16.573093000 GMT Daylight Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1565944516.573093000 seconds
[Time delta from previous captured frame: 1.300275000 seconds]
[Time delta from previous displayed frame: 1.300275000 seconds]
[Time since reference or first frame: 23.358377000 seconds]
Frame Number: 52
Frame Length: 74 bytes (592 bits)
Capture Length: 74 bytes (592 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: Microsof_00:8e:06 (00:15:5d:00:8e:06), Dst: Netgear_c4:65:28 (b0:b9:8a:c4:65:28)
Destination: Netgear_c4:65:28 (b0:b9:8a:c4:65:28)
Address: Netgear_c4:65:28 (b0:b9:8a:c4:65:28)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: Microsof_00:8e:06 (00:15:5d:00:8e:06)
Address: Microsof_00:8e:06 (00:15:5d:00:8e:06)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.21.6.16, Dst: 10.21.6.1
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 60
Identification: 0x7daa (32170)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 128
Protocol: ICMP (1)
Header checksum: 0x9cdc [validation disabled]
[Header checksum status: Unverified]
Source: 10.21.6.16
Destination: 10.21.6.1
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x4d43 [correct]
[Checksum Status: Good]
Identifier (BE): 1 (0x0001)
Identifier (LE): 256 (0x0100)
Sequence number (BE): 24 (0x0018)
Sequence number (LE): 6144 (0x1800)
[No response seen]
[Expert Info (Warning/Sequence): No response seen to ICMP request]
[No response seen to ICMP request]
[Severity level: Warning]
[Group: Sequence]
Data (32 bytes)
0000 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 abcdefghijklmnop
0010 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi
Data: 6162636465666768696a6b6c6d6e6f707172737475767761…
[Length: 32]
У меня есть еще журналы wirehark, но я не хочу сбрасывать их сюда. Заранее спасибо всем, кто может помочь!
На всякий случай, если у кого-то еще есть эта проблема - мне наконец удалось ее исправить.
Кто-то подключил наш резервный маршрутизатор 4G к VLAN сборки SCCM - это означало, что он назначал внешние IP-адреса клиентам через DHCP в середине развертывания. Это было нелегко, так как A. это было прерывистым, а B. это происходило не на экране загрузки, это произошло в середине последовательности загрузки, когда PXE перезагрузил сетевые драйверы непосредственно перед отображением меню последовательности задач. На самом деле я узнал об этом только потому, что увидел, что машина, которую я использовал для зеркалирования порта с помощью Wireshark, на самом деле получила один из этих внешних IP-адресов. Разочарование, поскольку вся эта проблема была вызвана чьей-то небрежностью при установке исправлений 😡