说一件自己挖坑自己跳的扯淡之事，供大家幸灾乐祸。

在远程虚拟机中配置Win10，wf.msc限RDP的源与目标。开始设复杂密码，因为太过复杂，写在临时文件中，肉眼看了一遍，然后Copy/Paste到lusrmgr.msc的GUI中。虽然有个确认输入，实际就是Paste两次。

离开远程Guest Console，开始测RDP登录。nc测出3389/TCP可达，直接mstsc，弹出登录框，输入user/pass，登录失败。听说有沿线设备限制过RDP协议，自做聪明误判不是简单限制3389，而是做了协议解码后的干扰。

有些沿线设备的规则可能约束较强，比如逻辑与了3389，此时若切换到4489，就会绕过。回到远程Guest Console，reg add，改4489。不知何故，sc stop TermService失败，services.msc重启终端服务成功。调整wf.msc，nc测4489/TCP可达。mstsc登录，仍然失败。

脑子进水了，决定重启远程虚拟机，此处毫无逻辑。

重启后，mstsc登录失败依旧。至此，才开始怀疑pass设置有误。试图Guest Console登录，失败。天呐，改pass玩砸了。最后挣扎，在那个复杂密码的字符范围内做各种长短测试，比如首尾部多个空格，假设Copy时少复制了几个字符，等等。挣扎无果。

因故，无法对这台远程虚拟机动用U盘WinPE，满补丁Win10，悲剧。

事后复盘，第一次Copy/Paste时，很可能出现低级错误，剪贴板中的数据可能是其他意料之外的内容，并不是计划中的复杂密码，这是第一个大错误。发现RDP登录失败时，趁远程Guest Console还在，立即lusrmgr.msc改密码，手动输入两遍，即可抢救，但毫无逻辑地盲目重启，失去Guest Console，这是第二个大错误。沿线设备没有限制RDP，全是自己给自己加的戏，没有道理3389可达然后解码干扰，从概率上考虑，若真如此就属于没事找抽。事实表明，沿线设备没有找抽，是我找抽。

不想再折腾，直接废了这台远程虚拟机，重新远程上传已在本地改好配置的虚拟机，除了有点大、上传耗时长，没啥。