昨天见了一个客户，他请我们帮他规划一下后台的Profile该配多大，每个人多少空间，选什么存储类型，甚至抱怨管理太麻烦。有感于此，特综合了一下各种资料，准备写一个关于Profile的系列文章，分三期发布，今天是第一期，聊一下Profile的配置难点。

事先申明，以下内容不是关于回答什么是Profile的科普文章，有关什么是Profile，或者什么是Folder redirector请自行使用搜索引擎Google学习。 

序言

如果你曾经经历过XenApp或者是XenDesktop的实施项目，一定会知道用户的Profile是最难搞定的问题之一，所以这也是Citrix推出自己的Profile管理工具UPM的驱动力， XenDesktop从VDI版本（含）之上都可以免费使用该功能。

我不想谈太多关于不同种类Profile的区别。解释为什么需要漫游配置文件的文档google随便一搜一大把。这里主要想谈一下如何正确的配置Citrix ProfileManagement这个产品，或者说是Citrix ProfileManagement的最佳实践。另外，本篇文章只要针对的是Pool模式下的Windows 7 VDI桌面环境。

在大部分的情况下，我碰到的情况都是Citrix ProfileManagement只是安装上去之后简单配置了事。似乎只是把Citrix ProfileManagement安装好，并且启用之就可以解决用户的个性化文件配置问题，或者想当然认为就可以改进配置文件管理。问题就出在这里，答案是远非如此。事实上，如果你只是简单的安装了Citrix ProfileManagement然后启用它，你所能得到的就是一个漫游配置文件。在一个实际场景中，这只会使用户体验更差，老实说还不如就在AD里面配置一个标准的漫游配置Profile好。

文件夹重定向

用户配置管理的核心是文件夹重定向，无论是AD的，还是Citrix Profile Management，还是其他第三方产品都是如此。从Windows2000操作系统发布以来微软就提供了一个组策略功能来实现这个配置，你甚至可以通过注册表的修改来实现。由于文件夹重定向是Profile管理的核心，所以无论是标准的漫游配置文件设置，还是Citrix ProfileManagement，还是类似AppSense的工具，第一步就是首先要启用“文件夹重定向”。

从Windows 7操作系统之后微软已经明显改进了文件夹重定向，新的配置包含了更多的目录。缺省状态下，你可以通过内建的组策略重定向以下的文件目录：

AppData(Roaming)

Contacts

Desktop

Documents

Downloads

Favorites

Links

Music

Pictures

Saved Games

Searches

Start Menu

Videos

在一个设计良好的Profile设计方案中，上述文件夹都应当被执行重定向操作。唯一的例外就是如果用户对上述某些目录不希望作永久保留。例如，一般来说公司都不希望用户保留“Saved Games”这个目录，这种情况下你就可以不做这个目录的重定向操作，你需要做的事情就是做一条例外策略以排除这个或者这些个目录。在做了这个策略之后该文件夹就只会驻留在本地的虚拟机中，如果虚拟机不是永久保留的（例如Pool模式），这个文件夹将会在这个虚拟机logoff或者是重启后被清理。

做文件夹重定向需要做一条策略将上述目录转移到新的位置中，下图就是设置的策略截图：

文件夹例外操作

将某个不希望做重定向的目录从漫游配置或同步配置中排除，一般来都是通过制定排除策略来完成，在项目中这种策略是非常常见的。如果使用的是Citrix ProfileManagement，可以通过一个专门的GPO来阻止这些目录的同步。你需要做的事情就是把所有你不想做同步的目录添加到这个策略中。此外，最低限度你还应该添加下面的目录到例外列表中：“AppData\Local”,“AppData\LocalLow”, 以及 “LocalSettings”.

在什么情况下需要对某些文件夹做例外处理，第一种情况是如果这些Profile中的文件夹在做了重定向操作后仍然是孤立状态。第二种情况是，也是更经常的情况是那些编写很烂的程序总是写入那些不能做重定向的路径中，这就导致Profile逐渐膨胀。举个例子来说，如果该软件的程序员在写程序的时候本来应该读取Shell文件夹的值，但是他却直接使用了%userprofile%这个目录。

