SID是个很久远的东西了，最早去了解这个东西，还是第一次尝试迁移Windows NT 4的域到Windows 2000…开始是知道SID相同加域会报错，后来迁移项目做多了，也就熟悉了SID History…然后是在SCCM/OSD的时候了解Client ID…后来，我给微软发布Windows 2012做全国TTT的时候，开始深入 VDI，再后来，莫名其妙就做了Citrix和VMware的VDI……
扯的有点远了……写段简历，其实是为了后面分不同角度来讨论SID在今天的环境中关联的一些问题。之所以把SID和VDI两件事情扯到一起，是因为长期以来对于VDI都会有挺多的有意思的细节，当然也因为我经常和伙伴及客户所强调的，VDI的出现，改变了 整个PC桌面管理的方式。所以接下来会讨论一点技术细节，同时也尝试讨论带来技术细节所带来的背景和方向。
为什么主流VDI的制备方式默认都不使用Sysprep了？
所谓天下大势，分久必合，合久必分，从主机时代走来的PC，带来的是计算的革命。从集中到分散，坐在数据中心维护机器变成了到处帮用户装机器…因而出现了一大批“终端管理”的解决方案，例如AD/GPO，SCCM，Landesk…而到了“近现代”，由于移动互联网的兴起，终端更加的离散，更多的终端节点意味着更多数据失控的可能，所以基于远程访问的VDI突然就站到风口了。
如VDI的全称Virtual Desktop Infrastructure所昭示的，VDI是基于Windows虚拟机、通过远程协议访问虚拟机中的Agent，实现“数据不落地”的桌面使用的架构。由于操作系统和应用程序以及核心的数据不再位于终端上，而是运行在数据中心，因此带来了安全边界的收缩以实现更高的安全性。正是这样的架构，决定了桌面从以前的分散管理，又变成了集中管理的模式。可以说，从根本上也解决了PCLM类终端管理无法保证覆盖全部终端，维持100%全面配置基线、安全基线的问题。
因此，VDI的桌面天生就是集中化的管理模式。那么问题就来了，我们应该“安装”或完整克隆一堆的VM当成PC来管理，还是应该通过标准化的制备方式快速获得呢？
从VDI本身的意义来说，一方面实现了小而完整的安全边界，另一方面就是通过虚拟化、云化实现了资源的动态调度，从而提高硬件利用率。实际上由于很多场景下考虑到用户并发上线使用数量，按照接近峰值的资源计算VDI硬件，再加上服务器硬件组件的可靠性及使用强度和寿命的因素，并不会比现在越来越便宜的PC便宜多少。如果再使用传统PC的管理模式管理，将会使得原本分散的终端管理问题集中起来并且显得更加尖锐。因此，除非不得已，以我多年的经验，是强烈不建议使用全克隆方式制备出一堆虚拟机，用以往的PC管理方式进行管理的。上VDI项目之前，就应该考虑是否对PC管理进行标准化，并对支持的PC配置标准进行合并裁撤。只有这样，才能够通过VDI项目收获最大的管理效益。至此，前面提出的问题的答案也就呼之欲出了，除非满足特定需求，我们应该尽可能通过标准化来实现对虚拟桌面的批量制备。
如果您是一位曾经部署过大量桌面的工程师，或者曾经将通过ghost类似软件复制的桌面加入到AD域中，肯定会知道，如果一个桌面的SID和其他桌面相同，加域要么不成功，要么会出现一些奇奇怪怪的问题。所以，有经验的管理员，会使用微软的一个自带的工具，Sysprep来重新为计算机生成新的SID。这个工具是微软官方认可的，解决SID重复当然没有问题。可是放在VDI场景里，问题就来了——Sysprep需要完成后，系统进行一次重新启动方才全面生效。而当我们启动“复制”标准虚拟机镜像的时候，是不希望每个最终用户花费几分钟去完成大家熟悉的、Windows第一次启动时需要好几分钟的那个初始化过程的。更别说，不保留系统变更的“无状态”虚拟桌面“每一次”进入虚拟桌面都要完成这个过程……
所以，除了保留系统更改的“有状态”桌面，目前已经很少在VDI部署中看到使用Sysprep进行SID重置初始化的做法了。
VDI架构真的都不生成或更新SID了吗？
关于这一点，我们可以找到如下的KB文章或者材料进行确认。首先看看VMware的官方知识库文章：
Differences between VMware ClonePrep, QuickPrep and Microsoft Sysprep (2003797)
在这篇KB中，主要针对不同的VDI桌面预备方式，介绍了不同的系统准备方式（Sysprep、QuickPrep、ClonePrep）。对于全克隆桌面，比较推荐使用Sysprep；而链接克隆桌面，可以视需要选择QuickPrep或者Sysprep；对于即时克隆，则建议使用ClonePrep为制备大量桌面进行准备。为了便于理解这几个比较陌生的词，我们对批量制备桌面最为关键的一些要求进行比较：
| 功能 | ClonePrep | QuickPrep | Sysprep |
|---|---|---|---|
| 修改计算机名 | Yes | Yes | Yes |
| 使用新实例加域 | Yes | Yes | Yes |
| 变更安全标识 (SID) | No | No | Yes |
| 生成新安全标识 SID | No | No | Yes |
| 重启次数 | 0 | 0 | 1 |
在这个表格里，我们关心的几个功能都有直接的对比。首先大量制备桌面虚拟机时，肯定都要给每个虚拟机进行命名，并且加入到AD活动目录域中，便于集中管理和提供全局登录。表中可以看到这个要求三种预备方式都能够支持。那么那些功能对于三种预备方式是有区别的呢？主要在于是否变更SID/生成新的SID以及需要重启的次数。如表格所示，Sysprep能够”严格“按照微软要求，为每一个桌面生成新的SID，但是无法避免需要进行一次额外的重启，因此在很多时候我们会选择非Sysprep的方式来预备桌面。
除了制备阶段，在这篇KB中其实还介绍了整个桌面虚拟机生命周期中不同阶段对SID的处理方式。对于 链接克隆方式，实际上可以同时支持标准的Sysprep和快速的QuickPrep：
| Creation | Refresh | Recompose | Rebalance | |
|---|---|---|---|---|
| Sysprep | New SIDs are generated for the Desktops | SIDs are preserved | New SIDs are generated for the Desktops | New SIDs are generated for the Desktops |
| QuickPrep | Master Image's SID are used for the Desktops | SIDs are preserved | SIDs are preserved unlessMaster Image is changed | SIDs are preserved unless Master Image is changed |
随着产品发展，链接克隆将逐步退出历史舞台，在新的Horizon版本中，即时克隆已经下沉到更低版本，成为批量制备的优先选择。即时克隆与链接克隆机制上有所区别，因此其虚机的生命周期环节也稍有不同：
| Creation | Push Image | On User Logout | |
|---|---|---|---|
| ClonePrep | Master Image's SID are used for the Desktops | SIDs are preserved unless Master Image is changed | SIDs are preserved unless Master Image is changed |
从以上两种不同的预备方式，都能够看到，实际批量制备桌面时，并没有生成新的SID，跟我们所熟悉 的“每一个加域的计算机都需要使用不同的的SID”的认知貌似有所不同。
实际上，不仅VMware是这样处理虚拟机的，Citrix也是这样处理的。可以参考Citrix的官方支持文章：
MCS Provisioned VMs Share an Identical Machine SID (CTX226711)
我没有找到关于PVS制备方式对SID处理的官方KB，但是以我对PVS制备方式的了解以及社区文章的描述，PVS也是不会生成和更新桌面虚拟机的SID的。而这篇描述MCS制备方式的KB对与SID问题的描述非常简单：重复的SID不是个问题……不信你去看微软的介绍……
而微软自己其实从Windows Server 2008开始也提供了基于RDS架构的VDI，可是我并没有找到有关制备时SID的处理的介绍……
Recommended settings for VDI desktops
到底VDI中使用重复SID是不是问题呢？下一篇我们用微软的文章来说明。