DEM is sometimes also referred to as the manager service. Basically, this component is connecting vRA to possible deployment targets for VMs. This can be vCenter (as suggested during the wizard-driven installation for vRA) but it can also be other hypervisor targets such as Hyper-V or KVM. Besides that, vRA will also be able to connect to external clouds such as Amazon Web Services (AWS), vCloud Air (VMware), and Microsoft Azure, as well as OpenStack installations. Most of these targets need to have a DEM worker configured to access those. This configuration can either be added to an existing DEM or a new DEM for these targets to be deployed.

Basically, this is the web server component of vRA, which provides the portal as well as its basic functionality. In small environments, it can be installed together with the DEM on the same VM/OS. In enterprise environments, it is typically installed as a separate VM. The IIS configuration is done by the vRA setup routine, which takes care that all required functions for the portal are available.

vRealize Orchestrator is one of the most important components in a vRA setup. The vRA self-configuration service is basically a vRO workflow, which is added as a so-called XaaS service to the freshly installed vRA. Anything as a Service (XaaS) basically means that anything which can be automated can be a requestable service in vRA. vRO is included in the vRA appliance or can be run separately as its own vApp. In large environments, it makes sense to separate vRO from vRA to share the load of the tools. vRO can also be installed in an HA setup and sync its content to multiple vRO tiers.

An endpoint is an infrastructure target on which vRA can deploy VMs. The first and most important endpoint will be vCenter. The endpoint name has to be exactly the same as the one provided to the DEM during its setup. This means the name will also be case-sensitive. vRA can have multiple endpoints including clouds as well as other hypervisors. Endpoints will actually form the so-called infrastructure fabric from which resources can be cut out in the form of reservations and offered to portal users.

Either by highlighting an endpoint and hovering over the arrow symbol or by clicking on the Resources menu at the left-hand pan, the portal will display all currently discovered resources. In terms of vCenter, these will be vSphere clusters, including their storage configuration such as data stores or even data store clusters. In this menu, resources from an endpoint can also be excluded.

This especially makes sense if the management cluster is part of the same vCenter, but should never show up as a resource available to end users in vRA. In this case, it can be simply unelected by un-ticking the box:

This handles the reserved capacity for a tenant/business group based on the actual available resources. For example, not all resources from the cluster might be made available for a given audience:

This reservation will be enforced by vRA and is unknown to vSphere or vCenter. Also, it has nothing to do with resource pool reservations. However, a vSphere resource pool can also be chosen as a provider instead of an entire cluster. The idea of a reservation is to guarantee a select part of the infrastructure fabric without exposing all of its capabilities. Reservations can be dynamically increased and shrunk.

Under this option, vRA will list all current managed VMs deployed using the portal (or imported). This is especially useful since not all users will see all VMs deployed, they will only see their own VMs. If there is an incident to analyze, an administrator with the appropriate role assigned could use this to trace whether vRA is able to reach the VM. Besides that, it will also list the owner and the state of all deployed and currently managed VMs for quick identification.

Approvals are important to keep an automated data center clean and structured. If everything was free and instant to deploy without approvals, users would keep creating machines until the data center eventually ran out of space. There are also process and regulatory reasons to have approval policies. This menu will allow approvals to be defined based on various different conditions.

Approvers can be defined by username or group; additionally, vRA can try to fetch the manager of a requesting user right from AD.

Approvals are distinguished in two major groups: preapprovals or postapprovals. Preapprovals are run before a request is processed. There will be no provisioning until the request has been approved.

Postapprovals are issued after the request has been processed. If the approver denies the request, all provisioned resources will be deleted instantly. Both can be used at the same time. There are scenarios where it makes sense to use both types of approval.

If the technical approver needs to ensure that a request can be fulfilled technically or capacity-wise, it will make sense to add this as a preapproval. If there is a financial decision-maker who needs to approve the use of resources, it might make sense to do this after the resource has been provisioned. By doing that, it will be instantly available to the user/group after it has been approved.

Finally, approvals can be set on many different actions and items in vRA, from creating snapshots to deploying machines, all the way to destroying a deployment. All these actions can have different approval rules as well as different approvers.

