微软发布 MDT 8456

[ 2019/01/28 13:47 | by gOxiA ]

image

微软发布 MDT 8456

        中国当地时间1月26日,正值周末,也临近新年,但 gOxiA 早已养成早起的习惯,上了推才发现圈内人士都在转发 MDT 的最新推文,原来是微软发布了 Microsoft Deployment Toolkit 的最新版本 MDT 8456

        在这一版开始支持 Windows 10 / Server 2019 的 1809版本,并且可与 Configuration Manager 1810 进行集成。功能方面并没有带来太多的惊喜,嵌套任务序列的支持是本次更新带来的新功能。此外,MDT 8456 仍继续支持部署 Windows 7 操作系统,所以 IT 人员不要犹豫,为了能够提供更完善的 Windows 10 部署,建议升级到 MDT 8456。有关本次更新版本的具体信息,可参考微软官方文档。

https://docs.microsoft.com/en-us/sccm/mdt/release-notes

        升级到 MDT 8456 非常容易,从微软下载中心拿到 MDT 8456 后可直接在当前 MDT 环境执行升级安装,他会自动卸载当前旧的 MDT 版本,并使用新版替代。

1

        在完成升级安装后,打开 MDT 的 Deployment Work Bench 会看到提示,要求对当前部署点进行更新。我们可以在左侧的部署共享列表中选中部署点然后执行“Upgrade Deployment Share”,这样就会自动更新部署点内的相关脚本和文件。

2

        在部署点升级完毕后,我们仍旧需要执行“Update Deployment Share”来更新我们的 LTI PE,如果之前有创建过媒体部署,也需要进行更新。

MDT 8456 下载地址:https://aka.ms/mdtdownload

为什么我的 Windows 10 系统会有很多 SVCHOST 进程

        有不少网友反应自己 Windows 10 的系统中会运行很多 svchost.exe 进程,怀疑自己的系统有问题?!其实相对于现在来讲,这是一个正常的现象。

1

         因为微软自 Windows 10 1703 开始重新设计了 Windows 服务的运行机制。对于内存超过 3.5GB 的 Windows 10 系统,其运行的服务将以独立运行的方式通过 Svchost.exe 进程运行。如果你的内存少于 3.5GB,那么这些服务将会自动分配到共享的 Svchost.exe 进程中运行,这也是 1703 版本以前 Windows 服务默认的运行方式。

        分离 Svchost 运行服务所带来的好处是显而易见的:

  • 通过将关键网络服务与主机中的其他非网络服务的隔离,并在网络组件崩溃时添加无缝恢复网络连接的能力,提高了可靠性。
  • 通过消除与隔离共享主机中的行为不当服务相关的故障排除开销,降低了支持成本。
  • 通过提供额外的服务间隔离来提高安全性。
  • 通过允许每项服务设置和权限来提高扩展性。
  • 通过按服务CPU,I/O和内存管理改进资源管理,并增加清晰的诊断数据(报告每个服务的CPU,I/O和网络使用情况。)

        在过去,Windows 将服务与匹配的安全性要求相结合来确定共享的服务主机组。

  • 本地服务
  • 本地服务无网络
  • 本地服务网络受限制
  • 本地系统
  • 本地系统网络受限制
  • 网络服务

        下图是分离和共享服务主机(Svchost.exe)进程的运行对比。

23

        虽然分离机制已经在 1703 及之后版本的 Windows 10 上应用,但是某些服务仍将继续通过分组方式共享服务主机(Svchost.exe)进程。例如,Windows 防火墙(mpssvc - Windows Defender Firewall)和基本筛选引擎(BFE - Base Filtering Engine),远程过程调用(RpcSs - Remote Procedure Call)和 RPC 终结点映射器(RpcEptMapper - RPC Endpoint Mapper)。

        如果需要识别这些分离和继续分组的服务,除了可以通过任务管理器的进程选项卡来查看 Service Host(服务主机)信息意外,还可以通过详细信息选项卡查阅 svchost.exe 的命令行。

4

        此外微软也提供了通过注册表项检查的办法,打开注册表编辑器定位到“HKLM\SYSTEM\CurrentControlSet\Services”下,查看每个服务下“SvcHostSplitDisable”的值即可,当值为“1”时则表示服务禁止拆分。

HOWTO: 使用 DISM 配合脚本批量删除驱动程序

        利用 DISM 或 Pnputil 我们已经能够实现脱机或在线模式批量安装硬件的驱动程序,那么如何能够实现批量卸载已经集成到映像中的驱动程序呢?!

        假设我们的映像编制人员为 Surface 设备创建了定制化的系统映像,并集成了 Surface 的设备驱动程序,现在我们希望编制好的映像可以作为通用映像部署在其他计算机上,这时我们就需要清理已经集成在映像内的驱动程序。

        要卸载映像内集成的第三方驱动程序,我们首先需要列表出来它们,所以为此我们执行如下命令行。

dism /image:c:\ /get-drivers

get-drivers

        利用上述的参考命令我们可以检索到当前映像中已经安装的硬件驱动程序,其中“已发布的名称:oemX.inf”是我们需要记录的数据。接下来使用下例命令行就可以从映像中卸载驱动。

dism /image:c:\ /remove-dirver:oemX.inf[code]

        细心和已经在使用该命令管理的驱动的朋友会注意到,由于映像中第三方驱动可能会很多,有时多大近70个,那么我们就需要一次一次执行上面的卸载驱动命令,将 oemX.inf 从映像中删除,这将是一件令人崩溃的任务。有些朋友可能会利用 Excel 批量转换和生成指令,其实我们完全可以利用批处理命令“For ... Do ...”来实现。

        实现逻辑就是利用 DISM 的 Get-Drivers 参数获取驱动列表,并查找其中的唯一特征,例如下图所示我们能看到所有被列出的第三方驱动程序都不是“内置驱动程序”,那么可以用它来作为检索关键词。

[code]dism /image:c:\ /get-drivers /format:table

get-drivers_table

        我们有了用于检索的关键词,就可以使用“find”来获得准确的驱动列表,可创建变量以生成动态驱动列表,便可以实现动态批量卸载驱动,参考脚本如下:

for /f %%a in ('dism /image:c:\ /get-drivers /format:table ^|find \"|否\"') do (dism /image:c:\ /remove-driver:%%a)

        以上脚本可以从 gOxiA 的 Github 获取。https://github.com/goxia/ITSM/blob/master/remove_driver.bat

troubleshooting

排查 Windows 必须关闭所有会话框才能关闭 MMC 的故障问题

        在 Windows 系统的日常操作中,我们经常会遇到这样一种故障问题,当要关闭基于 Microsoft 管理控制台(MMC)的程序时,会提示我们必须先关闭所有会话框,但实际上我们已经关闭了 MMC 下对应设置的属性对话框,当反复切换几次后,才能正常关闭 MMC。

hyper-v_mmc_error

        这种问题在 Hyper-V 管理器、服务管理器中尤为突出。那么造成这种问题出现的原因是什么呢?!使用何种工具能协助我们排查这类故障?!

        我们可以使用微软官方工具 Spy++ 来排查这类问题,Spy++隶属于 Visual Studio 的组件,它支持绿色方式运行,利用 Spy++ 可执行下列任务:

  • 显示系统对象之间关系的图形树,这些对象包括:进程、线程和窗口。
  • 搜索指定窗口、线程、进程或消息的属性。
  • 直接从视图中选择窗口、线程、进程或消息。
  • 使用查找程序工具,通过鼠标指针定位选择窗口。
  • 使用复杂消息日志选择参数设置消息选项。

        对于本案例要使用 Spy++ 排查原因,需要在故障重现时启动 Spy++,然后切换到线程视图,再点击工具栏上的“Find Window”图标,通过拖拽标靶图标到要监视的 Windows 对话框上来定位窗口。

FindWindow

        之后在弹出的 Property Inspector 对话框中单击 Synchronize 按钮,即可在 Spy++ 的线程列表视图中,同步定位到这个窗口。

