I'm familiar with using the NET commands to get information for local users and groups in most scenarios. However, I'm running into a problem using it to get information for domain groups with long names. The output of NET USER appears to cap group names at around 20 characters, and I haven't found a way to use NET GROUP to get information about any groups that have names longer than that.

Certainly, from my own workstation I can use Remote Server Administration Tools utilities (e.g.: "ds..." commands, or the Active Directory module in PowerShell) to get the information I need. However, I also want to be able to look up domain group details from other systems which might not have RSAT and on which I may not be able/allowed to install additional tools.

While solving the problem with the NET GROUP command would be interesting, I'm not necessarily limited to that tool. However, I do need to limit myself to only the tools available in a core installation of the Windows 7 (or similar) operating systems so that I can easily port the solution across different computers where adding other tools might not be an option. If there's a way to do this with something like WMIC, or PowerShell without the additional RSAT modules, I'm definitely interested in hearing about it.

Example: "MyReallyLongDomainGroupName" is a member of the local Admins group. So, who has admin access to the system? Or "AnotherVerboseDomainGroupName" is in some file share permissions - who has access to that share?

  • What are you looking for as far as output? You say "net group" but that's pretty deprecated at this point. Why not PS? – TheCleaner Nov 12 '14 at 20:20
  • @TheCleaner The PS cmdlets that fulfil this need are a component of RSAT. Where I need to do this, I cannot count on RSAT being available. – Iszi Nov 12 '14 at 23:20
  • @TheCleaner Oh, and output I'm looking for is pretty much just a list of group members. Ideally, I should be able to get any other details normally available via NET GROUP (i.e.: find a workaround for the character limit, or another built-in tool that does the same job without such limitation) but for now I'm just looking for members. – Iszi Nov 13 '14 at 6:15

The old NET command still has limitations from the Windows NT era that it was created in. To handle longer names you're better off using the various ds... commands dsquery, dsmod, etc, or third-party tools like adfind. You won't have name length limitations there.


The ds tools are standalone EXEs that, while present in RSAT, can be freely copied around. Even so, because I want to honor the spirit of your request, here's a Powershell script that relies on the ADSI interface (present in Windows w/o requiring RSAT to be installed-- it's a base OS component) that will enumerate the membership of a group.

# iADSNameTranslate constants

if ($args.count -ne 1) { "`nUsage: ./GroupEnum.ps1 <DOMAIN\groupName>`n"; Exit; }

$ns = New-Object -ComObject NameTranslate

[System.__ComObject].InvokeMember(“init”, ”InvokeMethod”, $null, $ns, ($ADS_NAME_INITTYPE_GC, $null))
[System.__ComObject].InvokeMember(“Set”, ”InvokeMethod”, $null, $ns, ($UNKNOWN, $args[0]))
$dn = [System.__ComObject].InvokeMember(“Get”, ”InvokeMethod”, $null, $ns, $DISTINGUISHEDNAME)

$Group = [ADSI]"LDAP://$dn"
if ($Group.SchemaClassName -eq "group") {
    $Group.Member | ForEach-Object { 
        $x = [ADSI]"LDAP://$_" 
        if ($x.SchemaClassName -eq "user") { $x.sAMAccountName }

I tested this with a limited user account on a Windows 7 x64 SP1 machine w/ no RSAT installed. I tested with a group named "123456789012345678901234567890123456789012345678901234567890", as well.

There's absolutely no error checking in this script.

  • DS tools are a component of RSAT. I'm trying to find solutions that aren't dependent upon RSAT or any tools not in a default Windows 7 installation. Down-voted this answer due to RSAT dependency (which was specifically called out in the original post) and updated my question to also exclude other tools not included in the core OS. – Iszi Nov 12 '14 at 23:19
  • I accept your challenge. – Evan Anderson Nov 13 '14 at 1:30
  • Ok... a little less portable across systems (e.g.: I was really hoping to get something I could easily carry in my head - not a thumb drive) but definitely worth at least dropping the -1. Can't help but think there should be an easier way, but probably isn't. – Iszi Nov 13 '14 at 3:34
  • 1
    If you don't mind typing the LDAP path yourself you can condense that to a two-liner pretty easily. The bulk of that code is just to resolve the group name into an LDAP path. – Evan Anderson Nov 13 '14 at 3:35
  • Looks like this may or may not be a somewhat more straightforward avenue worth exploring. Unfortunately, I'm not on a good test system now. – Iszi Nov 13 '14 at 4:06

Adding another answer, since my current answer is based on the currently logged on user's groups...and the OP stated in a comment:


So here you go...I tested this from a regular user's account on a Win7 workstation:

From the RUN line (win+R)

Rundll32 dsquery.dll OpenQueryWindow

That should pop up an AD query window where you can then find the group in question...double click the group...and see the users in the group.

  • Now that's the kind of solution I was looking for. Portable to systems without RSAT or other add-ons, easy to remember, and pretty user friendly to boot! Only negative I see is that it seems a bit limited in functionality - for example, I don't appear able to view users' group memberships (reverse of what I was asking for, I know, but still handy). Otherwise, a much preferable workaround compared to the other options I've seen here or elsewhere thus far! – Iszi Nov 13 '14 at 14:45
  • Yeah, for user's group membership you could use my other solutions for the currently logged on user. But for a different user unfortunately I don't have a great solution, especially without knowing their password. – TheCleaner Nov 13 '14 at 15:05

OK, so knowing you want NON-RSAT tools from a domain computer that isn't your workstation, then I'll make an assumption that you are wanting to figure out the groups that the user on that workstation is a member of.

IF that's the case there's a few options I can think of:

  1. you can run WHOAMI /GROUPS
  2. You can run mstsc and rdp into your workstation or a DC and use normal tools
  3. You could run gpresult /R /SCOPE USER

All of these of course require that you are on the domain with the computer able to query a DC.

Hope that helps...best I can think of at the moment.

  • #2 - Exactly what I'm trying to avoid. #1 & 3 - Great, but they only work for the currently logged-in user. (Or another user who's available to log in for Run As.) I'll often need to get information about other users, and in most cases (though perhaps not quite clearly spelled out in my question) I'm really looking for information on groups instead of users. Example: "MyReallyLongDomainGroupName" is a member of the local Admins group. So, who has admin access to the system? Or "AnotherVerboseDomainGroupName" is in some file share permissions - who has access to that share? – Iszi Nov 13 '14 at 3:27
  • 1
    Your comment should be part of your original question...makes better sense now as to what specifically you are after as results. I'll edit your question. – TheCleaner Nov 13 '14 at 14:05

You could use Powershell.

Get-ADGroup -Filter '*'
Get-ADGroup -Filter '*' | Select-Object Name

The first just print a bunch of details on the groups. The second prints only their names.

EDIT: If ActiveDirectory module is available only through RSAT, then here's a .net solution.

$dn = New-Object System.DirectoryServices.DirectoryEntry("LDAP://WM2008R2ENT:389/dc=dom,dc=fr","Username","PWD")
$dsLookFor = new-object System.DirectoryServices.DirectorySearcher($dn)
$dsLookFor.Filter = "(&(objectCategory=group))"; 
$dsLookFor.SearchScope = "subtree"; 
$n = $dsLookFor.PropertiesToLoad.Add("cn"); 
$n = $dsLookFor.PropertiesToLoad.Add("distinguishedName");
$n = $dsLookFor.PropertiesToLoad.Add("sAMAccountName");

$lstUsr = $dsLookFor.findall()
foreach ($usrTmp in $lstUsr) 
  Write-Host $usrTmp.Properties["samaccountname"]
  • Pretty sure the AD module comes in RSAT. I'm looking to do this on systems where RSAT may not be available. Down-voted this answer due to its dependency on RSAT, which was explicitly called out in the original question. – Iszi Nov 12 '14 at 23:24
  • I've added a .net solution. – EliadTech Nov 13 '14 at 4:39

Your Answer

