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

win10creatorsupdate1703

HOWTO: 为Windows 10开始界面的程序添加 以其他用户身份运行

        Windows 10 Pro v1703 版在未加域前可以在开始界面上鼠标右键点击程序使用更多菜单下的“以其他用户身份运行”(run as a different user)来执行程序。这个功能使在加域的客户端环境下能快速的以不同的域账户身份或本地用户身份去运行一个程序,而无需切换桌面环境。例如安装了 RSAT 当要使用 ADUC 进行管理操作,而当前登录用户又没有对应权限时,就可以利用“以其他用户身份运行”,如下图所示。

RunAsADifferentUserInStart

        令 gOxiA 感到郁闷的是在实际的环境中,一旦客户端加入域后开始界面上的“以其他用户身份运行”就消失了,本以为是域组策略限制了使用,但实际并没有做任何限制。如果要启用这个功能可以通过域组策略进行预配,该选项位于 用户配置/策略/管理模板/“开始”菜单和任务栏/在“开始”中显示“以其他用户身份运行”,启用即可。

GPO-RunAsADifferentUserInStart

        如果无法实施域组策略,那么可以修改本地组策略,或注册表。但实际测试发现,当修改注册表重启计算机后功能虽然生效了,但是第二天貌似又会被覆盖掉。在咨询微软后了解到,虽然该选项属于用户配置,但可以在 HKLM 下创建对应的项和键,除了可以解决所有登录用户都能够在开始界面上显示”以其他用户身份运行“外,也可以避免设置被覆盖。(PS:是不是 Bug 目前不得而知!)

        下面是针对用户配置和计算机配置的对应路径和键值,可参考使用。

  • HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Explorer
  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Explorer
  • Name: ShowRunAsDifferentUserInStart
  • Type: REG_DWORD
  • Data: 1

win10creatorsupdate1703

HOWTO: 解决因 ESENT ID49 WebCache 损坏导致的 IE 或 Office 异常故障

        企业环境中通常会使用经过定制的系统作为企业标准化系统映像,用于客户端的操作系统部署和安装。最佳实践中通常会再审计模式下复查或配置用户环境,之后通过启用 CopyProfile 将所有用户桌面统一。但是在审计模式下定制,或之后通过离线模式安装更新补丁,可能会因 WebCache 损坏,导致进程无法正常读写操作 WebCacheV01.dat 文件,从而引发其他用户登录系统后无法正常运行 IE 或 Office Outlook 等异常故障。

        例如在 Administrator 下封装系统打包为 WIM 后进行分发部署,客户端安装后执行后续配置任务,完成后使用域账号或其他本地账号登录,此时会发现点击 IE 图标运行 IE 后其程序界面并未显示,但在任务管理中能看到其进程存在。检查 CPU 和 内存 占用正常,应用和系统事件中没有其他错误或警告记录,唯一可疑的就是来源为ESENT,ID49的错误事件,其内容为 Administrator 对应目录下的 WebCacheV01.dat 损坏,如下图所示。

屏幕截图(1)

        在随后的排错中,在 IE 无运行界面,和 Outlook 挂起的状态下,删除 Administrator 用户配置文件后,所有程序立刻恢复正常,目前分析应与 ESENT 出现的 WebCache 损坏有关。

win10creatorsupdate1703

HOWTO: 使用命令行为 Windows 10 添加备份计划

        还记得 Windows 7 内置的“备份和还原”功能吗?是 Windows 自带的一款用于个人电脑备份和还原的数据备份工具,可根据用户需要创建一次性的系统备份映像,或制定一个备份计划,按照时间备份需要的数据文件。如果还不曾了解这个好功能,可以先看看 gOxiA 早期分享的文章“使用 Windows 备份功能保护硬盘数据”,之后的“使用 webadmin 自动恢复系统备份”则分享了如何利用命令行加参数快速恢复备份。

        虽然在 Windows 7 中备份和还原功能提供了命令行以及一组常用的参数,但是细心的朋友会发现其只提供了创建一次性备份的参数,而缺少重要的计划备份创建参数,这样不利用用户编写命令行脚本以实现自动化的备份需求。

