Table of Contents
Directory Lookups, the Address Book, and the Get-MgDomainNameReference Cmdlet
The news published in message center notification MC706449 (13 January 2024) is surprising only because people must still be accessing elements like the Global Address List online. This is surprising because I assume most people use Outlook in cached Exchange mode and take advantage of the Offline Address List (OAB). Access to the online address book is only necessary to find details of recipients added since Outlook last downloaded and applied an OAB update.
In any case, Microsoft wants people to stop browsing online address books and use search instead. They don’t want people doing what they call “infinite browsing,” which I assume means that users start scrolling through the address list to find interesting entries. Such activity causes the client to make multiple calls to fetch directory information.
Moving to a search-first posture makes sense and it’s the way things work with OWA and Outlook Monarch. Basically, Microsoft wants Outlook users to construct a search (like find people with “Tony” as their first name) and use the search to find matching entries. Microsoft says that they’ve improved search performance to ensure that users get fast results. In a further change, to encourage people to change habits, directory lookups against online address lists return only the first 500 entries, even if more exist.
Another tweak is that if you attempt to use a very broad search and more than 5,000 entries result, Outlook won’t show anything and you’ll be forced to narrow the search to see results. These changes have no effect on lookups against the OAB.
Finding Numbers of Directory Entries
Five hundred sounds like a lot of entries but the number is easily exceeded when you consider the number of mail-enabled objects that appear in address lists. Even though my tenant supports just 35 mailboxes, 490 mail-enabled objects are in the GAL:
[array]$MEObjects = Get-Recipient -ResultSize Unlimited -Filter {HiddenFromAddressListsEnabled -eq $False}
$MEObjects.count
490
$MeObjects | Group-Object RecipientTypeDetails -NoElement | Sort-Object Count -Descending | Format-Table Name, Count -AutoSize
Name Count
---- -----
GroupMailbox 174
GuestMailUser 125
MailUniversalDistributionGroup 60
UserMailbox 35
DynamicDistributionGroup 24
MailUser 18
RoomMailbox 17
MailUniversalSecurityGroup 12
SharedMailbox 10
RoomList 5
PublicFolder 4
SchedulingMailbox 4
EquipmentMailbox 2
Fortunately, I use the OAB and search rather than browse to find entries, so MC706449 doesn’t affect me.
Issue with Domain Name References
Also related to the directory, last week, I discussed how to report issues to the Microsoft Graph PowerShell SDK development team. I suggested that browsing the reported issues is a good way to learn about how people use the SDK. Taking my own advice, I came to issue 2494, which discusses a problem with the Get-MgDomainNameReference cmdlet. The cmdlet is derived from the list domainNameReferences Graph API, which retrieves a list of directory objects referencing a specified registered domain belonging to a tenant. To see the valid domains for your domain, run the Get-MgDomain cmdlet:
Get-MgDomain | Format-Table Id, Isdefault Id IsDefault -- --------- microsoft365itpros.com False office365itpros.com True office365itpros.onmicrosoft.com False office365exchangebook.com False office365itproebook.com False
For instance, if you ask for directory objects referencing office365itpros.com, Entra ID should retrieve a list of all user and group objects referencing the domain, such as in an object’s email address or user principal name. Figure 1 shows the Graph Explorer retrieving a list of office365itpros.com objects.
Here’s an example of the data returned for a user account:
Name Value
---- -----
mail Ben.Owens@office365itpros.com
surname Owens
id a3eeaea5-409f-4b89-b039-1bb68276e97d
displayName Ben Owens (DCPG)
givenName Ben
jobTitle Chief bottle washer
businessPhones {}
officeLocation Moscow
@odata.type #microsoft.graph.user
userPrincipalName Ben.Owens@office365itpros.com
preferredLanguage en-US
The equivalent query can be run using the PowerShell Invoke-MgGraphRequest cmdlet:
$Uri = "https://graph.microsoft.com/v1.0/domains/office365itpros.com/domainNameReferences"
$Data = Invoke-MgGraphRequest -Uri $Uri -Method GET
Data
Name Value
---- -----
@odata.context https://graph.microsoft.com/v1.0/$metadata#directoryObjects
value {a3eeaea5-409f-4b89-b039-1bb68276e97d, 96155a51-6885-4c8f-a8b6-e1614af08675, 67105a51-e…
What’s odd is that the query returns 300 items as a default and doesn’t include a nextlink pointer if further pages of data are available for retrieval:
$Items = $Data.Value $items.count 300
Because the Get-MgDomainNameReference cmdlet is derived from the Graph query, it also returns 300 items, even if the All parameter is passed to instruct the cmdlet to retrieve all available pages:
[array]$DomainNames = Get-MgDomainNameReference -DomainId office365itpros.com -All $DomainNames.count 300
You can increase the page size to retrieve up to 999 items, but that’s the limit. We can go no further because of the lack of a nextlink.
[array]$DomainNames = Get-MgDomainNameReference -DomainId office365itpros.com -PageSize 999 $DomainNames.count 424
SDK Cmdlets Depend on Underlying APIs
The same results occur in both the V1.0 and beta APIs. The original problem reported in issue 2494 was that the user accounts for shared mailboxes are not in the returned set. Perhaps the problem all along was the inability of the API to retrieve the complete set of available items? Who knows… Microsoft generates the SDK cmdlets from the underlying Graph APIs, so when a Graph API has a problem, it also shows up in the SDK.
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.