举个例子来说，程序员在写程序的时候，将该程序的数据写入路径设置为：

%userprofile%\ApplicationData\CrappyApp

如果开发人员使用的是%userprofile%这个变量，那么AppData是不是做重定向就不重要了，因为该应用程序始终会写入本地的profile目录中。

正确的做法是将应用程序使用如下格式的%AppData%变量：

%AppData%\GoodApp

在给“Application Data” 以及“AppData\Roaming”,添加例外策略后，管理员就可以阻止这些编写很糟糕的程序把用户的Profile逐渐撑爆。

总结一下，管理员应当在微软的GPO中重定向所有的文件夹，然后在Profile同步中排除不需要同步的目录。做好这些策略后会让Profile保持在一个非常小的容量，对性能的提升，以及降低IOPS的开销效果来得非常明显。

应用程序数据

我相信你肯定会想，如果把AppData做了重定向操作肯定会导致某些应用程序出问题；另外，设置一个例外规则来禁止数据写入%userprofile%可能会导致个人的设置丢失。好吧，我们应该这么看，不管一个应用程序编写的好还是不好，用户肯定是希望他的个人应用程序数据是永久保存的，有这样几种办法可以考虑：文件夹/文件的包含列表，以及ApplicationStreaming，我们姑且先把这个功能翻译成应用程序流吧。

文件夹和文件的包含清单

我们先假设有一个应用程序叫做CrappyApp。这个程序的开发者犯了一个菜鸟级的错误，他把“%userprofile%\Application Data\CrappyApp” 设置为用户应用程序数据存储的目录了。接下来我们做了Appdata目录的重定向，然后添加了一个例外规则用来禁止“%userprofile%\Application Data” 目录的漫游和Profile同步。这个程序在工作过程中所有写入“%userprofile%\Application Data”目录的数据在用户Logoff或者是重启后都会丢失。管理员在项目的Pilot阶段应该很快就能发现这个问题，而不应该把这个问题带入到生产环境中。加入管理员没有发现这个问题而将这个系统发布到生产环境中，用不了多长时间用户就会打电话给管理员抱怨他们的CrappyApp这个应用程序产生的个性化数据在注销后都不复存在了。不过这其实是个好事情，至少你知道这个程序写的有多么的烂。管理员现在要做的事情就是赶紧通知该应用程序的开发商去修正这个软件Bug。一般来说，只要这个公司还没有倒闭，这种小错误都很快能够得到解决。如果是实在要花费太长的时间来修正这个软件的Bug，我建议你做一下分析，来看看有哪些数据被写入了“%userprofile%\Application Data\CrappyApp”这个目录中，看看那些文件应该永久保存。如果这个目录不太，包含的数据不太多，你可以创建一个文件夹的包含策略，把CrappyApp这个目录添加进到Profile的同步目录中去。

如果该目录实在太大，里面有太多的文件在里面，你可能就要花点心思分析一下看看这个烂程序都写了些什么东西在这个目录里面，这些文件是不是都有必要永久保存。由于我们已经知道这个程序实在是写得太烂，如果看到有temporary文件，或者是其他垃圾文件被写道这个目录，我觉得毫不奇怪，既然是这样，也就没有什么必要保留这些文件了。大部分的情况下管理员会发现目录下面有一个蛮小的.DAT文件，或者是一些.ini文件，这些文件其实才是真正包含了用户个性化设置的文件，所以这几个文件才是最重要的。你如果明白了这点，接下去你要做的事情就是创建文件同步规则，把刚才说的这几个文件同步到Profile中去。你可以使用通配符规则来同步上述文件，例如：“Application Data\CrappyApp\*.dat, *.ini”。如果我们只添加了这几个只是必需的文件到Profile中，即使这个程序写的并不好，但是我们还是做到了保持Profile的精简。

