Exchange Online MFA module updated to use refresh token

One frustration of the MFA module for connecting to Exchange Online is its inability to use the refresh token it gets from Azure AD.  As a result, you can use the session for 60 minutes before you are prompted again for credentials.  This makes it very difficult to run any scripts or long-running commands without it stopping mid-run to get your username and password, just to have it happen again 60 minutes later.

This limitation has been fixed starting with version 16.00.2015.000.  If you load the module from the desktop shortcut, the updated version is installed automatically.  (If you side-load the module, you’ll want to run the shortcut so it updates and be sure your code is loading the highest version.

The other requirement is that you must use the UserPrincipalName parameter when running Connect-ExoPsSession .  It is not a required parameter (like it is for Connect-AzureAD ), so you might be used to simply running the cmdlet and entering your UPN in the authentication form.  The reason for the UPN requirement is because, if you provide it in the authentication form, the cmdlet has no reference for which user’s refresh token to present when the access token expires.  It only knows which user authenticated in the first place if you provide the cmdlet with your username and let it pass it to the authentication form.

The other benefit you get with this fix is that, unlike using PowerShell remoting with Basic authentication, the module is able to silently reconnect after the session has been broken.  I successfully tested this by connecting one afternoon, changing networks and putting my laptop in sleep mode overnight, then running a cmdlet in the existing shell the next day.  I briefly saw the modern authentication prompt, it went away, then created a new implicit remoting connection and executed the cmdlet, all without having to type a username or password.

Even if you do not have MFA requirements, you may want to consider using the module to connect to Exchange Online for this added benefit.

Find mailbox folders with recently changed content

Mailbox settings can be stored in a number of places inside a mailbox.  A number of my scripts use Exchange Web Services to manipulate these settings, usually when there isn’t another way for an admin to manage them on behalf of a user.  An example is Office 365’s app launcher, which is currently being updated to v3 for tenants.  Because the method of managing the v2 launcher doesn’t work with v3, I had to try and find where the settings are stored.  The first step in doing that is changing a setting the way a user does (in this case, OWA) and then looking for changed folders as an indication that the setting is stored somewhere in one of them.  I decided to share how I do that.

The folder property PR_LOCAL_COMMIT_TIME_MAX (0x670A) stores the last time an item in the folder has changed.  This can be used in a search filter to quickly find all folders that have changed since a specific time.  First, I define all the MAPI properties I am going to be using in a search filter or in the results:

For efficiency, you usually only want to return as many properties as you will be using in some way.  (It is easier/simpler, though, to return the first class properties, when you will be using a lot of the common properties.)  So I define a property set to return only what I need:

After creating a folder view and adding the property set to it, I need to create a search filter.  This filter gets all folders (that aren’t search folders) where the last commit time is newer than a date and time:

Next, I connect to the mailbox’s root folder because I want to search all folders in the mailbox, not just the ones the user can see, and execute a search:

I then loop through the results.  First class properties, even if you manually add them to a property set, can be referenced by the object’s property name, e.g., $folder.DisplayName, but all other properties (known as extended properties) are collectively stored in another property.  You have to attempt to retrieve a defined extended property from this collection.  To do this, you have to define a variable in which the value of the extended property will be stored.  If you don’t, you will get an error.  Then you call the TryGetPropertymethod, specifying the defined property you want and, by reference, which variable you want to put its value.  For example, such as with the last commit time:

(Using the [void]  type accelerator suppresses the output of the object that is returned, which in this case is just True or False as to whether the extended property is in the collection.  It is the same as piping the command to Out-Null .)  While having the folder name is helpful, that alone doesn’t always make it clear where that folder is.  Therefore, I also get the path to the folder.  But the property stores it as a binary value, so I convert it to a string:

I put all the folders in an object, reverse sort by the last modified date, and output it to the screen:

To make it more consumable for others, I prettied it up and put it into a script.  You can download the script or copy the code below (after expanding).

  Get-FoldersWithContentChanges.ps1 (5.6 KiB)



 

Delegate management module updated to v1.5.0

It had been some time since I updated the delegate management PowerShell module. I started to update it last year after I decided to move the admin configuration settings to their own file, but didn’t complete it.  After a user of the module recently contacted me about adding one of the supported options for delegate meeting forwarding, I went back and finished updating it.  These are the changes:

  • Configuration settings have been moved to a file.  This allows for drop-in updates to the module without you having to reconfigure your settings again.  The file, DelegateManagementSettings.xml, should be located in the same directory as the module.  A default file is included in the download, but you can also use the new  Set-DelegateManagementSetting  cmdlet with the  CreateDefaultFile  parameter to have the module create one for you.  You can run  Get-DelegateManagementSetting  to view your current settings.  If you want to change one or more settings for the current session, the  Set-DelegateManagementSetting  cmdlet can do that, and you can use the Persist parameter if you want the changed setting to be written to the file.  (Comment-based help is available for both new cmdlets, e.g., Get-Help Set-DelegateManagementSetting .)
  • The following functionality has been moved from static values to configurable settings: whether to use Autodiscover, specifying an EWS URL, whether to use impersonation, and if permission should be added/set by default for the Deleted Items and Sent Items folders when adding a delegate.
  • The Azure AD module is no longer needed for managing delegates in Exchange Online.
  • The ability to specify that meeting requests for the owner/manager should not be forwarded to delegates.  (This is supported with Exchange 2013+ and Exchange Online mailboxes.)  NoForward has been added as a valid value with the MeetingRequestDeliveryScope parameter.
  • All functions for connecting via PowerShell to on-premises Exchange and Exchange Online have been removed.  Connection to the appropriate environment should be handled externally to the module, as would usually be done with any other module or cmdlet.  The exception to this is for Exchange Web Services (seeing as it is a stateless connection).  If managing delegates in Exchange Online, the first time you run a delegate cmdlet it will prompt for EWS credentials, which will be used for all future cmdlets in the same shell.  On-premises will use the current user credentials.  If you would like the module to be able to store and recall credentials automatically (in Credential Manager, for example), specify credentials for on-premises, or other credential options, let me know.

The updated module, along with a settings file, is here:

  DelegateManagement.zip (9.2 KiB)

How to pin custom app tiles on behalf of your users in Office 365

Update December 19, 2017: The process described in this post will not work with app launcher v3.  The configuration of the tiles, such as those that are pinned, is no longer stored in the user’s mailbox.  At this time there is no way (supported or unsupported) that I am aware of to manage the new app launcher for users.

The app launcher in Office 365 is how users can quickly get to any workload no matter where they are in Office 365.  It is accessed by clicking the waffle (though I see it more as a keypad) in the upper left corner.  This image is the default tile layout for an E5 admin:

Admins can add custom tiles to the tenant that point to any URL.  These custom tiles then show up under the ALL tab for users.  Here is an example of one I added to my tenant that just points to this blog’s RSS feed (hence the icon):

You may want to not just add the tile, but also pin it to your users’ HOME tab.  Office 365 does not currently allow admins to pin tiles for users; you can only pin apps for your own account.  But that didn’t stop me from figuring out where these settings are stored and manipulating them programmatically.

App launcher settings are stored in a user’s mailbox.  This is why a user needs to have an Exchange Online mailbox in order to customize their app launcher.  The settings for the app launcher are in the PR_ROAMING_DICTIONARY property of the IPM.Configuration.Suite.Storage message at the root folder of the mailbox.  EWS has a class for working with user configuration settings that are stored in a dictionary property, so you don’t have to manually work with the binary property.  Using PowerShell and the EWS Managed API, get the value of this property (the credentials and email address of the mailbox have already been assigned to variables):

The Dictionary property contains a hash table:

and the app launcher settings are stored in the value for a key name of Suite/AppsCustomizationDataTEST.  Because the settings are stored as JSON, let’s convert them to a custom object:

You can see that the all tiles for the Home tab are in a property called PinnedApps, which are themselves stored as custom objects. Here is the first one:In order to pin a tile, you need an object for the one you want to pin.  The easiest way to do this is to manually pin a tile in your app launcher, then use EWS to get that tile object.  Pinning a tile/app adds it to the end of the Home tab as the last item in the collection so, assuming you don’t move it after that, it will be the 24th item in the collection (index 23).  I assigned that item to a variable, so this is the object that will be added to other users’ pinned apps:

The collection of pinned apps is a fixed array, so to add a new item to it, copy the existing array to a new one plus the object for the custom tile.  Then convert the app settings object back to JSON, update the dictionary hash table with the new object, and save the changed user configuration setting back to the server:

If the user is already logged in, refresh the browser and open the app launcher to see the newly added tile:

You can modify the above code to loop through any number of mailboxes and add the custom tile object to their app launcher.  You can also manipulate the size and placement of the tile if you want, but my example is to show you how it can be added.  It should be noted that, while all of this does work, it is unsupported, so programmatically customize at your own risk.

Get Inumbo message tracking records with PowerShell

Inumbo is a cloud-based mail hygiene solution.  Whether using their free or paid subscription, you can search the message tracking log in the web portal to see a history of messages being processed for your subscription.  The main thing I use it for is to know if I haven’t received a message because it was marked as spam.  But rather than use the web portal, you can also use their REST API to programmatically get tracking records.  So instead of logging into the portal and searching, you just run a script and perform filtered searches and also get more information that what is exposed in the portal.

You need to get a read-only or read/write API key since that is what is used to authenticate the request.  You don’t have to use any search restrictions, and my script doesn’t require any either, but usually you’ll want to narrow it down to a time frame, sender, recipient, or action performed (delivered, rejected, etc.)  I have included these common search parameters, plus subject and sender IP.  Subject is a substring filter, and the start date and end date parameters are not mutually exclusive.

Speaking of dates, the API requires the format to be in epoch time (number of seconds since 1/1/1970, aka UNIX time).  To convert a .NET DateTime object to UNIX time, I use a method that was introduced in .NET 4.6.  If you aren’t using 4.6+, you can modify the Get-UnixTime function (at line 61) to calculate it using a time span, and there is link in the script for how to do that.  Furthermore, the script will account for time zone in the request and the response, so you can use “3/23/16 7:00 AM,” “3/23/16 7:00 AM -0700,” or “3/23/16 2:00 PM UTC” and get the same results, and the time stamp for each result will be in local time.

There are a number of properties for a record, so I only keep the ones that are relevant for normal queries.  These are time stamp, action, sender IP, sender, recipient, subject, RPD (anti-spam) score, SpamAssassin score, and description (why it was rejected or next hop information).  That’s still nine properties, too many to display in a table and see enough of the values to be meaningful, and I want the default output to be as a table.  So I specified the default properties to return five of the nine in a table.

How did I do that?  I created a custom formatting file (included in the download).  The file specifies that, for the custom type I assign to the record object, the default view is a table with five properties and specific widths for the columns, except for the subject which will fill the rest of the width.  To use the file, you need to run Update-FormatData .\TrackingInfo.format.psx1.  You will need to this once in each time you open a new shell.  You can add the command to your profile or even add the line to the script.  If you don’t use the formatting file, I still set a default property set in the script so the five properties are displayed, but the default will be in a list.  You, of course, can use standard format and export cmdlets to choose the properties displayed and how they are displayed.  So, if you want to see all properties, pipeline the results to, for example, Format-List -Property *.

The script’s code can be expanded and seen below, but you can download the script and the formatting file in the below attachment.

  Get-InumboTracking.zip (2.9 KiB)

Search mailboxes for large items that may impede migrations to Exchange Online

I have a customer that will be enabling hybrid mode soon and moving mailboxes to Exchange Online. One part of the project entails finding mailboxes that will not have a successful migration because they contain items over 150 MB. I referred them to the script on the TechNet Gallery that does exactly that. When that script was run against an admin’s mailbox, it took 10 minutes to complete. Extrapolating that single mailbox’s time for all 80,000 mailboxes (555 days) is far from accurate, but it does indicate that the process would likely take far longer than they have available to complete that part. (The extrapolation also doesn’t factor running multiple threads of the script.) So I looked at the script to see how it is doing what it does. It enumerates every folder, searches every folder for every item in it, then looks at the size of each item so it can report how many total items there are in each folder and how many are over the size limit.

So they could get results in far shorter time, I wrote a script that uses the EWS Managed API and leverages the hidden AllItems search folder created by Outlook 2010+ when it connects to a mailbox. Since it isn’t a well-known folder name, you have to find the folder first. The following code searches the root of the mailbox for a search folder (folder property type is 2) whose display name is AllItems:

What if the folder doesn’t exist? If Outlook 2010+ for Windows hasn’t been used against the mailbox, the folder won’t exist. If this is the case, the folder needs to be created. To determine the search restriction used for the folder when created by Outlook, I used MFCMAPI and saw that there is only one: the item has the message class property populated. To create the same search folder with EWS:

When you create a search folder you need to specify the folders to search and whether subfolders are included, the name of the folder, the search parameters (restrictions), and where to put it. In this case, the folder to search is the well-known folder MsgFolderRoot, which is the visible root folder in the IPM subtree, and subfolders are included by specifying a deep traversal. (This means the recoverable items folders are not included. If you want to include them, you can add to RootFolderIds with the well-known folder for Recoverable Items.) The search parameter is that the ItemClass property exists. (This translates to PR_MESSAGE_CLASS when viewed with MFCMAPI.) The folder is then saved in the root of the mailbox. The folder search can be run again to get the newly created folder.

To get a count of any items that are over 150 MB, do a search against that search folder using a query string. This type of search leverages the content index and is faster than using a search filter with a restriction. This search returns the count of any items over 150 MB, where $maxSize is an integer representing the limit in MB:

Putting this all together, the script takes an email address (or mailboxes or email addresses from the pipeline), looks for the search folder, creates it if missing and looks for it again, searches for any items in the search folder over a given size, and outputs an object with the email address, the number of items found, and any errors. Running it in the customer’s environment went from 10 minutes per mailbox to 14 mailboxes per minute. You can pipeline the output to CSV to use a source with the large item script from TechNet to get more details of which folder has the oversize items, etc.

For performance, the autodiscover URL of the first mailbox in the pipeline will be cached and used for subsequent mailboxes. Or you can specify a URL to use instead. The default item limit is 150 MB, but you can specify any size you want. There is a switch to use impersonation; otherwise, full mailbox access is needed. I found that you don’t need any permission to a mailbox in order to bind to the root folder, so if you then do a search for the search folder, you get the same result when there isn’t a folder or when you don’t have permission. Therefore, the script checks the account’s permission to the root folder (which is contained in the bind response). Depending on what you want to do with the output, such as feed it to the TechNet script, you can choose to not include mailboxes with 0 large items in the output with the appropriate switch. Lastly, since creating a search folder and waiting for it to initially be populated can take a little time, when a mailbox needs the search folder created and you want to know that it is doing so, use the Verbose switch to see that in the console.

You can download the script via the link below or expand and copy code:

  Get-MailboxLargeItemCount.ps1 (8.3 KiB)