HOWTO: 为 Windows 自动添加配置无线网络

        由于 Windows 应答文件(Unattend.xml)中并未包含自动配置 WiFi 的选项,而在企业中确实存在为定制的标准化系统映像预先添加企业 WiFi 的需求,或者希望将一个脚本包发给用户,可以自动添加和配置无线网络。为此,微软在 Windows 10 上推出了新的配置工具 WICD,即:Windows 映像和配置设计器,可以轻松实现多种场景需求。

        以自动添加和配置无线网络为例,新建一个“高级预配”,然后在左边配置列表中找到“运行时设置-ConnectivityProfiles-WLAN-WLANSetting”,根据需要添加并设置其下的参数。如果要配置的 WiFi 不允许自动连接,可将“AutoConnect”设置为“FALSE”;一些企业默认的办公用途公共 WiFi 通常会进行隐藏,所以为此需要为此类型的 WiFi 启用“HiddenNetwork”;“SecurityType”和“SecurityKey”这是 WiFi 网络的安全协议和密钥。

ICD_AdvPreCon

ICD_WLANSetting

        当配置工作完成后,便可以导出这个预配包,格式为 .PPKG,可以在 Windows 10 系统上执行运行。

ICD_Export

ppkg_detail

        因为配置包通常都非常小,IT人员可以通过邮件发送给用户自助执行,当然也可以使用 DISM 在向标准化映像添加,或在映像初始化中自动执行,具体的命令行参考如下:

DISM.exe /online /Add-ProvisioningPackage /PackagePath:C:\oem.ppkg

        企业 IT 人员对于早期的 Windows 系统版本,如 Windows 7,也有非常高的需求。那么该如何实现呢?!

        使用 Netsh 可以在 Windows 7 上轻松实现以上的过程。首先找一台电脑连接到 WiFi,之后执行以下命令行,将无线配置导出为一个 xml 文件。

netsh wlan export profile name=\"SSIDNAME\" folder=d:\WiFiProfiles interface=\"Wireless Network Connection\" key=clear

        如果要在其他电脑上导入这个 WiFi 配置,则需要执行以下命令。

netsh wlan add profile filename=d:\WiFiProfile\SSIDNAME.xml

        在应用无线配置文件时,需要注意,如果当前 WiFi 是一个隐藏网络,且不允许自动连接,那么需要检查无线配置文件,并对主要参数进行修改。对于隐藏网络,需要将“nonBroadcast”设置为“TRUE”;而连接模式“connectionMode”设置为“manual”。

wlanprofile

Windows 优化分析

[ 2018/06/22 10:08 | by gOxiA ]

Windows-logo

Windows 优化分析

        Windows 计算机的性能和稳定性总是相互影响的。提升性能又兼顾稳定性,需要科学、反复的实践才能应对持续发展的复杂IT化境。而 Windows PC 性能的直观表现主要归为以下几个方面:

一、启动速度

         Windows PC 的启动速度,以秒为测量单位(实际监测和分析中可达到纳秒级),其对于用户的感知和体验尤为重要。排除硬件自身的启动过程(BIOS启动)所消耗的时间,加载操作系统到进入桌面欢迎界面,直到用户登录域能以正常响应速度进行操作,要经历一系列复杂的过程,涉及 PC 资源和模块的方方面面。

         无论用户是否能切身感受到它,这一过程始终在一定的时间内持续进行。Windows 系统的启动过程,可参阅下图:

1538.WindowsBootProcess

        加入到AD域的Windows计算机上的操作系统启动和用户登录延迟,通常要耗费几十到上千秒。因为现实情况中存在许多原因,包括硬件性能,网络性能,IT添加的工作负载量,以及应用程序和操作系统组件中的低效率。

        在OS初始化阶段,大部分操作系统工作都会发生。此阶段涉及内核初始化,即插即用活动,服务启动,登录和资源管理器初始化。操作系统初始化可以分为四个子阶段,每个子阶段都有独特的特征和性能漏洞。

BootPhases

  • 子阶段1 – Pre Session Init(PreSMSS):内核初始化
    PreSMSS子阶段在内核被调用时开始。在这个子阶段,内核初始化数据结构和组件。它还启动PnP管理器,该管理器初始化在OSLoader阶段加载的Boot_START驱动程序。
  • 子阶段2 – Session Init(SMSSInit):会话初始化
    当内核将控制传递给会话管理器进程(Smss.exe)时,SMSSinit子阶段开始。在此子阶段期间,系统将初始化注册表,加载并启动未标记为Boot_START的设备和驱动程序,并启动子系统进程。当控件传递给Winlogon.exe时,SMSSInit结束。
  • 子阶段3 – WinLogon Init:Winlogon初始化
    当SMSSInit完成并启动Winlogon.exe时,WinlogonInit子阶段开始。在WinlogonInit期间,出现用户登录屏幕,服务控制管理器启动服务,并运行组策略脚本。当Explorer进程启动时,WinlogonInit结束。
  • 子阶段4 – Explorer Init:资源管理器初始化
    ExplorerInit子阶段在Explorer.exe启动时开始。在ExplorerInit期间,系统创建桌面窗口管理器(DWM)进程,该进程初始化桌面并首次显示它。
  • Post Boot阶段
    PostBoot阶段包括桌面准备就绪后发生的所有后台活动。用户可以与桌面进行交互,但系统仍可能在后台启动服务,托盘图标和应用程序代码,这可能会影响用户对系统响应的感知。

