gOxiA=苏繁=SuFan Blog

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。

Windows 10 Native VHD Boot 案例分享

        在 Windows 10 Build 10162 发布之际，gOxiA 经不住诱惑决定再折腾一下，手上倒是有3台设备（T420、Surface Pro 3、Venue 8 Pro）可用，最终决定拿 T420（UEFI） 作为本次的测试对象，因为工作环境在这台笔记本上，而且内置 SSD 容量有效，其他两块内置磁盘存储有重要的数据，所以决定在 eSATA 接口上外接了一块 500GB 移动硬盘，以 Native VHD Boot 方式安装 Windows 10 Build 10162，这样一来可与 T420 原有系统实现有效的隔离，互不影响引导信息，而且日后还可以在这块 eSATA 硬盘上部署其他 Native VHD Boot 系统，有效利用空间。

        准备工作，在 500GB 硬盘上划分两个分区，一个 500MB FAT32 格式用于 MBR 引导（Letter S:），另一个使用剩余容量 NTFS 格式（Letter V:）；再准备好 U盘安装的 Windows 10 Build 10162 用于引导至新 PE 环境。接下来重启计算机按下 F12 选择从 U盘启动，进入 Windows 10 安装向导按下 Shift+F10，运行 diskpart 在 V: 上创建一个 VHD，并挂载到环境中，创建分区并执行格式化，之后分配盘符为 W: 至此准备工作结束。相关执行命令可参考 gOxiA 以往关于 Native VHD Boot 的文章，或下面的例子，具体用途和说明这里就不再复述。

diskpart

sel disk 4

clean

create partition primary size=500

format fs=fat32 quick

active

assign letter=s

create partition primary

format fs=ntfs quick

assign letter=v

create vdisk file=v:\win10162.vhdx maximum=120000 type=expandable

attach vdisk

create partition primary

format fs=ntfs quick

assign letter=w

exit

        接下来，使用 DISM 将 U盘上 10162 的 Install.wim 文件释放到 VHD磁盘内，即：分区 W，并为其创建引导信息，具体命令执行如下：

        至此，整个执行步骤就全部完成，Native VHD Boot 已经生效，是否感觉不可思议？！因为步骤里并未像以前一样修改 BCD 指定 VHD 相关信息，这是因为 Windows 10 会自动处理 Native VHD Boot 的信息，现在重新引导便可开始体验。

HOWTO: 利用 Import Service 向 Exchange Online 用户迁移数据

        Office 365 增加了一项新的功能 – Import Service（导入服务），使用这项导入服务可以将组织内部的文件传输到 Office 365 中，除了可以将硬盘寄送给 Microsoft 外，还支持通过网络上传文件。利用 Import Service 我们可以将本地 Exchange Server 导出的用户 PST 文件迁移到 Office 365 的 Exchange Online 用户中。对于小规模的 Office 365 用户而言，此种数据迁移方法显得更为便捷！步骤十分简单，大致分为四步。

        首先，参考 Technet Library 资料 如何导出邮箱数据，将各用户邮箱数据导出至对应的 PST 文件。然后，访问 Office 365，进入管理员界面的导入服务，添加新任务“通过网络上载文件”。

        在向导页面下载并安装 Azure AzCopy，并点击“显示密钥”和“显示 URL”获取上传数据的权限信息，然后运行 Azcopy 执行上传指令，参考如下：

        待上传完毕后，在向导页面点击下一步，为当前导入任务起个名字，并执行下一步；在“上载映射文件”向导页，点击“了解应如何设置 CSV 文件的格式”链接获取 CSV 文件创建的帮助信息，映射文件中需要注意的地方有几点：必须为 UTF-8 格式，Workload 填写 Exchange，FilePath 留空，Name 为用户 PST 文件名，Mailbox 则是对应 PST 文件用户的邮件地址即账号，IsArchive 设置为 FALSE，TargetRootFolder 这里 gOxiA 设置为“/”即导入根目录，最后勾选条款，点击完成。

        我们可以查看正在执行导入任务的进度，在导入完成后我们还能够下载错误，了解导入的情况，已保证导入的完整性。

        总结，利用 Office 365 新提供的 Import Service 解决用户数量极少的迁移环境还是非常奏效的，而且上传速率相当令人满意。温馨提示：建议在上传 PST 前使用 Office 自带的 Scanpst 工具扫描并修复一下导出的 PST 文件以确保之后导入能够顺利完成。