欢迎光临,这里是 gOxiA=苏繁=SuFan 独立的个人博客。
本站域名:http://goxia.maytide.net or http://sufan.maytide.net
移动设备请访问:http://goxia.maytide.net/m
转载文章,请务必保留出处与作者信息,未经许可严禁用于商业用途!

微软正式发布 System Center 2019

[ 2019/03/15 10:42 | by gOxiA ]

systemcenter

微软正式发布 System Center 2019

        今天微软正式发布了 System Center 2019,它是 System Center 重要的更新版本,隶属 LTSC 这意味着它有相当长的生命周期,将会获得微软长期的服务支持。目前批量授权用户及 MSDN 订阅用户均可从自己的渠道下载到该版本的 ISO。当然微软为了照顾广大的 IT 人员也提供了用于评估的 VHD 下载,便于用户能够快速在自己的虚拟化环境中进行有效的评估和体验,这些评估版 VHD 可从微软下载中心获取:

        此外,微软还在下载中心发布了用于 SCSM 的创作工具,可用于自定义和扩展 SCSM 内置的功能,如:窗体自定义,自定义类等。此外,还支持修改现有的流程管理包,并创建新的管理包。

        要了解和学习更多 System Center 相关的资讯,可访问微软官方站点:https://docs.microsoft.com/en-us/system-center/index#pivot=more

Windows 10 支持自动卸载有问题的更新补丁

        微软在3月12日发布了一篇知识库文章 - KB4492307,指出当安装更新后,由于新软件不兼容或出现问题,这些更新可能会失败。用户会收到“我们删除了一些最近安装的更新,以便从启动失败中恢复您的设备”这类的通知。当发生这一情景时,便是 Windows 检测到更新引发了问题,会自动尝试卸载最近安装的更新来解决故障问题。

        在卸载更新后,Windows 还可以在接下来的30天内自动阻止安装这些有问题的更新,而这之后才会再次尝试安装更新。

image

        在实际使用中,应该是在安装更新重启后,如果发生启动失败的情况,才会自动触发这一机制。如果真的在启动后发生应用程序运行失败等常见问题,恐怕不会触发自动卸载最近更新的动作。如果有实际体验过的朋友,不妨反馈至 gOxiA 这边分享给大家。

Surface

        在 2018 年末微软为部分 Surface 机型的 UEFI 设置提供了一个新的选项 - Battery Limit Mode。当 Surface 长时间处于充电状态下,并开启 Battery Limit Mode 后,电池主控将能够控制其充电量始终在 50%以下,这样就能够支持设备在长时间充电状态使用时延长其电池寿命。

        相信不少 Surface 使用者都会喜欢上这个功能,但是请注意 Battery Limit Mode 仅支持部分 Surface 机型,具体可参考下表。

  • Surface Pro 3 - September 10, 2018 update. UEFI version: 3.11.2550.0, EC version: 38.14.80.0 and later versions.
  • Surface 3 - December 6th, 2018 update.  UEFI version:1.51116.218.0
  • Surface Pro 4 - September 10, 2018 update. UEFI version: 108.2318.769.0, EC version: 103.2241.256.0 and later versions.
  • Surface Book - October 10, 2018 update. UEFI Version: 91.2327.769.0, EC Version 90.2226.256.0 and later versions.
  • Surface Laptop (1st gen) - January 24, 2019 update.  UEFI version: 137.2439.769 and later versions
  • Surface Pro (5th gen) and Surface Pro with Advanced LTE Model 1807 - Feature currently not available
  • Surface Book 2 - Feature currently not available
  • Surface Go - November 9, 2018 update. UEFI Version: 1.0.10.0 and later versions.
  • Surface Pro 6 - Feature currently not available
  • Surface Laptop 2 - January 24, 2019 update.  UEFI version: 137.2439.769 and later versions
  • Surface Go with LTE Advanced - Feature currently not available

        以上资料来源自微软官方知识库:KB4464941

        gOxiA 手中的 Surface Book 2 暂时未受支持,但是 Surface Pro 3 和 4 都已在列表中,以 Surface Pro 4 为例,检查 了 Surface Pro 4 的 Update History,可确认在 2018年9月的更新中改进了设备未使用电池时的稳定行。

surfacepro4_Sep2018updates

        在更新至此更新后,我们可以在 UEFI 中(电源+音量增)的 PC information 页面确认固件版本。

SurfacePro4_UEFI_Ver

        然后切换到 Boot configuration 配置中开启 “Enable Battery Limit Mode”。

enable_battery_limit_mode

有关 Enable Battery Limit Mode 更多资讯,可参考微软官方文档:https://docs.microsoft.com/zh-cn/surface/battery-limit

ADK