二、内存占用

         从系统开机过程可以理解和认识到用户终端的性能取决于计算机的四个主要资源:内存、处理器、磁盘和网络。其中内存部分,微软Windows系统使用多种内存,具体可分为物理内存、提交内存、应用程序虚拟内存和内核虚拟内存。基于微软官方的性能计数器指标,可以指出每个响应资源的潜在问题,并通过Windows性能计数器识别最初的性能问题。

  • 物理内存,识别物理内存是否出现性能问题的最好办法,是监控“MemoryAvailable MBytes”,当其小于100MB或小于总物理内存的5%~10%,则计算机可能在物理内存上运行严重不足,出现性能问题。因为此时会增加系统对磁盘子系统的依懒性,如果磁盘子系统不堪重负,则可能发生系统范围的延迟。相反,如果它高于10%则可将物理内存用于磁盘缓存。系统具有的磁盘缓存越多,避免磁盘I/O的机会就越大。磁盘比物理内存慢得多,所以需要大磁盘缓存。(注意:较低的内存占用是理想的优化目标,但在可用内存不足的情况下并不好。)
    AvailableMBytes
  • 提交内存,提交的字节数是提交虚拟内存量,以字节为单位。提交的内存是磁盘页面文件上保留了空间的物理内存。换句话说,它是由进程“使用”的内存。提交内存是操作系统可以用来存储数据的所有物理资源的总和,是内存和所有页面文件的总和。一旦所有的内存和所有的页面文件已满并且无法展开,那么系统已达到其提交限制。使用“MemoryCommitted Bytes In Use”大于75%,则计算机可能在物理资源(内存和/或页面文件)上运行不足。
    CommittedBytesInUse
  •     应用程序虚拟内存,Windows 中的每一个进程都有自己的专用虚拟地址空间。理想情况下,虚拟内存应用是大的难以想象,但事实是它是一个有限的资源。如果应用程序(用户模式)用完了虚拟内存,那么它可能会因内存不足异常而崩溃。要确定应用程序的最大虚拟地址空间,可使用以下命令确定应用程序虚拟内存的最大大小:
    wmic PATH Win32_OperatingSystem GET MaxProcessMemorySize

    Windows 7 x64计算机的示例输出如下:
    MaxProcessMemorySize

            MaxProcessMemorySize为8589934464,输出以千字节为单位,因此,这台Windows 7 x64计算机每个进程具有8TB的虚拟内存。如果应用程序(用户模式)的虚拟内存耗尽,即它接近MaxProcessMemorySize,那么它可能会因内存不足异常而崩溃。要判断虚拟内存不足,可通过“Process (*)Virtual Memory”,超过MaxProcessMemorySize的80%,那么应用程序很可能会用尽虚拟内存,并且如果无法为其下一次内存分配找到连续内存,可能会很快崩溃。此外,在虚拟内存概念中指出,进程并不知道物理硬件。每个进程都有自己的私有虚拟地址空间,这是有限数量的虚拟内存。这允许Windows操作系统更有效管理物理内存资源(内存和磁盘页面文件)。如果一个进程视图超过它的虚拟地址空间,那么它会因为内存不足出现异常而崩溃。每个进程的虚拟内存量取决于它是否编译为32位或64位。X86是Windows的32位实现;x64是Windows的64位实现。其中,x86进程默认具有2GB的虚拟地址空间;具有大量地址识别功能并在x64操作系统上运行的x86进程具有4GB的虚拟地址空间;x64进程具有8TB的虚拟地址空间。

  • 内核虚拟内存,内核也驻留在虚拟内存中,如果虚拟内存不足,则操作系统可能会挂起。内核有三个重要资源,即虚拟内存中的资源:系统页表条目(PTE),池分页和池非分页内存池。其中系统页面表条目提供了虚拟内存和物理内存之间的映射。使用“MemoryFree System Page Table Entries”进行监测,当小于10000,那么操作系统可能会遭受长时间的性能延迟。池分页和池非分页池用作操作系统和设备驱动程序用来存储其数据结构的内存资源。当它们无法分配内存时,操作系统可能会遭受长时间的性能延迟,通过对“MemoryPool Paged Bytes”或“MemoryPool NonPaged Bytes”的监测,当接近或超过其各自最大值的80%,则操作系统可能会遭受长时间的性能延迟。

