[RDS] HOWTO: 修改RemoteApp和桌面连接的自动更新周期
HOWTO: 修改RemoteApp和桌面连接的自动更新周期
在 RDS 环境中，客户端系统在控制面板的“RemoteApp和桌面连接”中添加了 RDWeb 的订阅，其更新方式默认为自动，且提示了会定期自动更新，但是并没有详细说明更新周期。如果用户此时需要更新 RDWeb 订阅以刷新发布的 RemoteApp 列表，则必须手动点击“立即更新”，那么是否有什么方法能够自定义更新周期呢？！
检查了 RDS 的相关设置和选项，也查阅了组策略，均没有线索！最后，通过对“RemoteApp和桌面连接”添加过程的轨迹进行了抓包，分析发现当添加一个 WorkResouces 时会向注册表添加连接信息数据（HKCU\Software\Microsoft\Workspaces\Feeds），并向任务计划添加一个定时任务，该任务位于任务计划路径"Microsoft\Windows\RemoteApp and Desktop Connections Update"下，任务计划名称是“Update connections”，如下图所示。
该任务的默认更新周期是一天更新一次，时间为每天的0:00，但是这个时间周期在实际环境下基本上是无效的，毕竟很少的用户会全天运行系统。所以，可以根据需要将其更改为每次登录时进行刷新。
此外，这个任务计划还为我们提供了非常有价值的命令行，通过下面的命令行可以执行手动刷新 RDWeb 订阅。
“%SYSTEMROOT%\System32\RUNDLL32” tsworkspace,TaskUpdateWorkspaces2
对于系统运维人员，可以利用上面的命令行编写脚本运行，方便调用。
掌控了“RemoteApp和桌面连接”的自动刷新周期，就可以方便的更新发布的程序列表，以实现便捷的推送和回收需求。
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 |
使用Hyper-V VLAN功能组建受隔离的网络环境
使用Hyper-V VLAN功能组建受隔离的网络环境
在开始今天的分享前，gOxiA 带着大家前先了解下面的截图，这样才能更好的理解所要分享的内容。在一个企业网络内（Corp LAN），已经部署了DC、DNS、DHCP、WDS等服务器，是一个完整的生产环境。在 10.1.50.x 的子网内 gOxiA 有三台 Hyper-V 主机（两台基于 Windows 10，一台基于 Windows Server 2016）进行工作相关的测试和评估。
默认情况下三台 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 段虚机互访。
虽然该法实现了最终的需求，但也确实与现有逻辑网络完全隔离，这意味着原有 10.1.50.x 段中的其他设备将无法访问这三台 Hyper-V 主机，否则也必须修改 VLAN 为 20。（如果 Hyper-V 主机是多宿主，倒是很好解决！）
