Walk-through: Configuring Organizations

This topic walks through the creation of two organizations in an enterprise lab management environment, each with its own customized cloud automation configuration.

See also the following articles:

In this walk-through, service catalog entries and the request approval process are assigned to organizations, but automated deployment destinations are assigned to specific users. There is no set "best practice" in this area. Your team structure and the layout of your virtual infrastructure will determine how assets are exposed to users. This walk-through highlights Commander flexibility in handling varying multi-tenant requirements.

In the real world, you will likely deploy services directly under a single cluster shared between multiple organizations, with a folder per organization. You may also rely on VM naming and other Commander metadata to determine who owns a resource. In our example, to show the flexibility of the Commander multi-tenant model, each developer has their own resource pool and folder on multiple managed systems, and each tester has their own cluster.

About the organizations in this example

The consumers in this example are the Development and Product Verification groups in a software development company. The groups exist in Active Directory as Development (dev@delta.pv) and Verification (verification@delta.pv). Brian is the manager of the Development group, and Mark manages the Verification group. Brian and Mark both report to Janet, the Director of Engineering. Scott is the IT Admin for both organizations.

An important note about adding Service Portal users

There are two ways to add Service Portal users: from the Configure Organization wizard and from the Users page (accessed through Configuration > Identity and Access). In most cases, you should add users from the Configure Organization wizard. This ensures that the user has only an organizational role.

There are two cases in which you should add Service Portal users from the Users page:

  • A user who requires visibility of services across organizations (such as Scott, our IT Admin) needs to have an individual role, and doesn't need an organizational role.
  • A user who requires visibility of services across organizations and will manage VMs as a member of an organization needs to have both an individual role and an organizational role.  In this case, you first add the user on the Users page, then add them to the organization (not the other way around). In this case, you first add the user to an organization, and then edit them on the Users page to provide an individual role. The user can then log into the Service Portal as a member of an organization, and can then switch between roles.

Create a custom Service Portal role for the Director of Engineering

The default Service Portal roles work well for these groups, with one exception — Janet requires a custom role. Janet needs to be a member of both organizations, so she can log into the Service Portal to monitor quota usage and approve requests that exceed quota for each organization. She needs a read-only role, but also needs permission to view all services assigned to each organization, and to approve service requests for the organization. Go to Configuration > Identity and Access > Service Portal Roles to create a custom role called Request Approver with all of the read-only permissions, plus:

  • Show All Organization Services
  • Request New Service
  • Request Service Change
  • Approve Requests
portal-role-approver

Note that because organizations provide data segregation, only organization members can access organization assets (service catalog entries, request forms, workflows, deployment destinations and quota usage information).

In this scenario, because the requesters are organization members, Janet must also be an organization member, so that she can see service requests from organization members.

More on custom Service Portal roles

Assign an individual role to the IT Admin

Scott, the IT admin, needs visibility of production services across organizations and is not a member of either Development or Verification. So you must create a Service Portal user with an individual role, rather than an organizational role.

To add Scott as a user, choose Configuration > Identity and Access > Users, then click Add User. The default Delegated Admin role works well for Scott. Choosing Not a Member of an Organization from the Organization menu ensures that Scott will have an individual role.

Add User dialog

More on adding users

Create organizations

Now you're ready to configure the organizations. Commander allows you to create the organization, add users to it, assign organizational roles to users, and set quotas all in one wizard.

Access through:

Configuration > Identity and Access > Organizations tab

Available to:

Commander Role of Superuser, Enterprise Admin

Go to Configuration > Identity and Access, then click the Organization tab to create the "Development" organization.

Add the AD group dev@delta.pv as an organization member with the Customer role. This allows you to assign production VMs to the group account, so that they count towards the organization's quota, not the members' quota.

Add Brian, assigning him the Manager role, and make Brian the primary contact for the organization.

Add User bcarter

Also, add each of Brian's direct reports, assigning them the Customer role.

Adding group members individually (in addition to adding their AD group) ensures that you can assign individual member quotas. If you don't add members individually, you can still set a quota for the entire organization.

Add beglinton user

Lastly, add Janet to the organization, giving her the new Request Approver role.

Click Next until you get to the Quotas page. On the Quotas page, select Global Quota. Note that you can also set a quota for each deployment destination that this organization can deploy to, but for the purposes of this walk-through, we'll set a global quota.

On the Organization Quotas page, choose Resource Quota and set limits for CPU, Memory and Storage.

Organization Quotas dialog

On the Member Quotas page, don't do anything, because you want to let Brian set quotas for Development members.

Now create the Verification organization in the same way:

  • Add the AD group verification@delta.pv as an organization member with the Customer role.
  • Mark is assigned the Manager role and is primary contact for the organization.
  • All of Mark's direct reports are added, with the Customer role.
  • Add Janet to this organization as well, giving her the Request Approver role.
  • Choose a Resource quota, specifying different limits for Verification.
  • Again, on the Member Quotas page, we don't do anything, because we want to let Mark set quotas for Verification members.

Here's a look at the list of users on the Users tab. Note that because Janet (jjones@delta.pv) has multiple roles, her role is listed as [multiple].

Users tab

Organization managers assign quotas to members