举个例子来说，Google Earth，这个程序就是把他的数据写到“AppData\LocalLow\Google\GoogleEarth”目录中。缺省状态下，微软的漫游Profile是会把 AppData\Local 和 AppData\LocalLow这两个目录自动作为排除目录来处理的，在Citrix Profile Management中，我们也是把这两个目录作为排除目录来处理的。微软把这些目录是称之为本地目录的原因之一就是认为这些目录缺省状态下不应该是网络路径。对Google Earth来说，他会把他的缓存文件和其他临时文件放在这两个目录下。缓存文件一般来说都非常大，所包含的内容通常来说都不需要永久保存。Google Earth通常还会存储用户的“我的位置”和他们KML文件在这两个目录中。其实真正需要保存的就只有这两个目录下的一些很小的.xml文件，这些.xml文件才是真正存储了用户的个性化设置数据。好吧，如果你碰到了Google Earth，那就做一条包含规则，把“AppData\LocalLow\Google\GoogleEarth\*.kml”设置为同步，这样就不用同步整个目录了。这么做用户也开心，Profile仍然被限制在一个很小的范围。

除了Google Earth之外，还有一些关键的功能点也需要做好同步，例如一些PKI的证书和Office的工具栏，等等。有关于这些必须同步的文件和文件夹的设置，可以参考下面两篇KB的文章：

http://support.citrix.com/article/CTX130665

http://support.citrix.com/article/CTX124948

Application Streaming

我们刚才已经处理了那种应用程序不把自己的数据写入到同步目录中的场景，如果万一应用程序不喜欢把他们的AppData目录重定向到网络路径呢？有时候如果你把AppData强行设置为网络路径，该应用程序可能会崩溃，或者工作不正常。老版本的Adobe就会出现这个问题（写得够烂得）。不过好消息是，过去的几年以来这种情况发生的越来越少了。大部分的软件开发商现在都很熟悉AppData目录的重定向技术，在发布前就会测试是否可以设置为网络路径。除非是一些很古老的程序，新的软件很少会碰到这个问题了。不过也不是完全碰不上，我最近就碰上一个Java的应用程序，只要一设置AppData为网络路径该程序就崩溃了。那我该怎么办呢？哈，请使用Citrix Application Streaming来对付这种场景。

通过XenApp来虚拟化应用程序并流化交付到前端，我们就可以实现应用程序的隔离，在应用程序启动的时候可以生成新的变量和路径。对了，再说一次，我这里说的技术是XenApp的应用程序流化技术，不是指XenApp的共享应用程序技术。

为什么Application Streaming能解决这个问题呢？其实是当一个流化的应用程序在启动时，我们能设置一个预启动的脚本并首先执行这个脚本。也就是说我们在预启动脚本中就修改隔离的AppData位置。这么做完全不会影响到其他的应用程序。

还是举个例子吧，我把Office2003这个程序打包了（好吧，必须说明一点的是Office2003其实是完全兼容AppData目录的重定向操作的，只是用它来做个示例）。在编辑这个流化应用程序Profile的编辑框中，我们可以设置一个预启动脚本。由于我们仅仅是想修改这个应用程序的AppData的路径，所以这个脚本必须在隔离状态下运行，如下图所示：

在上图中可以看到，我设置了一个脚本叫做setappdataNaNd，这个脚本将会该应用程序被执行前在隔离环境下运行。该脚本如下：

我喜欢写这种脚本时去调用另外一个脚本，这个第二个脚本通常我是放在文件服务器上。这么做的好处就是将来升级很方便。不管你什么时候想在一个流化的应用程序中放置一个脚本，你只需要该后台的那个脚本就可以了，应用程序里面的这个脚本无需做任何改动，也就是说应用程序本身不需要再重新打包了。这是一个最佳实践的经验，有关于这个设置，还可以参考Citrix Blog上的其他两篇文章：

http://blogs.citrix.com/2011/01/21/app-streaming-introduction-to-scripts/