三、处理器占用

        处理器(CPU)方面,当“Processor (_Total)%Processor Time”平均大于80%,则计算机可能正忙于处理资源调度。此外,处理器中还包含线程,即进程的工蜂,其以两种模式之一执行:用户模式或特权模式,可通过相关指标进行监测:“Process (*)%User Time” 和 “Process (*)%Privileged Time”,二者组成“Processor (_Total)%Processor Time”。其中,特权(内核)模式是在执行系统调用的Windows内核(如驱动程序、IRP(I/O请求数据包)、上下文切换等等)中花费的时间。如果操作系统花费超过特定模式的30%,那么这意味着它可能执行大量的I/O并且一个或多个驱动程序正在执行以管理该I/O。用户模式,是处理器花费在执行应用程序代码上的时间量,因此需要确定哪些进程消耗了大部分时间以及执行最多的函数调用。可通过用户进程的内核时间或“Processor (*)%User Time”进行识别。

UserTime

四、磁盘占用

        终端磁盘不仅用于存储重要的数据,也是影响终端整体性能的关键因素之一。虽然目前磁盘容量已经非常大,但其硬件参数并不一定完全满足现实 IT 环境的性能需求。关键的磁盘性能指标如下:

  • “LogicalDisk (*)Avg Disk Sec/Read”,以毫秒表示的值,因此在1秒样本取样中,将在1秒间隔内运行平均读取持续时间,并以毫秒为单位给出平均延迟时间。
  • “LogicalDisk (*)Avg Disk Sec/Write”,同上,但仅表示写入时间。

        一般而言,这两个值始终应在生产 IT 环境中低于15ms(0.015秒),否则说明计算机可能存在磁盘性能问题。但是,这些阈值只是假定传输大小为64KB或更小的文件。如果要移动较大容量的文件,则需要调整预期值,此时就需要考虑Disk Bytes/sec和Disk Transfers/sec因素。此外,关于磁盘性能的任何讨论都不能通过其容量以及物理性能特征来完成。制造商列出了大部分重要或相关指标,以便进行产品比较。平均搜索时间、平均写入时间或平均读取时间,以及内部控制器上的缓存数量,旋转速度,支持的技术(如本地命令队列)和物理特征(如接口,盘片大小等)。

        例如,一块希捷商用台式机驱动器。

  • 自转速度为7200转;
  • 持续的数据传输速率为138Mb/s;
  • 平均延迟4.16ms;
  • 随机读取寻道时间8.5ms;
  • 随机写入寻道时间9.5ms;
  • I/O数据传输速率600MB/s。

        该磁盘支持6Gb/秒的SATA接口,具有64MB板载高速缓存并具有2TB容量,转速是7200转。虽然其接口速度为6Gb/秒,但持续数据传输速率仅为138Mb/sec。就磁盘可以处理的负载而言,这是我们真正需要关注的数字。而这些参数的等待时间中,平均等待时间为4.16毫秒,随机(最差/典型情况下)读取和写入寻道时间均低于10毫秒。在Windows性能方面的含义,平均等待(延迟)意味着磁头需要这段时间将所需扇区放置在磁盘头下。读取和写入寻道时间是执行器将磁头移动到正确的刺刀进行读取或写入操作所用的时间。所以写入磁盘的平均传输时间应为13.66毫秒,读取为12.66毫秒。

PhysicalDiskAveSecCounter

五、网络

        “Network Interface(*)Output Queue Length”指标如果大于2,则表示网卡无法用足够快的速度将数据包发送到网络。这可能是网络存在延迟或瓶颈。

HOWTO: 解决因禁用防火墙服务引发的 Outlook 附件预览故障

        MPSSvc is a core service! MPSSvc is a core service! MPSSvc is a core service! [ 重要的事情说三遍!!!]

shout

        MPSSvc是什么服务?干什么用的?

        为了获取 MPSSvc 服务的相关信息,使用命令行 “sc qc mpssvc” 进行查看,可得知 MPSSvc 就是 Windows Defender Firewall,即 Windows 防火墙服务,启动方式为自启动。从遥远的 XP 时代开始,这个服务就存在,而且随着 Windows 系统的发展,已经成为必要的核心级服务。

