Exchange 2007 - Find Distribution Group Memberships Across Domains?

synaptix
synaptix used Ask the Experts™
on
I have a need to enumerate distribution group memberships via script (too time consuming and painful to do by hand). The only problem? We have Exchange 2007, and our AD organizational structure, though hierarchical, simple, and clean, has always caused EMS to be difficult to work with. Our AD is structured as shown below (all domains have direct two-way trust with the TLD.local domain though that should be irrelevant):

TLD.local (Exchange servers here)
|
---- domain1.TLD.local (Distibution groups are all here)
|
---- domain2.TLD.local (Some group MEMBERS are here)

Open in new window


All Distribution groups are located in our corporate AD domain. The users for one particular DG are all located in a different domain. Other DGs have mixed members from various domains in our AD forest. The script below is what I have come up with that gets about half of the users I am expecting to see (missing ALL of those outside of domain1.TLD.local).

# Use a list of distribution groups (their SMTP addresses) we have been requested to report on.
$list = Get-Content "C:\TEMP\dgroups.txt"
# Put the list of found distribution groups (all present in a single domain) into an array.
$groups = Foreach ($item in $list) { Get-DistributionGroup $item -DomainController DC-DOMAIN1.domain1.TLD.local }
# Actually find group members.
$MembershipList = Foreach ( $group in $groups ) { Get-DistributionGroupMember $group -DomainController DC-DOMAIN1.domain1.TLD.local | Select @{Label="Group";Expression={$group.Name}},@{Label="User";Expression={$_.Name}},SamAccountName,PrimarySMTPAddress }

$MembershipList | Sort Group,User | Export-CSV "C:\TEMP\dgmembers.csv" -NoTypeInformation

Open in new window


If I change "DC-DOMAIN1.domain1.local" to "DC-DOMAIN2.domain2.local" in either of the above commands, then I either get an error telling me I cannot find my distribution groups (obvious), or I can only find SOME of the members of the groups (those in the same domain as the DG itself). I fail to understand what the "-ReadFromDomainController" parameter is for on the Get-DistributionGroupMember cmdlet in this case, as it appears to have no effect, no matter how I structure my script.

In short, I cannot enumerate complete group memberships using EMS *unless* all of the the MEMBER objects happen to exist on the same domain controller as the DISTRIBUTION GROUP itself. Does anyone have any ideas on how I can modify the above (or use different commands) to get a list of the MEMBERS of various distribution groups, when those MEMBERS may exist in a different AD domain than the GROUP?

My thanks in advance for any assistance.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Gaurav SinghSolutions Architect

Commented:

Author

Commented:
Thanks, but that doesn't get me anywhere. Because our Exchange server sits in TLD.local, and our distribution groups reside in domain1.TLD.local, we must use the "-DomainController" parameter with both Get-DistributionGroup and Get-DistributionGroupMember. The problem is this

Exchange server - exists in TLD.local
Sales (distribution group) - exists in domain1.TLD.local
User1 (user / member) - exists in domain2.TLD.local

Get-DistributionGroup -Identity "Sales" | Get-DistributionGroupMember

Open in new window

Gets me NOTHING (error because DG not found in the TLD.local domain, where Exchange resides).

Get-DistributionGroup -Identity "Sales" -DomainController DC-DOMAIN1.domain1.TLD.local | Get-DistributionGroupMember

Open in new window

Gets me NOTHING because without a specified DC in Get-DistributionGroupMember the command defaults to the TLD.local (Exchange server) domain.

So we actually need to use something like the following:

Get-DistributionGroup -Identity "Sales" -DomainController DC-DOMAIN1.domain1.TLD.local | Get-DistributionGroupMember -DomainController DC-DOMAIN1.domain1.TLD.local

Open in new window

This unfortunately ONLY returns users within DOMAIN1, meaning users who exist in DOMAIN2 are simply omitted.

Get-DistributionGroup -Identity "Sales" -DomainController DC-DOMAIN1.domain1.TLD.local | Get-DistributionGroupMember -DomainController DC-DOMAIN2.domain2.TLD.local

Open in new window

This returns an error, because Get-DistributionGroupMember, although pointing to the correct domain for MEMBERS, cannot find the group itself because it does not exist in domain2.

The problem appears to be that both EMS commands are expecting everything to be in a single domain. Our distribution groups are all in DOMAIN1, but our users (group members) can exist in any domain.

Author

Commented:
Surely I can't be the only Exchange admin with users and distribution groups in different domains. How does everyone else get reports on group memberships across different domains?
Commented:
I figured it out. Fortunately, we are in the process of migrating our Exchange environment from Exchange 2007 to Exchange 2013.

- Exchange 2007 has no means to accomplish this. Limited design means you cannot cross domain boundaries when searching for distribution group members. Members of distribution groups will only be returned when both the group and its members are in the same domain.

- Exchange 2013 this can be accomplished as follows (note the combined use of the [-Anr] or "Ambiguous Name Resolution" parameter, along with the [-IgnoreDefaultScope] parameter to force the query to examine the ENTIRE recipient scope in all associated domains). Why I didn't think to just try the queries from a newer EMS interface is evidence that I need more sleep.

Get-DistributionGroup -IgnoreDefaultScope -Anr <displayname or alias or smtpaddress> | Get-DistributionGroupMember -IgnoreDefaultScope

Open in new window


So in my case, one such example might look like this:

Get-DistributionGroup -IgnoreDefaultScope -Anr "Outside Sales" | Get-DistributionGroupMember -IgnoreDefaultScope

Open in new window


Thanks for the input. I probably could have worked around this by querying AD directly, rather than using the Exchange Powershell cmdlets, but the script I had started on for this was getting rather painful, requiring me to first find objects in AD, get their distinguished names, then pass those found objects around to other cmdlets. Yeah, no need to have a 20+ line script in ultra-verbose Powershell when newer versions of Exchange are actually built properly from the start. Powershell one-liners are fantastic. It's when you find a problem that the cmdlets available don't readily solve that Powershell's usefulness begins to become questionable.

Author

Commented:
Tested and verified that this was the best / most acceptable solution in my environment.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial