从Sandbox到Prod在解决方案中部署业务单元和安全模型
我正在从事一个Dynamic365号项目(v9.1)，该项目有几个使用沙箱(例如DEV )的组织环境，然后是一些其他的项目(如QA )，最后是PROD (例如)。
有人告诉我，对业务单元的任何安全角色更改都必须在每个环境上手动执行。
有人告诉我这样做的原因是，在创建环境时，默认情况下Dynamic365会唯一地生成默认父业务单元名称，这将导致每个环境具有不同的父业务单元GUID，这会对子业务单元、团队等产生不利影响，因此每个环境的安全模型都必须手动执行。
我对Dynamic365非常陌生，但似乎并不完全正确，Dynamic365要求我在每个环境中手动进行安全性更改(而不是将它们封装在来自DEV的解决方案中)。
我的问题是：
- 为什么沙箱默认的父业务单元GUID与PROD不一样？
- 正确的方法是什么，这样我只需要在DEV沙箱上更改业务单元、团队和安全角色，然后将其作为解决方案输出/部署到链上以刺激？
回答 1
Stack Overflow用户
发布于 2020-02-10 20:51:46
这是正确的，因为Business是一个实体记录，当为Org提供与Org名称相同的名称时，就会创建默认的父BU。
- 维护目标系统中与源系统相同的业务单元层次结构。
- 在目标系统中保留与源(根业务单元除外)相同的业务单元ID (GUID)值。
根业务单元是上述目标的例外，因为它是在CRM组织提供时自动创建的。一旦创建了根业务单元，就无法更改其主键的ID (GUID)值(businessunitid字段)。换句话说，对于两个不同的CRM组织，根业务单元总是有不同的ID。
应该通过像基于金山软件的BU迁移技术这样的初始部署策略来修复。
在前提条件下，使用部署管理器复制生产数据库并创建较低的区域实例。
如果它是在线的，我们可以做一个PROD刷新，完全刷新(模式+数据)最好是一次。稍后，架构只在需要时刷新。
通过这种方式，我们可以确保较低区域的更改(角色、自定义等的解决方案)可以转移到QA/PROD中，而不必担心不同步环境。
但是，不能将团队作为解决方案的一部分进行移植，因为它们是表记录，无论是使用数据迁移实用程序还是使用CSV格式使用相同GUID的导出/导入都可以。
https://stackoverflow.com/questions/60158049
复制相似问题
腾讯云开发者