sc_qc_mpssvc

        而一些 “聪明” 的 IT 人员为了避免客户端计算机的 Windows 防火墙功能影响正常使用和管理,使用了自认为最有效的方法来禁用它!即,通过域 GPO 直接禁用 Windows Firewall(MPSSvc)服务。下发策略后,确实像 XP、Win7这样的客户端运行照旧,貌似没什么不良的影响,也满足了 IT 管理员的 “目标”,因为那些防火墙问题的报修有效减少了。

        但是在后续的发展阶段,随着 Win8、Win8.1 的发布,到现在 Win10 的发布,企业中运行 Win10 的客户端计算机也越来越多,而微软也一直在致力于改善 Windows 的安全功能以提高安全性。那么问题来了,一些用户开始抱怨自己的 Outlook 无法正常预览 Office 附件,且在双击打开这些附件后会报错。

        在预览附件时的报错提示为“不能预览此文件,因为以下预览程序发生了错误:...”;如果双击打开这个 Office 附件,则会提示“内存或磁盘空间不足,Microsoft ... 无法再次打开或保存任何文档。”在故障发生的起初,进行排错时一直都没有想到是防火墙导致的故障。(PS:谁会想到 “聪明” 的 IT 会如此禁用 WFW)

outlook

        在无奈之际,使用 Procmon 对执行 trace 进行了捕获,进行具体的分析。在密密麻麻的记录中,终于找到了线索。当用户执行预览时,会触发一个对防火墙动态链接库的查询操作,由于 GPO 禁用了防火墙服务的启动,所以未能找到相关的资源。

Snipaste_2018-05-04_09-37-47

        当时为了验证,立刻检查了防火墙服务,果然被禁用导致无法正常启动。恢复设置后,故障解除。(PS:就此问题与 IT 理论的结果就是之前怎么没问题,现在怎么就出问题,压根就不是禁用防护墙服务的问题嘛!)

        所以呢,要其变更下发的 GPO 是没戏了,为此想了一个 Workaround,即通过计划任务在每次启动系统后使用 sc 命令将 mpssvc 改为自启动,并启动它。具体的命令如下:

schtasks /create /tn StartWF /tr "\\server\fixitFixMPSSvc.bat" /sc onstart /ru system /rl highest

        在编写上段命令前,曾尝试调整 Office 的安全设置,将打开有异常的 Office 文档的程序保护试图功能关闭,如下图所示。但是在 Outlook 中预览还是无法解决。

ProtectedView

        就 Windows 防火墙 与 Office 的问题,微软也发布了知识库进行了说明和解释。当同时满足以下条件时,则会发生上述描述的故障问题。

  • Windows防火墙服务没有运行
  • Windows 10、Windows 8.1、Windows 8 或基于 Windows Server 2012 的计算机上使用 Outlook 2016 或 Outlook 2013

        具体是因为 Outlook 中的预览功能使用受保护的试图功能(也成为沙盒)。在 Microsoft Office 2010 引入了此功能。在 Windows 10、 Windows 8.1、Windows 8 和 Windows Server 2012,受保护的试图功能改进了 AppContainer 功能的结合。这提供了更强的进程隔离,并且它还会阻止从沙盒的网络访问。

参考资料:KB2912722

HOWTO:禁用 Windows 10 更新

[ 2018/06/04 16:50 | by gOxiA ]

HOWTO: 禁用 Windows 更新

        Windows as a Service 是大势所趋,满足了大多数用户的需求。在过去用户总是抱怨 Windows 更新周期过慢,现在 Windows 10 每半年就会推出一个功能更新,但也并不是所有的用户都感到满意,真是众口难调!之前抱怨 Windows 更新过慢的一些企业用户,反而现在又抱怨更新过快!gOxiA 倒认为,其实他们的抱怨不是因为更新过快,而是因为每半年一次的功能更新常会发生更新失败的问题,这就增加了 IT 维护成本。导致更新失败的原因确实很多,在企业中常见的是因为一些第三方安全软件导致的,所以 In-Place Upgrade 就极易失败。最终,IT 希望能禁用或推迟 Windows 10 的功能更新,但在实际操作中发现并不能彻底禁用功能更新补丁的推送,这主要是因为 Waas 策略导致的,要求客户端要获得持续的支持就必须更新到最新版本,所以在到达推迟更新的最后期限后 Windows 10 仍旧会接收功能更新。

        有不少 IT 人员来咨询是否有什么方案能解决这一问题?!网上也提供了很多种禁用更新的方法,但多少都有些瑕疵,其实我们完全可以借助微软 GPO 来实现禁用功能更新的需求。

        首先在企业内部部署 WSUS,使客户端接入到 WSUS 上接受企业的统一更新管理,这样企业 IT 可以利用 WSUS 的审批功能只允许每月的安全更新。

        虽然 Windows 客户端连接到 WSUS 上接受管理,但仍旧可以从微软官方获取更新,这就导致功能更新最终会被推送到系统上,尤其是“微软 Windows 10 易升”这样的工具。

        所以我们还需要阻断到微软更新服务器的连接,为此我们使用 GPO 来实现。在“计算机配置 /管理模板/Windows 组件/Windows 更新”中找到“不要连接任何 Windows 更新 Internet 位置”,将其设置为“已启用”。

