[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 主机是多宿主,倒是很好解决!)