Investigating vCAC 5.2 Models

When you play with vCAC workflow and scripts you will most certainly work with the ManagementModelEntitesClient or the MgmtContext for short. Have a look at my introduction to it in this blog post. But there is actually more in vCAC than just that. Out of the box vCAC ships with these models:

PS > $MetaModel.Models.Name

And some of them are actually quite useful. But before you instantiate each and every one of them just to see what they could do for you, I rather recommend to use Telerik JustDecompile or something similar to have a look at the assemblies, or the ‘DynamicOps.Repository.dll’ with its namespace ‘DynamicOps.Repository.CoreModel’, ‘DynamicOps.Repository.RepositoryModel’, ‘DynamicOps.Repository.SecurityModel’ and ‘DynamicOps.Repository.TrackingModel’. The other models are defined within assemblies as ‘DynmicOps.VMwareModel.Client.dll’ for ‘VMwareModelEntities’ and the like. You will figure out yourself …

To instantiate a model you have to find the corresponding class and a constructor that takes an URI to the service (‘serviceRoot’)- Basically all the services reside in the ‘Data/Repository/’ directory on the same hierarchy as the ‘ManagementModelEntities.svc’ you already know.


The ‘MetaModel’ itself is a little bit different from the rest as it is actually the starting point or the base model vCAC builds upon. And once you got a grip onto that you can enumerate all other registered models as we actually already did above.

If you already using our module ‘biz.dfch.PS.vCAC.Utilities’ you can use this as a starting point to load the other models. Once you added the assembly via ‘Add-Type’ you can create a connection to the base model:

Add-Type -Path "${ENV:ProgramFiles(x86)}\VMware\vCAC\Server\DynamicOps.Repository.dll";
$UriMetaModel = '';
$MetaModel = New-Object DynamicOps.Repository.RepositoryModel.RepositoryModelEntities -ArgumentList $UriMetaModel;
$MetaModel.Credentials = [System.Net.CredentialCache]::DefaultCredentials;
$MetaModel.SaveChangesDefaultOptions = [System.Data.Services.Client.SaveChangesOptions]::Batch;

PS  > $MetaModel.GetMetadataUri();
AbsolutePath   : /Repository/Data/MetaModel.svc/$metadata
AbsoluteUri    :$metadata
LocalPath      : /Repository/Data/MetaModel.svc/$metadata
Authority      :
HostNameType   : Dns
IsDefaultPort  : True
IsFile         : False
IsLoopback     : False
PathAndQuery   : /Repository/Data/MetaModel.svc/$metadata
Segments       : {/, Repository/, Data/, MetaModel.svc/...}
IsUnc          : False
Host           :
Port           : 443
Query          :
Fragment       :
Scheme         : https
OriginalString :$metadata
DnsSafeHost    :
IsAbsoluteUri  : True
UserEscaped    : False
UserInfo       :

With the MetaModel you can examine interesting things like which DEMOrchestrator or DEMWorker is active. Especially in a larger distributed environment this is useful to know where you are running.

foreach($demorch in $MetaModel.DEMActiveOrchestrators) {
	$null = $MetaModel.LoadProperty($demorch, 'DEM');
	if($demorch.DEM.IsOnline -ne $true) { continue; };
	$demorch | Out-String;
	$demorch.DEM | Out-String;
} # foreach

Id StartedProcessingTasksDatetime DEM
-- ------------------------------ ---
 1 2/14/2014 7:24:24 PM           DynamicOps.Repository.RepositoryModel.DEM

Id: 2
FriendlyName    : vcac52-orchestrator
InstanceName    : vcac52-orchestrator
Description     : vcac52 orchestrator DEM
LastPing        : 2/16/2014 5:56:04 AM
IsOnline        : True
HostName        : VCAC52
SessionId       :
LastCompletedWorkflowDatetime :
IsOrchestrator  : True
Skills          : {}
WorkflowInstances             : {}
DEMActiveOrchestrators        : {}

Furthermore the active workflow can check on which DEM worker it is running. That works just the other way round with just starting a new workflow instance: enumerate all running workflow instances and check for the input attribute ‘ExternalWorkflowId’ if it matches your workflow input parameter:

foreach($wfri in $metamodel.WorkflowInstances) {
  if($ExternalWorkflowId -eq [DynamicOps.Common.Utils.SerializeUtils]::DeserializeEntity(
    [guid], ($wfri.WorkflowInstanceArguments
    |? Name -eq 'ExternalWorkflowId').Value)) {
      # This is 'our' workflow ...
    } # if
} # foreach


