上个月看到 Windows Team 的工程师 Mounia Rachidi 发布的 Blog,提到了在 Windows Server 上利用 iSCSI 创建 RAM Disk 的方法,于是动手实践了一下,感觉还不错!决定分享一下实践经验。

        实践环境是一台运行 Windows Server 2016,且拥有 32GB 内存的工作站。计划在内存中创建 28GB 的 RAM Disk,用于系统映像(WIM)的处理。将 WIM 放在 RAM Disk 里进行读写操作的优势显而易见,降低磁盘IO瓶颈。当然,也许您还能想到更多 RAM Disk 的应用场景,不妨利用 Windows Server  iSCSI 服务来体验一下。

        首先,我们需要为 Windows Server 2016 安装 iSCSI 目标服务器(iSCSI Target Server)角色,可启动服务器管理工具添加角色和功能。iSCSI目标服务器角色位于”文件和存储服务“角色下,具体参考下图:

iscsi_role

        然后,在 Windows 防火墙(Windows Firewall)中允许”iSCSI 服务“例外,即允许通过防火墙。

iscsi_service_mpssvc

        为了确保 iSCSI 目标服务能够为本机提供 iSCSI 服务,需要修改 Windows Server 2016 的注册表以允许回环模式,为此执行 Regedit 定位至如下路径,修改 AllowLoopBack(REG_DWORD) 值为:1

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\iSCSI Target

iscsi_reg_allowloopback

        完成上述操作后,便可开始创建 RAM Disk,首先创建容量为 28GB 的 RAM Disk:

New-IscsiVirtualDisk -Path "ramdisk:WIM-RAMDisk.vhdx -Size 28GB

new-iscsivirtualdisk

        之后创建 iSCSI 目标:

New-IscsiServerTarget -TargetName targetRAMDisk -Initiatorlds @("IPAddress:X.X.X.X")

new-iscsiservertarget

        接下来将 RAM Disk 分配给 iSCSI 目标:

Add-IscsiVirtualDiskTargetMapping -TargetName targetRAMDisk -DevicePath "ramdisk:WIM-RAMDisk.vhdx"

add-iscsivirtualdisktargetmapping

        现在启动 Windows Server 2016 上的 iSCSI Initiator(iSCSI 发起程序,该程序位于管理工具组下) 来连接这个 iSCSI 目标。

iscsi_initator

        连接成功后,便可在通过磁盘管理器初始化这个 RAM Disk,默认配置下这个 RAM Disk 是动态扩展类型的 VHDX,所以分配并格式化后,不会马上占用内存容量,会随着 RAM Disk 数据量的增长,而发生变化,但不会因删除数据而逆转。也就是说拷贝了一个10GB的数据,删除后会发现内存占用还是10GB,必须重新启动服务器才会得到空间的释放。

diskview

        最后需要注意的是,在 iSCSI 目标服务上启用 RAM Disk 后,会导致无法正常访问 服务器管理器 下的 iSCSI 目标服务器角色。

win10creatorsupdate1703

HOWTO: 解决 Windows 10 UWP Apps 无法运行

        UWP - Universal Windows  Platform(通用 Windows 平台),自 Windows 10 引入,进一步推动了 WIndows Runtime 模型的发展,一统 Windows 核心。作为核心版的一部分,UWP 现提供了一个可供在每个运行 Windows 10 设备上使用的通用应用平台。

OneWindowsPlatform

        简单理解,就是我们开发一个 UWP 应用即可运行在所有的 Windows 10 设备上,其优势显而易见!有关 UWP 详细的介绍可以移步 https://docs.microsoft.com/zh-cn/windows/uwp/get-started/universal-application-platform-guide 参考。

        而今天 gOxiA 要与大家分享的肯定是与 ITPro 密切相关的内容,正如本期之题目解决 Windows 10 UWP Apps 无法运行。具体的故障现象是点击 UWP Apps 都会没有响应,UWP Apps 不会按照预期那样启动运行。在有些环境下能看到点击 UWP Apps 图标后会显示正在安装一样的进度条,之后再无反应。具体的故障现象可参考下面的动画截图:

errordemo

        但是切换到 Administrator 账户下却能够运行这个 UWP Apps(PS:已经配置了GPO允许本地管理员运行 UWP Apps),唯独无法运行 Microsoft Edge,会出现闪退。检查日志发现来源 Apps,ID 5973 的错误事件,具体错误是“系统找不到指定文件”。难道是应用相关文件损坏?!

log

        使用 PowerShell 命令行对 Microsoft Edge 进行重装测试,结果发现“部署失败,原因是 HRESULT: 0x80073D0A,无法安装该程序包,因为 Windows 防火墙服务未运行。请启用 Windows 防火墙服务并重置。”错误很明确了因为防火墙服务未启动导致!但是,为什么其他 UWP Apps 却能够运行呢?而且使用其他账号又都无法运行呢?!

ps_reinstall_edge

        带着迷惑执行了 PowerShell 命令行对所有系统 UWP Apps 执行重装任务,命令行参考如下:

Get-AppXPackage -AllUsers |Where-Object {$_.InstallLocation -like "*SystemApps*"} | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

        结果一致,同样提示因 Windows Firewall 服务未启动导致 UWP Apps 无法安装。检查 Windows Firewall 服务确实被禁用,重新启动后故障解除。

        其实这个过程还有另外一个版本,在发现故障的时候是在生产环境下,且之前交付的 Surface Pro 4 都是经过测试的,运行也有近一年突然出现这个问题,还是新装系统后,确实十分诡异!参考映像未有更新,故障现象均发生在加域之后,那必然与域环境有关,首先检查的就是 GPO,是否进行了限制,但经过分析发现是 Windows 防火墙服务启动被配置为禁用,恢复后故障消失,之后再禁用 Windows Firewall 服务进行测试,发现除了 Edge 外其他的 UWP Apps 均可正常运行,怀疑是系统 Bug 向微软开了 Case,引出前面提到的重装应用进行测试,确认 Powershell 命令行执行失败时提示的错误信息,因防火墙服务未运行是导致 UWP Apps 无法启动的根因。

        但该问题是否被确认为系统 Bug,还暂无结果。

win10creatorsupdate1703

HOWTO: 解决简体中文版Windows 10 IE主页和搜索被百度锁定的问题

        微软与百度达成合作,在简体中文版的 Windows 10 中内置了百度主页和搜索,当我们拿到一台装有 Windows 10的新电脑时启动浏览器会发现主页被重定向到了百度,而默认的搜索引擎也是百度。如果你不喜欢完全可以手工重新设定一次,便可改回自己喜欢的主页和搜索。

        但是对于企业IT人员在对Windows进行预定制时,可能会触发浏览器的保护策略。例如IT人员在Sysprep 的 Audit 模式下修改了IE的默认主页为企业内部站点,搜索改回Bing,这一切看起来都是很正常的。但此时如果将当前系统实例连接互联网,会发现再次打开浏览器时保护机制被触发了,系统会提示“由于默认搜索提供程序设置已损坏,Internet Explorer重置了你的默认搜索提供程序,要将默认搜索提供程序更改为Bing吗?”

1

        此外,还会提示“由于主页设置已损坏,Internet Explorer重置了你的主页,要将主页改为XXXX吗?

2

        接下来不论你如何选择,或是修改主页和搜索,都将无济于事,每次打开浏览器都会提示。分析了注册表发现了如下图的注册项”Protected - It is a violation of Windows Policy to modify. See aka.ms/browserpolicy“,确认是定制的主页和搜索触发了保护机制。(PS:百度相当有实力啊,可以让MS这么为他推广)

3

        不管怎样问题还是要解决的,用Procmon进行了抓包,发现了一些线索。当设置主页和搜索时会触发一个名为EUPP的注册表项,看内容其下的 BackupHomePage 和 BackupDefaultSearchScope 十分可疑,由于是16进制的HEX数据,Decode 后发现是加密的,所以无法得到具体的数据。

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\EUPP

        之后也咨询了微软方面,确认了与 EUPP 有关,建议可以修改 DoNotAskAgain 为想要的 URL,并且还需要修改 Hosts 文件添加一条记录 “127.0.0.1 ieonline.microsoft.com”,便可解决 IE 被锁定并重复提示设置主页和搜索的问题。

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 也有不足,前面讲过键盘连接后“旋转锁定”是不可用状态,那也意味着用户如果突然想启用屏幕自动旋转时不能不拔掉键盘重新设置。

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