win7_wbadmin

        从 Windows 8 开始”备份和还原”功能被淡化,微软推荐使用“文件历史记录”取而代之,但直至 Windows 10 ”备份和还原“功能仍被保留了下来,说明还是拥有一定用户群的。此外不同于 Windows 7 版,Wbadmin 的命令行参数得到了增强,支持创建或修改每日备份计划,这样将极大方便 IT 人员针对一些特殊用户或场景以命令行脚本方式自动为用户环境配置备份计划。该参数即“ENABLE BACKUP”,可以使用“wbadmin ENABLE BACKUP /?"获取详细的参数说明。

win10_wbadmin

        下面的命令行将创建一个每日11点和23点对指定目录且包含系统状态进行备份,并使用指定账号存储在网络共享的计划备份任务。

wbadmin enable backup -addtarget:\\backupshare\goxia-backup1 -include d:\personal,e:\sources -user:contoso\goxia -password:* -schedule:11:00,23:00 -quiet -allcritical

参考文档:

https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin-enable-backup

microsoft-office-365-logo

HOWTO: 解决 Outlook 无法打开正文嵌入的文件对象 故障

        最近一段时间应该有不少用户遭遇到了Outlook无法打开正文嵌入的文件对象 故障,具体表现为会议约会正文中嵌入的文档对象无法正常打开,会提示“用于创建此对象的程序时Outlook。您的计算机尚未安装此程序或此程序无响应。若要编辑此对象,请安装Outlook或确保Outlook中的任何对话框已关闭。”如下图所示:

snipaste20170727_141754

        出现该问题是由于用户安装了微软于6月13日发布的 Office 安全补丁(KB3203467)所致,该补丁旨在修复用户打开经特殊设计的 Office 文件时可能允许执行代码的漏洞,但是该补丁存在已知问题会导致用户无法正常打开 Outlook 附件或正文中嵌入的文件对象。

        在7月5日微软又发布了 KB4011042 用于解决 KB3203467 已知问题,但随后又撤掉了该更新补丁。可能该补丁存在一些问题,直至7月25日微软终于重新发布了用于修复 Office 文件可能允许远程执行代码的漏洞补丁——KB2956078,并且还修复了打开附件或嵌入的文件对象失败的已知问题。对于还在使用 Office 2007 的用户,请安装 KB3213643 解决此问题。

Hyper-V_logo

使用Hyper-V VLAN功能组建受隔离的网络环境

        在开始今天的分享前,gOxiA 带着大家前先了解下面的截图,这样才能更好的理解所要分享的内容。在一个企业网络内(Corp LAN),已经部署了DC、DNS、DHCP、WDS等服务器,是一个完整的生产环境。在 10.1.50.x 的子网内 gOxiA 有三台 Hyper-V 主机(两台基于 Windows 10,一台基于 Windows Server 2016)进行工作相关的测试和评估。

Hyper-V_VLAN

        默认情况下三台 Hyper-V 主机与 Corp LAN 是可以相互访问的,这个应该很容易理解吧;现在为这三台Hyper-V 主机分别创建了虚拟交换机 vNet-LAN50,那意味着其上的虚拟机将从 10.1.50.x 获取网络地址,并运行相互访问,到这里也很容易理解吧;由于一些测试需要进行隔离,通常会在Hyper-V 主机上创建 VMs Only LAN,仅供当前Hyper-V 主机上的虚拟机相互访问,或在当前 vNet-LAN50 上启用 VLAN 分配 ID 20 进行隔离,到这里相信也能理解;OK,我们继续,现在由于一个测试任务过于庞大所需的硬件资源很高,无法在一台Hyper-V主机上进行,需要现有的三台 Hyper-V 主机组网使用,且不变动现有的物理网络环境,同时实现与现有逻辑网络隔离。

        如果为每台虚拟机创建单独的网络,如192.168.192.x,是可以实现相互通讯的,但是并未完全实现逻辑网络的隔离,假如虚机部署了 DHCP 服务,那么极有可能会对现有的 Corp LAN 产生影响。但是启用虚机 VLAN 后,怎么实现跨 Hyper-V 主机访问呢?!按理说 vNet-LAN50 这个虚拟交换机的物理接口是 Hyper-V 主机上与 10.1.50.x 相连的网卡,由于是透明通讯,虚拟机设置 VLAN20 后理应透过 vNet-LAN50 与其他 Hyper-V 主机上 VLAN20 的虚机通讯,但是现实很残酷并非如所想的那样!!!

        经过测试需要通过 Hyper-V 的 Virtual Switch Manager(虚拟交换机管理器)为当前网络即 vNet-LAN50 也启用 VLAN ID 20,才能实现跨 Hyper-V 主机 的 VLAN 段虚机互访。

