Multi-Tenant Administration

Posted on November 4, 2018 by Michel de Rooij

Note: When writing this blog, the Azure portal received an update which allows for switching directories. Unfortunately, this feature hasn’t been ported to the other Office 365 admin UI’s at this moment.

Being a consultant, you often find yourself having to switch tenants, or having to keep multiple admin portals open to different Office 365 tenants. This may become a nuisance, as you can use only a single set of credentials per browser instance. In other words, if you connect to the Office 365 admin portal using credentials A, opening up the Azure portal will be in the same context.

A typical workaround for this situation would be to open up a new private browser session. From that private browser session, you need to provide credentials B. Any new tabs in that private window will also be in the same context. The whole private session is hosted in a new window.

A more neat solution for this scenario is leveraging browser containers, such as:

Notes:

This blog is written based on Firefox Multi-Account Containers, so your mileage may vary if you’re using Chrome or a 3rd party add-on.
Firefox also supports a basic version of context switching natively via about:config, setting privacy.userContext.enabled.
I’m not aware of similar features or 3rd party add-ons for other browsers.

Unlike the Chrome extension, FireFox’ Multi-Account Containers allows you to have multiple sessions from within the same browser. For this purpose, tabs are used to arrange sessions in what’s called containers. Each container shares the same set of site preferences, sessions, cookies etc. To identify containers, they can be assigned a (new) name, color and symbol.

After installing the add-in, you will get a button that will open the container selection window. In this example, I have set up 4 containers besides the default ones: one for every customer and one for my lab. Selecting Contoso will open a new blank tab. The right side of the address bar contains a visual reference to the active container, showing label and symbol in the configured color.

Keep Me Signed In Now, when you go to portal.office365.com, the Office 365 account picker may show up when connected before using this container. Pick one, or enter a new set of credentials. This account will be stored in this container. The question of wanting to stay signed in makes more sense now, as the token will be stored within the container, happily coexisting with other Keep-Me-Signed-In settings and sessions from other containers.

Now, when you open a different admin app in that tab, it will be in the same container and thus user context. You can also select to open a blank tab in that container, and navigate to portal.azure.com. You will notice it picks up the Contoso credentials provided earlier. This is because the session information is stored within the Contoso container.

Now click the container icon again, and select a different container, e.g. Fabrikam. Navigate to portal.office365.com, and you will notice you can provide new (or re-use) credentials which have a different context than Contoso. Also, opening the Azure portal after that in this container will be in the Fabrikam context.

Having set this up properly, you can easily switch between all admin portals from different tenants by selecting the different container tabs: no need to switch accounts or firing up separate private browser windows. This is a more elegant solution compared to private browsing sessions.

A final note that the above not only can be used to access the Office 365 admin portals of multiple tenants, but web-based applications such as Teams, Outlook Web Access or SharePoint as well.

Hybrid Configuration Wizard & F12

Posted on September 27, 2018 by Michel de Rooij

A small tip for those running the Exchange Hybrid Configuration Wizard. As announced at Ignite yesterday, a convenient feature was added to the HCW and is available now. Pressing F12 in the HCW will now open up a panel with shortcuts to the following tools and locations:

Exchange Management Shell
Exchange Online PowerShell
(current) Hybrid Configuration Wizard Log File
Create Support Package (to zip HCW logs for support)
Open Logging folder (of HCW)
Open Process Folder (of the HCW app)

Here is how it looks:

This might save you an occasional click or two.

Support Lifecycle changes for Office ProPlus & 2016 (a.o.)

Posted on September 7, 2018 by Michel de Rooij

Outlook 2013 Icon In a surprise – but welcomed – move, Microsoft announced yesterday that the office support lifecycle for Office 365 ProPlus on Windows 8.1 and Windows Server 2016 are extended to January 2023 (EOL of Windows 8.1) and October 2025 respectively. In addition, Office 2016 connectivity support for Office 365 services will be extended to October 2023 (was 2020).

