HOWTO: 通过 Remote Desktop (RDP) 远程访问 Hyper-V 下的虚拟机
HOWTO: 通过 Remote Desktop (RDP) 远程访问 Hyper-V 下的虚拟机
Remote Desktop 是 Windows 的远程桌面工具，通过 RDP 远程访问 Windows 计算机，可在 Windows 桌面下执行管理操作。那么它又是怎么跟 Hyper-V 扯上关系的呢？！本文 gOxiA 将分享通过 Remote Desktop 直接远程登录到 Hyper-V 下的虚拟机，对虚拟机系统执行操作。
在 Hyper-V 上如果要管理其下的虚拟机通常会在 Hyper-V 管理器下选中虚拟机（VM），并鼠标右键点击，选择“连接”。
之后 ，Hyper-V 管理器会为我们启动一个新的程序，名为 VMConnect，即虚拟机连接器。这样我们便可以像本地计算机一样去操控它。
当然，我们也可以为虚拟机启用远程桌面访问，这样便可以通过 Remote Desktop 登录。但是，前面所讲的都是面向 Windows 系统的，如果 Hyper-V 虚拟机是一个 Linux 呢？？？通常，接下来的解答是在 Linux 上开启 SSH 或其他远程访问服务，按照 Linux 的方案去执行。但是如果正好这个 Linux 虚拟机不能开启 SSH 怎么办？
OK，开始今天的主题！如果 Hyper-V 下的虚拟机是一个没有远程管理方案的 Linux，又或者虚拟机与客户端是隔离网络关系，那么该如何远程操控这些虚拟机系统？！
其实我们可以借助 Windows Server 2016 的 RDP 即远程桌面协议实现我们的需求。原理是客户端通过 RDP 连接到 Hyper-V Host，之后使用 RDP 作为桥去连接虚拟机的 VMMS 端口 2179，实现两端通信。（PS：默认该端口是由 VMConnect 去连接。）
要使用远程桌面来连接的具体操作步骤如下：
首先，获取要远程连接的虚拟机ID，可以通过 PowerShell 命令：get-vm | fl name,id
然后使用记事本新建一个扩展名为“.rdp”的文件，并添加如下内容：
保存后便可直接使用，以下截图是连接一台正要安装 Ubuntu 的虚拟机截图。
参考资料：https://technet.microsoft.com/en-us/library/Cc764268.aspx
| Connection type | Protocol | Default port | Where to change the port setting |
|---|---|---|---|
| VMM server to VMM agent on Windows Server–based host (control) | WS-Management | 80 | During VMM setup, registry |
| VMM server to VMM agent on Windows Server–based host (file transfers) | HTTPS (using BITS) | 443 (Maximum value: 32768) | Registry |
| VMM server to remote Microsoft SQL Server database | TDS | 1433 | Registry |
| VMM server to P2V source agent | DCOM | 135 | Registry |
| VMM Administrator Console to VMM server | WCF | 8100 | During VMM setup, registry |
| VMM Self-Service Portal Web server to VMM server | WCF | 8100 | During VMM setup |
| VMM Self-Service Portal to VMM self-service Web server | HTTPS | 443 | During VMM setup |
| VMM library server to hosts | BITS | 443 (Maximum value: 32768) | During VMM setup, registry |
| VMM host-to-host file transfer | BITS | 443 (Maximum value: 32768) | Registry |
| VMRC connection to Virtual Server host | VMRC | 5900 | VMM Administrator Console, registry |
| VMConnect (RDP) to Hyper-V hosts | RDP | 2179 | VMM Administrator Console, registry |
| Remote Desktop to virtual machines | RDP | 3389 | Registry |
| VMware Web Services communication | HTTPS | 443 | VMM Administrator Console, registry |
| SFTP file transfer from VMWare ESX Server 3.0 and VMware ESX Server 3.5 hosts | SFTP | 22 | Registry |
| SFTP file transfer from VMM server to VMWare ESX Server 3i hosts | HTTPS | 443 | Registry |
Project Honolulu Technical Preview 1711 Build 01003
Project Honolulu Technical Preview 1711 Build 01003
忍了好久终于可以发布这篇日志，微软在公布 Windows Server Insider Preview Build 17035 的同时，还公布了 Project Honolulu Technical Preview 1711 Build 01003，如果你还不了解什么是“Project Honolulu”，建议先复习一下 gOxiA 之前发布的文章“Project Honolulu Technical Preview 概览”和“Project Honolulu Technical Preview 部署 ”。
在新版的 Project Honolulu 中又带来了一些改进：
- 远程桌面
1711 Build 01003 中加入了远程桌面的支持，现在我们可以在 Honolulu 中通过 RDP 来远程登录计算机，对远程计算机进行操作和管理。目前 RDP 控制台的功能还比较简单，如果你实在无法忍受这么小的可视界面，建议还是单独启动 MSTC 更为合适，对于 Honolulu 这套服务器管理方案来说，提供 RDP 只是为了便于 IT人员能够执行那些 Honolulu 还未提供的管理功能。
- Windows 10 客户端管理
在 TAP 中看到 Honolulu 1711 的内部测试公告时，超兴奋！可惜当时处于 NDA 只能压抑心中的喜悦。在 1711 中已经能够添加 Windows 10 客户端进行管理，点击“Add Cpnnections”能够看到“Add Windows PC Cnnection”选项。
对 Windows 10 客户端的管理支持与服务器并无太大区别，除了常规的指标监控，计算机基本信息外，也可对证书、设备、日志、防火墙、当前进程、服务、存储，进行管理和操作，如果被管理的 Windows 10 客户端启用了 Hyper-V，还可通过 Honolulu 操控这些虚拟机，并对虚拟交换机进行管理和配置。
- Switch Embedded Teaming（SET）
Switch Embedded Teaming（PS：貌似是交换机嵌入式分组），应该是 SCVMM 的一个功能，看介绍之前没有提供 GUI 界面来配置，而现在作为 Windows Server 2016 的内置功能，已经可以通过 Honolulu 进行管理和配置，其位于“Virtual Switch”下。（PS：但是在实际使用中并未找到这个功能选项，可能是由于被管理的服务器系统版本不是 1709 所致。） - 数据网格性能改进
针对证书和日志管理工具做了网络数据方面的性能改进。能够在处理大型数据集时，确保不会出现性能问题。这项改进将会持续进行，以确保 Honolulu 的所有管理功能都会获得最佳的性能。从目前的测试看，事件日志的加载过程确实缩短了不少。 - 从 In Service 模式中移除 LAPS
LAPS（Local Administrator Password Solution）已经从服务器安装场景中移除，但是在 Windows 10 下安装之后 LAPS 依然能够使用。
Project Honolulu Technical Preview 下载地址：http://aka.ms/honoluludownload
HOWTO: 解决Outlook邮件正文无法正确插入UNC类型快捷方式链接的问题
HOWTO: 解决 Outlook 邮件正文无法正确插入UNC类型快捷方式链接的问题
实在想不出更准确的题目，所以在分享前，gOxIA 觉得很有必要详细描述一下这个故障现象。用户环境是 Windows 7 + Office 2010（经典组合），在其桌面上有一个文件夹快捷方式（.lnk），目标指向到的是一个 UNC 路径，结构基本就是“\\\\10.0.0.1\\aaa\\bbb\\ccc\\ddd\\eee”这个样子，当然示例路径中的字母在实际环境下是中文+符号。如下图所示：
故障现象：用户在 Outlook 中撰写一封邮件，在正文部分使用“插入——超链接”功能，添加这个桌面快捷方式的地址。正常情况下，“插入超链接”窗口中的“地址”中显示的应该是这个快捷方式（lnk）的实际 UNC 路径，确定后邮件正文中添加的也应该是这个 UNC 路径。
但是在用户故障环境下，显示和插入的结果却是这个快捷方式（lnk）的本地路径，如下图所示：
问题虽小，但用户重视程度之高，在其他用户电脑上测试发现显示的确实为 UNC 路径，那么说明这个问题是一个故障。在打 Office 补丁，甚至重装了 Office 后，故障仍未解决。从故障看很可能是一直问题，所以决定寻求官方支持，但结果是 by design，或第三方插件干扰，实在无法接受这个解释！从经验来看这个问题很明显是一个故障，并且很可能是产品的已知问题。
看来必须要在自己的测试环境下重现故障，才能更好的寻找根因！随即开了一台虚拟机配置好了环境，但未重现故障，对比版本后得到如下信息：
用户环境：系统6.1.7601.17567 Office14.0.7015.1000
测试环境：系统6.1.7601.23537 Office14.0.7181.5000
基本可以确认用户环境肯定是缺少了什么补丁所致，因为Office 2010也有安装 SP2，而后续的零星补丁又太琐碎，也尝试直接覆盖文件，但并未解决，可以判定该问题与 Office 补丁无关，那肯定就出在系统上面了。
随后，重新搭建了测试环境，为虚拟机安装 RTM 版操作系统和 Office，果然重现了故障。RTM 环境下的版本信息如下：
RTM环境：系统6.1.7601.17514 Office14.0.7015.1000
至此已经明确了故障问题，用户因缺少某个系统补丁，导致在插入一个 UNC 类型的快捷方式时，会出现未达预期的结果。通过测试，并不是所有的 UNC 快捷方式都会出现这个问题，难道是中文长路径所致？但长度并未超过 256，且字符也属常见类型，看来只能通过 Process Monitor 抓包进行分析。
在抓包的数据中发现了问题！当添加超链接时，进程会遍历这个 lnk 所对应的 UNC 路径，但此时却出现了拒绝访问，如上图所示。根据分析的结果对这个 lnk 对应的 UNC 每一级目录进行了访问测试，果然如此！这个 UNC 路径“\\\\10.0.0.1\\aaa\\bbb\\ccc\\ddd\\eee”中，其中 DDD 和 EEE 是允许用户访问的，而上一级目录则禁止当前用户访问。
这也进一步验证了，该故障属于一个 Windows 的已知问题，接下来就是对更新补丁进行验证。将 RTM 测试环境接入内网 WSUS，拿到了 103 个补丁，这些补丁包含了安全和质量更新，还有汇总更新补丁。在一次打完所有补丁后进行测试发现故障消除! Great，可算有了里程碑式的进展，那么这 100 多个补丁中哪个才是修复当前故障问题的补丁呢？
要对 103 个补丁进行测试真的是一个巨大、枯燥，令人抓狂的工作，最终锁定 KB4022722 这个补丁！！！至此故障彻底解除，结尾要与大家分享一个重要的经验，在处理 Windows 故障，尤其涉及更新补丁时，在关键节点判断问题类型十分重要，如果分析归类为已知问题，应确认该问题是属于安全的还是质量的，这样才能有效减少工作量！！！（:-P）