HOWTO: 使用 Windows ADK 生成 ADKTools

        Windows ADK 即 Windows 评估和部署工具包(Windows Assessment and Deployment Kit),可用于自定义和部署 Windows 10 映像的部署工具,其中 WinPE、USMT、DISM 等工具是桌面运维人员最为常用的部署工具,其中的 DISM 更是有别与 Windows 系统内置的 DISM,前者功能更强大,因为可以用于创建和部署 Siloed Provisioning Packages(SPP)。

        (注意:自 Windows 10 1809 开始 PE 与 ADK 分开发布)

        前面已经提到,ADK 中包含了桌面运维人员最为常用的部署工具,如果要在不同的设备上使用,默认则需要安装 Windows ADK,这样执行效率就大打折扣。其实 Windows ADK 中的工具多数都支持免安装运行,我们只需要在一台设备上安装完毕后,将所需的工具复制出来即可,但是手动复制各个工具所涉及的文件非常不便。

        其实,Windows ADK 中内置了一个脚本,可以方便我们生成所需的 ADKTools,其中包含了 DISM、USMT,以及 Windows Setup 的相关文件。要使用该脚本,需要从 Windows Kits 程序组中找到“Deployment and Imaging Tools Environment”(部署和映像工具环境)并运行它。

        然后,键入“CopyDandI.cmd amd64 d:adktools”执行自动复制,脚本会将适用于 64位系统的相关文件统一复制到指定的目录中。

copydandi

adktools_list

        最后我们将这个目录放到一个共享位置,或 U盘中即可,当然也可以集成到 PE Boot.wim 中。有了这个 ADKTools 后,我们就可以创建和部署 SPP,以及执行用户数据迁移等工作。

WDS_logo

HOWTO: 解决 WDS 无法导入 Realtek PCIe GBE Family Controller 驱动的问题

        一台基于 Windows Server 2012 的 WDS 服务器,为 Lenovo M910t 机型添加驱动,发现 Realtek PCIe GBE Family Controller 驱动无法导入,其文件名为 rt64win7.inf,属于 64位体系架构驱动。

Snipaste_2019-02-21_08-49-13

        在添加过程中仅提示某些程序包无法添加到服务器中,但并没有给出具体的失败原因。可参考的常见原因是驱动未签名,驱动程序包损坏或网络连接问题。

Snipaste_2019-02-21_08-49-49

Snipaste_2019-02-21_08-50-10

        经测试,该驱动可直接集成到系统映像(WIM)中正常安装和使用,检查发现驱动签名也是正常的,极有可能是该驱动与 WDS 不兼容,也尝试下载了其他版本的驱动发现均发生此类问题。由于 PE10 引导后可正常驱动该网卡,所以临时的解决方案即在 WIM 中集成该驱动。在 Windows 10 中由于 DISM 可以直接管理 WIM,所以 IT 人员可以直接使用 DISM Mount WIM,并将驱动集成到映像中,操作过程中使用到的命令行参考如下:

  1. Dism /mount-image /imagefile:d:\goldimages\customizeos.wim /index:1 /mountdir:c:\mount\windows
  2. Dism /image:c:\mount\windows /add-driver /driver:d:\drivers\realtek /recurse
  3. Dism /unmount-image /mountdir:c:\mount\windows /commit

        若要使用命令行对 WDS 已经添加的安装映像可使用 wdsutil /replace-image命令,参考命令行:

  1. wdsutil /replace-image /image:"Windows 10 Pro x64" /imagetype:install /replacementimage /imagefile:"d:\goldimages\customizeos.wim

        近期从 Realtek 官方下载了最新发布的网卡驱动,发现在驱动程序包中有一个提示文本文件,如下图所示!

Snipaste_2019-02-21_09-41-19

        按照 Realtek 官方的建议,将 Realtek PCIe GBE Family Controller 驱动包中的 WinPE 驱动添加到 WDS,此问题即可解决,且网卡也能正常使用。

winsrv2019_logo

关于 Dell 11 和 12 代服务器启用 Hyper-V 2019 后发生启动死循环

        Windows Server 2019 在 Dell 11 和 12 代服务器上,当启用 Hyper-V 角色重启后进入死循环的问题终于得到了解决。需要安装 1月22日发布的汇总更新 - KB4476976,系统版本会升级到 17763.292,由于要过中国年的关系,本文发稿时已是 17763.316,所以还请各位遇到问题的朋友升级到最新版本。

        该问题的具体症状是 gOxiA 手中的Dell T310 和 T610 服务器为了能使用更大容量的分区(>2TB)改用了 UEFI 引导模式并使用了 GPT 格式磁盘,早先安装使用 Windows Server 2016 是正常的,随后在 Windows Server 2019 发布后,全新安装了它,但发现只要启用了 Hyper-V 角色后,系统在第二次重启后并会进入死循环,无法正常引导系统并反复的重启。

        也向 Dell 官方寻求帮助,可惜服务器属于11代实在太老,以 OS 不再支持列表未能提供有效的解决方案,但是 Dell 的 12 代服务器也有发生类似的问题,据说与 Dell UEFI 有关,所以改为 BIOS + MBR 后问题得到了解决,也算一个 Workaround。

        估计遇到的同样问题的用户较多,而且也都有效反馈到了微软那边,所以在19年1月底该问题终于得到了修复 ,此时已是中国年开始,gOxiA 利用假期时间做了测试,在先安装 KB4476976 后,再启用 Hyper-V 则不会重现故障。

Snipaste_2019-02-19_10-50-32

微软发布 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

分页: 1/177 第一页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]