dcwui

        gOxiA 专门写了一个脚本,可通过 Github 获取。

https://github.com/goxia/ITSM/blob/master/W10_DisableOSUpgrade.bat

wdag_logo_430x130

Windows Defender Application Guard 快速体验

        为了阻止以前出现过的以及新涌现的攻击,微软为 Windows 10 v1709 新增了一个安全功能,利用独特的硬件隔离方法来化解来自互联网的攻击。这项安全功能称之为“Windows Defender Application Guard”(以下简称:WDAG),专为 Windows 10 和 Microsoft Edge 设计,WDAG可有效隔离用户或企业不受信任的站点,从而在浏览 Internet 时提供保护。应用的隔离容器技术基于Hyper-V,简单理解就是当用户触发访问不受信任的站点时,Microsoft Edge 将在 Hyper-V 的隔离容器中打开这些网站,这样就可以将网站与主机操作系统隔离开来,使主机系统得到保护,有效阻止攻击者。

appguard-hardware-isolation

更多信息可参考:https://docs.microsoft.com/zh-cn/windows/security/threat-protection/windows-defender-application-guard/wd-app-guard-overview

        在 Windows 10 v1709 版时,要启用 WDAG 需要企业版,但自 Windows 10 v1803 开始专业版(Pro)也可直接开启 WDAG,但一些管理、数据和打印支持特性仍需要企业版。

        要安装和启用 WDAG 只需要通过 Windows 程序和功能 添加即可,如下图所示。当然我们也可以通过 PowerShell 命令行安装。

Enable-WindowsOptionalFeature -online -FeatureName Windows-Defender-ApplicationGuard

Snipaste_2018-05-11_08-31-26

        虽然 WDAG 基于 Hyper-V,但是在安装“Windows Defender 应用程序防护”时,并不需要事先安装和配置 Hyper-V Role,而且与其也并不冲突,但是如果你要在虚拟机中体验 WDAG 是不受支持的。

Snipaste_2018-05-11_08-48-10

        要使用 WDAG 只需要运行 Microsoft Edge,在菜单中点击“New Application Guard window”(新应用程序窗口,PS:由于当时测试使用的是英文系统,所以截图为英文界面。)即可启动。

Snipaste_2018-05-10_10-13-45

        在首次启动 WDAG 时会进行初始化,gOxiA 使用的是固态硬盘,所以并没有等待太久,初始化完毕后会打开一个新的 Microsoft Edge,其窗口边缘为醒目的橙色,且左上角也有醒目的“Application Guard”图标,便于用户识别。

Capture

Snipaste_2018-05-10_10-14-25

        前面已经讲过,WDAG采用了隔离技术,默认配置下是不能在 WDAG 和主机系统间交互数据的,而且在 WDAG 中下载的一些资源也无法执行,但是就目前测试看处理流程上还有待完善,例如 gOxiA 在 WDAG 中点击了一个 PDF 链接并打开,是可以在 WDAG 中阅读这个 PDF 文件的,但是如果关闭后从下载列表中再次打开时则会被拒绝,当然也无法通过右键点击复制,将其从 WDAG 环境下复制到主机系统。

Snipaste_2018-05-10_10-23-01

        另一个有意思的发现是 WDAG 呈现出来的 Edge 是基于 RDP 的,可以在任务管理器中看到这个进程“hvsirdpclient.exe”,那么 WDAG 应该还用到了 RemoteApp。继续深挖,当然是想看看 WDAG 的系统环境,因为在主机系统环境下还能看到“vmmem”这个进程,占用了 1GB 的内存,它应该就是 WDAG 实例。

Snipaste_2018-05-10_10-44-34

        要想一探 WDAG 实例环境,只能从当前打开的 WDAG Microsoft Edge 入手,如下图所示 gOxiA 成功打开了 WDAG 的资源管理器,WDAG 的磁盘大小约40GB,查看占用的容量显示为 2.34GB(PS:有意思,占用了这么少的空间,怪不得启动速度有所保障。),但是其系统盘根目录下有个名为WDAG的子目录,存放这一个目录重定向文件,占用了4GB左右,而这个文件貌似是直接映射的 WDAG 主机系统下的目录文件,从命名看应该是供用户读写的区域。

Snipaste_2018-05-10_10-26-02