Other announced changes in product support lifecycles were extending Windows 10 Enterprise & Education support from 18 to 30 months. Also, for Windows 7 Professional & Enterprise, paid security updates (Extended Security Updates) will be offered, and those Windows 7 ESU devices will be supported through January 2023 – parallel to Windows 8.1 – with Office 365 ProPlus.

The intention of these changes is to provide customers more flexibility in adopting modern desktops on the client end (i.e. Windows 10) and upgrade their Office suite, preferably to the susbscription-based ProPlus. The release cadence of the cloud has significant impact on organizations, which were told in February to keep in line with product releases as a lot of product support lifecycles were going to end in 2020.

Extending those dates not only gives them more flexibility to plan and upgrade, but also might prevent organizations to do only to the minimum, which is likely the reason many organizations are still on Windows 7 and why it took many organizations a long time to get rid of Windows XP.

Exchange Mailboxes and Signatures

Posted on March 16, 2018 by Michel de Rooij

vote! One of the longest standing requests of the community regarding Exchange features is the request to have the ability to share e-mail signatures between Outlook for desktop, Outlook Web Access (OWA) and mobile clients like Outlook for iOS. Several 3rd party vendors have been filling this gap with solutions with the possibility of adding standardized signatures on the transport layer or through application add-ins for the WYSIWYG approach.

The Outlook products don’t share signatures; Outlook Web Access does store the signature in a so-called Folder Associated Item (FAI) in the mailbox, making the signature persist when moving the mailbox around. But that unfortunately is only for Outlook Web Access; Outlook for desktop signatures are stored in files in one’s user profile, and Outlook for iOS only allows you to configure a single line, which often is used to apologize for any typos in the message, more common when using mobile devices, by setting it to ‘Mail sent using mobile’ or text of similar nature.

However, after a recent discussion with the relevant product groups by Jeff Guillet, the product groups challenged MVPs that there is indeed a significant demand for this feature by getting people to vote on UserVoice. Jeff with the MVPs designed a functional specification for this feature, which will be shared with the product groups at a later date. There is no reason why we can’t expect this feature to work for both Exchange Online as well as Exchange on-premises. Part of the request will also be to be able to manage the signature through PowerShell, similar to how the Outlook Web Access signature can now be managed using Set-MailboxMessageConfiguration.

So, power to the community and get your voice heard if you want this feature. You can vote on UserVoice here. Thank you.

Comparing Sets of Cmdlets

Posted on March 12, 2018 by Michel de Rooij

powershell With the speed of development in Office 365, it is sometimes hard to track which changes have been made to your tenant. Of course, there is the roadmap and message board which you can use to keep up to date, but those are in general high level descriptions. Sometimes you may want to see what are the changes at the cmdlet level in your tenant, between tenants, or Azure Active Directory module. And there is also the occasional gem in the form of a yet undocumented cmdlet or parameter which could hint at upcoming features.

For this purpose I have created a simple script which has two purposes:

Export information on the current cmdlets available through Exchange Online or Azure Active Directory.
Compare two sets of exported information, and display changes in a readable way.

The script is in PowerShell (of course), and is called Compare-Cmdlets.ps1. To export information, you need to be already connected to either Exchange Online or Azure Active Directory (or both).

To export cmdlet information, use:

.\Compare-Cmdlets.ps1 –Export

For Exchange Online and Azure Active Directory, separate export files are created. The files are prefixed with a timestamp and postfixed with the Exchange Online build or Azure Active Directory module version, e.g. 201803121814-ExchangeOnline-15.20.548.21.xml or 201803121815-AzureAD-2.0.0.137.xml.

After a few days/week, or when connected to another tenant or using a new Azure Active Directory PowerShell module, run the export again. You will now have 2 sets of Exchange Online or Azure Active Directory cmdlets, which you can compare using the following sample syntax:

Compare-Cmdlets.ps1 -ReferenceCmds .\201801222108-ExchangeOnline-15.20.428.21.xml -DifferenceCmds .\201803120926-ExchangeOnline-15.20.548.21.xml

A progress bar is shown as comparison might take a minute. When the script has finished checking the two sets, you will see output indicating changes in cmdlets, parameters or switches, e.g.