Introduction
This document describes scenarios for Organizations and Resource Groups utilization in Intersight, as well as common troubleshoot.
Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:
Components Used
- Intersight Account with Admin Privileges
- Cisco UCS 6454 Fabric Interconnect managed by Intersight
- Cisco UCS B200 M5 server
- Cisco UCS C240 M6 integrated server
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Background Information
What is a Resource Group?
A Resource Group is a collection of hardware resources like servers, grouped for management purposes. These groups allow to manage them in a collectively way which makes easier to control and handle configurations.
What is an Organization?
An Organization is a logical entity that helps separate and manage different resources of an Intersight account so multiple users can work independently in the same system.
The Organizations let you manage the Resource Groups to apply configuration to specific resources.
Configure
Create a Resource Group
You can assign servers to specific Resource Groups to enable granular access control at the server level. You have the option to assign a target to one or multiple Resource Groups.
- Navigate to System > Organizations > Create Organization.
- Edit the Resource Groups, name it and select Custom membership to allocate only the desired targets or sub-targets to the Resource Groups.



Create an Organization
Assign a Resource Group to one or multiple Organizations.
- Navigate to System > Organizations > Create Organization.
- Edit the Organization, name it and add the desired Resource Groups.



If you check Share Resources with Other Organizations, the list displayed is for Organizations.
These are shown because they are intended to share the resources associated with other organizations that are about to be created:


Scenarios
For this document, three Resource Groups and three Organizations are used to illustrate scenarios.
Warning: The scenarios in this document are for illustrative and explanatory purposes only and must not be considered best practices. Users are encouraged to plan the organization of their resources and objects according to their specific needs to use the benefits this feature offers fully.
Tip: Regardless of the scenario to be used, you must ensure that at least one Organization is associated with all the resources managed by the domain. This ensures you the Fabric Interconnects belong to at least one Organization, and this lets you associate a Domain Profile with the devices.
Scenario 1. All Devices in Default
Diagram of Scenario 1
Result of the Scenario 1 Configuration
- This is the default configuration. All the resources and configurations are automatically placed in a default Resource Group (default-RG) and Organization (default-ORG).
Scenario 2. Default Shares with all Other Organizations
Diagram of Scenario 2
Result of the Scenario 2 Configuration
- All the objects (policies, pools and profiles) created in default Organization (default-ORG) can be used by DEV, OPS & QA Organizations (DEV-ORG, OPS-ORG & QA-ORG respectively), but not the other way around.
- Objects from one Organization (but the ones created in default-ORG) cannot be used in other Organizations. For example, DEV Organization (DEV-ORG) cannot be used in OPS Organization (OPS-ORG) nor QA Organization (QA-ORG).
- The default Resource Group (default-RG) does not belong anymore to the default Organization (default-ORG). The servers that belong to default-RG cannot be used unless they are assigned to another Organization.
Scenario 3. QA-ORG Shares with DEV-ORG & OPS-ORG
Diagram of Scenario 3
Result of the Scenario 3 Configuration
- Objects created in DEV, OPS or QA Organizations (DEV-ORG, OPS-ORG & QA-ORG respectively) cannot be used in default Organization (default-ORG) and vice versa.
- Objects created in QA Organization (QA-ORG) can be used in DEV and OPS Organizations (DEV-ORG & OPS-ORG).
- Objects created in DEV, OPS and default Organizations (DEV-ORG, OPS-ORG & default-ORG respectively) cannot be used in QA Organization (QA-ORG).
- The QA Resource Group (QA-RG) does not belong to QA Organization (QA-ORG) anymore. The servers that belong to QA-RG cannot be used unless they are assigned to another Organization.
For this scenario, the most intuitive solution is that QA-RG are associated with DEV-ORG and OPS-ORG:
Diagram of Proposed Solution for Scenario 3
This is the result of the configuration proposed as an intuitive solution for Scenario 3. It is seen that the DEV and OPS Organizations (DEV-ORG & OPS-ORG) are associated with the QA Resource Group (QA-RG).
Scenario 4. Default Shares with QA-ORG, DEV-ORG Shares with OPS-ORG
Diagram of Scenario 4
Result of the Scenario 4 Configuration
- Objects created in DEV and OPS Organizations (DEV-ORG & OPS-ORG) cannot be used in QA and default Organizations (QA-ORG & default-ORG) and the other way around.
- Objects created in DEV Organization (DEV-ORG) can be used in OPS Organization (OPS-ORG) but not the other way around.
- Same applies to default and QA Organizations (default-ORG & QA-ORG). Objects created in default-ORG can be used in QA-ORG Organization but not the other way around.
- The default Resource Group (default-RG) does not belong anymore to default Organization (default-ORG). Same for DEV Resource Group (DEV-RG), it does not belong to DEV Organization (DEV-ORG) anymore. Both Resource Groups are unavailable unless they are managed by other Organization.
For this scenario, the most intuitive solution is OPS-ORG associated with ORG-RG & DEV-RG. Identical solution for default-RG which could be attached to QA-ORG:
Diagram of Proposed Solution for Scenario 4
This is the result of the configuration proposed as an intuitive solution for Scenario 4. It is evident that the OPS Organization (OPS-ORG) is associated to the Resource Groups of OPS and DEV (OPS-RG & DEV-RG). On the other hand the QA Organization is associated with the default and QA Resource Groups (default-RG & QA-RG).
Verify
For this section, scenario 4 is used as a reference.
Through the Creation and Assignment of a Server Profile
Create a Server Profile in the desired organization.
- Navigate to Configure > Profiles > UCS Server Profiles > Create UCS Server Profile:

You can see the servers associated with your organization listed by the resource groups they belong to.

2. Associate the policies to the profile depending on the Organization the policies belong to.
The image shows the policies of the profiles from OPS and DEV Organizations. This can happen because DEV-ORG is shared with OPS-ORG:

Through Intersight API Requests
Tip: On Query Parameters, ensure to use the same exact letters for Key and Value Examples to avoid errors.
Navigate to Intersight API Reference and log in with your account:
- Look for the /api/v1/organization/Organizations request.
- Select the first GET call, and then enter the required Query Parameters.
This example uses these parameters:
Key |
Value |
Usage |
$select |
Name, MOID |
Select the value(s) to display from that object. |
The response lists the Organizations created in your Intersight Account. Copy the MOID of the organization you are interested in for future reference.
The MOID related to OPS-ORG is 678acbb76972653201ddedf8
Look for /api/v1/server/Profiles and enter the Query Parameters.
This example uses these parameters:
Key |
Value |
Usage |
$filter |
Name Eq 'OPS-SERVER-1' |
Filter output to server profile that has the name entered. |
$select |
Name, MOID, Organization |
Select the values to display from that object. Values displayed are Profile Name, Profile MOID and Organization MOID. |
Verify that the profiles belongs to the organization. Match the MOID.
The Organization MOID associated with the Profile 'OPS-SERVER-1' is 678acbb76972653201ddedf8 which corresponds to OPS-ORG.
You can do the same for your policies. For this case, /api/v1/boot/PrecisionPolicies is used. This is because a boot order policy is sought to check which Organization it belongs to.
This example uses these parameters:
Key |
Value |
Usage |
$filter |
Name Eq 'OPS-BOOT-ORDER' |
Filter output to server profile that has the name entered. |
$select |
Name, MOID, Organization |
Select the values to display from that object. Values displayed are Policy Name, Policy MOID and Organization MOID. |
The Organization MOID associated with the policy OPS-BOOT-ORDER is 678acbb76972653201ddedf8 which corresponds to OPS-ORG.
Troubleshoot
Issue 1. No Servers Listed after the Creation of a Server Profile with a Specific Organization
For this issue, Scenario 4 is used as a reference.
Server Profile is Created with Default Organization (default-ORG)
No Server is Listed when You Try to Assign the Server Profile
Verify that the organization is directly associated with the resource group of the server. It cannot be from a shared organization since they share objects such as pools, policies, and profiles; not resources such as servers.
The Default Organization (default-ORG) is not directly associated with the Resource Group. If the Server Profile is created with QA Organization instead (QA-ORG), the servers are listed in the Server Assignment section.
Issue 2. Cannot Delete a Resource Group
- Verify the Resource Group is not associated with any Organization. If so, edit the Organization to not use the Resource Group anymore.
Issue 3. Cannot Delete an Organization
- Check if a Profile, Pool, or Policy is associated with it. If that is the case, remove the object(s).
- Look at the Organizations table and confirm it is not shared with other Organization.
Caution: You can remove Organizations even if they are associated with a Resource Group.
Consider the attachment of Resource Groups to an Organization, since it is necessary to have a Profile assignment.
Issue 4. Fabric Interconnect does not Belong to any Organization and Domain Profile Cannot be Associated
Check that all domain servers belong to a common Resource Group. This Resource Group must be associated with the Organization that owns the domain profile.
Note: The Chassis Organizations work in much the same way as the Domain Organizations do.
Issue 5. Servers have been Added to a Resource Group, yet the Fabric Interconnect does not Show the Organization
- Edit the Resource Group, make a change: unselect a server from it. Save the changes.
- Edit the Resource Group and add the unselected server to add it again. Save changes and verify. Repeat 2-3 times if necessary.
- Ensure all servers that belong to the Fabric Interconnect are members of the Resource Group which is associated to the Organization you require.
Alternative:
- Edit the Resource Group and add All devices and save. Edit one more time and leave only the specific servers you want to belong to your Resource Group. (This is most likely to work but the complexity depends directly on the number of servers managed on the account.)
Related Information