image

        虽然该法实现了最终的需求,但也确实与现有逻辑网络完全隔离,这意味着原有 10.1.50.x 段中的其他设备将无法访问这三台 Hyper-V 主机,否则也必须修改 VLAN 为 20。(如果 Hyper-V 主机是多宿主,倒是很好解决!)

ie_logo

深入探讨 网站想要使用你计算机上的程序打开Web内容

        gOxiA 因为工作需要最近在做与桌面虚拟化相关的技术内容,期间就遇到了“网站想要使用你计算机上的程序打开 Web 内容”的问题。具体是在用户安装 VDA 客户端后,通过 IE 访问 VDI 门户时会弹出这个提示,如下图所示。其实问题是比较简单的,为了避免下次再弹出提示框,我们通常会复选“不再对此程序显示此警告”,然后点击“允许”。这样在访问 VDI 门户后就会直接启动 VDA 客户端正常访问。

snipaste20170630_091127

        之后 gOxiA 又用 Microsoft Edge 访问测试了一下,会直接提示下载一个扩展名为 ICA 的文件,而这个 ICA 在当前系统上被注册为使用一个特定的应用程序打开。

snipaste20170710_093642

snipaste20170710_093721

        也就是说在整个访问过程中是浏览器下载了一个文件,然后由指定的应用程序打开它,当在 IE 浏览器环境下时可通过复选“不再对此程序显示此警告”然后“允许”来实现通过应用程序直接打开文件的操作,这样用户体验就会更顺畅。

        那么问题来了,用户说如果我复选了“不再对此程序显示此警告”,然后点击了“不允许”,可发现是误操作了该怎么办呢?该如何恢复呢?为此,gOxiA 检查了 IE 设置还真的不像禁用弹出窗口、或兼容性视图设置那样会有明确的设置选项且支持修改操作。由于通常也都是习惯于正确的操作,确实会忽略掉如果复选不再显示警告并点击了不允许会有什么结果。

        期间也有咨询过微软支持,但也没有准确的解答,无奈只能自己研究 。使用 Procmon 抓包来看看这一设置都做了什么操作?!

snipaste20170630_092434

        还挺轻松立刻就锁定了位置,当我们在弹出“网站想要使用你计算机上的程序打开Web内容”的警告窗体上,复选“不再对此程序显示次警告”,并点击“允许“后,iexplore 进程会在注册表的 “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\” 下生成一个新的 GUID 项,并写入该程序的相关键值。其中 AppPath 和 AppName 是容易理解的,也没有什么特殊之处,而 Policy 则是非常关键,默认键值为”3“。如果我们修改了这个值,例如:2,那么再下次访问时又会重新弹出警告让用户选择,只有值为3时才会默认通过安装的应用打开下载的 ICA,而不再弹出任何提示。此外,在重新复选并允许后 iexplore 进程并不会修改之前已经添加的项和对应的键值,而是会重新生成一个新的项,很有意思!

        接下来 gOxiA 又重新做了一次抓包,但这次操作是复选不再提示后不允许运行,但在抓包数据中分析发现,执行这一操作并不会写入任何设置。也就是说即使用户复选了不再提示,只要点击的是不允许,那么前面的复选设置是不会起到任何效果的。

        至此,答案已经出来,我们也不必担心用户是否会进行误操作,如果出现 IE 访问 VDI 门户没有启动 VDA 客户端的故障问题,那么直接从 VDA 下手排错即可,无需再在 IE 身上徘徊!

        后来微软支持也给找到了一篇文档,原来早在2009年时就有微软人士详细讲解过这个安全功能,具体可参考下面这篇 Blog :

