概览 Windows 10 内置的 OpenSSH 功能
概览 Windows 10 内置的 OpenSSH 功能
回顾 gOxiA 早在2005年撰写的一篇日志，曾提到 SSH 才是王道，现在看来也不为过，命令行的魅力和实用性无法替代，不会随着科技的发展而消亡。对于管理 Linux 系统，命令行则更加至关重要，SSH 也是最佳的远程管理方式。过去要在 Windows 上使用 SSH Client 通常要找第三方工具，如 Putty，或者 Xshell，前者官方访问受阻，还被搞出过一次安全事件；后者又是需要付费的产品，实在令人难以选择。
但是现在 Windows 10 原生支持 OpenSSH Client，此外还支持 OpenSSH Server，也就是说我们无需再借助第三方的 SSH 软件去管理 Linux。需要注意的是由于 Windows 10 内置的 OpenSSH 还处于 Beta 阶段，所以微软并不建议你应用在生产环境。
迫不及待，那么我们该如何启用 OpenSSH 功能呢？！非常简单，通过系统栏的通知图标选择”所有设置“导航至”应用-应用和功能“，点击”管理可选功能“-”添加功能“，选择”OpenSSH Client (Beta)“。
如果希望借助命令行方式来安装，有两种方法可以参考：
一、 通过 PowerShell，可以使用如下命令行获取 OpenSSH 功能的完整名称，然后再进行安装。
二、通过 DISM 进行安装，过程与 PowerShell 类似，都要先找到 OpenSSH 对应的安装组件名称，再进行安装。
OpenSSH Client 安装完毕后，可以通过 CMD 执行 SSH 调用，例如要远程登录 name.cloudapp.net 的 SSH，则执行” ssh account@name.cloudapp.net“，域名首部附加 account@ 是告知所要登录的用户名，等同于 -l 参数，否则将会使用当前的 Windows 登录账号去执行 SSH 验证。
如下图所示，gOxiA 通过 ssh 命令行登录到了 远在墙外的 Azure Ubuntu 虚拟机。
Windows 10 当前内置的 OpenSSH Client 版本，满足基本的操作还是没问题的，但是诸如 nano、rz 等程序指令还不能完好的支持。考虑是不是可以尝试给 Azure Ubuntu VM 添加个简单的图形界面，能够以 RDP 协议登录？！
[Tips] 定制 Windows10 开始界面时 Import-StartLayout 的常见问题
定制 Windows10 开始界面时 Import-StartLayout 的常见问题
在部署 Windows 10 前，IT人员通常会生成自定义的 Windows 10 参考映像，为了提升用户体验并满足企业桌面标准化，都会对 Windows 10 的开始界面进行定制，添加符合规范的程序图标并进行分组排列和组合。想必大家已经踩坑，自 16299 开始通过在应答文件中启用 CopyProfile 来实现开始界面的统一已经失效，所以必须借助组策略强制部署 StartLayout，或通过 PPKG 实现。当然，也可以使用 Import-StartLayout 导入 StartLayout.xml 为用户指定默认的开始界面布局，但是该方法对已生成用户配置文件的用户是无效的。对于不能通过组策略实现开始界面统一部署的用户，在 OOBE 阶段使用 Import-StartLayout 也是一个不错的选择，gOxiA 就是通过这个方法实现所有新登录用户使用统一的开始界面布局。
但是在实践 Import-StartLayout 过程中，也遇到一些比较典型的问题，会比较常见，特以此文分享于大家。
Import-StartLayout 命令行通常为“Import-StartLayout -LayoutPath C:\startlayout.xml -MountPath C:\”，其中 -LayoutPath 是指定开始界面布局配置文件所在路径，-MountPath 是指定系统卷。在上面的截图中有展示的是三个常见故障：
- Import-StartLayout ：文件 不是有效的布局文件
该问题通常是因为修改了 StartLayout.xml 导致的，其中包含了未满足规范的语句，这就需要进行具体的检查。 - Import-StartLayout ：未能找到路径 的一部分
其中路径类似“D:\Users\Default\AppData\Local\Microsoft\Windows\Shell\LayoutModification.xml”，通常这个故障是因为 IT人员在 Unattend 中重新指定了用户配置文件目录导致的，开始界面定制文件默认会应用到 Default 对应目录中，所以处理该故障就要先确定 Default 所在的卷。 - Import-StartLayout ：对路径 的访问被拒绝
此故障很容易理解，要执行 Import-StartLayout 需要管理员权限运行，如果系统启用了 UAC，要执行它就必须提权运行。
最后，额外分享一下开始界面布局文件中需要注意的事项，有些 IT人员会在布局配置中添加任务栏图标的定制（CustomTaskbarLayoutCollection），那么必须要对 CustomTaskLayoutCollection 进行声明，即添加“xmlns:taskbar="http://schemas.microsoft.com/Start/2014/TaskbarLayout"”。
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）
