Keep up to date with Office 365 IP Changes

It’s quite common for administrators to get caught out by IP changes in the Office 365 pool, and to find a service becoming intermittently inaccessible due to the addition of an IP address range to the pool of IPs used by an Office 365 service.

Microsoft publish an RSS feed to make this a bit easier for admins to follow, however I wanted to take this one step further.

Using Microsoft Flow (or IFTTT if that’s your bag), you can configure an event so that an update to an RSS feed prompts an action. That action could be to send an email, to update SharePoint or Yammer, or to update a Spreadsheet (amongst others). People consume information in many different ways, and this is one way to customise the delivery of this information to suit the way you work.

As an example, I want to send an email to myself every time a change is made to the Office 365 IP address RSS feed. To do this, I have logged into Microsoft Flow and have created a new Flow for myself.

The trigger event will be an RSS feed to look for changes to https://support.office.com/en-us/o365ip/rss

Microsoft Flow RSS Trigger

Microsoft Flow RSS Trigger

 

The action event will be to send an email through to me to warn me to update my firewall:

Microsoft Flow Send an Email

Microsoft Flow Send an Email

 

That’s all there is to it! You can choose any action you desire when an update is made to the RSS feed.

Hope this helps!

 

Public Folder Migration Fail #2

Another day, another Public Folder migration failure. This time, on testing your Public Folder migration to Office 365, they appear to be unavailable and are not visible in the Outlook client.

I always follow the wonderful guide provided by Microsoft on how to migrate your Public Folders from Exchange > Office 365 (I’m not being sarcastic, it is actually a good guide) available here: https://technet.microsoft.com/en-GB/library/dn874017(v=exchg.150).aspx

The last two times I have run through this process, I have attempted to test the PF Migration on a single user prior to going live for all users. Microsoft suggest the following command for doing this:

Set-Mailbox -Identity <Test User> -DefaultPublicFolderMailbox <Public Folder Mailbox Identity>

However since the Exchange 2016 wave of Office 365 has gone live, this command no longer appears to have the desired effect. What seems to happen is that because the -IsExcludedFromServingHierarchy parameter is set to $true, the command does not fully enable the Public Folders for that user.

In both situations, I have taken the plunge and enabled Office 365 Public Folders for all users by running:

Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false

The end result (after a little patience) is that Public Folders become available for all users. I’m not sure if this is a general bug or a result of the Exchange 2016 backend of Office 365, but I’d be interested to hear your experiences!

 

Public Folder Migration Fail

The above title isn’t a surprise for anybody working in IT, but unusually for Public Folders, this one has a fairly simple fix!

The situation is thus; when attempting to complete a Public Folder migration to Office 365, you come across the following error:

Before finalizing the migration, it is necessary to lock down public folders on the legacy Exchange server (downtime required). Make sure public folder access is locked on the legacy Exchange server and then try to complete the batch again.

Public Folder migration error

The problem with this error is that you have already locked down Public Folders on the legacy Exchange Server by running:

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

So what’s an admin to do when they’ve already run the command they are being told needs to be run?! Some googling may lead you to the idea of rebooting the server, or restarting the Information Store. Both of these will work, but a much simpler solution is simply to dismount the Public Folder database/s, and then mount them. The PFs are already locked so are unavailable to the users so there is no negative impact of doing this.

TL;DR – turn it off, and turn it on again.

 

Office 365 PowerShell and Scheduled Tasks

There are many reasons why you might want to run PowerShell scripts against Office 365/Exchange Online on a schedule, so I won’t fuss with any examples. Here is how it is done.

First you must create an encoded script file which contains the password for the Exchange Online/Office 365 admin which you want to use to login. It is important that you create the .key file

a) on the computer which will be running the scheduled task
b) using the account which will run the Scheduled Task

This is because as only the creator can decrypt the .key file, and this can only be done on the computer which generated the key file. To create your encrypted password file, open Powershell and run the following command:

Read-Host "Enter Password" -AsSecureString |  ConvertFrom-SecureString | Out-File "C:\scripts\Password.txt"

This will ask you to enter the password and then give you a file full of rubbish. Now let’s do something with that rubbish! Your script to connect to Exchange Online and Office 365 should look like the following:

$TenantUname = "admin@myoffice365tenant.onmicrosoft.com"
$TenantPass = cat "c:\scripts\password.key" | ConvertTo-SecureString
$TenantCredentials = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $TenantUname, $TenantPass
$msoExchangeURL = “https://ps.outlook.com/powershell/”
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $msoExchangeURL -Credential $TenantCredentials -Authentication Basic -AllowRedirection 
Import-PSSession $session
Connect-MSOLService -Credential $TenantCredentials

After these lines, add in the Powershell commands you wish to run, or a reference to a script. Save this as a .ps1 file.

For example, Clutter can’t be disabled for the whole tenancy, so to get around this I might want to disable clutter for all my users every night by adding this line to the end of my script:

Get-Mailbox -ResultSize Unlimited | Set-Clutter -Enable $false

Once you are all done with your script, open Task Scheduler and create a new task.

On the general tab, ensure that the user account being used to run the task is the same account which created the password file, and make sure the ‘Run whether user is logged on or not’ is ticked. Add whichever time based triggers you need, and on the Actions page choose to ‘Start a Program’ with the following settings:

Program/script: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Add arguments: C:\Scripts\TestScript.ps1

Voila! You now have a script which uses an AES encrypted text file to connect to Exchange Online and Office 365 so that you can run your daily maintenance tasks from a single management server. Yay!

AADSync / AADConnect default Domain Controller

I came across an odd situation recently whereby my AADConnect installation had decided to communicate with a Domain Controller which was in another site, across an Active Directory replication link with a 180 minute replication interval. This was no good for my customer as they made their AD changes on the site local to AADConnect, so I decided to remedy this by forcing AADConnect to communicate with a particular DC. This can be useful for many reasons, and you can actually set a list of ‘preferred Domain Controllers’ to allow for fault tolerance.

To do this, go into the Synchronisation Service, head on over to the Connectors tab and find your Active Directory Domain Services Connector. The below example is synchronising multiple AD Forests. Once you’ve selected your domain, you can see which Domain Controller is currently in use by checking the ‘Connection Status’ area (shown in the central area of the below screenshot).

Synchronisation Service

To change the Domain Controller in use, go to the Properties tab for your domain (on the right hand ‘Actions’ pane). Go into the ‘Configure Directory Partitions’ tab and you will see a handy tick box entitled ‘Only use preferred domain controllers’.

AADConnect - Directory Partitions

Place a checkmark in this box, and a window will appear, allowing you to enter your shortlist of Domain Controllers.

AADConnect - Preferred DCs

Once you’ve entered your preferred DCs, OK your way out of these windows and hey presto, you are done! It’s a nice and easy task to perform, but not one I’ve seen documented online before.

Thanks for reading!

Setting the ImmutableID to $null

Here’s a small Friday afternoon snippet of useful information for all you Office 365/Identity nerds out there.

If you have converted an AAD user from ‘Synced with Active Directory’ to ‘In Cloud’ and you want to sync a new user object with that user, you will need to clear the ImmutableID and then match it up with the new user object. I’m planning on creating a more extensive post on that very subject in the near future, but for now, I’ll give you this titbit of information:

Clearing the ImmutableID is done using the Powershell command:

Set-MSOLUser -UserPrincipalName emily@misstech.co.uk -ImmutableID "$null"

You might think that those quote marks are a bit pointless, but you would be wrong! If you were to run the command as shown below, without the “” marks, it wouldn’t show you an error, but it also wouldn’t actually clear the ImmutableID.

Set-MSOLUser -UserPrincipalName emily@misstech.co.uk -ImmutableID $null

As with all things PowerShell, syntax is everything!

Shameless TechNet self promotion

I’ve just realised that I never shared this link. I wrote this technical piece for the TechNet UK Blog back in July 2015, and just thought I’d give it a bump. The subject matter is regarding the post-hybrid Office 365 landscape, and what you should be doing once you’ve migrated all your mailboxes (apart from get yourself an ‘I am a cloud god’ mug).

Office 365 – The Journey Continues

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&#8221; 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/

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!