Snipaste_2018-05-10_10-52-55

        之所以会有前面的说法,是因为通过对进程的监视发现 WDAG 这个虚拟机相关的资源文件相当复杂,除了常见的虚机 VHDX 外,还在其基础上生成了多个差异磁盘,而这些虚拟磁盘文件都只有几百兆的容量,要想单独拷贝出来 Mount 查看其内部结构或加载到 Hyper-V 跑一跑是不可能的。而且 WDAG 的资源目录中还有一个名为 Base 的目录,包含了完整的 Windows 目录结构,而这个目录应该就是前面提到的目录重定向的源文件。

Snipaste_2018-05-10_10-50-10

        有兴趣的朋友可以在深入挖掘,貌似微软针对 WDAG 的安全性问题还有奖励活动。最后概览一下 WDAG 这个系统环境,当前版本是 10.0.17134 即 1803 版 Windows 10,而且是个专业版,但这个专业版貌似又运行在 S Mode 下,因为无法在 WDAG 下执行传统 EXE 程序,当然 UWP 应用也被禁用了(PS:也许还应用了 AppLocker 技术进行了限制)。此外,要想在 WDAG 与主机环境交换数据或应用打印,是需要企业版支持的,且需要配合组策略(GPO)进行配置,此外通过组策略还可以为企业提供 WDAG 的统一管理特性,如果您所在的企业对 WDAG 感兴趣可联系 gOxiA 获得咨询服务。

Snipaste_2018-05-10_10-54-27

小贴士:

  • 重置容器环境,并放弃用户在WDAG中生成的所有数据
    C:\Windows\System32\wdagtool.exe cleanup RESET_PERSISTENCE_LAYER

Part3 - 使用 Windows FFU 映像部署 Windows 10

        在学习和了解 “Part1 - Windows FFU 映像格式概览”和“Part2 - 使用 Windows FFU 映像部署的准备工作”后,今天我们就要进入 FFU 部署的正题,首先启动 PE 引导要捕获的 Windows PC,执行如下命令行对 Windows 所在硬盘进行 FFU 映像的捕获。

dism /capture-ffu /imagefile:e:\oem.ffu /capturedrive:\\.\physicaldrive0 /name:Disk0-W10Pro

        上面这条命令行的重点是 /capture-ffu,即使用 FFU 进行捕获的重要参数;/imagefile 则指定 ffu 格式映像存储的路径;/capturedrive 是指定要捕获的硬盘,其中 \\.\physicaldrive0 表示硬盘 0,如果你的固态硬盘是 mSATA 接口,且本机还有机械硬盘,那么 SSD 的标识号可能是 1,当然为了准确定位硬盘号,最好是通过命令行获取“wmic diskdrive list brief”。

        捕获到的 oem.ffu 文件较大,有近 14GB。虽然在前文中提到 FFU 不支持压缩和分卷存储,但实践中还是能通过 /split-image 进行分卷存储的,具体参考如下:

dism /split-image /imagefile:oem.ffu /sfufile:winoem.sfu /filesize:3500

        执行上面的命令后,会基于原有的 oem.ffu 重新生成名为 winoem*.sfu 的多个文件,大小为 3500MB,这样我们就能方便的将其存储在 FAT32 格式的 UFlash 中。

Snipaste_2018-05-11_08-59-31

        至此 FFU 映像我们已经捕获完毕,接下来就可以部署到新 PC 上,这里 gOxiA 使用 Hyper-V 准备了一台虚拟机,分配了一个 256GB 容量的磁盘,使用 PE 引导执行如下命令行。

dism /apply-ffu /imagefile:oem.ffu /applydrive:\\.\physicaldrive0

Snipaste_2018-05-10_15-48-00

        如果是分卷存储的 FFU,则可以参考如下命令行:

Dism /apply-ffu /imagefile:winoem.sfu /sfufile:winoem*.sfu /applydrive:\\.\physicaldrive0

        FFU 释放后,会发现当前硬盘的分区和系统数据都已部署完毕,重新启动会执行 UEFI 初始化,之后就能正常启动 Windows 10 系统。

Snipaste_2018-05-10_16-00-29

        基于 FFU 映像格式的 Windows 部署,非常适合工厂部署的应用场景,因为无需再考虑磁盘分区准备的环节;由于 FFU 是基于扇区的,所以部署的效率会比 WIM 更高一些。对于一些需要大批量交付全新 Windows PC 的企业用户,其实也可以考虑采用 FFU 方式。

Part2 - 使用 Windows FFU 映像部署的准备工作

        在之前的分享中“Part1 - Windows FFU 映像格式概览gOxiA 简单介绍了了什么是 FFU(Windows Full Flash Update images)格式,其使用限制,以及与其他映像格式的特性比较。今天就要进行一次实践,具体感受一下 FFU 部署来带的便利性。

        要通过 FFU 部署 Windows 首先需要去捕获一台计算机的系统映像,这里 gOxiA 准备了一台自用的 UEFI 引导方式的 Windows 10 电脑,使用的是 128G 的 SSD 硬盘,因为是 UEFI 引导,所以硬盘采用 GPT 格式,包含启动分区、恢复分区,MSR 以及一个系统分区,是 Windows 标准的分区方案。