https://blogs.msdn.microsoft.com/ieinternals/2009/11/30/understanding-the-protected-mode-elevation-dialog/

hero_edge_sufandesktop

HOWTO: 关闭 Surface Pro 4 屏幕自动旋转功能

        用户的需求总是各式各样,不可能完全满足,就在上周 gOxiA 遇到了一个“奇葩”的支持请求,一位 Surface Pro 4 用户希望不论在何时何地,何种姿态下,都不要自动旋转 Surface Pro 4 的屏幕,希望在连接键盘时就是一个笔记本电脑。

        这个需求其实也容易理解,用户使用习惯也好,强迫症也好,总之不希望屏幕在连接键盘时自动旋转。那么要解决这个问题禁用自动旋转不就行了,可事实是当 Surface Pro 4 在连接键盘后默认的横屏工作模式下“旋转锁定”是不可用的,必须旋转至竖屏后方能锁定。

RotationLock

        现在感觉到用户的需求“奇葩”了,咨询了 Surface 在线技术支持,人家解释说键盘连接不稳定,让重新连接键盘,可是那么多台都是这样吗?后来人家又改口说是设计使然,并且也没有关闭硬件功能的方案,还让把驱动卸载掉再试,gOxiA 也是只能放弃了!

        自己研究还是妥妥的,既然拔掉键盘能够关闭旋转锁定,那就先拔掉键盘,关闭旋转锁定后再接上键盘,OK!用户需求搞定。但是这个 Workaround 也有不足,前面讲过键盘连接后“旋转锁定”是不可用状态,那也意味着用户如果突然想启用屏幕自动旋转时不能不拔掉键盘重新设置。

win10creatorsupdate1703

HOWTO: 快速在 UEFI 启动的 Windows 10 中添加 Native VHD Boot

        今天又要与大家分享关于 Native VHD Boot 的小技巧了,搜索本站 gOxiA 已经写了不少关于 Native VHD Boot 的文章,虽然之前也有撰写“Windows 10 Native VHD Boot 案例分享”,但本文将向大家介绍如何在基于 UEFI 启动的 Windows 10 中添加一个 Native VHD Boot 实例,整个操作过程期间并不需要重启进入PE环境,完全就地解决。

        准备一个准备添加 Native VHD Boot 的安装源,可以是 ISO 也可以是 WIM,前者需要先 Mount ISO 到当前系统,以便于访问其中的 WIM;之后在当前卷新建一个目录用于存放 Native VHD Boot 的 VHD 文件,例如“C:\VHDBoot\”;接下来使用磁盘管理器创建一个 VHD 文件WS2012R2.vhd,存储在前面的目录中,建议使用固定大小,注意请务必转换为GPT磁盘,根据需要进行分区,格式化为NTFS。固定大小的 VHD 虽然占用了不少空间容量,但可避免不必要的麻烦;然后再释放 WIM 映像到这个 VHD 中,方法相信大家已经轻车熟路,使用内置的 DISM 命令即可完成,命令行可参考“dism /apply-image /imagefile:G:\sources\install.wim /index:1 /applydir:V:\”,映像应用完毕即可unmount VHD,现在就差创建启动信息。

        由于是系统在线环境,且引导卷处于隐藏状态,所以最为方便的添加 Native VHD Boot 启动信息的方案就是使用 BCDEdit 工具,基于默认启动项新建一个新的 Native VHD Boot 启动信息,修改 Device 和 OSDevice 选项指定到前面创建的 VHD 路径上,即可完成。为此参考如下命令行执行!

1. bcdedit /copy {default} /d "WS2012R2 Native VHD Boot"

2. bcdedit /set {GUID} device vhd=[c:]\VHDBoot\WS2012R2.vhd

