XA和XD导致登录时间过长的原因
XA和XD简化了应用程序和桌面的管理，但是长时间的登录过程会导致用户的满意程度下降；此外，这样或者那样的问题也会延长登录过程。我公司刚刚发布了一个白皮书，详细说明虚拟应用和虚拟桌面的登录过程，接着定位导致登录时间过长的原因，并且说明如何解决这些问题。当然，白皮书最重要的是介绍给你如何通过使用EdgeSight来自动化的实现这个排错的过程，加大的简化你的工作量。我把白皮书做了一些摘录，供阅读时参考，希望对你有帮助。
白皮书的下载地址：http://support.citrix.com/article/CTX128277
一：登录过程
二：通常导致登录延迟的原因
有太多的原因会导致登录慢，我们只讨论最常见的原因并且探讨如何解决这些问题。这些原因一般都有：错误的配置、网络问题、硬件过载、资源消耗大户的应用程序/脚本、已经损害的profile，以及其他。网络负载过高或者硬件问题甚至会导致登录失败。
2.1 登录/验证原因1：AD服务器过载；
原因2：AD服务器无法访问；
2.2Profile访问问题在大部分的公司环境下，Profile是导致登录时间过长的一个最主要原因。其中的问题有可能是Profile太大，也有可能是连接到存储Profile的存储问题。
Profile有好几种形式，包括本地、漫游，以及强制，还有第三方解决方案/强制Profile管理上最简单，但灵活性欠佳。因此第三方的管理方案，例如Citrix 自己的Profile解决方案、AppSense Environment Manager，或者是Liquidware Profile Unity都可以是替代的解决办法。这些解决方案都提供了流化Profile的能力，避免了在启动时完全加载profile的默认方式。本章节主要讨论漫游profile的问题，因为这是虚拟化环境下碰到的最主要问题。
原因1：Profile过大，没有优化过的profile可能膨胀至几百M和上千个文件，下载这些内容导致了启动时间显著增加。
解决办法：重定向用户目录到网络共享；忽略一些目录（例如Cookie/历史文件）
原因2：损坏的Profile。如果用户同时打开了多个会话，这就会导致漫游profile文件的崩溃。
解决办法：在Windows 2008R2版本AD下，启用“临时漫游配置文件”的写功能（enable interim roaming profile writes ）。或者是使用第三方的profile解决方案来管理多个会话问题。
原因3：Profile存储地址无法访问。启用Profile存储方式的高可用。
原因4：Profile存储空间的服务器过载，有太多用户同时连接。
解决办法：优化文件存储，确保硬件和网络能够承受压力了，或者是分布到多个服务器上。
2.3GPO和启动过程GPO和启动脚本对启动时间影响较大，一些可能会导致启动时间变长的原因可能有：
大量的GPO
大量的访问控制规则
大量的脚本
大量的驱动器重定向
大量网络打印机
大量XA/XD策略
如果不使用专门的工具，例如EdgeSight，想要去找到是不是GPO和脚本导致的启动时间变慢原因可能会非常麻烦
原因1：访问控制太多
解决办法：优化访问控制，减少配置，使用AD组等；
原因2：太多GPO
解决办法：合并GPO，宁愿要大的GPO也不要众多的小GPO；
原因3：脚本运行时间太长，互相嵌套调用操作等
解决办法：优化或者合并登录脚本
原因4：打印机/磁盘映射
解决办法：减少打印机/磁盘映射数量
2.4网络问题
原因1：DNS记录不精确，导致解析地址出错
解决办法：检查地址的正确性；
原因2：网络带宽不够，网络质量不好
解决办法：监视连接，；包括丢包率，延迟等参数
2.5硬件过载
通过以下步骤可以大致看出瓶颈是在哪里：
1)
如果WI的登录时间太长，很有可能就是WI服务器或者是DC认证超载了；
2)
如果应用/桌面花费很长时间才显示出来，或者是ica文件花了很长时间才生成，有可能是ZDC/XDC超载。可以使用以下的办法来测试：
a.
右键点击WI里面的一个图标，选择“另存为”，测试一下花费的下载时间；
b.
在XA服务器上，检查ZDC上的计数器“Citrix Metaframe Presentation Server / WorkItem Queue Ready Count”有没有超过2，超过就是。
3)
上两步都无法确认问题的话，可能就是License Server无法访问或者是过载了；
4)
也有可能是App自己的花费太长时间启动。
原因１：硬件过载
解决办法：监视所有服务器的参数，包括磁盘、CPU、内存、网络等
原因２：硬件宕机
解决办法：监控
2.6应用程序和桌面的启动
原因1：后端数据库和文件服务响应很慢
解决办法：确保后台资源足够；
原因2：应用程序启动很慢
解决办法：判断一下是不是只是在XA里面很慢；
原因3：桌面花了很长时间启动
解决办法：用户访问前就启动桌面，优化启动过程，禁用不必要的服务／应用
原因4：一些应用额外的认证过程
解决办法：使用SSO解决方案。
三：使用EdgeSight对登录故障进行排错
EdgeSight可以极大的简化排错的步骤。它不仅仅是提供了服务器和桌面资源的监控及报警、WI响应时间，以及其他关键参数，他还能生成启动过程中不同过程的详细报告。例如使用“Session Startup Duration Detail”报表，就可以看到服务器端和客户端的应用程序启动过程，这在很大程度上减轻了定位问题所花费的时间。
下面的图就是一个报告的示例，粗看可能比较复杂，不过不要紧我们会详细分析。
上面的图看似复杂其实有几个关键可循。第一个就是上面的图由服务器端花费的时间和客户端花费的时间组成，这是分开的两个部分。
原因1：Credentials Authentication.
分析：这个参数时间过长可能就是DC过载了；
原因2：Profile Load.
原因3： Login Script Execution. GPOs 和登录脚本运行的时间.
原因4：Printer Creation
原因5：Drive Mappings.
上述表格的个别参数简单释义：
1)
服务器端
a.
CASD
b.
CONSD：只适用于Security Support Provider Interface登录
c.
DMSD：确保禁用不常见的虚拟通道，例如音频、COM口，以优化ICA协议；
2)
客户端
a.
AECD：考虑是不是XML Broker或者是WI服务器的问题；
b.
BUCC：如果这个值大于1就表示WI服务器不可用，Receiver正在连接备份WI服务器；
c.
NRCD：如果这个值很高，就表示XML Broker花费太长时间来解析应用到一个IP地址。
页:
[1]