2024年5月24日发(作者:)
责任编辑:赵志远 投稿信箱:
netadmin@
故障诊断与处理
Trouble Shooting
MDT 2013使用UEFI
引导安装Windows 10故障
■ 江苏 沈浩
当前Windows
编者按:
此次只能通
笔者通过UEFI的PXE网卡启动安装Windows
统,
10操作系统使
10系统,却发现启动WDS引导后报错,在网上查到类似
过UEFI的PXE
网卡启动安装
Windows 10系
用越来越普遍,
的解决方法并不能解决该问题,只能自己解决。
现有新采购的电
脑都只支持安装
Windows 10操作系
统,此次单位新采
购了一批DELL台
式电脑,开机只支
持UEFI方式了。
以前的电脑一直
使用MDT 2013通
过Legacy+MBR方
式来部署操作系
图1 更改DHCP下067的启动文件
统。
使用UEFI方
式PXE引导需要更
改DHCP下067的启
动文件:bootx86
改为
bootx64wdsmgfw.
efi,此文件在安装
MDT 2013后就有,
如图1所示。
【上接第148页】
拓扑上电后
C2发起ARP请求,包含它的
IP2和MAC-a。SW1和S收到
后有不同的动作:SW1更新
MAC-a在端口3方向,S在自
己的ARP表里添加记录IP2
和MAC-a映射关系。
接着C1发起ARP请求,
包含它的IP1和MAC-a,SW1
更新MAC-a在端口2方向,S
的ARP表添加IP1和MAC-a
映射关系。
倘若S向C2发送心跳数
据,数据帧目的MAC地址是
MAC-a,目的IP是IP2。SW1
收到数据后在MAC地址表里
寻找MAC-a对应的端口,由
于最后一次ARP请求是由C1
发起的,C1刷新SW1中MAC
地址表,最终SW1将数据发
往端口2,由于C1的IP并不
是数据帧期望的IP2不匹配,
所以C1丢弃数据帧,而C2
将长时间收不到S的数据,
出现“服务器心跳超时”断
开连接。
ARP表默认5分钟后过
期,也就是为什么C2断开后
10秒重连接失败的原因,直
至4
~
5分钟ARP表过期重发
起ARP请求,刷新SW1的MAC
地址表才连接成功。C1和
C2的MAC冲突属于竞争模
式,相互刷新SW1的MAC地
址表和S的ARP表,带来的
结果是不定时掉线。
2020.01
149
Trouble Shooting
故障诊断与处理
责任编辑:赵志远 投稿信箱:
netadmin@
可是使用UEFI的PXE启
动WDS引导后报错误,如图
2所示。
一时间毫无头绪,查过
资料报这个错误0x102表示
“服务器不可用”,网上有这
几种说法:
1.你的(UEFI)客户端
一旦加载了WDS固件,便不
再具有网络连接
2.你的服务器(在BIOS
模式下可以正常工作)拒绝
来自您的UEFI客户端的请
求。
3.你的DCHP配置错误,
但没告诉我错在哪里!认为
你的UEFI客户端无法正确
获得IP地址。
这些解释都不靠谱,无
法获IP地址为什么BIOS引
导就可以,固件加载后无法
联网更说不通了。
笔者认为从现象来看还
是主要此导文件无法正常说
别所致,DHCP指向的引导文
件存放在MDT(WDS)服务器
的 RemoteInstall文件夹下
的Boot目录,查看发现该文
件存在对比后字节数和生成
日期正常,不可能存在无法
识别的问题。如图3所示。
咨询了DELL厂商也没有
这方面的相关解决方案。
图3 字节数和生成日期正常
图2 使用UEFI的PXE启动WDS引导后报错
故障解决:无法使用
UEFI的PXE方式正常引导,
也无法启动MDT 2013生成
PE引导进行操作系统部署
界面。在仔细查看后发现
文件的生成日
期与其他文件相比为2015
年,感觉有点旧了,在查询了
微软文档后发现在Windows
Server服务器目录下也有
该文件的存在,目录路径
为C:WindowsSystem32
RemInstbootx64。
在此处查看发现其
文件字节数和
生成日期与前面后有所不
同,将该文件拷贝到WDS安装
目录生成的RemoteInstall
共享目录下bootx64替
换了该文件后启动正常了。
能使用UEFI方式进行PXE
引导启动MDT进入操作系统
部署界面。
从生成日期和字节数
来看原有文
件太老,经过测试不同版
本的服务器WDS服务自带
的文件也各
不相同。如拷贝后还无法
正常启动,说明该版本与新
电脑UEFI版本有兼容性问
题,建议使用最新的Windows
Server 2019WDS服务自带的
引导文件。
150
2020.01
发布评论