The Manager role provides Service Portal users with Organization Management permissions. Therefore, Brian and Mark can now log into the Service Portal to assign member quotas. On the Users and Quotas page in the Service Portal, they have several options: they can balance quotas across all members; they can leave all members at Max Quota, in which case quota is assigned to members on a first-come, first-served basis; or they can assign specific quotas to some or all members.

See Managing Quota for an Organization in the Service Portal in the Service Portal User Guide for more information.

Assign service catalog entries

Now assign service catalog entries to each organization by going to Configuration > Self-Service > Service Catalog, editing a service and going to the Visibility page:

org-service-visible

More on configuring the service catalog

Configure deployment destinations

Commander allows you to provide certain users with a choice over where they deploy, while restricting others.

Go to Configuration > Self-Service > Provisioning to create user-specific deployment destinations for each member of Development and Verification on each managed system, pointing to their personal folder/resource pool.

In the real world, deployment destinations would be configured per organization, not per user. This example is for illustrative purposes only, to show the flexibility of the Commander multi-tenant model.

  • On the Assignment page, assign the deployment destination to the specific user:

    org-depl-dest-visible

  • On the Folder page, choose the user's personal folder
  • On the Target page, choose the user's personal resource pool

To allow Brian to place VMs in his organization's folder, you must create a deployment destination for Development for each managed system, and assign all of these destinations to Brian. We choose the Development's folder and resource pool.

We do the same for Verification, assigning all of the destinations to Mark, choosing Verification's folder and resource pool.

Assign service request forms

Go to Configuration > Self-Service > Form Designer to create New Service and Change Request forms for each organization.

org-form

You must also create special forms for Brian and Mark. Because a user assignment always takes precedence over an organization assignment, Brian and Mark will always see this special form.

org-form-mgr

Include the Deployment Destination control, to take advantage of the organization-level deployment destinations we configured in the previous step.

org-form-dest

Configure a quota-based request approval process

Through a variable that returns the email address for the primary contacts in each organization, you can easily create a single approval workflow for new service requests that can be shared by both organizations.

Go to Configuration > Self-Service > Approval to create an approval workflow for new service requests. In the first step, you want to send an approval email to the primary contacts in the organization when a service request will exceed a member's quota. This means that Brian and Mark can decide whether to approve these requests.

We add a Quota Approval step, specifying that you want to send an approval email when user quota is exceeded, and we enter #{request.requester.organization.email} in the Address List field to send an email to the organization's primary contact:

org-wf-step1

In the next step, you want higher-level approval when a service request will exceed the organization's quota, so you'll send an approval email to Janet.

org-wf-step2

Finally, on the Automation Options page, enable automated deployment for approved service requests.

Assign VM ownership and visibility

To ensure that each VM is visible to the right users, you must assign owners and make the VM visible to the right organization.

For all VMs used in production by both Development and Verification, right-click the VM in the tree and select Lifecycle Management > Set Ownership. Add dev@delta.pv or verification@delta.pv as an owner (this means the VMs count towards the organization's quota, not the user's member quota).

Whenever you add an organization member as owner to a VM where an organization was not already assigned, Commander automatically selects the member's organization. Note the blue text in the following image:

Set Ownership dialog

You must also add Scott as an IT contact (so that he can log in to the production VMs to fix problems).

For each "personal" VM used by members of Development and Verification, we assign the member as primary owner (this means that personal VMs count towards a user's member quota, as well as to the organization's quota). Again, Commander automatically selects the member's organization.

org-owner-personal

Note that if you don't make a VM visible to the member's organization, the member must have an individual role (in addition to an organizational role) to see the VM.

Configure Default Ownership policies

To ensure that new VMs are always assigned to owners and organizations, go to Configuration > Policies to set up two Default Ownership policies.

The first policy makes the VM visible to the appropriate organization. On the Choose a Target page, select a target that's as high as possible in the infrastructure tree. Then select the organization on the Configure the Policy page. By default, the option to allow this policy to be overridden for children of the selected targets is enabled; this is the behavior you want.

org-policy

The second policy overrides this policy for VMs in each member's personal resource pool, with a policy that makes the VM visible to the right organization, but also assigns the member as primary owner. On the Choose a Target page, select the user's resource pool. On the Configure the Policy page, add the member as primary owner. Commander automatically selects the member's organization.

org-policy-user

Allocate service cost among organizations

For a service that's used by multiple organizations, you can allocate the cost among those organizations. For an example, see Allocating Service Costs to Multiple Organizations.

What each user can see in the Service Portal

When each user logs into the Service Portal with their Active Directory user name and password, what can they see?

Janet, the Director of Engineering, sees the following options in the Service Portal Views menu, allowing her to switch between organizations as well as between her personal VMs and all VMs owned by each organization. The view affects everything she sees in the Service Portal, such as the tree, searches, service requests and quotas. The current view is saved when she logs out.

org-janet-views

Brian, the manager for Development, can switch between his personal VMs and all VMs owned by Development. He can also switch to the Management view, where he can add and remove organization members and assign member quotas:

org-brian-views

Mark, the manager for Verification, can switch between his personal VMs and all VMs owned by Verification. He can also switch to the Management view, where he can add and remove organization members and assign member quotas:

org-mark-views

Organization members with the Customer role can see only VMs that are visible to their organization and VMs that they own. They don't have the ability to switch views:

org-icolby-views

Scott, our IT admin, can see only VMs where he has been added as IT contact. He has only an individual role, so he doesn't have the ability to switch views.

org-icolby-views