I was trying to set up some permissions on vCenter Server using PowerCLI 4.1.1. Here is an example of a command I was running:
foreach ($role in 'Host','Virtual Machine','VMware vCenter Update Manager') {
Set-VIRole–Role (Get-VIRole -Name <role>) -AddPrivilege (Get-VIPrivilege -Name 'Virtual machine')
}
PowerCLI returned the following:
WARNING: There were one or more problems with the server certificate: * The X509 chain could not be built up to the root certificate. * The certificate's CN name does not match the passed value. Name IsSystem ---- -------- <role> False <role> False <role> False
This looks like it worked, however upon looking at the permissions on vCenter Server, the checkboxes for these three options were not selected. If you attempt the command with any other permissions (e.g. Datastores) it works as expected (i.e. the checkboxes are selected).
Is this a bug or am I doing something wrong? One workaround I have found is to select all of the sub-options under option that is not working. For example, instead of adding a privilege for Host, add privileges for CIM, Configuration, Inventory, and Local operations. Since these four options make up the Host group, the Host group gets selected as well.
You aren't doing anything wrong, there is indeed a problem with the Get-VIPrivilege cmdlet.
The problem is visible with privilege groups that are nested more than 1 level deep.
As an example, let's take the privileges that are grouped under 'Scheduled task'
When you do a Get-VIPrivilege on this group you get the list of privileges involved
PS C:\> Get-VIPrivilege -Group "Scheduled task"
Name Id
---- --
Create tasks ScheduledTask.Create
Remove task ScheduledTask.Delete
Run task ScheduledTask.Run
Modify task ScheduledTask.Edit
When we do the same for a group that has 2 levels of nesting like the 'Virtual machine' group
it doesn't return anyhting.
PS C:\> Get-VIPrivilege -Group "Virtual machine"
As a workaround, you can do the following to retrieve all the privileges that reside under the 'Vritual machine' group as follows.
PS C:\> Get-VIPrivilege | where {$_.ParentGroupId -like "VirtualMachine*"}
Your script would then become something like this
$priv = Get-VIPrivilege | where {$_.ParentGroupId -like "VirtualMachine*"}
foreach ($role in Get-VIRole -Name 'Role1','Role2') {
Set-VIRole $role -AddPrivilege $priv
}
Replace the test roles I used by your names.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
You aren't doing anything wrong, there is indeed a problem with the Get-VIPrivilege cmdlet.
The problem is visible with privilege groups that are nested more than 1 level deep.
As an example, let's take the privileges that are grouped under 'Scheduled task'
When you do a Get-VIPrivilege on this group you get the list of privileges involved
PS C:\> Get-VIPrivilege -Group "Scheduled task"
Name Id
---- --
Create tasks ScheduledTask.Create
Remove task ScheduledTask.Delete
Run task ScheduledTask.Run
Modify task ScheduledTask.Edit
When we do the same for a group that has 2 levels of nesting like the 'Virtual machine' group
it doesn't return anyhting.
PS C:\> Get-VIPrivilege -Group "Virtual machine"
As a workaround, you can do the following to retrieve all the privileges that reside under the 'Vritual machine' group as follows.
PS C:\> Get-VIPrivilege | where {$_.ParentGroupId -like "VirtualMachine*"}
Your script would then become something like this
$priv = Get-VIPrivilege | where {$_.ParentGroupId -like "VirtualMachine*"}
foreach ($role in Get-VIRole -Name 'Role1','Role2') {
Set-VIRole $role -AddPrivilege $priv
}
Replace the test roles I used by your names.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Ah, I did not notice it was with double nested permissions. I also thought it was interested as it was not under the known issues of the release notes.