In Part1 of this article we had all the roles and permissions exported to an XML file. It’s now time to import the roles and permissions into a Virtual Center.
The script does in fact the reverse of what the script in Part 1 did.
But there were a few “gotchas“ that had to be solved before arriving at a working solution.
The script does not take into account that you can have different objects in your vSphere environment with the same name! Which imho is not a good practice in any case.
Should someone have the need for this functionality let me know and I will try to adapt the scripts.
The script does not create the principals that are mentioned in the XML file. If these principals do not exists in the environment where you want to import the roles and permissions the script will show errors.
Speed of execution
The permissions are set with an API called SetEntityPermissions.
As can be seen in the API Reference Guide this method requires a Managed Object Reference (MoRef) to a ManagedEntity. A ManagedEntity object is the parent object of most of the managed objects in vSphere.
This way of working avoids that there would have to be a separate method for each of the derived managed objects.
In the XML we have the name of the vSphere entity in property $_.Entity. We could get at the required ManagedEntity MoRef like this:
But if you run this you will notice that this is in fact quite slow. If you need to import hundreds of permissions the script would run for hours.
After some trial and error the following turned out to be the fastest method (see line 62 in the script below).
- Use the Get-View cmdlet. It’s a lot faster. See also PowerCLPowerCLI on steroids – Custom attributes.
- The Get-View cmdlet, in this format, requires the type of object (-ViewType) to be passed. We can solve this requirement by adding the EntityType attribute to the Permission node.
- We use the -Filter parameter of the Get-View cmdlet to get only the object we want. But watch out with this filter! See the next section for more details.
Get-View filter and regular expressions
As it turns out the –Filter parameter interprets the “value” as a regular expression!
That means that if you have vSphere objects whose name accidently contains one or more [regex] meta-character, the –Filter won’t return the object.
As an example, suppose you have a VirtualMachine with a name of “MyPC (v1)”, which is by the way a valid guest name. When you do the following:
The Get-View cmdlet will not return the VirtualMachine object as you would expect.
The solution is to “escape” all the regex meta-characters in the value. Something like this
To solve the occurrence of regex meta-characters in the script the lines 58..60 were added.
Note: these aren’t all the regex meta-characters! Depending on your environment and the object names you used you will have to update these lines!
“True” is not $true
In the Permission nodes there are two attributes that represent a Boolean value. But when you access these attribute values you will notice that they are text representations (strings) of the actual Boolean values.
In the Permission object we need to pass two Boolean values.
So we have to convert the node attribute values from strings to Booleans.
This can be done like this:
The import script
Below the actual script that will recreate all custom roles and set all permissions as defined in the XML file.
Since it was impractical (and even impossible) to test the script in all possible environments I would strongly advise to test the script thoroughly before using it in your production environment !