Exchange Online Public Folder Migration Fail

Today I have been migrating Public Folders (yuk!) from Exchange 2010 to Exchange Online, and have come across a slightly odd issue.

I had followed the lovely guide to Public Folder migrations provided by Microsoft here, however I could not complete my migration as the migration batch had completed with errors. The error I was receiving was as follows:

Error: MigrationMRSPermanentException: Error: There are 2 mail public folder‎(s)‎ in Active Directory that were not linked to any public folder during migration.

The Public Folders referenced in the error message were both Exchange system folders, so I wasn’t sure why it was bothering to try and synchronise them. Luckily the error message does give us a clue as to what to do;

You may also run "Set-MailPublicFolder -IgnoreMissingFolderLink:$true" for each AD object that is a legacy system folder and resume the migration

Being the silly person I am, I assumed that this command needed to be run against the legacy Public Folders On Premise, but apparently -IgnoreMissingFolderLink is not a parameter in Exchange 2010. What I actually needed to do, which is not obvious from the error message,  was to run this command in Exchange Online. I ended up using a catch all command, which looked like this:

Get-MailPublicFolder | Set-MailPublicFolder -IgnoreMissingFolderLink:$true

Once this was done, I stopped the migration batch, and then started it again. It then performed it’s initial sync and I was able to continue the migration!

 

ADFS & Multi Factor Authentication – Force MFA for browser based access to Office 365

Azure MFA is a great concept in itself, especially when applied to Office 365 using ADFS, but quite often there is a need for granular control over when MFA is actually applied. There are GUI options for enabling MFA just for extranet requests, but this poses several problems:

  1. Issues with Autodiscover requests – these are proxied from Office 365 and thus always route via the ADFS Proxy servers. This means that all Autodiscover requests, no matter where the client is located, appear to originate from the internet, which poses a problem when applying MFA to only be enforced for Extranet requests, as Outlook clients will be prompted for MFA even when inside the Intranet.
  2. Mobile Applications – These will likely always come from Extranet locations. It is undesirable, and in some cases unsupported, for these applications to use MFA whenever they are opened.
  3. Skype for Business client – It is not desired to require MFA when Skype for Business is opened from the Extranet.

One thing worth mentioning straight off the bat is that using the Azure MFA server with ADFS requires the ADFS Proxies either use the WAP role in Server 2012 R2 or a 3rd party proxy which can add the claim “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy” to show whether the connection is coming from the Extranet or not.

If you need more granular control than Extranet or Intranet (taking into account the considerations above), you need to use the Azure MFA server option to integrate MFA with ADFS. This provides the ability to great custom rules for your relying parties. There is a great guide on installation of this service here: https://azure.microsoft.com/en-gb/documentation/articles/multi-factor-authentication-get-started-adfs-w2k12/#securing-windows-server-2012-r2-ad-fs-with-azure-multi-factor-authentication-server

In addition to the MFA Server configuration itself, a custom ADFS claim needs to configured to force MFA if certain conditions are present. This can be very fiddly and currently there are not any GUI based tools to achieve this, so PowerShell is your friend!

For my example, I wanted to force MFA if the request comes from a browser on the extranet. This ensures that Outlook, the Skype for Business client and mobile applications never require MFA, but any access from browsers outside of the local network are MFA secured. The claim looks like this:

c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && 

c1:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "(/adfs/ls)|(/adfs/oauth2)"] 

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");

This rule was applied using the below command. First, the above rule was set as the $mfarule variable.

$mfarule='c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c1:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "(/adfs/ls)|(/adfs/oauth2)"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");'

Then the Office 365 Relying Party Trust was set as a variable.

$rpt = Get-AdfsRelyingPartyTrust –Name "Microsoft Office 365 Identity Platform"

And then the Authentication Rule was applied to the Relying Party!

Set-AdfsRelyingPartyTrust –TargetRelyingParty $rpt –AdditionalAuthenticationRules $mfarule

Before this was placed into production, a similar claim rule was applied which limited MFA to only a particular group of users. The claim for this is shown below and the group is specified using the ObjectSID. This is useful for testing the rule out on a subset of users:

c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c1:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "(/adfs/ls)|(/adfs/oauth2)"] && c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-3388933763-2387696048-3050347461-86618"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");

This gave us the settings we needed for compliance, and figuring out the claim rules was complicated but quite fun. I hear that all this functionality will be moving into a GUI based system in Server 2016 so that’ll be nice.

Anyway, if anybody has any particular claim types they would like for particular situations, let me know and we can try and put something together

P.S. Huge thanks to Mark Vale and his article on the same subject, it helped me find the light in a very dark tunnel!

http://skype4b.uk/2015/06/12/adfs-multifactor-authentication-not-good-for-office-365/

Office 365 Hybrid – On Premise Room Mailboxes not available in OWA

I came across an issue today wherein a user whose mailbox was hosted on Office 365 attempted to use OWA to book a meeting On Premise, and was told that there were no rooms available. The list simply didn’t contain any rooms. The Room Mailboxes were synchronised to Office 365 using the AADSync tool, however OWA knew nothing about them. When using Outlook, the Rooms were shown correctly, so this was just an issue with OWA, not with Room Mailboxes per se.

After a little digging, I found the following KB article: https://support.microsoft.com/en-us/kb/2904381 which explains that a Room List should be created and synchronised to Office 365 to get this working in OWA.

However the PowerShell cmdlet in the KB article fell a little short as I had over 100 Rooms to add into the Distribution Group. This was the PowerShell I ended up using:

$members=Get-Mailbox -RecipientTypeDetails RoomMailbox
New-DistributionGroup -Name "RoomList" -RoomList -Members $Members

I then moved the newly created Distribution Group into the correct OU and performed a Directory Sync. The RoomList showed up instantly, but it took 5-10 minutes for it to become populated. Once this was all done, the Rooms were available!

RoomOWA

Restrict OneDrive for Business synchronisation to domain joined machines only

Edit: This can now be done in a GUI by using the OneDrive Admin Centre at admin.onedrive.com. It also allows Mac clients by default now.

A quick preface to this post; making the changes listed below will stop all Mac clients from being able to sync their OneDrive, and will not stop mobile devices from connecting to OneDrive using the app. It also doesn’t stop the downloading or uploading of files from the web access of OneDrive. It’s sole purpose is to limit the functionality of the Windows OneDrive for Business sync client!

Firstly you need to find out the GUID for the Active Directory domain which you want to be able to sync OneDrive for Business from. To do this, log onto a Domain Controller and run the Active Directory Module for PowerShell, or run a normal PowerShell window and run

import-module ActiveDirectory

in order to get the correct cmdlets imported. Get a list of your domains by running

(Get-ADForest).Domains

And then use this command to get a list of GUIDs which will be in the same order as your domain list

$domains = (Get-ADForest).Domains; foreach($d in $domains) {Get-ADDomain -Identity $d | Select ObjectGuid}

From this you should be able to work out the correct GUID for your Active Directory domain name. Copy and paste that sucker into notepad. Now head on over to a SharePoint Online PowerShell session using the SharePoint Online Powershell module and Connect-SPOService and run

Set-SPOTenantSyncClientRestriction  -Enable -DomainGuids "b45b7d67-e68b-430e-bb76-2a31948b3221”

Make sure you replace the GUID here with the GUID you copied and pasted earlier and this setting will lock down your OneDrive for Business synchronisation to client which have the same domain GUID. If you want to enter more than one GUID, separate them with commas.

Hope this helps and sorry if it’s a bit of a haphazard blog post, it was written in a bit of a hurry!

Disable Clutter feature for all users in Office 365

DisableClutter

Now I’m not one to advocate turning features off in Office 365, but sometimes when deploying Office 365 for a customer, there is simply too much change at one time. And if there is one thing that users hate, it is too much change!

Many customers I work with will choose to disable Skype for Business or OneDrive during the initial migration of email into the cloud. They can then plan the roll out of these services at a later date, and educate users on how to make the best use of it. This is much more preferable to just throwing a load of new functionality at users and expecting them to just start using it all with no training. After all, adoption of new technology starts with giving users the knowledge and power to be able to use the tools effectively!

And on that subject is a feature which has baffled and confused some users. This is called ‘Clutter’, and it uses machine learning to help organise the email which you don’t look at regularly, but may not want to delete (for example, that weekly newsletter from exchangeserverpro.com). This mail is automatically moved into your Clutter folder, clearing up your inbox so that it contains the email you need to know about now!

Email which is automatically moved out of your inbox does have the ability to freak users out if they aren’t expecting it, so you may want to disable this at first and then enable once you can communicate it’s purpose and usefulness to the business. To do this, you will need to make use of the mighty PowerShell!

Log yourself into Exchange Online PowerShell and use the following commands depending on your needs:

To disable Clutter for a single user:

Set-Clutter -Identity user@domain.com -Enable $false

To disable Clutter for all users:

Get-Mailbox | Set-Clutter -Enable $false

This command has a long list of outputs. If you want to hide the outputs, just add > $null to the end of the command, like this:

Get-Mailbox | Set-Clutter -Enable $false > $null

You can check to see if a mailbox has Clutter enabled by running:

Get-Clutter -Identity MailboxID | fl

And look for the IsEnabled parameter, which should be set to False!

So in summary, feel free to turn it off, but whatever you do, make sure you turn it on again as Clutter is definitely a useful tool to have in your email armoury!

Hybrid Configuration Wizard and Multiple Domains – Get-FederationInformation cmdlet had thrown an exception

When running the Exchange Hybrid Wizard for multiple domains, you may find it fails and shows you the error below:

Execution of the Get-FederationInformation cmdlet had thrown an exception. This may indicate invalid parameters in your Hybrid Configuration settings.

Federation information could not be received from the external organization.

In addition to this, if you check the Update-HybridConfiguration log file in the Exchange Logging directory, you will find that the failure occurs just after the command Get-FederationInformation is run on one of your domains.

The first test you can run is to login to Microsoft Online PowerShell and try running:

Get-FederationInformation -DomainName domain.com

If this comes back with an error, then you likely have an issue with Autodiscover. It may be that autodiscover is not configured for all your domains, which is quite a common occurrence. There are 2 traditional ways to get around this:

  1. Configure multiple SRV DNS records to point Autodiscover at your primary Autodiscover service
  2. Add all your autodiscover domains to your SAN certificate and configure A records to point autodiscover to the public facing IP of your Exchange server/s

As of Exchange 2010 SP3 UR6 and Exchange 2012 SP1 however, there is a much cleaner way of doing this.

  1. Make sure Autodiscover is configured and working on your Primary SMTP domain (use https://testconnectivity.microsoft.com/ to verify functionality)
  2. Run the HCW (Hybrid Configuration Wizard) for just your Primary domain. This should complete without issues
  3. Go into the Exchange Management Shell on your On Premise Exchange environment and run:

Set-HybridConfiguration -Domains domainb.com,domainc.com,domain.com,autod:domaina.com

Where domaina.com is your Primary SMTP domain. This sets your autodiscover domain for all domains to domaina.com.

  1. Re-run the HCW. You should now see all domains populated and the HCW should complete successfully.

Restrict access to OneDrive for Business

Edit: A new admin centre for OneDrive has been launched as of December 2016, and allows for much more granular control over what can be synchronised, and where from. Check it out at admin.onedrive.com

A question which I get asked quite frequently is whether OneDrive for Business can be blocked, locked down, or restricted. Whatever your reasons for doing this, there are some things you can do to restrict access.

As a little bit of background information, OneDrive for Business is not the same as your personal OneDrive, and is essentially your own private SharePoint library. If you have no plans to use SharePoint Online, then the easiest way to block access to OneDrive for Business is to simply remove the SharePoint Online license from the users in question. This is done in the sub menu of the licensing options for a user and can be applied on a per user basis.

SharePoint License

Another thing you can do is to hide the OneDrive button from the portal. This is done under the SharePoint Admin section of the Office 365 portal, under the Settings Tab. This setting applies to all users.

Hide OneDrive for Business

With this option selected, OneDrive will not show up in the Portal menu, along with the Office Web Apps.

Hide OneDrive for Business

We can also stop users from being able to create a personal site at all, by going into the User Profiles area of the SharePoint admin center. Go into Manage User Permissions and remove ‘Everyone except external users’. This will stop any users from being able to create their own OneDrive for Business sites. If you like, you can then add users or groups into this list who you would like to be able to create a OneDrive for Business site.

Personal Site Lockdown

This doesn’t stop any users who have already created their OneDrive for Business sites from accessing it if they know the direct URL or have added it as a favourite into their Internet Browser. I won’t be covering that scenario here, however if this is something you would like more information on, let me know in the comments and I will put a post together!

The perils of deleting a Shared Mailbox user account

The world of IT is a perilous and dangerous place to be. Particularly when your mouse is hovering over that ‘Delete’ button.

I came across an incident recently where a user had left a company, and as per standard practice for leavers in Office 365, their mailbox had been converted to a Shared Mailbox to free up the license whilst preserving mailbox access for their manager. As this mailbox was now Shared and the user was no longer present, the administrator deleted the user account in question out of Active Directory. The effect of this was that the user and mailbox in Office 365 was also deleted. This behaviour is something worth remembering if you are the administrator of an Office 365 environment.

I could see that the mailbox was listed in the Office 365 ECP under Recipients>Mailboxes>…>Deleted Mailboxes therefore it was recoverable. I went for the Recover option and was faced with the error:

'User not found'

Uh oh. Usually this process would recreate the MSOL User account along with restoring the mailbox. I checked in the Office 365 Admin Centre and the user had not been recreated, however if I went to the ECP and Recipients>Shared I could see the restored mailbox. Unfortunately though, the mailbox was only half there and the details pane showed no email address, just ‘the items you’re trying to open couldn’t be found’:

ItemCouldntbeFound

My mailbox was stuck in limbo! I went into Powershell for Exchange Online and ran Get-Mailbox, but the Shared mailbox wasn’t listed. I then ran Get-Mailbox -SoftDeletedUsers and the Shared mailbox wasn’t here either. This wasn’t looking good.

I was concerned that if I deleted the limbo mailbox then I would lose it forever, but I had no choice but to try. I got another error message ‘User not found’ when trying to delete the mailbox but after a minute or two it showed up in Deleted Mailboxes and when running Get-Mailbox -SoftDeletedUsers it also appeared. Hurrah!

My mantra whenever I work with Exchange, online or on premise is that if something doesn’t work in the GUI, try it in Powershell. So I ran the command shown below to try and recover the mailbox, and by the Power of the Shell, it worked!

Undo-SoftDeletedMailbox sharedmailbox@doubledit.co.uk -WindowsLiveID sharedmailbox@doubledit.co.uk -Password (ConvertTo-SecureString -String ‘Passw0rd’ -AsPlainText -Force)

In my opinion, this looks like a GUI based bug when recovering a Shared Mailbox. User mailboxes restore without a hitch, but Shared Mailboxes are not so friendly via the GUI. The answer, as usual, is the mighty Powershell.