Deep privileges are not inherited by the subunits of a child business unit after the parent business unit is reassigned to a different business unit (883463)



The information in this article applies to:

  • Microsoft CRM 1.2

CRM SE:923CRM SE:953

SYMPTOMS

You cannot read or write to Microsoft Business Solutions CRM records when those records are in a subunit of a child business unit. You experience this problem even though your security role has "Parent: Child Business Unit" read and write privileges.

CAUSE

This problem occurs because the "Parent: Child Business Unit" privileges are not inherited by the subunits of a child business unit after the parent business unit is reassigned to a different business unit. See the "Steps to reproduce the problem" section for information about the business unit structure and the steps that cause this problem to occur.

RESOLUTION

Microsoft CRM has a fix for this problem that is part of a cumulative update. The cumulative update information is described in the following Microsoft Knowledge Base article:

904435 Update Rollup 2 is available for Microsoft CRM 1.2

MORE INFORMATION

Steps to reproduce the problem

Note Do not create these business units and security roles except in a test system. We provide the following steps to describe the business unit structure and the Microsoft CRM security roles that cause the problem that is described in the "Symptoms" section.

In this scenario, each business unit has at least one Microsoft CRM user who is associated with that business unit. That user owns multiple contacts, accounts, and leads.

The original business unit structure contains a root business unit. The root business unit has two child business units. The child business units of the root business unit are Region 1 and Region 2. The Region 1 and Region 2 business units each have two child business units. The child business units of Region 1 are Area 1A and Area 1B. The child business units of Region 2 are Area 2A and Area 2B.

