Connecting to both ExO and SCC using the MFA-enabled PowerShell module

There seems to be an unfortunate issue with the recently updated Exchange Online PowerShell module that brings support for Modern authentication for the Security and Compliance Center cmdlets. Namely, the script’s Connect-EXOPSSession function, used to establish the connectivity for both the ExO and SCC parts, clears out every remote session upon execution.

In effect, this means that you cannot use the module to connect to both ExO and SCC remote PowerShell sessions at the same time. Any existing sessions are simply removed upon connecting to a new one. Or illustrated with a picture:

As the Connect-IPPSSession cmdlet calls the Connect-EXOPSSession one upon execution, the order in which you connect to both will not matter. If you want to connect to both session, you will have to use separate PowerShell instances. Or, make some changes to the underlying script (edit/comment line 173).

Alternatively, you can load the necessary module functions in your scripts and bypass the execution of the Connect-EXOPSSession cmdlet. I’ve alerted the corresponding teams at Microsoft so hopefully this hiccup will get looked at soon.

Posted in Exchange Online, Office 365, PowerShell | 2 Comments

Enforcing idle session timeout restrictions in SharePoint Online

So Ignite is over and now it’s time to catch up on all the cool new Office 365 and Azure AD features announced or showcased. One such cool feature is the ability to configure custom idle timeout window for SharePoint Online, as showcased in this session:

To configure the feature, you will need the latest version of the SharePoint Online Management Shell PowerShell module, which you can download here. Yes, it’s only configurable via PowerShell for the time being, by means of the Set-SPOBrowserIdleSignOut cmdlet. Here’s an example:

Set-SPOBrowserIdleSignOut -Enabled $true -WarnAfter (New-TimeSpan -Seconds 30) -SignOutAfter (New-TimeSpan -Minutes 1)

To check the settings, use:


Enabled WarnAfter SignOutAfter
------- --------- ------------
True 00:00:30  00:01:00

Once configured, any user that access a SharePoint Online resource will be subject to the new timeout, regardless of permissions, network location, device and so on. The only factor that has impact on this particular feature is the “Keep me signed in” checkbox. If it was ticked during login, you will be able to use SPO as usual. If the KMSI checkbox was not ticked, then you will be subject to the newly imposed restrictions.

Here’s how the end user experience will look like. If I configure the setting and navigate to any SharePoint Online site (a Group site in this example) and leave the window inactive for a while, I will be presented with the following warning:

Yes, it’s ugly, I know. But it gets the job done. If I press the continue button, I can continue working until the next time I leave the device idle for the warning period specified when configuring the feature. If I don’t do anything and the signout threshold is reached, I will be automatically redirected to the sign out page:

As mentioned already, this applies to all sessions, regardless of user, location or device. In fact, the above screenshots are taken with my global admin account. Only if you *did not* select the “keep me signed in” checkbox when logging in however. So the question then is, how can I make sure that my users cannot click this checkbox when logging in from shared devices?

You can prevent the “Keep me signed in” checkbox from being displayed by customizing the Azure AD branding: navigate to the Azure AD blade, select the directory in question, click on Company branding, create a new configuration or edit the existing one, then set the “Show option to remain signed in” toggle to No. Detailed instructions here.

But again we have a similar issue, as the branding changes will apply to all login attempts, regardless of user, location or device. One way to get around this is to use smartlinks, if you are in a federated scenario that is. You can simply add the “loginoptions” parameter to your smartlink and ensure that every login attempt using that link will not only be seamless SSO experience, but also will not be a subject to the idle controls configured above. If you need more info about smart links, check out this article.

Posted in Office 365, PowerShell, SharePoint Online | Leave a comment

Free eBook: Eradicating legacy Public folders

Public folders have existed for a long time now and many companies are facing challenges fitting them in the “digital workspace” vision. Microsoft hasn’t been particularly helpful in this regard, with no new client-facing functionality introduced to Public folders in over a decade. Even when a company decides to replace their Public folders with some of the new modalities available in Office 365, the migration tools offered by Microsoft leave a lot to be desired, and the situation with analyzing the hierarchy and making a proper decision on which target is most suitable is even worse.

