部署 Microsoft Dynamics CRM 4.0
Aaron Elder
概览：
- CRM 系统的软件组件
- 在开发生命周期
- CRM 解决方案的元素
- 查看 multi-tenancy
内容
解决方案开发生命周期
CRM 解决方案的元素
multi-Tenancy 呢？
设计注意事项
密钥 Takeaways
如果您习惯考虑的 CRM，只是一个销售和市场营销管理工具，再次考虑。 Microsoft Dynamics 客户关系管理是一个平台开发管理和跟踪信息和过程与实际的对象的应用程序。 这些对象可能是客户，但它们也可以几乎任何实体 （和相关的活动） 需要管理的。
使用任何大型的自定义解决方案，有一些基础知识与需要理解的部署。 此文章中, 我将介绍 Microsoft Dynamics CRM 部署包括如何使用这些概念支持完整的产品生命周期部署与相关的一些基本概念。 我还将讨论管理多个部署作为一个单一解决方案发布和 multi-tenancy 应该的方式，不应作为整个解决方案生命周期的一部分的一部分。
我想在本文我引用 Microsoft Dynamics CRM"解决方案"时, 我意味着的所有自定义、 扩展、 自定义编码、 架构更改和等 totality 的开始进行清除。 一个解决方案不只是一件事 ； 同时是您所做的所有更改。
在后台 Microsoft Dynamics CRM 解决方案都是一个标准的 ASP.NET 2.0 和 Microsoft.NET Framework 3.5 数据驱动的 Web 应用程序。 三层系统包括下列主要组件：
数据层 SQL Server 2005 或 SQL Server 2008 数据库。 知识库文章中所述，使用 SQL Server 2008 要求修补程序" 对运行 Microsoft Dynamics CRM 4.0 一起 Microsoft SQL Server 2008 的支持."
中间层 Microsoft Internet Information Services (IIS) 6.0 或更高版本 Web 前端 ； SQL Server 报告服务 (SRS) 2005 或 SRS 2008 ； ASP.NET 3.5 ； 自定义的 Windows 服务。
客户端层 Microsoft Internet Explorer 6.0 或更高版本客户端 ； ASP.NET 2.0 或更高版本 ； （具有可选的脱机访问） 的 Microsoft Office Outlook 2003 或 Office 2007 客户端 ； 其他如 SDK 的使用者和第三方移动客户端。
Microsoft Dynamics CRM 还依赖于各种外部包括 Microsoft Exchange Server 2003 或更高版本的系统和 Active Directory。
解决方案开发生命周期
Microsoft Dynamics CRM 解决方案经历生命同一个周期的自定义应用程序开发项目，看操作例如过程所示的 图 1 .
图 1 周期应用程序开发
一起组成开发、 测试和生产系统的多个环境支持此整个过程。 在世界任何 multifaceted 企业应用程序中中, 这，当然，可以打开时必须非常复杂。 如果在是例如，您是以反映您的环境，您可能会与看起来像 图 2 结束设置。
图 2 镜像您的开发人员、 测试和生产环境
这三个域、 三个域控制器三个邮件服务器、 三个 Web 服务器，和三个数据库服务器和此模型假定 SRS 和客户关系管理位于相同框并不考虑帐户等负载平衡。 现在让我们添加冗余和几个外部服务 （如 Microsoft Office SharePoint Services (MOSS)，和您的魔力未能得到类似 图 3 中的一个方案。
图 3 Increasing 复杂性
成本和复杂性由于原因可能权衡考虑以平衡环境隔离对需要保留成本向下和可管理性最需要。 组织有因此查找诸如不是虚拟化和 Microsoft Dynamics CRM 的技术的各种内置 multi-tenancy 功能，来解决这些难题。
在设计一支持 CRM 项目的生命周期的环境时有几个学校的想法，具体取决于什么原则将重要，您可以选择一个方法或其他。 在该系列一末尾，设计器升级总隔离使用完全复制。 这些朋友们认为只有这样才验证内容将外部的生产工作将与生产环境的 100%的测试环境。 每个服务器、 每位和每个设置必须相同和完全隔离开发和测试人员的生产和 IT 可以接受，并认为在生产的内容仍可使用。
相反，其他人认为的隔离进行排序并不真正根本重要。 如果他们未能，它们将开发，并直接在生产环境中测试。 它们往往冗余看作是浪费时间和资金，并它们某些如果它们可能只有并进行处理的内容传递会更容易。
希望，您属于某处这些 extremes 之间，并且将打开思路谈到 Microsoft Dynamics CRM 的解决方案，则可以开发余额复杂性、 成本、 隔离和可管理性的混合。
CRM 解决方案的元素
Microsoft Dynamics CRM 解决方案组件可分为四个主要的存储桶，，您的解决方案可能包括一个、 两个、 三个，或所有四个。
自定义设置 它们包括窗体、 网格、 架构和元数据的更改、 安全角色、 工作流 ； 系统设置 ； 和模板。 Microsoft Dynamics CRM 自定义提供为一个或多个 （通常一个或两个) 压缩的 XML 文件。 在导入到通过 Outlook 或 Web 客户端的 CRM 部署"设置 | 自定义"区域然后"发布"以使其活动。 所有这些可以自动完成使用针对 Microsoft Dynamics CRM SDK 编写的代码。
扩展 其中包括报表和自定义代码必须部署自定义设置中的单独的插件。 插件的注册信息都存储为 XML 文件，并可以通过命令或者行部署或 Windows 窗体应用程序提供由 Microsoft。 这还可以自动通过针对 Microsoft Dynamics CRM SDK 编写的代码。
自定义代码 任何开发作为您的解决方案的一部分，并且它可能包含外部 Web 服务、 自定义 Web 应用程序组件，等。 规则和部署自定义代码的实践应该不不同于任何其他自定义 Web 应用程序。
数据 要导入到函数的该环境的环境需要的任何信息。 这可能包括域数据 （例如，产品代码的列表） 或用户。 到使用脚本的代码或 CRM 的批量导入功能在 Microsoft Dynamics CRM 实例或某些形式的外部进程使用 BizTalk 或其他 ETL 提取、 转换加载） 的工具，可以部署您的解决方案需要的数据。 某些数据，如用户，需要创建手动或通过 Microsoft Dynamics CRM SDK 调用。
我希望的 CRM 解决方案部署就如同它们是自定义应用程序开发部署。 也就是说，在开发和测试，清理基本的系统中安装解决方案的每个新版本而进程已为可重复并尽可能脚本。
multi-Tenancy 呢？
现在让我们讨论您要部署到它们在环境应类似。 您可能必须了解 Enterprise Edition 的 Microsoft Dynamics CRM 4.0 支持功能称为它可以分区的一个部署中的 Microsoft Dynamics CRM 多个实例的 multi-tenancy。 这意味着具有自己的报告、 工作流、 自定义和架构的多个完全不同组织可以运行同一组的使用相同的物理服务器使用同一个数据库实例和 IIS Web 站点的硬件。
在第一次不易这可能似乎在 panacea，解决了所有我们可管理性，隔离，并成本 conundrums。 如 图 4 中，可能被可视化类解决方案。
图 4 A 多 tenancy--只解决方案
因为每个组织获取有关共享的 SQL Server 或实例 （包括自定义、 工作流、 用户、 角色和设置） 和它自己的 SQL Reporting Services 文件夹自己物理数据库，这似乎逻辑。
如果这些不同的组织不同的团队或部门的解决方案的一部分完全和此模型工作。 这，别是忘是什么 multi-tenancy 专。 满足每个组织 （或租户） 获取自己的数据库时，它们都共享同一个组织单位 (OU) 和 Active Directory 组和它们将所有共享在同一平台服务和以及前端应用程序。 这意味着在组织之间共享同一异步服务和 IIS Web 站点。 前端服务器可以"承载这些不同的组织通过 URL 提供程序，确定，基于在的 URL 主机的组织。
执行这些 URL 作为示例： crmserver/ContosoDevOrg/loader.aspx 和 crmserver/ContosoTestOrg/loader.aspx。 在 CRM 服务器查看根目录下，来确定组织能够提供名称。 如果没有根组织名称位于，为 crmserver/loader.aspx 的服务器默认第一个组织在部署或其中调用用户具有访问权限。
因为如果必须自定义代码作为您的解决方案的一部分在同一网站用于这两个的组织，它太将共享由两个组织，例如、 crmserver/ContosoDevOrg/ISV/mycustomdialog.aspx 和 crmserver/ContosoTestOrg/ISV/mycustomdialog.aspx。
同时指向 （如 C:\inetpub\wwwroot\isv\mycustomdialog.aspx 与的磁盘上相同的物理文件。 因为它是可能的自定义的扩展版本将不同开发人员、 测试和生产，这会导致严重的问题。 假设，是例如您的应用程序的版本 11 当前开发，生成 9 处于 UAT （用户验收测试） 测试时。 如果试图使用 multi-tenancy 解决您的环境问题必须硬盘时间隔离这些两个版本。 在这样的情况下有些可能会想要尝试解决方案 图 5 所示。
图 5 使用不同的 IIS 服务器以隔离在自定义解决方案代码的 Attempting
在该模型 （如果不再使用的网络负载平衡地址） 的用户可能会按如下所示的 URL：
开发 192.168.1.100/ContosoDevOrg/loader.aspx
测试 192.168.1.105/ContosoTestOrg/loader.aspx
生产 192.168.1.110/contoso/loader.aspx
此模型允许您进行三个单独承载三个不同的组织，与磁盘上的三个不同的代码基的前端服务器。 只要用户不会无意中点击错误的服务器上错误的组织，一切应当工作出完全。
遗憾的是，因为所有的前端服务器被视为一个一部分，相同的部署的问题开始出现有点进一步下游比乍一可能实现。 这真正成为一项挑战如果您的解决方案使用异步插件或工作流，因为您可以控制哪些服务器时您的用户点击，您无法控制的异步服务将处理事件和请求的组织。
这是的是因为所有的异步服务，在部署工作以循环的方式，，在这种情况下，开发服务器的异步服务可能处理一个工作流、 系统作业或异步插件响应请求从您的测试服务器从而能够右出的水隔离要求。 此外，如果此异步过程由运行自定义代码依赖于必须部署到该服务器 （例如，配置文件或全局程序集缓存或 GAC 中的文件） 的磁盘上的文件则将版本冲突。
值得注意的在很大程度这些挑战出现仅当要编写需要部署在磁盘上的自定义代码或自定义代码依赖于将只能在上或从特定的服务器可用的资源时。 如果您的解决方案很简单，并且仅使用自定义 （架构、 表单、 视图，等）、 工作流和报表，不用 图 4 中使用的方法的任何问题。
那么什么是 multi-tenancy 为和时是它为产品生命周期环境很好解决方案？ multi-tenancy 最初设计为解决硬件问题与承载多个不同的承租人在生产环境中，并且它很实现此。 在此之前，Microsoft Dynamics CRM 3.0，每个部署或租户中, 必须有自己专用的 SQL Server 或 SQL Server 实例，以及前端服务器。
出于包括事实的多个原因是 True 部署特定于设置用于将存储在注册表中和磁盘上。 所有这些配置已经现在移动到在的数据库因此在单个应用程序服务器是能够处理多个组织。 multi-tenancy 有方便地联机包括 Microsoft Dynamics CRM 的 CRM 的托管版本。
设计注意事项
现在，您了解的一些潜在的问题让我们讨论设计您的部署时请牢记一些指向。 在的答案当然，是它取决于。 肯定可以在单个的盒上运行一个完整的 CRM 环境 （包括控制器 SQL Server，和 Web 服务器） 可以看到在 Microsoft Dynamics CRM 4.0 虚拟机演示 （请参阅"CRM 资源"侧栏的 URL）。 很开发环境中使用单个计算机虚拟映像很常见。 测试，但是，很重要，来验证密钥的生产环境质询，并为由于这个原因建议让您测试环境镜像生产环境的结构，但不是产能。 您的环境可能类似于 图 6 。
图 6 </a0>-测试环境结构应反映生产结构
在这种方法，您尝试最小化使用虚拟化基础结构的物理硬件，并进一步尝试通过虚拟化要测试的仅关键的方案中尽量减少虚拟化的资源。 您将能够使您的开发人员开发一个单台服务器映像 （或图像，） 上，如果其个人的台式计算机上有其自己的虚拟机如果您确保它们将特别注意并且注意要他们的解决方案部署到其中的环境。 开发人员应特别注意的问题是您应能构建测试环境来验证，同样的问题包括：
使设置可配置 不要，是例如假定该服务器将响应 localhost 或特定的端口。
能识别的多台服务器 不要假定操作能够不必设置代理服务器的用户或委派的信任。
保持负载平衡在线 非常谨慎会话状态和缓存。 请注意 Microsoft Dynamics CRM 设计为完全无状态和使用循环法负载平衡器。
考虑 Multi-Tenancy 一台计算机上承载多个承租人时, 它们共享相同的进程空间。 这意味着元素 （如缓存需要为键依据组织的名称，以便一个组织中的用户将不无意中利用另一个组织中的数据。 此外，当链接或回调到服务器的客户端代码必须是能确保调用保留在 URL 中的组织名称 ； 否则，您可能遇到默认组织或组织预计不会。
CRM 资源
Microsoft Dynamics CRM 4.0 实施指南
Microsoft Dynamics CRM 4.0 作为业务应用程序开发平台
Microsoft Dynamics CRM 4.0 虚拟机
优化和维护 Microsoft Dynamics CRM 4.0
密钥 Takeaways
隔离是重要 在设计解决方案时请记住，哪种方法 （如图 4、 5 或 6 所示） 将使用最佳并注意自定义代码时和位置可能会运行。 也的值得注意时不必担心由于的解决方案使用的扩展类型的类问题。
虚拟化 虚拟化有助于减少在构建对应的生产的密钥的测试方案的环境的复杂性。 以下是有关安装程序的一些指导。 CRM 和 SQL Server 放单独的服务器。 这有助于验证信任委托和其他相关的问题。 CRM 服务器应是负载平衡这有助于确定会话、 缓存，和跨服务器问题。 最后，将单独的服务器上的域控制器和电子邮件，这有助于确定连接问题。
刷新每个生成的环境 作为一般的规则是一个好主意虚拟环境之一创建备份，或只是的可以还原将该服务器在 Microsoft Dynamics CRM 数据库 （数据和配置） 返回"传统"状态。 然后，您执行到新的环境包括自定义代码、 自定义、 插件的和域数据在每次一个完整的全新部署。
冗余 / 性能测试可以被完成单独 除了对于非常大的组织来说，您通常可以解决故障转移和性能测试通过独立的模拟和未通过"实际"生成的输出。 这意味着不需要尝试建立测试环境，这些方案的测试。 作为一的种替代方法您可以依靠在生产或单独的一次性环境中测试它们。
在关闭，Microsoft Dynamics CRM 是一个可伸缩的企业级系统，，适当地配置和部署时, 可以处理小型团队、 企业范围的解决方案和每个选项之间。 尝试确定哪个产品生命周期环境适合您将取决于多种因素。
通常来说 multi-tenancy 解决产品生命周期开发挑战，复杂的解决方案的理想方法并不完全理解时最适合使用。 需要仅基本的自定义或的进行的简单解决方案不依赖磁盘资源或特定于服务器的访问的正确编码和独立自定义扩展的使用应执行正常以下模型 图 4 中描述。
如果您的解决方案要求更多隔离、 服务器特定资源或 （可能是外部服务只允许通过从一台特定的服务器之间的 VLAN 上） 的访问，这样其他我建议与 图 6 所示的模型的访问。 我会建议避免 图 5 说明了，该方法，因为它是混合黑客最。
最终，Microsoft Dynamics CRM 可以部署在数千个配置，和究竟是适合您将取决您的解决方案的需要。 与好地了解 multi-tenancy、 单服务器开发环境、 虚拟测试的环境和何种测试的方案将重要，应当可以设计功能和经济高效的产品生命周期部署。
Aaron Elder (Microsoft Dynamics CRM MVP) 适用于 Ascentium、 技术的咨询和交互的市场营销部门。 访问在 Ascentium 博客 ascentium.com/blog/crm.