http://blogs.citrix.com/2011/02/04/app-streaming-global-scripts/

现在我打开刚才说的放在文件服务器上的那个被调用脚本，可以看到这是一个.vbs的脚本：

现在我们看看这个.vbs脚本，看看他是怎么写的：

这个VBS脚本在隔离的应用程序注册表中设置了四个注册表键值：

1. 设置了两个AppData Shell文件夹简直指向AppData回到%userprofile%

2. 设置了两个%AppData%环境变量值回到%userprofile%

这个脚本的意思其实就是欺骗这个流化的程序，让他认为这个AppData目录从来都没有重定向过。

现在看看实际的效果。下面的截图显示了在一个Windows 7的Pool桌面中加载了这个流化的Word 2003程序后首先运行了我刚才写的这个预启动脚本。当我选择打开文档的时候，选择 %AppData%作为目录来打开。

从上面的截图中可以看出，Word2003程序的AppData这个变量值已经被解析到%userprofile%\AppData\Roaming，而这个目录看起来就在C盘上。

还有一个办法用来判断这个流化的程序中的AppData变量值指向什么地方去了，我们可以从这个流化的程序中打开一个命令行窗口，如下图所示：

我是从流化的Word这个程序中打开的cmd命令行，所以这个cmd命令行其实也是隔离环境下的。可以注意到AppData变量指向的就是C盘上用户Profile路径。

现在我们看看如果是从隔离环境之外的本地OS运行这个CMD命令行是个什么结果：

从上图中可以看出来，本地OS仍然使用了重定向的AppData目录。通过使用预启动脚本，我们能够成功实现将AppData回指向本地C盘而不用影响其他应用程序。

由于缺省状态下我们希望将%userprofile%\AppData\Roaming 这个目录列为Profile同步的例外处理，即不同步这个目录，那么流化程序写在这个位置上的任何数据将会在注销OS后被删除。但是正如我们在上面谈过的，如果你有想永久保留的任何文件和文件夹，你还是要做一条同步规则来保留这些数据。

只要正确的使用Application Streaming 以及文件夹/文件的同步规则，我相信没有理由你始终避开重定向AppData。任何重定向AppData时碰到的问题都可以解决。

最后我想谈一下当把AppData目录重定向到网络路径时的应用程序性能问题。首先重申一点，我在这里谈的都是运行在HyperVisor上的虚拟桌面环境。在这种场景下，用来AppData文件夹重定向的网络路径服务器应当是和虚拟桌面在同一个数据中心中，也就是说两者一定是高速连接的。如果是大型企业，我相信把这个NAS连接到网络上的带宽应该是万兆的，或者说至少都是几条千兆网络的聚合吧。如果你正确设计了你的文件服务器基础架构，我相信不会有什么性能问题的。

所以如果你在做AppData的目录时遇到了性能问题，你肯定在哪里有配置错误的地方。

Profile的流化（ProfileStreaming），以及主动回写（ActiveWrite Back）

Profile Streaming（还是不翻译了吧，直接用英文）这个功能其实说的是如果一个文件/文件夹当不被真正使用的时候，它就不被OS拷贝出来，只有在真正被应用程序或者是OS调用时才去读取它并进行读写操作。这个功能可以减少数据的下载量，也能加速Profile的加载速度。

这个功能确实不错，但是在实际场景中，却经常看到它被误用的情况。我们在前面的章节已经谈到过，管理员应当重定向所有可用的文件夹，包括AppData目录。如果你严格按照我上面说的来进行，那么你的UPM的Profile目录实际上将会非常的小。在一个实际项目中，我做过的Profile目录基本上都不会超过10M大小。

下面的图就是一个正确配置的UMP Profile文件夹的截图：

我们可以看到这个UPM的文件夹里面其实只有14个文件，27个文件夹，以及不到1.2M大小的数据。这是因为所有的文件夹重定向规则和例外规则都正确配置了。在上面这个例子中，Google Earth KML文件以及PKI证书都已经做了同步到AppData的操作，即使在这种情况下我们看到这个Profile的文件夹也是非常的小！

