I'm curious if the bug referenced at http://communities.vmware.com/message/1435306 is still not fixed? I'm still trying to apply permissions to entities via New-VIPermission and trying to use a combination of local groups, domain accounts, and domain groups and the results are inconsistent to say the least. For example, if I run it with Carter's workaround (posted in the referenced thread) I get the following errors:
New-Object : Cannot find type [VMware.VimAutomation.ViCore.Impl.V1.PermissionManagement.VCUserAccountImpl]: make sure the assembly containing this type is loaded.
At import_vCenter_perms.ps1:52 char:26+ Write-Output (New-Object <<<< VMware.VimAutomation.ViCore.Impl.V1.PermissionManagement.VCUserAccountImpl -ArgumentList $principal, "", $client)+ CategoryInfo : InvalidType: (:) [New-Object], PSArgumentException+ FullyQualifiedErrorId : TypeNotFound,Microsoft.PowerShell.Commands.NewObjectCommandNew-VIPermission : Cannot validate argument on parameter 'Principal'. The argument is null or empty. Supply an argument that is not null or empty and then try the command again.At import_vCenter_perms.ps1:57 char:84+ New-VIPermission -Entity $hshPathsAndViewObjects[$oPerm.oPermPath.Path] -Principal <<<< $objVCAccount -Role $oPerm.Role -Propagate $oPerm.Propagate -Confirm:$false+ CategoryInfo : InvalidData: (:) [New-VIPermission], ParameterBindingValidationException+ FullyQualifiedErrorId : ParameterArgumentValidationError,VMware.VimAutomation.ViCore.Cmdlets.Commands.PermissionManagement.NewVIPermission
If I run it without the work around (i.e. try to insert my AD group directly into the -Principal parameter) I get this:
New-VIPermission : 9/19/2011 1:00:13 PM New-VIPermission Could not find VIAccount with name 'domain\group'. At import_vCenter_perms.ps1:58 char:18 + New-VIPermission <<<< -Entity $hshPathsAndViewObjects[$oPerm.oPermPath.Path] -Principal $oPerm.Principal -Role $oPerm.Role -Propagate $oPerm.Propagate -Confirm:$false + CategoryInfo : ObjectNotFound: (AM\VCLab_SysAdmGMRG_DL:String) [New-VIPermission], VimException + FullyQualifiedErrorId : Core_ObnSelector_SelectObjectByNameCore_ObjectNotFound,VMware.VimAutomation.ViCore.Cmdlets.Commands.PermissionManagement.NewVIPermission New-VIPermission : 9/19/2011 1:00:13 PM New-VIPermission Value cannot be found for the mandatory parameter Principal At import_vCenter_perms.ps1:58 char:18 + New-VIPermission <<<< -Entity $hshPathsAndViewObjects[$oPerm.oPermPath.Path] -Principal $oPerm.Principal -Role $oPerm.Role -Propagate $oPerm.Propagate -Confirm:$false + CategoryInfo : NotSpecified: (:) [New-VIPermission], VimException + FullyQualifiedErrorId : Core_BaseCmdlet_UnknownError,VMware.VimAutomation.ViCore.Cmdlets.Commands.PermissionManagement.NewVIPermission
The above is when run from PowerCLI 5.0.
If I do it with PowerCLI 4.1 U1 build 332441 and Carter's workaround it looks like this:
New-VIPermission : 9/19/2011 5:35:15 PM New-VIPermission The user or group named 'domain\group' does not exist. At line:3 char:21 + New-VIPermission <<<< -Entity $hshPathsAndViewObjects[$oPerm.oPermPath.Path] -Principal $objVCAccount -Role $oPerm.Role -Propagate $oPerm.Propagate -Confirm:$false + CategoryInfo : NotSpecified: (:) [New-VIPermission], UserNotFound + FullyQualifiedErrorId : Client20_InventoryServiceImpl_NewPermission_VIError,VMware.VimAutomation.ViCore.Cmdlets.Commands.PermissionManagement.
Without the workaround I get:
New-VIPermission : 9/19/2011 5:35:05 PM New-VIPermission A general system error occurred: error accessing directory At line:4 char:21 + New-VIPermission <<<< -Entity $hshPathsAndViewObjects[$oPerm.oPermPath.Path] -Principal $oPerm.Principal -Role $oPerm.Role -Propagate $oPerm.Propagate -Confirm:$false + CategoryInfo : NotSpecified: (:) [New-VIPermission], SystemError + FullyQualifiedErrorId : Client20_VmHostServiceImpl_RetrieveUserGroups_ViError,VMware.VimAutomation.ViCore.Cmdlets.Commands.PermissionManagement.NewVIPermission New-VIPermission : 9/19/2011 5:35:05 PM New-VIPermission Could not find VIAccount with name 'domain\group'. At line:4 char:21 + New-VIPermission <<<< -Entity $hshPathsAndViewObjects[$oPerm.oPermPath.Path] -Principal $oPerm.Principal -Role $oPerm.Role -Propagate $oPerm.Propagate -Confirm:$false + CategoryInfo : ObjectNotFound: (domain\group:String) [New-VIPermission], VimException + FullyQualifiedErrorId : Core_ObnSelector_SelectObjectByNameCore_ObjectNotFound,VMware.VimAutomation.ViCore.Cmdlets.Commands.PermissionManagement.NewVIPermission New-VIPermission : 9/19/2011 5:35:05 PM New-VIPermission Value cannot be found for the mandatory parameter Principal At line:4 char:21 + New-VIPermission <<<< -Entity $hshPathsAndViewObjects[$oPerm.oPermPath.Path] -Principal $oPerm.Principal -Role $oPerm.Role -Propagate $oPerm.Propagate -Confirm:$false + CategoryInfo : NotSpecified: (:) [New-VIPermission], VimException + FullyQualifiedErrorId : Core_BaseCmdlet_UnknownError,VMware.VimAutomation.ViCore.Cmdlets.Commands.PermissionManagement.NewVIPermission
However, the above will take forever to run and sometimes some groups work, but most of the time not. It seems random.
I haven't investigated using LucD's method on the referenced thread yet because I was hoping to learn the status of this bug first.
I just tested this in PowerCLI 5 and didn't encounter any problems.
This is what I used
# Local group on VC
Get-Folder -Name TestPerm | New-VIPermission -Role Admin -Principal "TestLocalGroup"
# Local user on VC
Get-Folder -Name TestPerm | New-VIPermission -Role Admin -Principal "TestLocalUser"
# AD domain group
Get-Folder -Name TestPerm | New-VIPermission -Role Admin -Principal "domain\TestDomainGroup"
# AD domain user
Get-Folder -Name TestPerm | New-VIPermission -Role Admin -Principal "domain\TestUser"
How do your New-VIPermission lines look ?
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Hi,
Did you try to get AD group using Get-VIAccount cmdlet?
Get-VIAccount -Group -Domain "domain" -Id "group"
Luc,
The command I'm using looks like this:
New-VIPermission -Entity $hshPathsAndViewObjects[$oPerm.oPermPath.Path] -Principal $oPerm.Principal -Role $oPerm.Role -Propagate $oPerm.Propagate -Confirm:$false
$hshPathsAndViewObjects[$oPerm.oPermPath.Path] is a folder object$oPerm.Principal is a string in the format "domain\group"$oPerm.Role is a string containing the name of the role I want to assign$oPerm.Propagate is a boolean set to $true
I modified your script and basically have the same issues. Here's one with a domain group:
New-VIPermission : 9/20/2011 10:29:03 AM New-VIPermission Could not find VIAccount with name 'domain\group'.
At line:1 char:45
+ Get-Folder -Name TestPerm | New-VIPermission <<<< -Role ReadOnly -Principal "domain\group"
+ CategoryInfo : ObjectNotFound: (domain\group:String) [New-VIPermission], VimException
+ FullyQualifiedErrorId : Core_ObnSelector_SelectObjectByNameCore_ObjectNotFound,VMware.VimAutomation.ViCore.Cmdlets.Commands.PermissionManagement.NewVIPermission
New-VIPermission : 9/20/2011 10:29:04 AM New-VIPermission Value cannot be found for the mandatory parameter Principal
At line:1 char:45
+ Get-Folder -Name TestPerm | New-VIPermission <<<< -Role ReadOnly -Principal "domain\group"
+ CategoryInfo : NotSpecified: (:) [New-VIPermission], VimException
+ FullyQualifiedErrorId : Core_BaseCmdlet_UnknownError,VMware.VimAutomation.ViCore.Cmdlets.Commands.PermissionManagement.NewVIPermission
And here's one with a domain account:
New-VIPermission : 9/20/2011 10:30:12 AM New-VIPermission Could not find VIAccount with name 'domain\user'.
At line:1 char:45
+ Get-Folder -Name TestPerm | New-VIPermission <<<< -Role ReadOnly -Principal "domain\user"
+ CategoryInfo : ObjectNotFound: (domain\user:String) [New-VIPermission], VimException
+ FullyQualifiedErrorId : Core_ObnSelector_SelectObjectByNameCore_ObjectNotFound,VMware.VimAutomation.ViCore.Cmdlets.Commands.PermissionManagement.NewVIPermission
New-VIPermission : 9/20/2011 10:30:12 AM New-VIPermission Value cannot be found for the mandatory parameter Principal
At line:1 char:45
+ Get-Folder -Name TestPerm | New-VIPermission <<<< -Role ReadOnly -Principal "domain\user"
+ CategoryInfo : NotSpecified: (:) [New-VIPermission], VimException
+ FullyQualifiedErrorId : Core_BaseCmdlet_UnknownError,VMware.VimAutomation.ViCore.Cmdlets.Commands.PermissionManagement.NewVIPermission
Quick question, is the user/group member of the same domain as your vCenter ?
And I ran this with PowerCLI 5 against a vSphere 4.1U1 environment.
Same for you ?
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Yep, the groups I'm using are all in the same domain as the vCenter server, which yes, is also 4.1 U1 and I was using PowerCLI 5.0 against it (and PowerCLI 4.1 U1 for that matter). One oddity is that some groups are domain local groups while some are global groups, but the error is the same.
Very strange indeed
I suppose this cmdlet needs a bit more work.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
I've tried this command. Sometimes it works, sometimes it doesn't, so it seems to align well with the New-VIPermission cmdlet problems I've having. I tried your command with three different AD groups and only one of them actually worked. However, we are onto something now. I say "we" because I work with mattboren and he noticed that if you run this:
(Get-VIAccount -Group -Domain DOMAIN).Count
You only get 1500 groups returned. And strangely, sometimes you only get 1000 if you run it multiple times--not sure why that is. So after that we just tested the command with Onyx to learn more and here is what we found.
Get-VIAccount looks like this in Onyx:
$_this = Get-View -Id 'UserDirectory-UserDirectory'
$_this.RetrieveUserGroups("DOMAIN", $null, $null, $null, $false, $false, $true)
The API reference for the UserDirectory Managed Object shows that the RetrieveUserGroups method has a nice parameter named "searchStr" that doesn't appear to be used at all (shows $null in Onyx anyway). Maybe this would help? We are not actually sure how it finds any group without using that, but somehow it does. Regardless, as I mentioned before, I used three AD groups in my testing. When we scan the output of the 1500 groups the Get-VIAccount cmdlet finds, the group that works is in that output and the two groups that don't work are NOT in that output of course.
We can only guess that when Get-VIAccount or New-VIPermission run, there is some sort of limit/timeout that prevents them from searching all of the AD groups in our large AD environment and that it is somehow just looking for the supplied group in the limited result set it returns. Get-VIAccount is also very slow to return those 1500 groups, so we wonder if using either or both the "searchStr" and "exactMatch" parameters would make performance increase as well?
Anyway, I hope this helps. I'm going to test LucD's Christmas Day workaround from http://communities.vmware.com/message/1435306 and see if that works with PowerCLI 5 I guess. Though I need it to handle both AD groups and AD user accounts.
Message was edited by: allencrawford -- left some info in the post I didn't want to include, forgot to hyperlink the API reference
Hi Allen,
I'm having the same issues, if I ran (Get-VIAccount -Group -Domain DOMAINNAME ).Count the ESXi 4.1 only returns 100 Groups.
If I run this in our vCenter I get all my AD Groups.
I'm getting crazy with that issue. Let me know if you've fixed that.
Regards,
Stefan
Strange, when I run this, I get the correct number returned.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Could you check the ads settings in vCenter ?
Perhaps your maxFetch is set to 100.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
ads.maxFetch is set to 1000, but vCenter is not the problem. I'm able to set permissions using New-VIPermissions on vCenter.
I do have ESXi 4.1 Hosts which are AD Integrated and I want to set permission on them locally (to authenticate directly, without vCenter).
On the single node I do have the limit of 100 users/groups. I just wanted to know if there is any possible limit (lsassd) to modify on the ESXi Host.
Thanks
This is not vCenter but AD limits. To confirm try to get group details directly using powershell.
Powershell cannot be directly used to query group if it is large group. Sorry I do not know the exact number.
We are still exploring this since we're experiencing the same problem (vSphere 5 server fails to find a given group but vCenter 5 works)
I think we need to control the advanced vSphere server setting: Config.HostAgent.plugins.vimsvc.userSearch.maxResults
The default value is 100 which means you don't find stuff if you have more than 100 objects in your directory. It also explains the different behaviour with vCenter and vSphere server when you're trying to query.
I'll update this entry if more details come to light (e.g., what's the relative behaviour between 0 and 128000 - a good maximum based on the number of objects in our directory.
Here's LucD's code amended for vSphere 5. It seems to work when we connect directly to the vSphere server, finding groups that can't be found using New-VIPermission or Get-VIAccount. It's exactly the same except for the name of the AuthorizationManager object.
$domain = "ourDomain"
$groupname = "ourGroup"
$svcgroup = $domain + "\" + $groupname
$folder = Get-Folder -Name "ha-folder-root"
$authMgr = Get-View "AuthorizationManager-ha-authmgr"
$perm = New-Object VMware.Vim.Permission
$perm.principal = $svcgroup
$perm.group = $true
$perm.propagate = $true
$perm.roleid = ($authMgr.RoleList | where{$_.Name -eq "Admin"}).RoleId
$authMgr.SetEntityPermissions(($folder | Get-View).MoRef, $perm)
Oct 06: Updated to add workaround code for setting permissions on vSphere servers in large AD domains
Hi,
There is a similar setting for ESXi too. Go to Host-> Configuration -> Advanced settings -> Config-> Host Agent -> Config.Hostagent.plugins.vimsvc.userSearch.maxResults
I'm going to do one of those things that I hate forum contributors doing - speculate.
From our testing, I *believe* that vSphere does not do paged LDAP queries against AD (but I also believe that vCenter does which is why vCenter can find everything but vSphere cannot). As a result, the most entries that can be returned to the vSphere server for any query is the lower of the maximum configured here in vSphere, and the maximum configured in the Active Directory LDAP Policy MaxPageSize setting. That second limit defaults to 1000, and should only be changed once you understand the consequences (http://technet.microsoft.com/en-us/library/cc770976(WS.10).aspx).
So if your domain has less than 1000 users and groups (i.e., your lab or a separate administration domain), you are probably OK using the current version of Get-VIAccount which seems to do a really big query then finds what you're looking for in the result set.
Otherwise, you should use LucD's workaround which I posted previously which does a focused query for the account/group you specify.
Hopefully, the next version of Get-VIAccount and the underlying code for New-VIPermission (which seems to use the same process), will do the directed queries as well.
For those it might help, I took LucD's code snippet and created an easy-2-use function called New-VIGroupPermission which will take 4 objects and do all the magic you need to get the group added. I have attached the function.
Here's the syntax:
New-VIGroupPermission
REQUIRED parameters
$GroupName: [string]: Active Directory Group name in the DOMAIN\Group format
$VIObject: [viobject]: VI Object such as a Datacenter or Folder object that permissions are to be set on
$VIRoleName: [string]: Valid VI Role name of the role you want set
$Propagate: [bool]: ($true | $false) Set to enable or disable propagation of permission
SYNTAX: New-VIGroupPermission <GroupName> <VIObject> <VIRoleName> <Propagate>
Example Usage: > $Datacenter = Get-Datacenter "EUROPE"
> $Folder = Get-Datacenter "EUROPE" | Get-Folder "Sales"
> New-VIGroupPermission "mydomain\mygroup1" $DataCenter "Admin" $true
> New-VIGroupPermission "mydomain\mygroup2" $Folder "ReadOnly" $false
Hey Mackopes,
Thanks for putting this into a function!
I'm getting the error "WARNING: Invalid VIObject. Exiting" on every folder I try.
Whether standalone host or a folder in VCenter, I am getting this error. I used Get-Folder to verify the folder name I am using is correct.
Any thoughts?
Thanks!