In Office 365 recipients may have different mailbox types. A mailbox enabled user may have one or more archive mailboxes or a guest user that you have invited to interact with organization groups may have a component shared mailbox.

 

I recently participated in an escalation where there was a need to understand how many mailboxes were enabled with archives and how many of those archives had been auto expanded.

 

Prior to the release of the Exchange Management PowerShell version 3.0 administrators had access to a command called Get-MailboxLocations. In the new PowerShell this command was replaced with Get-MailboxLocation. (Notice the subtle difference). The usage of the command has also changed significantly allowing for the passing of either an identity or user object and allowing the scoping of the command to return either all or specific mailbox types. Information on get-mailboxLocation can be found at: Get-MailboxLocation (ExchangePowerShell) | Microsoft Learn

 

I have published a sample script to the following location: timmcmic/MailboxLocationsReport (github.com)

 

To utilize the script an Exchange Management PowerShell session must be opened and authenticated. When running the script, the administrator is presented with six predefined options.

1. Collect all recipients that can have a mailbox. This covers primary mailboxes, archive mailboxes, auxiliary archive mailboxes, and component shard mailboxes.
2. Collect all primary mailbox enabled recipients (may or may not have an archive enabled).
3. Collect all primary mailbox enabled recipients only if an archive is enabled.
4. Collect all recipients only if an archive is enabled.
5. Collect all Office 365 / Unified Groups.
6. Collect all guest recipients.

 

When the script has concluded a CSV file is generated at the path contained in the script. (This may be adjusted prior to execution.).

 

#Define user variables – please update as appropriate prior to running code.

 

[string]$outputFileName = “mailboxLocation.csv”
#Define the CSV file name.

[string]$outputFilePath = “C:\temp\”
#Define the output file path

 

 

Here is a sample entry in the csv file.

 

 

The CSV file can be opened in Excel and the columns filtered if necessary to parse information.

*IMPORTANT* Preparing for MS Graph Implementations

The DLConversionV2 PowerShell Module has dependencies on Azure Active Directory PowerShell commands. The Azure AD PowerShell commands are started a phased deprecation. The commands are being replaced by Microsoft Graph Commands.

 

When version 2.9.8 releases to the PowerShell Gallery using Microsoft Graph will be the standard method for querying and capturing information from Azure Active Directory. The necessary Microsoft Graph modules will be installed when either a current build is upgraded, or a new build installed.

 

When running DLConversionV2 administrators may use either interactive authentication for graph or certificate authentication. Unfortunately, the method of passing non-interactive credentials for authentication from scripts is not available in the Microsoft Graph modules.

 

DLConversionV2 now has the following switches included to establish the MSGraph session.

 

#Define Microsoft Graph Parameters

        [Parameter(Mandatory = $false)]

        [ValidateSet(“China”,“Global”,“USGov”,“USGovDod”)]

        [string]$msGraphEnvironmentName=“Global”,

        [Parameter(Mandatory=$true)]

        [string]$msGraphTenantID=“”,

        [Parameter(Mandatory=$false)]

        [string]$msGraphCertificateThumbprint=“”,

        [Parameter(Mandatory=$false)]

        [string]$msGraphApplicationID=“”,

 

 

$msGraphEnvironmentName = The specific Office 365 environment if connecting outside of the Global environment.

 

$msGraphTenantID = The Azure Active Directory / Office 365 tenant ID associated with your tenant. This can be obtained from the Azure Portal -> Azure Active Directory.

 

$msGraphCertificateThumbprint = The certificate thumbprint assigned to the local user profile and also assigned to the Microsoft Graph application created in Azure AD.

 

$msGraphApplicationID = The application of the application created in Azure Active Directory for Microsoft Graph.

 

The above four switches are required to have a migration performed in a non-interactive authenticated session. If performing a single distribution list migration the switches can be omitted at which time an interactive authentication prompt will be presented.

 

To use Microsoft Graph either the application you are connecting to or the user account you are using has to consent to access and request certain rights. The minimum rights required for the DLConversionV2 module are Group.Read.All and User.Read.All. You may have to work with others in your organization to consent to these rights when connecting to Microsoft Graph.

 

As most migrations are performed in a non-interactive format I suggest reading the following blog post: Using Certificate-based Authentication with the Microsoft Graph PowerShell SDK | Practical365

 

The blog post by Tony Redmond presents an easy process for establishing your Azure Active Directory application and implementing certificate authentication for connections to Microsoft Graph. It also provides a simple command structure to test your installation.

 

I know for many this will break processes that are already in flow. The decision is not taken lightly but is required to allow sufficient time to move forward on supported APIs and continue the development of the modules.

 

Happy migrating!