3. bcdedit /set {GUID} osdevice vhd=[c:]\VHDBoot\WS2012R2.vhd

        现在重新启动便可以出现多启动菜单,可选择 Native VHD Boot 来启动系统,UEFI 比较不人性化的是当选择另一个启动项后会再次重启计算机,这个没办法 UEFI 的设计使然。是不是非常简单,只要理解了相关的概念,命令能够做到得心应手,就能针对不同场景制定实现方案!

win10creatorsupdate1703

HOWTO: 使用 Windows 10 内置命令管理设备驱动

        在 Windows 10 之前在线管理和维护设备驱动是相当困难的事情。对于IT专业人员如果需要批量导入并安装驱动,只能依赖第三方应用程序,或者事先编写执行脚本。虽然我们可以使用 DISM 来执行操作,但关键的操作命令还是只能对脱机系统映像有效,所以还是非常的繁琐!为什么会如此尴尬呢?因为 Windows 支持硬件设备的即插即用(PnP)特性,而这一特性是由本地系统映像中强大的驱动库(DriverStore)来支撑的,它位于 Windows 的 System32 目录下。当系统连接一个新的硬件后会从这个 DriverStore 中搜索驱动,当发现匹配的驱动后变化配置为硬件设备使用,而此时驱动会被复制到 Windows 的 System32 下的 Drivers 目录中,被设备实时加载,而设备所需的其他子配置文件或程序文件可能分布在系统的其他目录中。

WinHardwareDriverStore

        如果我们要安装驱动则需要使用设备管理器手工为硬件设备更新或安装驱动,也可以使用设备生产商提供的驱动安装程序来执行安装,但是对于一些 OEM 设备,尤其是笔记本来说,需要反复执行设备驱动安装操作十几次,也是相当令人崩溃的,即使像前面所讲使用第三方应用程序实现批量安装,但要实现自动化处理还是命令来的更实在。

        Windows 10 提供了两个内置命令用于设备驱动的管理和维护,DISM.exe 和 Pnputil.exe 。DISM 在系统在线(联机)状态下只支持导出驱动,如果要添加和删除驱动必须在系统脱机状态下进行。

  • DISM 添加驱动
    dism /image:c:\mount\offline /add-driver /driver:c:\drivers /recurse /forceunsign
    /recurse,遍历指定目录下的所有子目录,还是相当有用。
    /forceunsign,添加未签名的驱动,在 X64 系统上添加未经签名的设备驱动可以使用这个参数。
  • DISM 删除驱动
    dism /image:c:\mount\offline /remove-driver /driver:oem1.inf
    设备所安装的第三方驱动都会被重新按照 Oem0.inf,Oem1.inf,Oem#.inf 命名方式存储,而删除的时候亦是如此。要获取系统都安装了哪些驱动可使用 /get-drivers 参数。令我们感到悲催的是删除驱动不支持通配符,只能一条一条执行,或编写成批处理脚本。
  • DISM 导出驱动
    dism /online /export-driver /destination:c:\exportdrivers
    也只有导出驱动是可以在系统脱机和联机状态下进行的,这倒是十分方便。一般IT部门拿到新型号笔记本后通常会使用这个命令导出驱动。(PS:这个习惯要养成,因为厂商提供的打包驱动不一定会完整,这是真的!!!)

        注意,即使能够脱机状态添加驱动,但是所添加的驱动也只能用于未安装驱动的设备实现自动的驱动安装,即已经安装的驱动不会被自动更新和替换,除非你在设备管理器中手动执行更新,或通过 Windows Update 从微软获取最新的设备驱动。(PS:十分无奈!!!)

        DISM 在脱机 Windows 映像中添加和删除驱动程序的完整过程可参考微软官方提供的资料,这里就不再过多的讲解。

        参考资料:https://msdn.microsoft.com/zh-cn/library/windows/hardware/dn898469(v=vs.85).aspx

        接下来再说说 Pnputil.exe - Microsoft PnP 工具,在 Windows 10 之前,这个工具简直就是鸡肋,可实现的设备驱动操作非常的有限,它更像是 DriverStore 层的维护工具。因为对硬件的实时驱动根本起不到管理作用。直到 Windows 10 v1703 版,Pnputil 才算真正意义的即插即用硬件设备驱动管理工具。其主要特性是允许在系统联机状态下执行添加、安装、卸载、删除以及导出驱动的操作。前面提到过设备被识别后,驱动是实时加载的,此时是无法使用命令行在联机状态下删除驱动的。而 v1703 较 v1607 最大的改进是支持了 卸载 和 安装 参数,即除了对 DriverStore 层执行操作外,也可以对 Drivers 层执行操作。

  • Pnputil 卸载和删除驱动
    pnputil /delete-driver oem#.inf /uninstall /force
    /uninstall,卸载并删除驱动
    /force,强制执行即使设备驱动正在使用中
    /reboot,更具需要重启系统以完成操作
    注意:直至 Windows 10  v1703 仍旧不支持批量卸载和删除驱动。
  • Pnputil 添加和安装驱动
    pnputil /add-driver c:\oem\*.inf /subdirs /install
    /subdirs,遍历子目录
    /install,安装或更新驱动
  • Pnputil 导出驱动
    pnputil /export-driver * c:\driverbackup
    注意:导出驱动支持 * 通配符,也支持导出单个驱动 Oem1.inf,要枚举驱动可使用 /enum-drivers 参数。

        DISM 和 Pnputil 相比较,DISM 更适用于系统映像准备阶段方便日后分发,例如拿到一批新型号设备,可以导出 OEM 驱动,并准备一个测试用途的企业标准化系统映像,使用 DISM 将驱动导入脱机映像中,当映像被安装到这些新型号设备后便可自动识别和安装驱动到系统中。而 Pnputil 更适用于联机系统的维护,例如 IT 专业人员从厂商获取到设备的最新驱动包,可以使用 Pnputil 直接批量安装和更新设备驱动。利用这些命令,我们还可以编写灵活的脚本满足更多的应用场景。