Each Area business unit also has two child business units. The child business units of Area 1A are Biz 1A_1 and Biz 1A_2. The child business units of Area 1B are Biz 1B_1 and Biz 1B_2. The child business units of Area 2A are Biz 2A_1 and Biz 2A_2. The child business units of Area 2B are Biz 2B_1 and Biz 2B_2. Table 1 shows the organization of these business units.
Table 1
RootRegion 1Area 1ABiz1A_1
Biz1A_2
Area 1BBiz1B_1
Biz1B_2
Region 2Area 2ABiz2A_1
Biz2A_2
Area 2BBiz2B_1
Biz2B_2
  1. Create a custom Microsoft CRM security role at the level of the root business unit. Name the security role C1_Region1, and then give "Parent: Child Business Unit" privileges to the security role. To do this, follow these steps:
    1. On the GoTo menu, point to Home, and then click Settings.
    2. On the Settings page, click Business Unit Settings.
    3. On the Business Unit Settings page, click Security Roles.
    4. In the Business Unit list, click Root Unit.
    5. On the Actions menu bar, click New Role.
    6. In the Role Name box, type C1_Region1.
    7. On the Core Records tab, click Account three times to change the privileges to Parent: Child Business Unit. Then, click the Save and Close button.
  2. Create a new user. Name the user User_Region1. Then, assign the C1_Region1 custom Microsoft CRM security role to this user in the Region 1 business unit. To do this, follow these steps:
    1. On the GoTo menu, point to Home, and then click Settings.
    2. On the Settings page, click Business Unit Settings.
    3. On the Business Unit Settings page, click Users.
    4. On the Actions menu bar, click New User.
    5. In the First Name box and in the Last Name box, type User_Region1.
    6. In the Domain Logon Name box, type adventure-works\User_Region1.
    7. Click the lookup button next to the Business Unit box.
    8. In the Look Up Records dialog box, click Go.
    9. Select Region 1, click OK, and then click Save.
    10. On the Actions menu bar, select Manage Roles.
    11. In the Role Name column, click to select the C1_Region1 check box.
  3. Create another custom Microsoft CRM security role at the level of the root business unit. Name the security role C1_Region2, and then give "Parent: Child Business Unit" privileges to the security role. To do this, follow these steps:
    1. Repeat step 1a through step 1e.
    2. In the Role Name box, type C1_Region2.
    3. On the Core Records tab, click Account three times to change the privileges to Parent: Child Business Unit. Then, click the Save and Close button.
  4. Create a new user. Name the user User_Region2. Then, assign the C1_Region2 custom Microsoft CRM security role to this user in the Region 2 business unit. To do this, follow these steps:
    1. Repeat step 2a through step 2d.
    2. In the First Name box and in the Last Name box, type User_Region2.
    3. In the Domain Logon Name box, type adventure-works\User_Region2.
    4. Click the lookup button next to Business Unit.
    5. In the Look Up Records dialog box, click Go.
    6. Select Region 2, click OK, and then click Save.
    7. On the Actions menu bar, click Manage Roles.
    8. In the Role Name column, click to select the C1_Region2 check box.
  5. Log on to the Microsoft CRM Web client as User_Region1 to verify that you can read and update account records in all the child business units and the subunits of the child business units in Region 1.
  6. Log on to the Microsoft CRM Web client as User_Region2 to verify that you can read and update account records in all the child business units and the subunits of the child business units in Region 2.
  7. Log on to the Active Directory server as a user who can view the Microsoft CRM organizational units (OU) and the child organizational units.
  8. Start the Active Directory Users and Computers snap-in. To do this, click Start, click Run, type dsa.msc, and then click OK.

    Notes
    • The Region 1 organizational unit has the MSCRM ROLE (C1_Region1) security group and the MSCRM DEEP (C1_Region1) security group for the C1_REGION1 custom Microsoft CRM security role. All the child organizational units under Region 1 have the MSCRM ROLE (C1_Region1) security group and the MSCRM DEEP (C1_Region1) security group for this custom Microsoft CRM security role.
    • The Region 2 organizational unit has the MSCRM ROLE (C1_Region2) security group and the MSCRM DEEP (C1_Region2) security group for the C1_Region2 custom Microsoft CRM security role. All the child organizational units under Region 2 have the MSCRM ROLE (C1_Region2) security group and the MSCRM DEEP (C1_Region2) security group for this custom Microsoft CRM security role.
  9. Reassign the Area 2B business unit to the Region 1 business unit. To do this, follow these steps:
    1. Log on to the Microsoft CRM Web client as a user who has administrative privileges.
    2. On the GoTo menu, point to Home, and then click Settings.
    3. On the Settings page, click Business Unit Settings.
    4. On the Business Unit Settings page, click Business Units.
    5. Double-click Area 2B.
    6. On the Actions menu bar, click Change Parent Business.
    7. In the New Parent Business box, type Region 1, and then click OK.

      Note After you reassign the business unit, the business unit structure contains a root business unit. The root business unit has two child business units. The child business units of the root business unit are Region 1 and Region 2. Region 1 has three child business units, and Region 2 has one child business unit. The child business units of Region 1 are Area 1A, Area 1B, and Area 2B. The child business unit of Region 2 is Area 2A.

      Each Area business unit also has two child business units. The child business units of Area 1A are Biz 1A_1 and Biz 1A_2. The child business units of Area 1B are Biz 1B_1 and Biz1B_2. The child business units of Area 2A are Biz 2A_1 and Biz 2A_2. The child business units of Area 2B are Biz 2B_1 and Biz 2B_2. Table 2 shows the organization of these business units.
      Table 2
      RootRegion 1Area 1ABiz1A_1
      Biz1A_2
      Area 1BBiz1B_1
      Biz1B_2
      Area 2BBiz2B_1
      Biz2B_2
      Region 2Area 2ABiz2A_1
      Biz2A_2
      Figure 2
  10. Wait until the Microsoft CRM security descriptors are updated.

    Note To determine when the security descriptors are updated, open the C:\Program Files\Microsoft CRM\Server\Bin directory, where C: is the letter of your drive. Wait for the SSPCQC.bin file to disappear. Your settings for the \Program Files\Microsoft CRM\Server\Bin directory must be set to show hidden files for this file to appear. The SSPCQC.bin file is present after you perform an action that updates Microsoft CRM security roles. This file is also present after you create a new Microsoft CRM role. The file disappears after all security descriptors are updated.
  11. Log on to the Microsoft CRM Web client as User_Region1. Verify that you can see and write to accounts that belong to the Area 2B business unit users. This behavior is expected.

    Note You cannot see or write to accounts that belong to any child business unit of Area 2B. This behavior is not expected.
  12. Log on to the Active Directory server as a user who can view the Microsoft CRM organizational units and the child organizational units.
  13. Start the Active Directory Users and Computers snap-in. To do this, click Start, click Run, type dsa.msc, and then click OK.

    Note View the Biz 2B_1 organizational unit and the Biz 2B_2 organizational units. No roles exist for the MSCRM ROLE (C1_Region1) security group or for the MSCRM DEEP (C1_Region1) security group. However, this organizational unit still has the MSCRM ROLE (C1_Region2) security group and the MSCRM DEEP (C1_Region2) security group.

REFERENCES

For more information about the terminology that is used to describe Microsoft product updates, see the following article in the Microsoft Knowledge Base:

824684 Description of the standard terminology that is used to describe Microsoft software updates

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

887283 Microsoft Business Solutions CRM software hotfix and update package naming standards


Modification Type:MajorLast Reviewed:12/20/2005
Keywords:kbfix kbQFE kbMBSMigrate kbprb KB883463 kbAudEndUser kbAudITPRO