The SecurityModel can be used to assign and change permissions and role membership (and much more such as defining your own roles and permissions). You instantiate it basically the same way as the MetaModel:

PS > [Uri] $UriSecurityModel = '';
PS > $SecurityModel =
  New-Object DynamicOps.Repository.SecurityModel.SecurityModelContext
  -ArgumentList $UriSecurityModel;
PS > $SecurityModel.Credentials = [System.Net.CredentialCache]::DefaultCredentials;

PS > $Securitymodel
Applications                    : {VMPS, MetaModel, Amazon, UcsModel...}
Identities                      : {Everyone, BUILTIN\Administrators, SHAREDOP\vcacservice, SHAREDOP\Domain Users...}
IdentityTasks                   : {VMPS, VMPS, VMPS, VMPS...}
RoleAssignments                 : {User With UI Access, Design Center User, Website Bootstrapper, VRM Administrator...}
RoleDefinitions                 : {Enterprise Administrator, Service, AccessControlAdmin, VRM Administrator...}
Scopes                          : {ManagementModel, Enterprise Administrator, vCenterEnterpriseGroup, vCenterProvisioningGroup...}
TaskDefinitions                 : {Request New Virtual Machine, Operate On Behalf Of User, Enumerate Requests, Manage Virtual
BaseUri                         :
Credentials                     : System.Net.SystemNetworkCredential
MergeOption                     : AppendOnly
ApplyingChanges                 : False
IgnoreMissingProperties         : False
DataNamespace                   :
ResolveName                     :
ResolveType                     :
Timeout                         : 0
TypeScheme                      :
UsePostTunneling                : False
Links                           : {}
Entities                        : {DynamicOps.Repository.Runtime.SecurityModel.RoleDefinition,
SaveChangesDefaultOptions       : None
IgnoreResourceNotFoundException : False


The TrackingModel can be used to write entries to the tracking log

[Uri] $UriTrackingModel = '';
$TrackingModel =
  New-Object DynamicOps.Repository.TrackingModel.TrackingModelEntities
  -ArgumentList $UriTrackingModel;
$TrackingModel.Credentials = [System.Net.CredentialCache]::DefaultCredentials;

PS > $TrackingModel.TrackingSources
Id Name               AuditLogItems TrackingLogItems
-- ----               ------------- ----------------
 1 Unknown            {} {}
 2 DEM-Worker         {} {}
 3 DEM-Orchestrator   {} {}
 4 Repository         {} {}
 5 Manager Service    {} {}
 6 GUI Administration {} {}
 7 GUI Self-Service   {} {}
 8 VRM Agent          {} {}
 9 Cdk                {} {}
99 Test Application   {} {}


The CoreModel has significantly fewer functionality but still has some benefits, as you can use it to get global settings or send emails via the predefined templates (or lets you add new ones):

PS > [Uri] $UriCoreModel = '';
PS > $CoreModel = New-Object DynamicOps.Repository.CoreModel.CoreModelEntities -ArgumentList $UriCoreModel;
PS > $CoreModel.Credentials = [System.Net.CredentialCache]::DefaultCredentials

PS > $CoreModel.GlobalPropertyItems | select Name, Value
Name                     Value
----                     -----
EmailDefault.FromAddress vcacservice@SHAREDOP.ORG
EmailDefault.SmtpPort    25
EmailDefault.UserName    myUser
EmailDefault.Password    TlR2cm8wWUUxRENmV2V3aF1aM1Z1Z0Ej
EmailDefault.EnableSSL   False
# [ ... ]

You can then even use the CoreHelpers and extract, format temapltes and retrieve global settings in a very efficient way. But for this to work you have to modify the config/manifest of your script host (eg PowerShell.exe):


This was a quick walkthrough about vCAC models and some of their possible use cases. Enjoy to further dive down into vCAC and its models!


  1. […] Calling PowerShell from vCAC is easy, right. But how about the other way round? Suppose you want to start the ‘ReclaimDestroyedStaticIPAddresses’ or the ‘WFStubMachineExpired’ workflow manually? As usual this can be done via the vCAC MetaModel ODATA REST service and of course with PowerShell. For a brief overview about the MetaModel you can have a look at Investigating vCAC 5.2 Models. […]

  2. […] [ UPDATE ] For an introduction of vCAC other models have have a look at Investigating vCAC 5.2 Models. […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: