If the result from the above is “Investigate” then you will not be able to complete the move even if you set the usual properties of -PreventCompletion $false and -CompleteAfter 1, that is – the following will not work:
Upon running the above (the move request will auto resume in my tests), the move will start to complete if completion is allowed (the cmdlets at the top of the post). Obviously you will want to check why there are a number of bad items in the move and what you are going to try and do to fix them.
The SkippedItemApprovalTime property approves all bad items detected before the specified time. So in the above example we are approving all bad items to be discarded that were found before “now”. You could set an earlier specific time as well.
You now do not need to set a bad item limit (BadItemLimit) value as you are approving items by time instead.
With Teams (and Zoom, and probably other video conferencing apps) as well as apps that add to the live camera image such Chromacam and Snap Camera in popular use, you might have noticed that all the example backgrounds have no text on them.
So what happens when you or your company roll out a set background to use that does contain text – for example, this mockup image:
Teams Background With Added Text
Now my graphics editing skills are not great, but this is just one of the included background images that come with Microsoft Teams and a logo added as if it were a picture on the wall.
So what happens when I use this as my custom background in Teams (or Zoom etc.) – the following is what I see:
Teams (Presenter View) on Desktop with Text In Background Meeting
You can see that in the view of the background I can see the text is back to front. This is correct, as the view from my camera that is presented back to me is usually mirrored for my convenience. This is because they way I see myself is in a mirror, and so to show me “unmirrored” so to speak would look odd to me. Also if I raise one hand or move to one side, the mirrored image of me from my camera shows this happening on the side of the screen I would naturally expect it to be on.
The downside of this is that any text we add to background images will appear back to front for us – but it will appear correct to all attendees, as the Teams will not show the attendees the mirrored image. Just as we expect to see a mirror image when looking at ourselves, others who look at us do not expect to see that, and the video conferencing apps will not show that to them – so they see your logo, or text or whatever, correctly as you intended.
Teams (Attendee View) on iPhone, with text the correct orientation
With the sudden change in working practices, a (large) number of companies has start to use Zoom as their video conferencing software. Though this software is not from Microsoft, that does not stop an Office 365 or Exchange Server administrator helping their users out in terms of scheduling Zoom meetings via an add-in in Outlook.
On the Zoom website the user can download and install their own add-in and the Zoom application, but the steps below will push the Outlook add-in to all users (or all Zoom users if you have a group containing just these users).
These steps are run from the Office 365 Admin Center and not from Zoom, and they push the add-in to Outlook without end end-user interaction
To deploy an add-in, and in this case the Zoom Outlook add-in, first go to the Microsoft 365 Admin Center at https://admin.microsoft.com/.
Click Show All on the left and then select Settings > Add-ins from the expanded menu.
In the Add-In main page click + Deploy Add-In.
Deploy Add-In Screen
This screen outlines the Centralized Deployement service for Office Web add-ins. These add-ins work across the web version of the application, the desktop versions (PC and Mac) and in some cases the mobile version as well. The important thing to learn here is that they are not just for the web version, so not just for OWA. In the context of the Zoom add-in, on the Zoom website it says the add-in only works in Outlook for the Web (OWA), and this is not correct.
Click Next and click Choose from the Store as shown:
Deploy A New Add-In Screen
You will now see a list of all the add-ins in the Microsoft Store (once you have logged into the Store if you needed to do this).
Select Add-In From Store
As we are discussing the Zoom for Outlook add-in at this point, type Zoom in the Search box.
Zoom for Outlook Add-in In the Add-In Store
Click Add next to the Zoom for Outlook add-in. Then accept the licence terms and privacy policy shown to you as shown below. If you click on the title of the add-in then you see a description of the add-in and can complete deployment from that screen.
Zoom for Outlook License Terms and Privacy PolicyZoom for Outlook Details
If after clicking Add and accepting the licence you get a correlation error similar to that shown, it means the add-in was already deployed. There is a bug in the new Admin Center that does not show existing deployed add-ins and you need to go to the old old Office 365 admin center (switch the slider top right) and search for the add-in:
Configure Add-In ErrorZoom for Outlook Add-In Shown in Old Admin Center
If you had no error on deploying the add-in, then you will be asked who to deploy the add-in to. The options are to Assign Users and choose all or some of the organization and also the Deployment Method and Fixed, Available or Optional. This last option controls whether the add-in is deployed for the user to the ribbon in the Office application and they cannot remove it (Fixed), where the user can choose to add the add-in to the office app (Available), or where the add-in appears on the application ribbon, but the user can remove it (Optional). This is shown below:
Configure Zoom for Outlook Add-In
Select your user and deployment options. For users, any group cannot be a nested group and the requirements for groups is covered in the documentation. For this blog post I selected Everyone and Fixed. Click Deploy to start the deployment to the users.
Deploy Zoom for Outlook
The listed time is dependent upon the number of users in your deployment scope or your Office 365 tenant. You will get an email upon completion.
Once completed the add-in appears in the Office application. In this particular case, Zoom for Outlook appears in the New Appointment window in Outlook.
If you deployed the add-in as Available then the user needs to click the Get Add-In button in Outlook to install Zoom as shown:
Admin Add-Ins
Once the add-in is deployed, it will appear in the New Appointment screen as shown (on the right):
Zoom for Outlook Add-In in New Appointment
Clicking the Add a Zoom Meeting button will present a dialog box where you can login with your Zoom account or if you have set up Zoom as an Enterprise Application then click the Sign in with SSO button.
In the below screenshot, Outlook Appointment shows the Zoom meeting details automatically added. The HTML view for the meeting details is an option available in your Zoom account settings, as is the location for your audio dial in settings (here shown as UK) as you don’t get to choose these options per meeting as you can do when meetings are made via the web browser on the Zoom site.
The Settings button on the tool bar allows you to control other meeting settings such as Meeting ID (personal or auto-generated), password or not!, and video and audio settings for the meeting.
Zoom for Outlook Settings
To edit the Add-In deployment you need to visit the old Microsoft 365 Admin Center (switch off “Try new admin center” to top right of admin center). From here you can adjust the status of the add-in and who it is deployed to, as well as removing the add-in.
Zoom for Outlook Add-In Settings (old Office 365 Admin Center)
Finally, for info, the Teams Add-in to do the same thing in Teams is automatically added to Outlook if you have the Teams client installed and your deployment option is not Skype for meetings – for example if you are in Islands Mode you will be able to see both Skype and Teams buttons in Outlook!
Or, how to run a Microsoft Teams Live Event with average technical capability presenters, or how to run a Microsoft Teams Live Event for events that you would not normally consider this service for!
So with this title and alternative titles in mind we are going to look at how I set up and ran a Microsoft Teams Live Event for a weekly church service because access to the church building was closed due to social distancing because of the SARS-CoV-2 (Covid-19 Coronavirus global outbreak). The previous week at church we ran a YouTube live streaming event as we could get access to the church building and we needed five people to put the service together (preacher, piano player, camera operator, sound desk and computer [for hymn words] operator). The second week of self isolation, government rules made this method of live broadcast impossible. So we turned to Microsoft Teams Live Events.
Microsoft Teams Live Events requires an Office 365 E3 or higher licence. The other requirements are that the producer(s) role and the presenters need to install Microsoft Teams and have a login to your tenant, but the attendees do not need a licence at all (as this particular Live Event will be open to anonymous attendees).
So how do we put this together:
Set up the live event and a practice live event (as you cannot reuse a live event twice, so set up at least one practice event as well)
Publish your event on your church website, and if interested use a URL shortening service that you can update (we use https://rebrand.ly) as this gives you click count and geo-location of the audience. Our first live event had attendees in India, northern Africa, and North and South America (as well as the UK where the church is based).
Have all presenters arrive early to the live event (we went for 30 minutes) and aim to go live around 10 minutes before the actual event
Have a collection of presenters for different roles – in social isolation it is of great benefit to see many different people taking part in the church event rather than it being run by one preacher
Audio is open from all presenters unless they are muted – this allows the attendee to hear more than one person in different locations at the same time – this allowed us to have a pianist 15 miles from the person displaying the hymn words on the screen.
Create a Teams Live Event
To create a live event open the Teams app or website and go to the Calendar component.
To the top right, click the down arrow next to New Meeting and choose Live Event:
Fill in the details for the Live Event. This will include a title, a location (which we will leave blank due to self isolation!) and a start and end time. The start time should not include the pre-show preparation by the presenters and does not need to include time for the pre-event greeting which we will discuss below. So in our example here, church starts at 10:30am on a Sunday so that is the start time for the event.
Also invite the presenters. You can come back and edit this information later and add and remove presenters as the event information changes regarding what and who is going to be involved in the event.
Click Next and then select your audience. In our case this is an anonymous audience:
Scroll down in the New Live Event dialog and ensure that you select Recording available to all attendees (this allows attendees to watch the event at a later time on the Teams Live Event URL). Ensure that you pick the translations that support your expected audience and choose the Audience Engagement Report to be able to download a list of attendees who signed in after the event.
Click Schedule to create the Live Event. This sends the invitation to your other presenters and producers.
You then see the following dialog:
From the above you grab the attendee URL, which we will use in the next section and also from here you can edit the live event. You can return to this dialog box if you open the event later from your calendar in Teams (remember to show “Whole Week” from the calendar view as it just shows “Working Week” by default).
URL Shortening
Your live event is now created and its time to tell the audience how to get to the event. The below is what the Teams Live Event URL looks like (this below will not work):
We used a URL shortening service where we could send the attendees a single URL that we updated the target of each Friday or Saturday. We do not update the URL shortener link earlier in the week as the attendee can click the link after the Sunday and watch the event again or maybe for the first time. We did not use Bitly for link shortening as we could not update the link target without buying an expensive package.
So our church service can be reached at https://rebrand.ly/wrbcliveevent. We also placed this link on our website and wrote instructions on how to connect to the event and this is at https://wrbc.org.uk/live/ so that the user has some advice on how to connect as well (for example, mobile apps need the Teams app installed, but PCs can view the event in a modern browser).
Presenter Practice
I highly recommend running a presenter practice. In our example of a church service we wanted the ability to play music via a keyboard and to wire that keyboard into the PC that was running Teams. During practice for the first week we were unable to do this because of a suspicious device driver that impacted the ability to connect in a audio source via Line In. So in practice we decided just to place the PC near the piano and audio quality was acceptable but not great. We left this to fix for the second week!
Presenter practice also allows each presenter to get familiar with the application and what they see on the screen. For example in our case I as the producer was also sharing my second monitor to show the hymn words in our projection software (not PowerPoint). Each presenter could see my second monitor image large and the live view quite small (as can be seen below) which caused some questions during the rehearsal, and I as the producer could see something else (producers can see the live screen and the queued video image).
Above is an example of what a presenter can see when the producer is sharing content. You can see the minature video streams for the other presenters and the yellow “pre-live” notice. Once the session goes live (again this was a practice session), the presenters can see the following:
Now there is a red “live” notice on the control bar and the image that is live is shown boxed in red.
On the producers screen they can see each video feed at the bottom and have the ability to share an app or desktop. During practice we shared the second desktop with the plan to run our hymn projection software (Zionworx) but as this has a control application on screen one and display on screen two it was too busy to try and do that and the Teams live meeting production – so during rehearsal we decided to have all the hymns and other slides (welcome, sermon, notices, reading and exit slide) as a single PowerPoint with presentation viewer option turned off (so running only on the second screen and press enter to move to next slide). This is what the producer could see:
Here you can see we are pre-live (yellow) and we can see the final attendee view to the bottom right as well as each video feed and the mute status of each presenter – the producer can mute (but not unmute) presenters. The content (producers second screen) can be seen on the right of the video feed screens.
Going Live
The plan for the live event was that all presenters would be online 30 minutes before the service start time, and that at 10:20 (10 minutes before start time) we would “go live”. At this point all presenters where muted and ensured the holding slide in PowerPoint was displayed on the right-hand view. It looks like this:
To get the PowerPoint presentation as a valid source of data you click the Share button on the bottom row and choose the application to share. We decided during the practice that we would share only PowerPoint and have a single slide desk for the whole service rather than sharing individual different presentations. The slides where structured in order, notices and hymns as required. We did not use PowerPoint Presenter View, as that would appear on the monitor that Teams Live Event controller was running on. So in turning off Presentation View all I needed to do was Alt+Tab between the Live Event (Teams app) and PowerPoint and press Enter to move to the next slide in time with the pre-planned order of service.
At five minutes to the start the pianist unmuted her Teams client and started to play some music. This ensured that attendees could both see and hear audio – we briefly swapped video feed to the pianist so that people knew they should be hearing something. This meant that attendees could be sure they were looking at the pre-start notice and that their volume was up.
At 10:29am we went live (there is about a minutes delay to the attendees but real time between the presenters, so this meant we started on time!)
To go live we clicked the Content option on the bottom row – this added it to the Queue (left larger video window) and we clicked “Send live” to place it on the right. We then clicked the video feed of the service leader and this added him to the Queue – this is what you can see above. At the start time we just clicked “Send live” – the pianist stopped and muted herself, the leader was unmuted in advance (but kept quite) and the producer (my role) used hand signals to indicate they were live – the leader and I were about a mile apart, the preacher was eight miles away and the pianist 15 miles away – hand signals via my video feed worked great as a way to communicate.
As each part of the service progressed, I added the next video or PowerPoint content to the queue on the left and sent it live as I needed to.
Finishing and Downloading Recordings
The service went fine, a few people had issues connecting that we later worked out to be issues installing apps on phones (no Apple account set up or credit card saved with Google, and both of these stop you installing any app) and one person had issues with Internet Safety software blocking the Rebrandly URL shortner service! We recommend that you get people to attempt to join the service in the days before Sunday so that they can follow up issues that they have rather than trying one device at the start time on the Sunday and giving up disappointed that it did not work for them.
Once the service finished we placed the final thank you slide on the screen and stayed muted for about 1 minute and then clicked “End”. This finishes the live event and after this point it cannot be restarted – so you need to confirm you really want to end the event. Don’t click Leave at the top as that pauses the event if there are no producers online.
The automatic recording is stopped and all the presenters can talk freely. We each left the meeting and a few hours later I came back and downloaded the recording along with the attendance engagement report. This showed the times people connected and who had a dodgy connection and kept needing to reconnect. If the user is logged into Teams it shows the username as well.
The video stream was then uploaded to our YouTube channel so that anyone who could not connect still had a way to listen to the service, though not in real time.
Now all ready to repeat this next week! And each week until self-isolation in the UK is lifted…
This is a new feature in Office 365 Advanced Threat Protection Plan 2 in addition to Safe Attachments. Safe Documents at the time of writing is only available in US based Office 365 tenants and only used by Office 365 ProPlus 2002 Monthly Channel (Targeted) builds (build 12527.20092) and later.
When a user receives an Office document from an external source the document is marked as such and can only be opened in “protected mode”. This stops editing and printing, but also (more importantly) stops macros and the like running as well. This reduction in functionality of editing and printing is enough for the user to often just take the document out of protected mode and impact your network.
When the document is emailed to the user, Office 365 ATP Safe Attachments (a Plan 1 feature) will process the document, but if the document is obtained another way, such as via a download link or copied onto a local file share, but is an externally sourced document, then the Safe Attachments vector of protection over email no longer applies.
This is where this new feature of Safe Documents comes into play. The entire document is uploaded to Microsoft’s datacentre and processed as if it where an attachment in email being processed via Safe Attachments.
An EU/UK datacentre version of this feature will come in due course.
What now happens is that the document is scanned in the cloud for “maliciousness” and the user is allowed to open the file and turn off “protected mode” only if the document is considered safe. If the document is considered malicious then the user is not allowed to take the document out of “protected mode”.
This functionality was announced at Microsoft Ignite in November 2019 and is now in early preview at the time of writing this article. Future updates to this functionality will include the ability to open “protected mode” documents in a virtual machine automatically so that if the document does go rogue then closing the document results in closing the virtual machine and the removal of the impact, as all the changes were confined to the virtual machine. This feature is due Summer 2020 and is known as Application Guard for Office ProPlus. Application Guard will be included in subscriptions that include Windows 10 E5 (Windows 10 + Microsoft Defender Advanced Threat Protection).
Come Feb 29th 2020 and Microsoft are turning off the baseline security policies. If you used these policies to do MFA for all admins (as that was an easy way to achieve this), then a replacement Conditional Access rule might cause errors with AADConnect.
The reason being is that you could create a new Conditional Access rule that stops all administrative roles from logging in unless they perform MFA. The AADConnect service sync account is an account that is created for you automatically by AADConnect in Azure AD and it has some special admin roles – but cannot operate with MFA enabled.
If your MFA Conditional Access rule (or Admin only from Compliant Devices or similar type of rule) does not exclude the sync account then expect sync to stop working. It will stop with MA errors on the connection to Azure AD and if you run Start-ADSyncSyncCycle you get the following error message about a modal dialog box or form when the application is not running in UserInteractive mode.
The fix is to add the sync account to the group that contains your break glass accounts, so that you bypass MFA for this account. If you do not have a break glass account then make one, and ensure it and the sync account bypass MFA or other limiting conditional access rules. The sync account is called “On-Premises Directory Synchronization Service Account” and is named sync_computername_uniquestring@tenant_domain.
The full error message for a search engine to find and bring you here is:
Windows PowerShell
Copyright (C) 2014 Microsoft Corporation. All rights reserved.
PS C:\Users\administrator> Start-ADSyncSyncCycle
Start-ADSyncSyncCycle : System.Management.Automation.CmdletInvocationException: System.InvalidOperationException:
Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the Service Notification or DefaultDesktopOnly style to display a notification from a service
application. at
Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Platform.WebUI.<AcquireAuthorizationAsync>d__12.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenInteractiveHandler.<AcquireAuthorizationAsync>d__11.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenInteractiveHandler.<PreTokenRequestAsync>d__10.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenHandlerBase.<RunAsync>d__57.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.<AcquireTokenCommonAsync>d__39.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.<AcquireTokenAsync>d__30.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AuthenticateADAL(String userName,SecureString password, Azure Service azureService, Boolean useCachedToken, String& accessToken, String& adalErrorType,String& additionalDetails, Boolean throwOnException) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AcquireServiceToken(AzureServiceazureService, String userName, SecureString password, String& serviceEndpoint, String& additionalDetail,AuthenticationStatus& status, Boolean throwOnException) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AcquireServiceToken(AzureServiceazureService, String& service Endpoint, String& additionalDetail, AuthenticationStatus& status, BooleanthrowOnException) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AcquireServiceToken(AzureServiceadalResource, String& additionalDetails, Boolean throwOnException) at Microsoft.Online.Coexistence.ProvisionHelper.GetSecurityToken() at Microsoft.Azure.ActiveDirectory.Synchronization.ProvisioningWebServiceAdapter.ProvisioningWebServiceAdapter.InitializeProvisionHelper() at Microsoft.Azure.ActiveDirectory.Synchronization.ProvisioningWebServiceAdapter.ProvisioningWebServiceAdapter.Initialize() at Microsoft.Azure.ActiveDirectory.Synchronization.ProvisioningWebServiceAdapter.ProvisioningWebServiceAdapter.GetCompanyConfiguration(Boolean includeLicenseInformation) at Microsoft.Azure.ActiveDirectory.Synchronization.AADConfig.get_CloudEnforcedSyncSchedulerInterval() at Microsoft.MetadirectoryServices.Scheduler.SchedulerSettingUtilities.get_CurrentSchedulerSettings() at SchedulerUtils.GetCurrentSchedulerSettings(SchedulerUtils* , _ConfigAttrNode* pcanList, UInt32 ccanItems, Char**syncSettingsSerialized, Char** errorString) —> System.InvalidOperationException: System.InvalidOperationException:Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service
application. at
Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Platform.WebUI.<AcquireAuthorizationAsync>d__12.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenInteractiveHandler.<AcquireAuthorizationAsync>d__11.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenInteractiveHandler.<PreTokenRequestAsync>d__10.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenHandlerBase.<RunAsync>d__57.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.<AcquireTokenCommonAsync>d__39.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.<AcquireTokenAsync>d__30.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AuthenticateADAL(String userName,
SecureString password, AzureService azureService, Boolean useCachedToken, String& accessToken, String& adalErrorType,String& additionalDetails, Boolean throwOnException) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AcquireServiceToken(AzureServiceazureService, String userName, SecureString password, String& serviceEndpoint, String& additionalDetail,
AuthenticationStatus& status, Boolean throwOnException) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AcquireServiceToken(AzureServiceazureService, String& serviceEndpoint, String& additionalDetail, AuthenticationStatus& status, BooleanthrowOnException) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AcquireServiceToken(AzureService
adalResource, String& additionalDetails, Boolean throwOnException) at Microsoft.Online.Coexistence.ProvisionHelper.GetSecurityToken() at Microsoft.Azure.ActiveDirectory.Synchronization.ProvisioningWebServiceAdapter.ProvisioningWebServiceAdapter.InitializeProvisionHelper() at Microsoft.Azure.ActiveDirectory.Synchronization.ProvisioningWebServiceAdapter.ProvisioningWebServiceAdapter.Initialize() at Microsoft.Azure.ActiveDirectory.Synchronization.ProvisioningWebServiceAdapter.ProvisioningWebServiceAdapter.GetCompanyConfiguration(Boolean includeLicenseInformation) at Microsoft.Azure.ActiveDirectory.Synchronization.AADConfig.get_CloudEnforcedSyncSchedulerInterval() at Microsoft.MetadirectoryServices.Scheduler.SchedulerSettingUtilities.get_CurrentSchedulerSettings() at SchedulerUtils.GetCurrentSchedulerSettings(SchedulerUtils* , _ConfigAttrNode* pcanList, UInt32 ccanItems, Char**syncSettingsSerialized, Char** errorString) at Microsoft.DirectoryServices.MetadirectoryServices.UI.WebServices.MMSWebService.GetSchedulerSettings(String&settingsDeserialized, String& errorString) at Microsoft.IdentityManagement.PowerShell.Cmdlet.GetADSyncScheduler.ProcessRecord() — End of inner exception stack trace — at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input) at System.Management.Automation.PowerShell.Worker.ConstructPipelineAndDoWork(Runspace rs, Boolean performSyncInvoke) at System.Management.Automation.PowerShell.Worker.CreateRunspaceIfNeededAndDoWork(Runspace rsToUse, Boolean isSync) at System.Management.Automation.PowerShell.CoreInvokeHelper[TInput,TOutput](PSDataCollection`1 input,PSDataCollection`1 output, PSInvocationSettings settings) at System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1output, PSInvocationSettings settings) at System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings) at Microsoft.Online.Deployment.PowerShell.LocalPowerShell.Invoke() at Microsoft.Online.Deployment.PowerShell.PowerShellAdapter.TypeDependencies.InvokePowerShell(IPowerShellpowerShell) at Microsoft.Online.Deployment.PowerShell.PowerShellAdapter.InvokePowerShellCommand(String commandName,InitialSessionState initialSessionState, IDictionary`2 commandParameters, Boolean isScript) at Microsoft.Azure.ActiveDirectory.Synchronization.PowerShellConfigAdapter.SchedulerPowerShellAdapter.GetCurrentSchedulerSettings() at Microsoft.MetadirectoryServices.Scheduler.Scheduler.StartSyncCycle(String overridePolicy, BooleaninteractiveMode) at SchedulerUtils.StartSyncCycle(SchedulerUtils* , Char* policyType, Int32 interactiveMode, Char** errorString)
At line:1 char:1
+ Start-ADSyncSyncCycle
+ ~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : WriteError: (Microsoft.Ident…ADSyncSyncCycle:StartADSyncSyncCycle) [Start-ADSyncSyncCycle], InvalidOperationException + FullyQualifiedErrorId : System.Management.Automation.CmdletInvocationException: System.InvalidOperationException : Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application. at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Platform.WebUI.<AcquireAuthorizationAsync>d__12.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenInteractiveHandler.<AcquireAuthorizationAsync>d__11.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenInteractiveHandler.<PreTokenRequestAsync>d__10.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenHandlerBase.<RunAsync>d__57.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.<AcquireTokenCommonAsync>d__39.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.<AcquireTokenAsync>d__30.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AuthenticateADAL(String userName, SecureString password, AzureService azureService, Boolean useCachedToken, String& accessToken, String& adalErrorType, String& additionalDetails, Boolean throwOnException) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AcquireServiceToken(AzureService azureService, String userName, SecureString password, String& serviceEndpoint, String& additionalDetail, AuthenticationStatus& status, Boolean throwOnException) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AcquireServiceToken(AzureService azureService, String& serviceEndpoint, String& additionalDetail, AuthenticationStatus& status, Boolean throwOnException) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AcquireServiceToken(AzureService adalResource, String& additionalDetails, Boolean throwOnException) at Microsoft.Online.Coexistence.ProvisionHelper.GetSecurityToken() at Microsoft.Azure.ActiveDirectory.Synchronization.ProvisioningWebServiceAdapter.ProvisioningWebServiceAdapter. InitializeProvisionHelper() at Microsoft.Azure.ActiveDirectory.Synchronization.ProvisioningWebServiceAdapter.ProvisioningWebServiceAdapter. Initialize() at Microsoft.Azure.ActiveDirectory.Synchronization.ProvisioningWebServiceAdapter.ProvisioningWebServiceAdapter. GetCompanyConfiguration(Boolean includeLicenseInformation) at Microsoft.Azure.ActiveDirectory.Synchronization.AADConfig.get_CloudEnforcedSyncSchedulerInterval() at Microsoft.MetadirectoryServices.Scheduler.SchedulerSettingUtilities.get_CurrentSchedulerSettings() at SchedulerUtils.GetCurrentSchedulerSettings(SchedulerUtils* , _ConfigAttrNode* pcanList, UInt32 ccanItems, Char** syncSettingsSerialized, Char** errorString) —> System.InvalidOperationException: System.InvalidOperationException: Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a va lid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application. at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Platform.WebUI.<AcquireAuthorizationAsync>d__12.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenInteractiveHandler.<AcquireAuthorizationAsync>d__11.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenInteractiveHandler.<PreTokenRequestAsync>d__10.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenHandlerBase.<RunAsync>d__57.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.<AcquireTokenCommonAsync>d__39.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.<AcquireTokenAsync>d__30.MoveNext()
— End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AuthenticateADAL(String userName, SecureString password, AzureService azureService, Boolean useCachedToken, String& accessToken, String& adalErrorType, String& additionalDetails, Boolean throwOnException) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AcquireServiceToken(AzureService azureService, String userName, SecureString password, String& serviceEndpoint, String& additionalDetail, AuthenticationStatus& status, Boolean throwOnException) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AcquireServiceToken(AzureService azureService, String& serviceEndpoint, String& additionalDetail, AuthenticationStatus& status, Boolean throwOnException) at Microsoft.Online.Deployment.Client.Framework.AzureAuthenticationProvider.AcquireServiceToken(AzureService adalResource, String& additionalDetails, Boolean throwOnException) at Microsoft.Online.Coexistence.ProvisionHelper.GetSecurityToken() at Microsoft.Azure.ActiveDirectory.Synchronization.ProvisioningWebServiceAdapter.ProvisioningWebServiceAdapter. InitializeProvisionHelper() at Microsoft.Azure.ActiveDirectory.Synchronization.ProvisioningWebServiceAdapter.ProvisioningWebServiceAdapter. Initialize() at Microsoft.Azure.ActiveDirectory.Synchronization.ProvisioningWebServiceAdapter.ProvisioningWebServiceAdapter. GetCompanyConfiguration(Boolean includeLicenseInformation) at Microsoft.Azure.ActiveDirectory.Synchronization.AADConfig.get_CloudEnforcedSyncSchedulerInterval() at Microsoft.MetadirectoryServices.Scheduler.SchedulerSettingUtilities.get_CurrentSchedulerSettings() at SchedulerUtils.GetCurrentSchedulerSettings(SchedulerUtils* , _ConfigAttrNode* pcanList, UInt32 ccanItems, Char** syncSettingsSerialized, Char** errorString) at Microsoft.DirectoryServices.MetadirectoryServices.UI.WebServices.MMSWebService.GetSchedulerSettings(String&settingsDeserialized, String& errorString) at Microsoft.IdentityManagement.PowerShell.Cmdlet.GetADSyncScheduler.ProcessRecord() — End of inner exception stack trace — at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input) at System.Management.Automation.PowerShell.Worker.ConstructPipelineAndDoWork(Runspace rs, Boolean performSyncInvoke) at System.Management.Automation.PowerShell.Worker.CreateRunspaceIfNeededAndDoWork(Runspace rsToUse, Boolean isSync) at System.Management.Automation.PowerShell.CoreInvokeHelper[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings) at System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings) at System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings) at Microsoft.Online.Deployment.PowerShell.LocalPowerShell.Invoke() at Microsoft.Online.Deployment.PowerShell.PowerShellAdapter.TypeDependencies.InvokePowerShell(IPowerShell powerShell) at Microsoft.Online.Deployment.PowerShell.PowerShellAdapter.InvokePowerShellCommand(String commandName, InitialSessionState initialSessionState, IDictionary`2 commandParameters, Boolean isScript) at Microsoft.Azure.ActiveDirectory.Synchronization.PowerShellConfigAdapter.SchedulerPowerShellAdapter.GetCurrentSchedulerSettings() at Microsoft.MetadirectoryServices.Scheduler.Scheduler.StartSyncCycle(String overridePolicy, Boolean interactiveMode) at SchedulerUtils.StartSyncCycle(SchedulerUtils* , Char* policyType, Int32 interactiveMode, Char** errorString) ,Microsoft.IdentityManagement.PowerShell.Cmdlet.StartADSyncSyncCycle
One of the benefits of Microsoft 365 is the interaction across many products and features to create services that otherwise you might not have available to you or need to implement unrelated and unconnected additional software and maybe client agents as well.
Recently announced is an interaction between Windows Defender (client AV and other security protections on Windows 10), Microsoft Cloud App Security – MCAS (cloud based reverse proxy for cloud app protection), Microsoft Defender Advanced Threat Protection (cloud service for analysing activity on end compute devices and determining if the activity could be malicious or warrant further investigation) and Microsoft Endpoint Protection Manager (recently renamed from Microsoft Intune) for pushing the settings needed to enable all of this. This interaction is to take apps that your users are browsing to, read the discovered app score and if the score is too low then to tag the app as unsanctioned and push the URLs for this app to the client (via MDATP) and have Windows Defender block access to the app shortly afterwards.
Client Experience
So lets take a look at what this looks like from the users perspective and then how to set it up. First on the left if Microsoft Edge (either the old or the new version) and Firefox on the right. The action is the viewing of a URL that is unsanctioned. This particular app that I chose is an news agency and I browsed to the site directly. If the site is browsed indirectly (say via an embedded advert or graphic) then a different view will appear.
Making This Work
Now lets see what we needed to put together to make this work. First Intune (Endpoint Manager) for the settings on the client, then MDATP for the interaction with MCAS and then MCAS for the app protection:
Endpoint Manager (Intune)
For this protection feature we need to ensure that you have a Device Configuration policy for Windows 10 or later that sets both Endpoint Protection and Device Restrictions in place. These two policies need to be in place and scoped to all the users that you want to protect.
The first policy is an Endpoint Protection policy, and you may have one of these already configuring Windows Defender on your Windows 10 endpoints. You need to make sure that the Microsoft Defender Exploit Guard and then the Network Filtering policy is set to Enable. This is supported in Windows 10 1709 and later, and I have seen this break outbound network connectivity on Windows 10 version 1703 machines that had the Microsoft Firewall disabled (where it did not break later versions of Windows).
Save and apply this policy.
Create a second Device Configuration policy, again for Windows 10 or later and for Device Restrictions this time. For this policy select Microsoft Defender Antivirus and then Enable the Real-Time Monitoring option, the Cloud Delivered Protection option also to Enabled, for Prompt users before sample submission, select Send all data without prompting and for Submit samples consent select Send all samples automatically. These are shown in the following two screenshots, both showing the same set of settings, but as its quite a long list the second picture is scrolled down.
Again save and apply this policy. Now wait for it to download to your client machines, or in the MDM settings on Domains and Accounts, click Sync to speed this process up.
MDATP
Next you need to set up the interaction between MCAS and MDATP. This is done in the Settings > Advanced Features. Here ensure that Custom Network Indicators is enabled. This ensures that machines can be set to allow or block URLs. This feature requires Windows 10 version 1709 and later as well and an up to date version of the antimalware platform. The network protection in block mode, which is also listed as a requirement, is what we have enabled above.
You also need to make sure that the integration with Microsoft Cloud App Security (MCAS) is enabled. Again, a list of client requirements is displayed along with the requirement that you are running EMS E5 licences for all targeted users.
If you don’t have the MCAS or EMS E5 licence then you can add the URLs and other indicators directly into MDATP via Settings > Indicators > URLs/Domains. It is here the MCAS pushes the URLs that the client will block against, and so any way of pushing data into the indicators in MDATP will generate the same result.
MCAS
In MCAS we need to set up the pushing of unsanctioned apps to MDATP and configure unsanctioned apps either manually or automatically.
To push the status of unsanctioned apps click the cog to the top right and choose Settings. Select Microsoft Defender ATP and ensure that Block unsanctioned apps is enabled here.
Finally we can go to the Discovered Apps portal in MCAS. If you recently enabled the integration between MDATP and MCAS then this list of apps on the Discover > Discovered Apps will be empty. This will populate over time and store up to 90 days of information on the cloud apps your users are browsing.
On the report, possibly called the “Win10 Endpoint Users” report, which is client data from MDATP, click on the Score column to sort the list from 0 upward and see the apps that users are browsing that MCAS scores with a low rating. Click the app name to get the stats on why the app gets a low score.
Under the Actions column click the “no entry” sign, which tags an app as unsanctioned. Once you do this, this app will be blocked in Windows 10 that is under the scope of the Intune policy created above within 2 hours (allowing 8 hours for Intune to sync the new settings in the first instance).
To automatically unsanction any app with a low score (for example 0 to 3) then select Policies from the Control menu. Create a new App Discovery Policy by clicking the Create Policy option. This new policy will have a name like “Unsanction Apps With A Low Score” and the policy setting will be Risk Score equals 0-2. It will apply to All Continuous Reports. Decide if you want to be alerted to this app running and finally select Tag app as unsanctioned.
Shortly after you create this rule apps that fall into the category will be tagged as unsanctioned. Before you enable this rule it would be wise to check the list of apps with the same score as shown under the Discovery reports that meet your score to ensure that it would not be business impacting immediately (unless you need that to happen). For example at the time of writing this 3,095 apps where shown as scoring #2 and below and 14 apps of score #2 and below that had been viewed by end users in our company over the last 30 days. In the Continuous reports you can click any app and see who is using it and who would be impacted by blocking it.
I recommend individually unsanctioning an app for testing purposes. You can get the URL for the app by clicking the app name in MCAS and then you can browse this from a end user device that is under the scope of your MDATP deployment and your policy Intune deployment. This takes about 2 hours to take effect first time around. The automated rule to tag apps as unsanctioned automatically takes a bit longer and therefore harder to test.
Once users then access these unsanctioned apps they appear as alerts in MDATP as well. On the Alerts Queue you get a “Connection to a blocked cloud application was detected”. For example I got the following during writing this blog because when my screen-shooting software was capturing the above Firefox image it decided to follow the URL and now I see that snagit32.exe was blocked from making a connection to a blocked cloud application
Reversing The Changes
Added to this blog 1 year later after seeing this process in use!
Once a app is tagged as unsanctioned it will remain unsanctioned. It is not possible to view the app in MCAS becuase users are not visiting it anymore, and MCAS has a filter for 30, 60 or 90 days. If you delete the URL from the Indicators node in MDATP (renamed Microsoft Defender for Endpoints since this article was written) then the URL is written back again shortly afterwards, as the app is still unsanctioned in MCAS.
Therefore you should check occasionally the MCAS policy you created, click “End and preview results” in the filter and look for unsanctioned apps that should no-longer be blocked.
From this Select app filters screen modify the filter, which you are not going to save at the end, to add a new filter row for “app tag”, “equals” and “unsanctioned”. Change the top filter to 0-10 and not 0-2 or whatever you selected. You will see this:
Here I can see two apps that are now set to 5 (yellow icon) that are also unsanctioned, becuase in the past they were in the scope of my filter. Click the red banned icon to unsanction the app and confirm the dialog as shown:
Once you are finished clearing apps you can cancel the edits to the filter as you dont need to save these changes, they are only here to find higher scoring unsanctioned apps. You cannot make a new MCAS filter to automatically unsanction them when outside of the range you set above as MCAS only allows you to sanction or unsanction, not to clear a previous setting.
In a few minutes the indicators in MDATP will be removed and this will sync down to the client and release this app in a few hours.
From Feb 29th 2020 Microsoft will remove the “baseline policies” from Azure AD. These were very useful in the past to enable blanket settings like MFA for all admin accounts (well, selected admin roles) and to disable legacy auth for the same admin roles.
With the removal of the baseline policies you need to ensure that before Feb 29th 2020 you have a replacement policy/policies in place. If you are reading this blog post after that date these steps will help you implement MFA for admin roles without using the Microsoft Security Defaults.
The Security Defaults are great for tenants without Azure AD P1 or higher licences (including Enterprise Mobility + Security E3/E5 licences) as they turn all this security on for you. If you have Azure AD P1 or higher licences (including Enterprise Mobility + Security E3/E5 licences) then you can use Conditional Access instead.
These steps below will implement a rule to allow selected admin roles to login only if they perform MFA successfully and to block legacy authentication for the same roles. The configuration below will also include a break glass account so that you always have a way to bypass this security should the need arise (loss of auth code generator device, outage at Microsoft that stops MFA working etc.).
1. Create Conditional Access Policy to force MFA for admin roles
Create a new policy called “Protect All Administrators – Require MFA for All Logins” and set the following options
Users and Groups > Directory Roles > select all roles relevant to your organization. Suggest selecting all those that end “Administrator” as a minimum and maybe include Global Reader as well.
Users and Groups > Exclude tab > Exclude the group that contains your AADConnect sync account and you break glass accounts. If you have not done this yet, go and do it and then come back here. As a minimum exclude your account for now.
Cloud apps or actions > All Cloud Apps
Conditions > Client Apps > deselect “Other Clients” to remove clients that only do legacy authentication
Grant > Require multi-factor authentication
Report Only – this is to make sure that we do not lock ourselves out by getting this wrong – we change it to “On” later once we know it is working
2. Create a policy to block legacy authentication clients from doing administrative actions
Create a second policy called “Protect All Administrators – Block Legacy Authentication” and set the following options:
Users and Groups > Directory Roles > select all roles relevant to your
organization.This list will need to be identical to the above list, and when in future you edit the above list because Microsoft add new administrative roles, you need to match those changes to this policy list as well.
Users and Groups > Exclude tab > Exclude the group that contains your
break glass accounts.
Cloud apps or actions > All Cloud Apps
Conditions > Client Apps > deselect all options except for “Other Clients” to remove clients
that do modern authentication (therefore deselect browser and modern clients).
Grant > Block Access
Report Only – this is to make sure that we do not lock ourselves out by
getting this wrong – we change it to “On” later once we know it is working
3. Future changes
As mentioned above, when Microsoft release new administrative roles, you you add the first person to a new role you have not used before, come and edit both of these policies to include that administrative role.
Once you are sure that the policy is working (by reviewing the Conditional Access reports) change the policies to “On” instead of “Report Only”.
There are a number of general recommendations that SMS (text messages) as an MFA method is not a good idea (mainly to do with the ease of porting or moving devices the number is associated with). You should always be looking at MFA with an app (Microsoft Authenticator or other) or hardware device. But the default in Azure AD is to include SMS as an option – so if we turn off text messaging as a second factor what is the impact to our user base who might have already registered their phone number.
My previous article on MFA end user experiences covered the different options available for the different registration wizards (legacy and the new combined MFA/SSPR wizard), what happens if you have SSPR enabled (and what happens if you do not). Each of the scenarios in that article allowed the user to register a phone number and then to have a text message sent at login.
If the user registered with the legacy authentication wizard (which is the default setting as of the time of writing) then there are three options by default – authentication phone, office number (set by the admin and not by the user) and mobile app (and phone is the selected option). Using SMS for second factor is therefore automatically set up unless the user chooses “office number” or “mobile app” whilst registering. The registration page looks as follows:
So in scenarios where the user followed the defaults they get an MFA prompt at login that looks like this:
Notice that they have an option to “sign in another way” for scenarios where the user maybe cannot receive a phone call but would be able to receive a text message (if you are in a location where you can receive neither, then you need to register the app as well in advance). If the user clicks “sign in another way” then they see the following where they can choose to receive a text message as the second factor proof:
To disable SMS/text as an MFA method you need to be in the Azure AD portal > MFA > Additional cloud-based MFA settings (or click Multi-Factor Authentication in the Users page of the same portal). You will see the below once you click the ServiceSettings tab:
This dialog includes the “skip multi-factor authentication…” box which you only have if you have Azure AD P1 or P2 licence. The four options at the bottom include the “Text message to phone” – uncheck that to stop SMS as a second factor.
So if SMS/text is removed as an option – what changes for the users who has already got a phone number stored as a MFA method? First change is that “sign in another way” message is now missing. A user who previously got a phone call with the option to change to another option will find that they cannot change options anymore (unless they have also registered a different method such as office number or mobile app:
Therefore if there is not enough mobile signal to manage a call (and there might be for a text message) then the user cannot authenticate.
What about users who when they registered for MFA set SMS as their default? Setting text message as a default is not a obvious setting – but the default is whatever you initially choose to register with – so in the registration wizard if you select “send me a code by text message” then your default is SMS:
Once the admin disables SMS as a valid second factor, those users with phone as their default (or app) are not impacted – but users who set text message as their default are required to re-register. In the registration they are told their organization needs further information, that “call me” is the only available option, but their previously registered telephone number is shown in the registration wizard. This is shown in the following series of images:
Once the users settings are saved, the user clicks Finish and their registration for phone authentication is updated to remove text message as a valid option. Enabling texts again in the admin portal does not allow this user to use texts again unless they register again or they update their additional security verification settings (Office 365 browser app > click photo > My account > Manage security & privacy > Additional security verification > Update your phone numbers used for account security (go to https://aka.ms/mfasetup as a shortcut to avoid all these steps)
If you remove both phone and text as a registration option as shown then users who previously only had phone and/or text registered will be required to register again.
This time registration will default to “mobile app” – where the user can select “code” or “notification” as their new default:
In scenarios where you have enabled the new registration wizard (see my previous article on MFA end user experiences for more on this) then the default registration option is to use the app and not phone or text, though phone numbers are collected if you also turn on two or more options for requiring a password reset with SSPR. So in these scenarios you will probably find that the user has lots of registered options and so turning off SMS is not an issue.
So to disable SMS is only a problem in Azure AD for the user – as it means that at the next login they need to register again (so not a real problem). I had previously seen in 2018 that if the admin disabled text messages then users could not login if this was their only method! So that issue is clearly fixed now.
So as a call to action from this article – consider turning off text messages as a second factor and noting that the only impact is some users will either need to register again or you can ask them to go to https://aka.ms/mfasetup beforehand to change their default setting.
This article will look at the various different MFA settings found in Azure AD (which controls MFA for Office 365 and other SaaS services) and how those decisions impact users.
There is lots on the internet on enabling MFA, and lots on what that looks like for the user – but nothing I could see that directly laid out all the options and the impact of each option.
The options that the admin can set that I will cover in this article are:
Default settings for the MFA registration service
The enhanced registration service (now depreciated)
The refreshed enhanced registration service (MFA and Self-Service Password Reset registration combined)
The general impact to the user is that the user needs to provide a second factor to login. In this article I will not detail the above registration for each of the second factors and only cover the general process of registration – your exact experience on registration will depend upon what second factors (app notifications, app code, phone call and text message) you choose to implement.
This article will look mainly at the different between having no MFA and what happens from the users perspective as the admin turns on a requirement to have MFA. The various options that the admin can use to enable MFA are as follows:
Office 365 MFA (aka the legacy method) that is available to all users with or without a licence
Azure AD Conditional Access and setting a rule that requires MFA (when the user is not registered)
Azure AD Premium 2 licence and MFA Registration (register without requiring MFA to be enabled)
Azure AD Free fixed Conditional Access rules (MFA for all users) which is in preview at the time of writing (Aug 2019)
Terminology and Settings
This article refers back to a series of different settings in each of the following sections. To make the article avoid repeating itself, this section outlines each of the general settings, what I mean by the description I use and where I turn that setting on or off.
Office 365 MFA – This is the legacy MFA options set via https://admin.microsoft.com > User Management > Multi-Factor Authentication. This user experience turns on or off MFA for users regardless of app or location (unlike Conditional Access) and has settings for the different second factor methods (for example you can disable SMS from here).
Conditional Access Based MFA – This is where you set rules for accessing cloud apps based on the user, the location, the risk (P2 licence required), the device (domain joined or compliant), the location (IP), the device risk (MDATP licence required), compliance (Intune required) etc. If you rule requires MFA and the logging in user passes the requirements for this rule (and is not otherwise blocked) then this is what I call Conditional Access Based MFA. This is set in https://portal.azure.com > Azure Active Directory > Enterprise Applications > Conditional Access
Azure AD Premium 2 MFA Registration – This is where you can get users to register before you turn on MFA via either of the above routes. Without the P2 licence you turn on MFA and at the next login the user needs to register. With P2 you can turn on registration at login without forcing MFA. You would then enable MFA later or you can have registration at next login (and defer that by 14 days) so that the user registers even if they never hit an endpoint that the need to do MFA on. For example, MFA when external and the user never works remotely. Therefore they will never have to do MFA and therefore never be required to register – which P2 licence you can get them to register independent of the requirement to do MFA. You access these settings via https://portal.azure.com > Azure AD Identity Protection > MFA Registration
Self Service Password Reset Registration – This is shown if the user is in scope for SSPR and SSPR is enabled. This is not MFA registration – but if the user is in scope they will be asked to register for this as well. This therefore can result in two registrations at next login – one for SSPR and one for MFA. We will show this below, but it is best if you move to the combined MFA/SSPR registration wizard mentioned below.
Enhanced Registration (Depreciated) – This was the new registration wizard in 2018 and have been replaced by the next option. If you still have users on this option you will see it, otherwise the option to enable this older wizard is now removed. This is accessed via https://portal.azure.com > Azure AD > User Settings > Manage user features preview
Combined MFA and SSPR Registration – This is the current recommended MFA registration process and it includes self-service password reset registration as well. You should aim to move your settings to this. All the new MFA reporting and insights are based on this process. This is accessed via https://portal.azure.com > Azure AD > User Settings > Manage user features preview. Note that if you still have users on the previous “Enhanced Registration” shown above then this one is listed as “enhanced”. If not – if only one slider is shown – it is the new registration process. You can enable this for a group of users (for pilot) or all users:
Office 365 MFA + Original Registration
This is not recommended to be used any more – use the Azure AD Free Conditional Access rules for all users or all admins instead. But for completion of the process to show all the options, you select a user(s) in the Office 365 MFA page and click Enable. In the below screenshot we can see that Cameron White is enabled for MFA. This means that it has been turned on for him, but he has not yet gone through the registration wizard:
The video below shows the first run experience of this user – they login and are prompted to register for MFA. They register using the legacy experience and are then granted access to the application.
OFFICE 365 MFA + LEGACY REGISTRATION
Office 365 MFA + Enhanced Registration
For this scenario I have a user called Brian Johnson. He has been enabled for MFA as above (Office 365 method) but additionally has been added to a group that is configured to support the new MFA+SSPR combined registration process. Brian is not enabled for SSPR. The video shows the user experience. Note that the user needs a valid licence to be able to use this experience. If they do not have any licences they will get the old experience:
VIDEO OFFICE 365 MFA + ENHANCED REGISTRATION
Conditional Access MFA
The following video looks at the experience of two users who are enforced for MFA via Conditional Access. The login will trigger the registration for MFA as neither user is already registered. The first user (Christie) gets the old registration wizard and the second (Debra) gets the new registration wizard. The Conditional Access settings are basic – MFA in all circumstances for our two users:
CONDITIONAL ACCESS WITH OLD AND NEW REGISTRATION
Impact of SSPR on MFA Registration and User Sign-In
When users are set up to register their password reset security methods and MFA, but using the old registration wizard the user needs to do two sets of registration. Again, it is recommended that the combined registration process is used instead of this process.
For this demostration, we are enabling SSPR for our test users. One with the old registration wizard and one with the new one:
SSPR WITH AND WITHOUT COMBINED REGISTRATION
Adding SSPR To Already Registered Users
Once a user has registered for MFA (old or new registration) it might come a time where you enable SSPR for them after that (and not at the time of original registration). In this scenario the users that registered with the old registration wizard are asked to register for SSPR, but users who went through the new wizard – though they did not specifically register for SSPR – there is enough details already available for them to use the service (as long as app notifications and codes is enabled for SSPR). If SSPR is left on the default of SMS and Email, then the new registration wizard does not have your alternative email and so SSPR is unavailable to you. The user process and flow is shown in the next video:
ENABLE SSPR AFTER REGISTRATION
Azure AD Identity Protection and MFA Registration
The Azure AD Premium 2 licensed feature called Identity Protection contains the ability to request that the user registers for MFA (and SSPR if via the new combined registration wizard) even if the user is not required to perform MFA for login – all our previous registrations only required registration because the user needed to do MFA. You can ask users to pre-register via https://aka.ms/mfasetup but Identity Protection adds this functionality with a 14 day option to defer. The video shows the settings and the user experience:
Azure AD IDENTITY PROTECTION WITH AND WITHOUT NEW REGISTRATION
Azure AD Free Conditional Access for All Users
Early Q2 2019 Microsoft rolled out new baseline policies for Azure AD Conditional Access. These are available even without the Azure AD P1 licence needed for Conditional Access – but as they are licence free they are heavily restricted – they apply to all users and need MFA if sign-in is risky. So though they do not require MFA on all logins (unlike the O365 MFA legacy settings) they do require registration. But they offer a 14 day deferral process if the user is not ready to register. But unlike Azure AD Identity Protection mentioned above, you cannot do this for some users – it is enabled for all users upon enabling the rule. Lets see the settings and the user experience in the video. The video will also enable the “all admins” baseline policy as well, as that should always be turned on.
Or How to Use Set-Place to Configure Your Meeting Rooms or How Wheelchair Users Can Find The Best Meeting Rooms In Your Organization etc. – there are many different titles I can think of for this blog post. They are all to do with setting useful properties against your meeting rooms so that your users can find the best rooms.
As of the time of writing (updated July 2020), “Outlook Places” service exposes a client-side UX only in Outlook on the web (OWA) with Outlook for Windows and Mac due by end of August 2020. Given Microsoft’s previous behaviour of flighting Exchange Online features for one client initially before rolling them out to other clients, this is likely to hit Outlook mobile etc. at some point after that. Therefore I recommend that you update all your room properties now using the PowerShell cmdlet Set-Place so that your users are able to find meeting rooms and other resources upon the functionality appearing in their client.
The Exchange Online Management Shell cmdlet Set-Place allows you to configure properties such as if the room is accessible for wheelchair users (hence the title of this blog post), or what AV equipment it holds or indeed how many people the room can hold (comfortably!). As this information, especially in a large organization, is probably known by many different people and requires the input of these different users to maintain a master list, this blog post will look at the process of creating this list and then importing it back into Exchange Online when updated.
Creating A Master Room Metadata List
From Exchange Online Management Shell run the following:
Open the file, here called OrganizationRooms.csv in Excel. I removed the first three columns (PSComputerName,RunspaceId,PSShowComputerName) as well as Type, ResourceDelegates, IsManaged, BookingType and Localities and the last two columns (IsValid and ObjectState) from this file and then save it as an Excel file to OneDrive for Business or SharePoint Online and shared it with the relevant facilities management and other interested parties (don’t share it as a CSV file, as multiple users cannot edit a csv file in real time). We wait for this information to be updated. If you wish you could lock out cells from being edited such as Identity and maybe DisplayName so that future updating of existing rooms is easy to do.
Specifically we are looking at information such as location (physical street/city address, building name [for campus type organizations], floor number and GeoCoordinates), AV equipment (such as audio, video, display devices and room phone number), accessibility for wheelchair users, and miscellaneous tags (in the form of a comma separated list such as “Conference Room”,Lecture,“Tiered Seating”) that users could use in their room search. There are tools to generate geo-coordinates from addresses that you can find online (including Google Maps) and they are required as latitude;longitude;altitude (where altitude is optional)
Updating Room Metadata in Exchange Online
To upload the new data, save the shared Excel spreadsheet as a CSV file again and run the following Exchange Online Management Shell script. Note that the following script works where the object is created in Exchange Online/M365 and not synced from Active Directory (hybrid). For hybrid see the code further down the page:
In the above code I have not included attributes from Get-Place that I cannot write back such as IsManaged, BookingType and Localities – I am interested though in knowing what they are used for as they are undocumented?
If you get back the error “Encountered an internal server error.” then this is because you are trying to update an AADConnect synced object when your directories are in hybrid mode. The correct script to run is further down this page.
The above code just replaces the current values in Exchange Online with the values in the spreadsheet, so the spreadsheet becomes your master.
Note that values with spaces need to be quoted in the CSV – such as tags and various display names. Also it is worth being aware that with conference bridges and Teams meetings, room “capacity” is not always as important as it might sound – a room with a capacity of 3 people will work fine if everyone is remote! Booking multiple rooms for a single meeting is also planned.
Hybrid
If the room object is synced from on-premises Active Directory then you can still use Set-Place to update the object in the cloud, you just cannot set the City, CountryOrRegion, GeoCoordinates, Phone, PostalCode, State, and Street attributes. The way to set these properties is Set-User and that needed to be run against the source of the object (that is on your management Exchange Server on-premises against Active Directory).
The cmdlet to run instead of the above in Exchange Online is
All rooms and resources that you manage via the steps in the blog post need to be Exchange Online resources. If the mailbox is still on Exchange Server and not moved to Exchange Online in a hybrid scenario, you are not able query and set the information in Get-Place or Set-Place
But that does not mean you cannot get ready for the day that you move those resources (rooms) to Exchange Online. On Exchange Server you can run the following Exchange Management Shell PowerShell and get a csv file with exactly the same columns as above. Get the spreadsheet filled in as mentioned above and then when you move the room to Exchange Online and update Set-Place and Set-User, the room will be found and updated.
At the time of writing (July 2020) this experience is rolling out to Outlook, having been in OWA for about a year. The new experience will use the “Outlook Places” backend service, which Set-Place we used above populates.
To view and search for rooms based on these settings you need (for now) to wait 24 hours from using Set-Place before the property can be searched. You then create a new event in OWA calendar and click “Search for a room or location” and then click “+ Browse more rooms”.
The suggested rooms listed are those you have used or attended meetings at recently, but if you click in the “Search for a city or room list” box you can either enter a city or room list name (suggest naming your room lists after buildings) and click “Show all rooms” or click the City or Room List name:
This allows the “Filters” option to become available, where you can filter for capacity (rooms larger than) or properties such as audio/video or accessible rooms.
Once you have set the features you need, click Apply and select the room you need for the meeting. Being able to book multiple rooms for a single meeting is coming to Office 365 in the next few weeks from writing this article as well – imagine booking a meeting where people attend remotely but the remote location is another office.
Call To Action
Even though this “places” functionality does not reach all the Office email/calendaring clients (yet), this should not be a reason not to do this categorization work. Its quite easy to generate a list of all the rooms and their current settings (see above) as a spreadsheet. Its more work to update that list, but if you have a list then you can start. Rooms don’t often change their status regarding accessibility etc. but if you start cataloguing your rooms now or add this work to an Exchange Server migration project, then your users will benefit as the functionality reaches the client they use.
If you don’t update your places metadata, then clients will be unable to successfully find meeting rooms.
This article is based on the public preview of the use of hardware tokens/Microsoft Authenticator to do sign-in without passwords released in July 2019
Using Microsoft Authenticator for Passwordless Sign-in
You used to be able to do this by running the following in PowerShell for the last few years
Interestingly, if you have done this in the past, the new Azure AD portal settings for doing this do not take this into consideration. So first, if you have run the above then you need to remove it with Remove-AzureADPolicy –Id <get the ID using Get-AzureADPolicy> before you implement the below, otherwise it is turned on for everyone even though Azure AD Portal says it is not enabled:
Click Microsoft Authenticator passwordless sign-in and choose Enable and to pilot choose Select Users and the group you want to pilot with. Otherwise if you want to turn it on for all users, just leave the default. Note that nothing changes for the user – they need to do stuff before it works for them.
which results in
As the notice says, also ensure that you have MFA with push notifications enabled. This option has been available for a year or so now, and you will find it on Password Reset > Authentication Methods (or directly with https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/PasswordReset). This is not the same setting as the blue bar at the top of the page you are currently on.
For the user, from within Microsoft Authenticator, they need to go to the settings and register the device with their login. This is a one time process and once you have done the above and they have registered the device, they can choose to do password-less sign-in.
From a login perspective, it looks like this:
Enter your username to an Azure AD login
On your phone, in the notification from the Microsoft Authenticator app, you select the displayed number (which changes number, and the position of the number each time)
Hardware Tokens Instead of Passwords (FIDO2)
This is the second option made available in Azure AD in July 2019. This allows the use of hardware tokens such as Windows Hello and FIDO2 devices (i.e. Yubikey and others) to authenticate to the platform. Note that this is not MFA – you have one factor, the hardware token. There is no requirement to implement a second factor with the hardware token as this replaces the password and is not storing a password. That is, if you do not have the token you do not have access – you cannot guess or intercept the token exchange.
To turn on this feature select the FIDO2 Security Key option under Authentication Methods (under Security) and then Authentication Method Policy (Preview).
As with the Microsoft Authenticator option above, Enable the feature and select All Users or Select Users.
Unlike the Microsoft Authenticator option, you now have the choice of Self Service and Key Restrictions
Self Service is useful when you have All Users selected, as the user registers their own security key. Without Self Service you need to configure a key for each user. Self Service requires the new registration service which is mentioned above and linked to at the top of the configuration page in Azure AD portal.
Enforce Attestation allows you to ensure that a specific model / device of hardware security key is used. Enforce Key Restrictions requires that you add the key by its AAGUID as shown:
From here you can also Restrict Specific Keys to only allow keys you have issued to be used. Block would allow you to have any key.
Enhanced Registration Preview
This preview has been available since early 2019, but now supports passwordless and security token as authentication methods. Click the link in the blue bar and ensure everyone whom you have enabled the new authentication policy for is included for the new registration preview. In the graphic below, this is the lower of the two options – your tenant might show only the lower option.
To direct users to the new preview experience visit http://aka.ms/mfasetup or if you have a Conditional Access login but you have not registered, you will be directed here anyway.
On the security info page, if you have already registered for MFA you will be shown your current authentication methods:
If you have not registered before you will be asked to register – either way, you get to pick the methods you want to use for authentication. These need to be:
Authenticator App – you can add up to five of these
Security Key
To add a new Security Key select this and follow the steps but make sure you are running Microsoft Edge on Windows 10 1903 or later or Firefox. On Chrome (which supports FIDO2 for Google Services) you get the below:
On a supported browser, you will see the following series of prompts:
The above is for a USB key. NFC keys and readers will have different prompts along the lines of holding the device near to the reader.
Then you need to name your key:
Signing In With A Security Key
Login to Office or your selected cloud app and enter your username and click next.
Now you can click “Sign in with Windows Hello or a security key”
As with registration, you now need to enter your PIN and press the button on the USB device, scan your fingerprint, look at your camera or hold your NFC device next to the reader – whatever your device requires you to do.
When you install Exchange Server into an existing Exchange organization, your existing configuration typically remains intact and associated with the previous servers and some configuration, that is global in nature, also works across both versions.
I can across a scenario where this does not work the other day. The scenario was the installation of Exchange Server 2016 CU12 as a brand new Exchange installation into an existing Exchange Server 2013 deployment. This AD forest has previously seen Exchange 2003 and Exchange 2010, but these server versions are now long gone.
The issue was that the transport rules all appeared in Exchange Server 2016 as disabled, but where all enabled in Exchange Server 2013. The Exchange Admin Center could not open the rules and an error was displayed at the bottom which when expanded showed that the RejectEnhancedStatus was invalid, along with lots of the settings of the rule – they all are missing in the right-hand side of the EAC view.
RejectEnhancedStatus is the error code returned when you write a rule that rejects messages with notification. In Exchange Server 2016 only 5.7.1 and 5.7.900 through 5.7.999 are allowed for the RejectMessageEnhancedStatusCode parameter, but the Exchange Server 2013 deployment at CU21 does not block the creation of other status codes. Therefore, if you have transport rules with codes other than the ones allowed in Exchange Server 2016 you get corrupted transport rules:
So – how to fix. Well you cannot set the RejectMessageEnhancedStatusCode to a new value in Exchange Server 2016, because this server says you also need to set the RejectMessageReasonText value as that is also an empty string and also shows that a lot of the rule properties are also empty. So you need to fix it in the older version of Exchange.
In Exchange Server 2016 running Get-TransportRule “name of rule” results in:
WARNING: The object transport rule name has been corrupted or isn’t compatible with Microsoft support requirements, and it’s in an inconsistent state. The following validation errors happened:
WARNING: Rule ‘transport rule name’ is corrupt. The specified enhanced status code ‘5.7.x’ is invalid or isn’t compatible with Transport Rule policy requirement. Valid values are 5.7.1, or a value in the range between 5.7.900 and 5.7.999. The code must contain no spaces or other characters.
Parameter name: RejectEnhancedStatus
But running the same on Exchange Server 2013 is successful:
Run the following Exchange Management Shell cmdlets in Exchange 2013:
Get-TransportRule “name of rule” | FL Name,RejectMessage*
This will return the configuration of the current rule regarding the RejectMessageEnhancedStatusCode (which is wrong for 2016) and the RejectMessageReasonText.
Then run the cmdlet to change the code to a supported value as shown:
Set-TransportRule “name of rule” -RejectMessageEnhancedStatusCode 5.7.1 –RejectMessageReasonText “copy the reason from the output of the above cmdlet”
You need to set the code to 5.7.1 and provide the text again, or Exchange will replace the text with its own text or you need to create a New-SystemMessage for the status codes .900 and above and then use that code in the transport rule.
Once the change has been made on Exchange Server 2013, and this change is written to the configuration partition of Active Directory, that change will replicate around AD. Once the change reaches the DC used by Exchange Server 2016 the error will disappear and Exchange Control Panel can be refreshed to remove the error.
A long request within Azure AD/Office 365 has been the request to be able to register your security info from a known location or only on certain other conditions. Well it looks like this has appeared in Azure AD in the last few days!!
Its visible under Azure AD > Conditional Access > New/Existing Policy > Cloud Apps or Actions:
So, what does this look like in practice? Lets put this preview to the test.
Create the Conditional Access Policy for User Actions
From here click Conditional Access (this is also accessible under Azure AD > Security as well)
Click Add Policy and give the policy a name. I have chosen “Register Security Information On-Premises” for here
Click Users and Groups. I have selected “Users and Groups” rather than “All Users” as I plan to test this out first! I have picked the group that I use for testing Conditional Access changes. Eventually I will change this to All Users so that no-one can register security info apart from when on a trusted location. Note that this would also I think include guest users – I need to test that! Guest users are by their very nature not on my network but I might have MFA required for them – so they need to register, but I don’t want to apply the below to them
Select Cloud Apps or Actions (this was recently renamed to support this functionality we are describing here)
Select User Actions in the slider and check the option for Register Security Information (Preview)
Select Conditions and select the conditions you want to apply when users are registering security information. Its probably location based, so I will set that up here.
Select Locations, click Yes under Configure and select Any Location under Include and then under Exclude select Trusted Locations. Note that you need to have set up trusted locations in Conditional Access as well – I’m going to assume the public IP of all your offices is added and marked as trusted.
This setting will ensure that all locations other than trusted locations cannot register security information – note that this is the reverse of what you might expect. We need to block the locations we don’t want to access the MFA/SSPR registration process rather than the reverse. This is because we are required to add a control to the rules
With Azure AD P2 licences you could user a sign-in risk condition, ensuring that registration does not happen on medium or high risk sign-ins!
Click Done to bring you back to the first blade of settings and set Enable Policy to On to turn on this feature
Under Access Controls, click Grant and choose Block Access – be very careful here – don’t block all your access to everything!
Click Done
This takes us back to the first blade in the Conditional Access settings.
Click On in the Enable Policy slider
Now the Create button is available – this is not available if you do not create the reverse of what you might expect to do – block unknown locations rather than allow trusted locations!
Click Create
You will get your notification – you can test this in a few minutes:
Enable The New Combined MFA/SSPR Registration Page
Though I noticed that this conditional access restriction works against the older MFA registration page, Microsoft have said in their release blog article for this feature that it will only work against the new MFA/SSPR combined registration page. Therefore you should turn this on for your users impacted by the above policy – initially for your pilot users and then for all users.
In an in-private browser session on the Wi-Fi of your favourite coffee company, browse to https://aka.ms/mfasetup (as this is not a trusted location!)
After logging in you would expect to be take to the registration page for MFA and SSPR – but you are not!
Repeat your test from on-premises, and you will get the MFA and SSPR registration pages (or both if you have the new combined MFA+SSPR wizard enabled):
Note that for a brand new user where you have SSPR enabled, they are required to register by default every 180 days. This will mean they have to register at first login – therefore first login needs to be from a trusted network (in this example) – you could use Trusted Device as the only place to register from, but adding a user to a trusted device requires MFA by default, so watch out for an issue here and if you want to do this, test it very well.
I have not had the opportunity to test this with the 180 day refresh of your settings – presumably that should work from any location and only changing them would be blocked, but this is something that needs to be tried out.
A new feature as of May 2018 in Office 365 is to filter communications based upon the offensive language machine learning filter. This is part of the Supervision settings that have been available for a number of years. The Offensive Language model uses a combination of machine learning, artificial intelligence, and keywords to identify inappropriate email messages as part of anti-harassment and cyber bullying monitoring requirements.
Here we will walk through the process of setting up the offensive language filter and testing it out (without offending anyone)!
At the time of writing, the Compliance Center is new and not everything is visible here. By the time you read this article it might be possible to create your supervision reviews from this portal, but for now we need to go to the Security and Compliance Center – so click the link at the top of the page. You will see this:
If you cannot see this then you do not have the right permissions. Add yourself to the Supervisory Review role group so you can set up policies. Anyone who has this role assigned can access the Supervision page in the Compliance Center.
Click Create to create a supervision review. Enter a name and a description. You cannot change the name later on.
In the next page, select the users to supervise. Start with a test group before editing this policy to add a group that contains everyone.
You can also select users who are in the group and specifically exclude them if needed. Communications via Exchange and Teams are included by default. Third party sources can be added as well.
Click Next and move to the Choose communications to review tab. Here select Internal communications (which is not selected by default) and choose Use match data model condition. There is only one model, and that is the Offensive Language model – so that gets selected by default.
If you want to scope the filter a bit more then you can select Add a condition and set up rules – for example you could exclude a specific domain inbound.
Click Next and get to the Specify percentage to review tab
Here you get to set the percentage of communications to review. The default is 10%. This means that only 10% of all communications are reviewed, and the results you see are based on what was found in that 10%. In large organizations, 10% could be a lot of communications, and therefore could be a fair amount of offensive content. Therefore ensure both your reviewers are able to manage the review process without undue impact and understand that whatever you find – there is 10 times more of it happening. Smaller organizations might want to increase the percentage to review, or at least consider increasing the percentage to review.
Click Next and enter the email addresses of the reviewers. They need to have an Exchange Online mailbox to be able to do this, but the content for review does not go into the reviewers mailbox.
Click Next and get to the Review your settings tab. Check everything is okay and click Finish.
Your policy will be listed so that you can update it, apart from the name, in the future.
The policy is also displayed in a pop-out as shown:
In this pop-out you can see the name of the mailbox that the content for review will go into – therefore those users who are reviewers will need to have access to this mailbox if they want to use Outlook to do their review process. If the reviewers have access to the Compliance Center then review can be done there instead of in Outlook/OWA. Permissions need to be granted to the mailbox using PowerShell. The two cmdlets are, using your supervisory review mailbox as listed in the policy results.
Add-MailboxPermission "SupervisoryReview{GUID}@domain.onmicrosoft.com" -User "alias or email address of the account that has reviewer permissions to the supervision mailbox" -AccessRights FullAccess
Set-Mailbox "SupervisoryReview{GUID}@domain.onmicrosoft.com" -HiddenFromAddressListsEnabled: $false
You can add “-AutoMapping $false” to the Add-MailboxPermission if you want the review mailbox not always to appear as an additional mailbox in Outlook.
To Review Your Supervision Policy
In the Supervision Review pop-out (which you can get back by clicking on the policy name), click Open at the top.
This takes you to:
Here I can see I have nothing to review or pending items to look at. If you want to test this, think of something offensive and send it to yourself! It might turn up in the review portal, or it might not – remember only 10% of communications are subject to review.
Note: Emails subject to defined policies are processed in near real-time and can be tested immediately after the policy is configured. Chats in Microsoft Teams can take up to 24 hours to fully process in a policy.
I’m not going to send anything, but I will take a look back here later and I might update this blog if I ever get any hits!
To review the content, the menu across the top for Review and Resolved Items will show you the items and those that have been resolved. The actual HR and discipline process is obviously not covered by anything in this review process. Once resolved in the company, mark it as resolved here.
In OWA, you can open an additional mailbox and enter “super” and the supervisoryreview{GUID} mailbox appears:
Inside the supervisory review mailbox, there is a folder for the policy you just created and inside that are subfolders that indicate review (Non-Compliant and Questionable) and Resolved:
Article Depreciated: Microsoft now auto-hides the Calendar icon in Teams if your on-premises Exchange Server is not reachable via AutoDiscover V2 and at least Exchange Server 2016 CU3 or later. Once you move your mailbox to Exchange Online (or a supported on-premises version), assuming you did not do any of the below, your Calendar icon appears in the left rail shortly after mailbox migration, though I have seen it take six hours and needs a Teams client restart as well
In Microsoft Teams, you have a calendar (previously called meetings) icon in the main display that shows your diary and meetings etc. – except it does not work if your mailbox is not either in Exchange Online or, if if your mailbox is on-premises, you are not using Exchange Server 2016 CU3 or later.
The reason for this is that the Teams calendar uses AutoDiscover v2, which is only supported by Exchange Server 2016 CU3 and Exchange Online (note that CU3 is not the current version of Exchange Server 2016 and versions later than CU3 also support AutoDiscover v2).
This means that if you have an earlier version of Exchange Server on-premises then the calendar in Teams is not functional. This raises IT support calls as users expect it to be available, and this impacts your deployment of Teams as it appears broken.
So how can we fix this. Well clearly migrating to Exchange Online or installing the 2016 or later version of Exchange Server is the obvious option from the above, but there is another option to work around this issue. The “fix” is to remove the calendar icon from Teams. This does not stop you booking meetings, as you can still do that in Outlook with the Teams add-in or in the Outlook mobile client, where Teams meeting support is rolling out as I write this blog. If I remove the calendar icon, then the source of the errors disappears, but Teams is not really adversely impacted.
So this is what we start with:
And we remove the icon by creating a new App Setup Policy in the Teams Admin centre and then deploying that policy to all your users (with on-premises mailboxes on older versions of Exchange, or those not using Exchange for calendaring). You can easily roll this out as a test, though its about 24 hours for the effect to be seen, and then roll it out in bulk for all your impacted users. We will cover all this below:
1. Creating App Setup Policy
In the Teams Admin centre (https://admin.teams.microsoft.com) expand Teams Apps > Setup Policies and create a new policy. This policy is based on your current Global policy.
Select the Calendar app and remove it from this new policy. You should see something like this:
Here I have created an app policy called “With OnPrem Mailboxes” and removed the Calendar app from it.
2. Applying App Setup Policy To A Test User
Once you have the policy ready, its time to test it. Policy changes will take 24 hours to apply (so say the docs) and I found on my testing it was 18 hours when I ran through these steps – so this is not quick!
To make sure your changes work, the plan here is to deploy this new policy to a few selected individuals in the Teams admin centre.
Find the first user and click on their name. In the details page you will see the policies applied to the lower left:
Click Edit at the top right of this section and change the App setup policy to your new policy:
And click Save:
You will see your new policy in the list.
Repeat for the rest of your test pool of users using the portal. We will not use the portal for deploying it to all users though, that will take too long!
Next day, these users should see something like this – no calendar:
3. Applying App Setup Policy To All Users
To apply this change to all users once your test users are happy we will use PowerShell, and we will use the Skype for Business Online PowerShell cmdlets (not the Teams PowerShell!).
The following one-line PowerShell, once you have connected to your tenant, is:
This gets all your users and applies a new Teams App Setup Policy to each of them. This works initially with this problem, as we assume all users are affected. If only a subset of your users are on-premises, then do not use this cmdlet to apply the initial change, but use the below to be more selective.
Within 24 hours the Calendar app will disappear from Teams for your users and they will not be phoning the help desk with issues that none of you can easily fix!
4. Applying App Setup Policy To Selected Users
The above cmdlet is a single run – it does not affect later and new users, nor is there a concept of a default policy that you can set as the one each new users gets. So every so often depending upon how often new users start employment you will want to run the below:
This gets all users where they do not have the selected App Policy already set and sets this just for these users. This is quicker than setting it for all users regardless.
You can use other filters to select users – for example, you could look for users without an on-premises mailbox and then run the ForEach against each of these users instead – this would work in a hybrid deployment.
When you are in a hybrid deployment and you move mailboxes to Exchange Online from on-premises, you will want to set those users just moved back to a policy that includes the calendar app. The same would go for organizations migrating to Exchange Server 2016 with inbound AutoDiscover from Office 365. Here you could use something like importing a CSV file of mailboxes being migrated (the same list you used to build the migration batches in the first place would do) and then run the ForEach for each item on the CSV file.
