[Tips] 使用 OneDrive 自动保存屏幕快照
使用 OneDrive 自动保存屏幕快照
最近在更新 Windows 10 系统后发现 OneDrive 的版本也更新到了 17.3.595.0827，除了对程序方面的改进外还添加了一些新的功能 - 自动保存，其中的自动保存屏幕功能快照非常实用。gOxiA 过去一直没有安装专门的截屏软件，只是使用系统一直以来默认支持的 PrtScn 键，然后再运行 Paint.Net 生成图片文件，执行保存操作……虽然看起来挺繁琐，但也坚持了N年！
而现在利用 OneDrive 的自动保存屏幕快照这个功能就省去了后续生成图片和命名保存的步骤，而且自动保存在云中，可方便从任何地方和设备上提取。要实现这一功能非常简单，只需鼠标右键点击系统栏上的 OneDrive 图标，单击“设置”，进入 OneDrive 设置的“自动保存”选项卡，勾选“屏幕快照”下“自动将我捕获的屏幕快照保存到 OneDrive”复选框，确定即可！
[Tips] Windows 10 Hyper-V 0x80041008 无法删除虚拟交换机
Windows 10 Hyper-V 0x80041008 无法删除虚拟交换机
当我们对 Windows 10 进行 Build 级别的更新，或者在用户已经安装 Hyper-V 的情况下又安装 VMware 后，便有可能会出现 Hyper-V 虚机网卡失效的故障问题，当用户发现故障发生并准备删除已经在 Hyper-V 中创建的虚拟交换机时，会提示无法删除虚拟交换机，错误代码：0x80041008，有网友建议找到网卡并勾选“Microsoft 网络适配器多路传送器协议”后便能删除虚拟交换机，PS：不知道其根据是什么！总之，如果你发现这招无效可继续往下阅读。
在本例中，通过 Hyper-V 创建了一个名为 ExNet – LAN 的虚拟交换机，桥接到物理网卡上，出现 0x80041008 故障无法删除虚拟交换机时回忆之前的操作，除了将 Build 10240 升级到了 10547 外，最近一次操作是安装过 VMware Workstation Player，之后发现 VMware 产品检测到系统安装有 Hyper-V，提示无法正常运行 VMware Player，卸载 VMware 产品后再运行 Hyper-V 虚机，便发现无法进行网络通信，此时意识到出现了问题，进行排错时检查出之前创建的 ExNet-LAN 网卡已经不存在，但是 Hyper-V 虚拟交换机中还能看到，所以当删除时会提示失败。
随后又通过硬件管理器检查隐藏设备，并未发现异常，便尝试将所有已建虚机的网卡配置先断开，然后尝试使用 “netsh winsock reset”命令行对 winscok 目录进行复位，重启计算机再次执行删除操作，故障消失。由此可见 VMware 产品安装和卸载时会自动创建/删除 2个虚拟网卡，破坏了之前 Hyper-V 已创建的网卡和驱动，才会导致 0x80041008 故障的发生。
另，前面还怀疑与 Build 升级有关是因为目前 Windows 10 进行 Build 升级，或者从低版本 SKU 升级后，虽然号称是无缝升级，但是在多台机器上发现升级后都会重置网卡，使网卡物理 ID 变更，有可能会引发 Hyper-V 虚机交换机配置问题，是否最终也会导致 0x80041008 故障，还需做进一步的验证。
[Tips] Hyper-V Windows 10 虚机使用增强会话模式故障一例
Hyper-V Windows 10 虚机使用增强会话模式故障一例
还记得 gOxiA 早前撰写的一篇文章《Hyper-V - 增强会话模式》，向大家介绍了有关 Hyper-V 的一个新功能特性，即：增强会话模式，该模式会基于 RDP 方式连接到虚机进行管理和控制，以获得更好的操作体验，例如方便向虚机复制文件等等，文章也在末尾提到了一些使用方面的注意事项。
自 Windows 10 RTM 后 gOxiA 使用已经有一段时间，但最近偶然用到了一个小问题，感觉很有意思与大家分享！一台 Windows 10 Enterprise x64 的 ThinkPad T420，安装了 Hyper-V，并安装了一个 Windows 10 Enterprise LTSB 虚机，因为在 Hyper-V 设置中启用了“使用增强会话模式”，即：如果虚机系统支持增强会话模式时，VMConnect 默认以增强会话模式进行连接。
所以当连接启动好的 Windows 10 虚机时会提示增强模式会话的显示分辨率确认提示，直接连接即可进入虚机。
这个过程很显然并没有多大问题，但是在进入虚机后刚进入系统桌面便会自动退出，并未出现如下图的提示。即使反复重新连接都无济于事，必须停止增强会话模式。起初以为是只添加了网卡，并未分配桥接网路所导致，而且分配网络也确实恢复正常，但就在撰写此篇文章时发现元凶并非网络，而且早先文章也介绍过增强会话模式无需网络支持。
那么问题出在哪里呢？！切换回标准模式查看当前系统状态发现此时提示“由于远程桌面服务当前正忙，因此无法完成你尝试执行的任务。请在几分钟之后重试。其他用户应该仍然能够登录。”
看来与用户登录有关，之后在标准和增强会话模式间反复切换时发现了重点，系统提示我“与此计算机的连接数量是有限的，现在已经使用所有链接。请尝试稍后连接或与系统管理员联系。”出现这个提示意味着当前系统存在多个并发登录，并且这些用户 Session 处于活动状态，之后又反复测试发现在增强会话模式下即使已经登录到桌面，但是当切换回标准模式后会回到登录界面并要求重新登录。
而当从标准模式切换到增强会话模式时会自动使用当前账号提交自动登录。那么在 gOxiA 环境中，这个虚机没有设置用户密码，所以系统启动后会自动进入桌面，当使用 VMConnect 连接时又会自动提交一个新的用户登录 Session，此时的登录 Session 便会与标准模式下的已经登录的用户 Session 造成冲突，因为没有一个监测和处理机制所以就会出现上述的故障问题。
最后 gOxiA 启用了 Administrator 账号，并为两个账号设置了密码又进行了几番测试，结果从下图可以看到，如果账号设置了密码，那么即使是在同一个账号下进行模式的切换，都会触动一个正常标准的登录过程，标注实际操作为当前登录 Session。
身为一名 Windows ITPro 都应该知道 RDP 不接受账号密码为空的登录请求，很显然 VMConnect 使用增强会话模式连接一个系统账号密码为空的虚机时，提交了一个看似并不合规的登录请求，以绕过 RDP 协议规范的检查，最终才会导致这个故障的发生。但是有趣的是如果当前账号没有 RDP 权限，例如属于 Users 组时当使用增强会话模式连接时便会被阻止。
综上所述，要正常使用 Hyper-V 的增强会话模式，避免不必要的麻烦，务必满足用户RDP权限，并且为账号设置一个密码。此外 gOxiA 也会反馈给 Windows Insider，这个问题应该属于一个 Bug。