PropertyInspector

        接下来便可审查这个进程中的子线程,看看是否存在可疑项。本例中发现的可疑线程是必应输入法,当尝试切换输入法后,故障消失,可正常关闭 MMC。

Trouble

        而对于大多数安装了第三方输入法,尤其是使用搜狗输入法的朋友,相信这类问题更为常见,所以可切换关闭搜狗输入法,该问题便会消失。此外,如果你尝试使用 Spy++ 进行排错,需要注意它区分 32 和 64 位版本。有关 Spy++ 的详细信息可参考微软官方资料。

https://docs.microsoft.com/en-us/visualstudio/debugger/spy-increment-help?view=vs-2017

在 Azure 中创建 Upgrade Readiness 以管理 Windows 10 升级

        Windows 7 EOS 的日子所剩无几,更多的企业开始着手将更多的设备升级到 Windows 10,但是 IT 人员心里都非常清楚升级到新操作系统是一项非常具有挑战性的工作,已交付的众多应用程序和驱动是否兼容新的 Windows 10,是否具有潜在的兼容性问题,它们成为 IT 不能不面对的问题。

        有不少同行朋友向 gOxiA 咨询微软是否提供有一种工具,可以帮助评估企业 IT 化境下的 Windows 设备,是否具体升级到 Windows 10 的能力,并且只需投入很少的精力和成本,最好基于云来实现?!

        Windows 10 的 Upgrade Readiness 工具便可满足这些用户的需求,其利用 Windows 诊断数据功能,收集系统、应用程序和驱动数据以供分析,以便帮助 IT 人员确定可能阻止升级的兼容性问题。

        Upgrade Readiness 提供了一种可视化的工作流程,以及丰富的计算机和应用程序库,为用户提供有关应用程序和驱动兼容性相关问题的指导和见解,以及建议的修复。并允许将收集的数据导出到常用的软件部署工具中,如SCCM。

        通过下图我们来了解一下 Upgrade Readinesss 在典型场景中的工作方式。

升级准备架构

        在用户计算机上启用 Windows 诊断数据后,用户计算机通过微软数据管理服务将计算机、应用程序和驱动诊断数据发送到 Azure,在 Upgrade Readiness 就绪后,其会将分析诊断数据推送到 OMS 工作区,然后我们便可以使用 Upgrade Readiness solution 来规划和管理 Windows 10 升级。

        接下来 gOxiA 将演示如何在 Azure 中创建 Upgrade Readiness,首先登录到 Azue ortal 创建资源,通过搜索框找到“Upgrade Readiness”,并创建该资源。

0

        随后跟随向导创建OMS 工作区,如下图所示。

1

2

        等待片刻待 Upgrade Readiness 创建完毕后,便可进入 Upgrade Readiness solution 面板,在 Upgrade Readiness Settings 中我们能够获取到“商用 ID 键”,复制它到后面的 Upgrade Readiness 部署脚本中,即可在客户端计算机上执行以收集相关数据。此外,我们还可以根据需要选择 Windows 10 的版本,如当前最新的为 1809,待客户端上执行脚本后,便可以执行“生成报告”。

4

        Upgrade Readiness 部署脚本可从微软下载中心获取到,其下载地址是:

https://go.microsoft.com/fwlink/?LinkID=822966&clcid=0x409

        下载到 Upgrade Readiness 部署脚本后,解压缩对于较小规模的环境,可以选择使用 Pilot 版本的脚本,并需要编辑 RunConfig.bat 将前面提到的商业ID 填写到“set commerciallDValue”中。

5

        最后在一台准备升级到 Windows 10 的 Windows 7 设备上执行 Pilot 版本的脚本,如果运行成功,则回到 Azure Portal 的 Upgrade Readiness Settings 页面下,点击生成报告。(PS:通常需要等待一段时间报表才会生成数据。)

3

        如下图所示便是 Upgrade Readiness 生成的分析报表,我们可以基于它管理我们的 Windows 10 升级过程。

6

分页: 1/1 第一页 1 最后页 [ 显示模式: 摘要 | 列表 ]