In an effort to raise some awareness to the issues surrounding Public folders use in a modern world, myself, Dan Clark and Steve Goodman teamed up and published an independent eBook on the subject. Two other MVPs helped us in the process, namely Tony Redmond (editor of the eBook) and Siegfried Jagott (aka “Mr. Public folder”).

The eBook covers the history of Public folders, the most common usage case scenarios we have seen over the years, and the possible replacement features/products to consider. Moreover, we tried to include a comprehensive set of criteria, which one can use to evaluate whether a particular target, such as Office 365 Groups is a good choice for Public folder replacement. We also tried to include some bits on the analysis and migration tools offered by Microsoft, as well as coverage of some of the 3rd party tools available on the market.

You can download the eBook for free by registering at this address: Quadrotech has offered sponsorship, but other than that is not affiliated with the process in any form, so rest assured that this is not a marketing publication. Even though one of Quadrotech products is indeed mentioned in the eBook, this is only done in the context of the independent reviews section, authored by the well-known and respected MVP Steve Goodman. Alternatively, you can get the eBook directly at

If you do happen to read the book, feel free to give us feedback and recommendations!

Posted in Exchange Online, Office 365 | Leave a comment

Report on users connecting via RPC/HTTP in Office 365

By now, you should be well aware that Microsoft is planning to remove support for the RPC/HTTP protocol in Exchange Online, starting Oct 31, 2017. In case you’ve missed the announcement, multiple blog posts and the support article, you can find a nice summary for example here.

With less than two months remaining, most organizations have already moved away from older Outlook versions. If you are one of those that are yet to tackle the issue, there is some good news – Microsoft has released a report that should help you identify the users that are connecting to Exchange Online via RPC/HTTP. The report can be found under the Office 365 Admin Center -> Reports -> Usage -> Email app usage, or by clicking here.

Clicking the “Export RPC users” button will initiate a download of the CSV file, containing the needed information. Unfortunately, in my case there aren’t any details to show, as the tests I performed with older Outlook clients are yet to be reflected in the report (you can as well expect delays of few days, but after all it’s the historic data we’re most interested in). Rest assured though, the report works OK, as showcased by some good folks at Microsoft. Unfortunately, there seems to be no way to export this report via PowerShell or access it by any API.

There you have it! This has been a much requested functionality, as previously the only way to gather information about RPC/HTTP usage was indirect – one had to enable mailbox auditing and crawl the entries to gather the client version. Connecting with specific Outlook version itself doesn’t necessarily indicate that the user will be affected, but at least gives you a clue on which users to focus.


Update: here’s a screenshot of the report

Posted in Exchange Online, Office 365 | 2 Comments

Security and Compliance Center PowerShell finally supports Modern authentication

Modern authentication, ADAL or MFA are all different things, but often used to designate the same scenario – using additional authentication factor when logging in to Office 365. Generally speaking, the added security is a great thing, especially important for any privileged accounts. The different teams at Microsoft however have been very slow to adopt this new trend, and Office 365 administrators had to make compromises with security, simply because some of the modalities did not support Modern authentication.

Well, slowly but surely the different PowerShell modules have been updated and now we finally have MFA support for the Security and Compliance Center (aka Protection Center) PowerShell cmdlets as well. It is delivered as part of the new, MFA-enabled Exchange Online PowerShell module, which I blogged about almost an year ago. Those of you that have used the ExO PowerShell module know that it’s delivered as click-once application, which updates automatically, and might have noticed that the latest version introduced a new cmdlet, namely Connect-IPPSSession.

The cmdlet is a simple wrapper function that gets an authentication token from Azure AD and passes it to the New-PSSession cmdlet in order to create a new remote PowerShell session to the Security and Compliance Center endpoint, Which means, you can simply do the steps yourself, following the approach I outlined here.

Or, simply use the shortcut you get on your desktop after installing the tool. You can download it from the Exchange Admin Center, Hybrid tab, or directly via Here’s how a connected session will look like:

So there you have it, the SCC PowerShell module is the last to get support for Modern authentication, which in turn means there are no reasons left to not protect all your administrative accounts with Azure MFA or any other form of multi-factor auth!

Posted in Uncategorized | Leave a comment