Not only can the different categories be approved, but approvals will also be able to be set based on conditions. For example:

Also, a configuration is possible where all approvers need to approve, or any approver can do this.

This setting ensures that vRA can be added to a user directory such as Microsoft Active Directory. It is used to browse users and grant access to certain vRA functionalities. Directory access can be set on a per-tenant basis, which means that every tenant can be connected to a different user directory. This ensures that separate organizations can use their own user directory and do not have to duplicate this data into any local portal user directory.

Here all the users and groups get matched to vRA's role-based access model. There are separate roles in the system, from a simple user to a designer, as well as a tenant admin. According to the role, they can accomplish different tasks in vRA:

Of course, these roles can be combined as well. There are some notable side effects when combining, so this feature should be used with care. One side effect is that if the fabric administrator role is combined with a system-wide role such as IaaS administrator, it can control all the fabric items for ALL tenants in the system. System-wide roles are commented with Does not follow multitenancy concept in this table for better understanding.

vRA organizes Services in so-called catalogs. They can be seen as categories and therefore hold may services of a kind. Catalogs are useful to organize the service offerings, but also to give the right users or groups access to their services. Instead of entitling each and every service, the whole catalog can be entitled.

Categories of catalogs may be:

vRA maintains a dictionary of properties. Those can be used as inputs for the services. Typically, properties hold information, which are required for pre or post processing of service requests. This information can be used to run a vRO workflow once the VM is deployed, or to add a custom hostname during provisioning. Also, they can be used to instruct the vRA agent, also referred to as the Guest Agent to run certain scripts after the VM deployment. All usable vRA built-in properties and their meaning can be found in the vRA installation documentation from VMware. It is highly recommended to make yourself familiar with those in order to use the full potential of vRA.

Additionally, properties can also be user-defined to ask for specific settings to be used in vRealize Orchestrator workflows. It is recommended to use a unique preset to quickly identify custom properties, also, this helps to prevent using system-wide properties instead of custom ones.

Click on Property Definitions to define custom properties. Also, a property group needs to be defined in order to use custom properties in blueprints. This is just a logical container to which multiple custom properties can be added.

This is basically the functionality to reclaim so-called wasted space from the environment. If vRealize Operations is used, it can be connected to this service and will deliver data and suggestions on VMs which can be reclaimed. A reclamation request can be started at this menu based on the data provided. If vRealize Operations is not used, vRA will use its own algorithm to display reclaimable VMs.

For a tenant admin, this is where the look and feel of the portal can be changed to support any customer identity. Colors, logos, and text, as well as the login screen and even a logon box can be customized to fully blend into an organizational environment. These customizations can be done per tenant.

Under this menu, mail servers for inside and outside notifications can be set up. vRA will send e-mails toward users for all kind of events. Typically, those include the expiration of a service, or if something is not going as it should. The servers and the e-mail account to use for these mailings can be set here. Also, under the Scenarios submenu, all the notification actions can be activated or suspended. This is especially important if approvals should also work with e-mail replies, therefore, this setting should be configured very carefully.

This can be used to display event logs of vRA. In this list view, all vRA events are displayed plus additional content. It can be seen as the audit trail of the entire cloud portal. It is useful to analyze or troubleshoot user requests.

The second menu is called Subscriptions and contains a very powerful option of vRA 7. In previous versions, VM provisioning could be tweaked by adding so-called workflow stubs. These stubs are bound to specific VM deployment states such as preapproval, postapproval, provisioning, or deleting. These workflow stubs were used to add third-party system functionality such as IPAM functionality or implementing a backup workflow.

However, in vRA 7, these workflow stubs have been replaced with so-called subscriptions. These are more flexible and can be added easier than workflow stubs, since vRA can decide to run them based on a series of criteria, which the user can set. These can also include custom properties, which makes it even easier to run customization workflows during a VM deployment.

This is the part where the vRealize Orchestrator interface is set up. Under Server Configuration, it can be decided to use an external vRO instead of the built-in vRO server. In large environments, it is recommended to have at least one external vRO server for executing all the necessary customization workflows. Also, if vRO is already used for daily automation in an environment, it makes a lot of sense to use the same also for the cloud automation.