dep-win10-partitions-uefi

        如果希望了解如何手动创建 UEFI-based PCs,可参考官方文档:https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions

        Windows 10 版本是最新的 1803,不过从 1709 开始对 FFU 的支持就已经相当完善,此外 Windows SKUs 方面并没有特殊要求,因为 FFU 毕竟属于工厂模式部署,所以不论是家庭版、专业版、企业版还是教育版,都受 FFU 支持。(PS:FFU 概览中曾提到仅支持捕获经过 Sysprep 的 Windows PC,但实践中并非如此。

        Windows PC 准备好后,我们还要准备一个 PE 引导盘,该 PE 需要基于 1709 版本,所以安装 Windows ADK 时要注意版本号。从下面的官方页面可以轻松下载到我们需要的 ADK。

Windows ADK 下载:https://docs.microsoft.com/en-us/windows-hardware/get-started/adk-install

        如何制作 PE?怎么打包成 ISO 格式?怎么 UFlash 引导 PE?这些问题就用如下命令行来快速解答,以 x64 为例,启动“部署和映像工具环境”开始。

copype amd64 c:\winpe_amd64

makewinpemedia /iso c:\winpe_amd64 c:\winpe_amd64\winpe_amd64.iso

makewinpemedia /ufd c:\winpe_amd64 H:

        自 Windows 7 开始制作一个可引导的 UFlash 就是非常简单的事情,只需要在 diskpart 下使用 active 激活分区即可,之后直接从 ISO 拷贝启动文件便可引导。

        如果你希望在当前 PE(PS:一些网友会使用第三方制作的 PE 工具盘)版本上来以 FFU 部署 Windows,则可以参考如下命令行,将支持 FFU 部署的 DISM 拷贝到你的 PE 中。

copy \"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\" E:\DISM_Win10 /s

        其实,还有一个比较灵活的办法就是直接使用对应版本的 Windows 10 安装盘引导,其修复模式中的 CMD 环境就能够执行 FFU 部署命令。当然在测试环境中,还可以直接通过“Reagentc”来进入 PE 环境!!!

        所有的准备工作都完成后,在 Part3 中将进入 FFU 部署正题,敬请期待!:-P

MSFT_logo_rgb_C-Gray_D

  

微软发布适用于 Windows 10 v1803 的远程服务器管理工具

  

        微软近日发布了适用于 Windows 10 v1803 版的远程服务器管理工具(RSAT),利用该工具可以在 Windows 10 PC 上远程管理Windows Server 的服务角色,如:DCHP、DNS、AD 等等。

  

        RSAT 区分 x86 和 x64,需要根据当前 Windows 10 架构选择下载和安装适当的 RSAT 版本,在下载页面提供有多个系统版本的 RSAT,请务必下载 1803 版。(PS:早期的 RSAT 存在已知问题,安装后缺少 DNS 服务器管理工具)

  

        RSAT 下载地址:https://www.microsoft.com/zh-CN/download/details.aspx?id=45520

  

        要卸载 RSAT 需通过“程序和功能”中的“查看已安装的更新”找到“KB2693643”,将其卸载即可。

  

image

Part1 - Windows FFU 映像格式概览

[ 2018/05/04 14:34 | by gOxiA ]

  

        Windows FFU images 的全称是 Windows Full Flash Update images,字面上翻译是全闪存更新映像。早期用于微软移动设备的更新及系统的安装(刷机),当然也支持工厂模式快速部署 Windows PC 设备。FFU 格式与 Ghost 的特性很像,能够将物理驱动器的映像直接应用到其他驱动器上,这包括了:Windows、恢复分区和系统启动分区等信息。

  

        正如上面所述的特性,FFU 与 WIM 格式是不同的,WIM 是基于文件的,而 FFU 是基于扇区,它能够存储一个或多个分区。而基于扇区的映像意味着更短的部署时间,但缺点是一个 FFU 文件的容量要比 WIM 大。(PS:磁盘容量越来越大,对于企业部署来说,时间才是关键。)

  

        FFU 自 Windows 10 v1709 开始正式被支持(PS:之前虽有资料,但 gOxIA 从未成功过),DISM 具有捕获、部署和服务 FFU 的能力,但是 FFU 仍有以下限制:

  
      
  • 应用 FFU 的驱动器容量必须与源驱动器容量相同或者大于后者。
  •     
  • FFU 不支持捕获加密磁盘
  •     
  • FFU 不支持启用了卷影复制服务(VSS)的磁盘
  •     
  • FFU 不支持拆分和压缩
  •     
  • FFU 仅支持 1709 或更高版本的 系统或 PE 环境
  •     
  • 要捕获的 Windows PC 需经过 Sysprep
  

        此外,建议使用 USB3.0 驱动器来存储 FFU 映像,由于 FFU 不支持拆分,所以请务必确保驱动器的格式为 NTFS。

  

        下图展示了  FFU 格式,详细的说明请参考:

  

https://msdn.microsoft.com/zh-cn/library/windows/hardware/dn757539(v=vs.85).aspx

  

OEM_FFU_Image_Format

  

        为了更好的认识 FFU 格式,可参考 WIM、VHD 与 FFU 的比较:

                                                                                                                                                                                                                                                                                                                                                                                             
        

Windows 映像 (.WIM)

      
        

虚拟硬盘 (.VHD/VHDX)

      
        

完整刷机更新 (.FFU)

      
        

常见用法

      
        

测试和修改 Windows 映像的最快方式。

          

快速装载和修改映像。

      
        

将 Windows 部署到虚拟电脑的最简单方式。

          

你可以直接从单个 VHD/VHDX 文件启动新的设备。

      
        

在工厂车间捕获和部署 Windows 的最快方式。

          

包含验证签名映像的内置安全功能。

      
        

映像样式

      
        

基于文件

      
        

基于扇区

      
        

基于扇区

      
        

压缩

      
        

支持多种类型的压缩

      
        

      
        

      
        

它捕获了哪些内容?

      
        

一组文件,最多为整个分区。

      
        

捕获完整的驱动器信息集,包括分区。

      
        

捕获完整的驱动器信息集,包括分区。

      
        

当应用映像时,会发生什么情况?

      
        

将文件和文件夹添加到分区。

          

如果现有的文件和文件夹具有相同名称,则将会替换它们。否则,将保留现有文件。

      
        

清理整个驱动器。

      
        

清理整个驱动器。

      
        

是否可以部署到不同大小的硬盘驱动器?

      
        

是。

      
        

是,不过新驱动器的大小必须等于或大于原始驱动器。

      
        

是,不过新驱动器的大小必须等于或大于原始驱动器。

      
        

是否可以修改映像?

      
        

是。通过使用 DISM 等工具,你可以装载、修改和卸载映像。

      
        

是,你可以将 VHD/VHDX 视为可移动介质来进行装载,并修改文件。

      
        

是,不过它仅限于添加程序包。

      
        

安全性

      
        

包括一个安全标头和一个映像标头,可标识安全的映像。

          

包括一个目录和一张哈希表,可在设备上进行刷机之前先验证签名。

      

  

HOWTO: 解决 Windows 10 Hyper-V Host Compute 启动故障 0x80070005

  

        今天微软为 Windows 10 v1709 发布了新的累计更新 KB4093105(16299.402),解决了不少的问题,于是 gOxiA 一早更新了这个补丁,但在更新完毕重启后发现 Hyper-V 无法使用,但在已知问题列表中未查询到有价值的信息。

  

Snipaste_2018-04-24_13-29-53

  

        打开服务管理器(Services.msc)检查 Hyper-V 相关服务,发现 Hyper-V Host Compute Service 服务无法正常启动,提示 0x80070005 访问拒绝。而在事件查看器中也找到了这个事件的记录。

  

Snipaste_2018-04-24_13-41-28

  

Snipaste_2018-04-24_13-40-28

  

        抓包大概看了一下,在栈中比较可疑的是“mmunsecurevirtualmemory”,貌似因为传递了未加密的虚拟内存数据,难不成因为什么安全规则导致的?!但貌似这函数与Hyper-V也没有直接的关系,Bing 了一下也没什么参考资料,也许这个思路就是错误的!!!

  

Snipaste_2018-04-24_16-32-29

  

        之后也想过用 WinDbg 附加到该服务上看看具体过程,但使用 gflags 附加 vmcompute.exe 未能成功启动 WinDbg,也没再深入研究为什么!!迷茫中,想起来同系统版本的其他机器也打了补丁,倒是没有发生这个故障,比较了两个系统设置,唯独是正常运行Hyper-V的机器禁用了 Defender,之后做了对比和测试找到了影响 Hyper-V 服务启动的根因——Control Flow Guard(CFG),Exploit protection 的一个子功能。有关 CFG 的介绍可以参考官方文档:“Control Flow Guard”。

  

ControlFlowGuard

  

        结论,当 CFG 为关闭状态时就会导致 Hyper-V Compute Service服务启动失败,所以必须将其设置为“On by default”。其中的“奥妙”也许只能期待以后微软方面能给出详细的说明!

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