如果不幸你遇上了我们前文说过的开发很烂的那些应用程序，又或者是那些不能和重定向的AppData正常工作的应用程序，那么文件/文件夹的包含策略就有可能导致UPM Profile中的AppData文件夹变得非常大。还是说一个实际的案例吧，我曾经帮助一个客户现场解决过他们的Profile问题。即在他们的XenDesktop环境中配置UMP以及Application Streaming策略。我用过了Explorer,Adobe Reader, Outlook, Word, Excel, Lync,以及其他应用程序。在我的Profile中有给电子邮件用的PKI证书，身份认证文件，以及其他东西。这个Profile基本上运行了一年多了，而大小呢？整个UPM的目录我做下来之后只有5M大小，其中包含了67个文件，71个文件夹。Profile的大小其实一年增长5M是个比较正常的数字。一般来说绝对超不过15M大小。

从个人观点出发，其实我认为没有必要使用Profile Streaming这个功能的。为什么？就是我们刚才说的Profile大小问题，你真的会在意5M大小的传输量吗？5M的数据不会对性能造成任何影响。所以，只要你配置正确，Streaming这个功能基本上没什么用处。

虽然是这么说，Profile Streaming这个功能还是有一些用处的。比如说，如果你有一个应用程序写的实在太烂，又或者和AppData重定向不兼容，你肯定就又要添加文件/文件夹的同步规则来允许一些特定的AppData的目录在登录时执行同步操作。接下去如果你关闭了这个应用程序，而这个应用程序又要写入很多需要同步的数据，此时Profile Streaming功能就起作用了，因为它能判断在应用程序实际需要使用这些个文件的时候才去下载，这样他能降低登录时间，减少数据的总下载量。

如果是这种情况，我建议可以打开这个功能。并且记住把这个功能应用在某个组的用户上，而不是给所有用户使用。

至于主动回写（Active Write Back）功能，其实适用场景和Profile Streaming一样。如果Profile很大，那么这个功能就用得上了。不过，只要是正确配置了Profile Management，我不认为你的Profile有多大可能性会在注销登陆的时候会上传超过10M的数据量。所以，主动回写（ActiveWrite Back）基本上也没什么作用。

基线策略

好了，到现在为止我相信你已经理解该如何做Profile management的重定向策略了。另外我还可以分享一个示例的Profile Management 和 Folder Redirection的基线GPO策略。为了简化起见，全部打包进这个GPO了。当然，你一定需要再去细化一下这个策略而不是拿来就用。

基线策略的下载地址：Win7 UPM & FolderRedir

其他注意事项

安装Citrix profile Mangement之后，记住将缺省的.ini设置文件更名：

“%ProgramFiles%\Citrix\User ProfileManager\UPMPolicyDefaults_V2Profile_all.ini”

别忘记启用Cookies目录到Mirror的策略中，可以参考下面的文章：

http://blogs.citrix.com/2011/01/25/notes-on-synchronising-internet-explorer-cookies-using-profile-management/

http://support.citrix.com/proddocs/topic/user-profile-manager-sou/upm-manage-cookies.html

如果是Outlook的PST场景，请创建一个策略来强制pst文件到重定向的AppData文件夹中。这样就可以把pst文件排除在profile之外，这样登录和注销的时候也就不会去同步pst文件了。注意请不要使用CitrixProfile Management去做pst文件的同步，包括Streamingprofile这个功能也不要用在.pst文件上。事实上，在Outlook2010发布以后，微软已经正式支持将pst文件放在高速的CIFS共享路径上了。其实Outlook2007和2003也支持。

下期预告：Profile的IOPS配置，敬请期待。

本文出自 “Citrix的虚拟世界有你有我” 博客，请务必保留此出处http://virtualworld.blog.51cto.com/1412963/1549874

Citrix Profile Management 和 VDI系列讲座之一：如何正确管理Profile