Exchange 2007 - Find Distribution Group Memberships Across Domains?
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):
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).
If I change "DC-DOMAIN1.domain1.local"
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.
TLD.local (Exchange servers here)
|
---- domain1.TLD.local (Distibution groups are all here)
|
---- domain2.TLD.local (Some group MEMBERS are here)
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
If I change "DC-DOMAIN1.domain1.local"
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.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
you can use the Get-DistributionGroup Command to get the details. Refer below link with Script might help you.
https://community.spiceworks.com/scripts/show/1388-export-distribution-list-members
or
http://www.careexchange.in/how-to-export-all-distribution-group-and-all-members-of-it-exchange-2010/
https://community.spiceworks.com/scripts/show/1388-export-distribution-list-members
or
http://www.careexchange.in/how-to-export-all-distribution-group-and-all-members-of-it-exchange-2010/
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-DistributionGroupMembe
Exchange server - exists in TLD.local
Sales (distribution group) - exists in domain1.TLD.local
User1 (user / member) - exists in domain2.TLD.local
So we actually need to use something like the following:
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.
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
Get-DistributionGroup -Identity "Sales" -DomainController DC-DOMAIN1.domain1.TLD.local | Get-DistributionGroupMember
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
Get-DistributionGroup -Identity "Sales" -DomainController DC-DOMAIN1.domain1.TLD.local | Get-DistributionGroupMember -DomainController DC-DOMAIN2.domain2.TLD.local
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.
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?
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.
So in my case, one such example might look like this:
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.
- 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
So in my case, one such example might look like this:
Get-DistributionGroup -IgnoreDefaultScope -Anr "Outside Sales" | Get-DistributionGroupMember -IgnoreDefaultScope
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.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial