Get-VIAccount Issues on Large Domains

[Tocano]

I'm trying to add a group to have permissions on a VM:

> Get-VM VMName | New-VIPermission -Role (Get-VIRole -Name "RoleName") -Principal "DOMAIN\GroupName"

However, this fails with a "Could not find VIAccount with name 'DOMAIN\GroupName'"

So I started trying to get the VIAccount object:

> Get-VIAccount -Domain "DOMAIN" -Group -Id "GroupName"

But this fails with 'ViAccount with id 'GroupName' was not found using the specified filter(s).'

So I decided to open things up a bit and see if I could find it in the list myself:

> $groups = Get-VIAccount -Domain "DOMAIN" -Group
> $groups.Count
8500

Odd... this is only a portion of all groups. And looking at the members, it appears to pull them back in alphabetical order and stops well short of my groupname. Wonder if those groups early in the alphabet work ok?

So I test my theory by specifying a group I create that starts with "AAA_...":

> Get-VM VMName | New-VIPermission -Role (Get-VIRole -Name "RoleName") -Principal "DOMAIN\AAA_GroupName"

Success!

So it seems to me that the algorithm for New-VIPermission/Get-VIAccount, instead of working against the entire domain, just grabs some arbitrarily large number of groups/users, based on alphabetical order, and then searches for the specified name/id within that subset. For large domains, this means that groups/users toward the latter half of the alphabet may not be included in the search set and result in "not found" errors, even though that group/user does, in fact, exist within the domain.

Does this make sense? Has this already been discovered by others and I'm just figuring it out myself?

Is there a workaround to deal with group names (who I, as a VAdmin do not have control over) that may have names starting toward the later half of the alphabet?

Thank you.

[LucD]

Couldn't this be the limit that Active Directory places on LDAP queries ?

I know you can bypass that limit by using a range option. See Searching Using Range Retrieval.

But that doesn't help in this case obviously.

Did you already try using masks in the call ?

Something like for example

Get-VIAccount -Domain "DOMAIN" -ID "X*" -Group

To retrieve all groups starting with X

[Tocano]

For the get-all-groups, I don't doubt it's a domain limitation. But it should never hit that limitation if it's asking the domain for a single group.

Unless the algorithm behind Get-VIAccount simply asks the domain for  all-groups in ALL cases, and THEN tries to process/search for the group name within  that list, instead of creating an LDAP query and letting the domain  server process the search.

As for masks, if what I've described about its behavior is accurate, then it doesn't matter whether you wildcard or not as it doesn't apply that mask filter until after it gets the list of all groups (or what it believes is all groups). Thus for large domains where it caps that, if the string falls outside that first part of the alphabet, then it won't be included, if it falls inside that subset, it will be included. It just depends on how large the subset of all groups the algorithm receives to process.

After I wrote that paragraph, I decided to test that assumption. Created 5 groups 'AAA_TEST_GROUP[1,2,3,4,5]' and 5 groups 'XXX_TEST_GROUP[1,2,3,4,5]'

Sure enough:

> $xxxGroups = Get-VIAccount -Domain "DOMAIN" -Id "XXX_*" -Group
> $xxxGroups.Count
[0]
> $aaaGroups = Get-VIAccount -Domain "DOMAIN" -Id "AAA_*" -Group
> $aaaGroups.Count
5

Now I'm pretty new to PowerCLI and even PowerShell itself, so I could be mistaken, but the more I play around with it, the more it seems that the PowerCLI process simply asks the domain for all groups and then tries to filter on them itself. To me, if this is accurate, it is a very bad method of fetching LDAP/Domain groups. Let the LDAP server process the search query - it's what it's designed to do.

If there is another method or a workaround to applying VM role/permissions to a group, I would appreciate any guidance.

Thank you.

[LucD]

First, I'm not aware of a bypass for this behaviour I'm afraid :smileysad:

Unless you make the AD queries directly. The Quest AD snapin could help here.

Secondly, and in the defense of PowerCLI, this is imho a problem with the RetrieveUserGroups method, which the PowerCLI cmdlet uses under the covers. That method apparently doesn't optimise the LDAP calls to AD.

[Tocano]

I guess I need to try to write my own version of Get-VIAccount to create the LDAP query and pass it to the Directory Service. Thanks.

I wasn't trying to be critical of PowerCLI itself. Just hoping that if we could identify the source of the ... errant alogorithm, we could encourage/initiate a fix.

Other than initiating a support request, do you have any better recommendations to try to inform VMware of this issue?

Thank you.

[LucD]

You have every right to be critical of any product.

They are written by people and hence can contain errors :smileygrin:

Several VMware people read these threads regularly, so they will probably see it.

But it wouldn't harm to open a service request.

[Kaustuvs]

Hi,

So is there any solution to this as I am also seeing the same issue now.

Has there been any resolution or fix to this?

Kindly let me know.

[LucD]

Seeing you are a VMware Employee wouldn't it be easier to ask this on your internal channel from the PowerCLI Dev Team?

And we, the users, would of course be interested to know the answer as well