image

HOWTO: 为 MDT Media LiteTouch 启用 WIM Split

        现在的系统映像容量是越来越庞大,像 Windows Server 2016 的 ISO 要想通过 UFD 以 UEFI 方式来安装,可真是要提前准备一番,2个 UFD 一个是 FAT32 格式的用来做 UEFI 引导,另一个 NTFS 格式的用来存储安装源,没办法WIM 超过了4GB,相信这个场景不少 ITPro 都曾遭遇过!尤其通过 MDT 的 Media LiteTouch 安装系统时,问题尤为突出!虽然前段时间 gOxiA 与大家分享了 Widnows 10 v1703 支持 UFD 创建多分区 的文章,在 MDT 实践中可以通过创建对应目录结构实现 Media LiteTouch 部署大容量自定义系统映像的需求,但之后的维护工作却非常繁琐。其实在 MDT 中已经提供了 WIM 的分卷功能,只是官方很少提及!截止到今日,官方与网上都没有一个明确的说明该如何为 MDT Media LiteTouch 启用 WIM Split。(PS:明显的坑,大坑!)

        gOxiA 抽出时间做了一下功课,对 MDT WIM Split 做个总结。WIMSplit 确实受 MDT 支持,但是官方并没有提供图形化的设置界面,我们需要修改配置文件中对应的选项参数来启用它。这个选项为“ <SkipWimSplit>False</SkipWimSplit>”,位于“settings.xml”中。也就是说只要在 Settings.xml 中将 SkipWimSplit 配置为 False 那么在对 Media 执行刷新时就会自动将大于 4GB 的 WIM 映像进行分拆。而网上普遍存在修改 SkipWimSplit 后并未生效的主要原因是选错了 settings.xml,问题就是这么简单!还没理解?!搜搜 settings.xml 都位于哪几个目录下?去修改主 settings.xml 就会作用到 Media LiteTouch。

        这个问题的起因完全是用户和开发者概念逻辑不统一所致!大家都认为应该修改 Media 下的 Settings,但实际上需要修改部署点的,在刷新 Media 时脚本会将系统映像分拆然后拷贝到 Media 下,完毕后会删除原始位置的 SWM文件。

SkipWimSplit

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