Keep up to date with Office 365 IP Changes

1 Comment

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!

 

Script – control Client Access features using set-mailbox

Leave a comment

I put together a short script recently which will enumerate all users in an Office 365 Group (Security/Distribution/O365Group) and disable certain Client Access features. In my case, I wanted to disabled IMAP, POP and MAPI connectivity. This leaves a user only able to perform Kiosk style connectivity through either OWA, EWS or ActiveSync. The users in question had E1 licenses, but the customer wanted to limit connectivity so that rich mail clients such as Outlook could not be used.

The script looks like this:

$group=Get-MsolGroup | Where {$_.DisplayName -eq "uk-dg-kiosk"}
$groupid=$group.ObjectId
$groupmembers=Get-MSOLGroupMember -GroupObjectId $groupid
ForEach ($member in $groupmembers.emailaddress)
{Set-CASMailbox $member -ImapEnabled $false -MAPIEnabled $false -PopEnabled $false}
ForEach ($member in $groupmembers.emailaddress)
{Get-CASMailbox $member}

I have also created a similar script which will apply to any user which has a particular license SKU:

$licensepack=Get-MsolUser -All | Where {$_.Licenses.AccountSKUId -ccontains "MISSTECH:ENTERPRISEPACK"}
ForEach ($user in $licensepack.userprincipalname)
{Set-CASMailbox $user -ImapEnabled $false -MAPIEnabled $false -PopEnabled $false}
ForEach ($user in $licensepack.userprincipalname)
{Get-CASMailbox $user}

This could be run on demand, or using a scheduled task. Using a scheduled task involves supplying credentials so be careful when you do this!

Have a look at my guide for setting up scheduled tasks with Office 365 to learn how to avoid using plain text passwords in your tasks: https://misstech.co.uk/2016/06/08/office-365-powershell-and-scheduled-tasks/

Till next time x

 

DNS Traffic Management Policies

Leave a comment

This awesome new Server 2016 feature can be used to create a DNS policy which responds to a query for the IP address of a web server with a different IP address based on the source subnet of the client.

Let’s take an example; we have ADFS configured in Azure using the following settings:

Hostname: sts.misstech.co.uk
Internal IP: 192.168.9.11
External IP: 57.119.128.179 (this is made up so don’t try and go there!)

There are 2 sites, London and Manchester. London has a VPN link to Azure, however Manchester has no route to Azure. Both sites are connected to each other and the Domain Controller is located in London.

This means that London users (on 192.168.10.0/24) can access ADFS, however Manchester users (on 192.168.11.0/24) cannot access ADFS using the internal IP. We need to route Manchester users to ADFS via the external ADFS IP, but how to do this when they are resolving DNS records via the same Domain Controller? Host files can do this but that is complex and doesn’t allow for mobility. Enter Traffic Management using Server 2016.

To do this, the following steps need to do performed.

·       First, add the subnets which you want to use for traffic management.

Add–DnsServerClientSubnet –Name “Manchester” –IPv4Subnet “192.168.11.0/24” –PassThru

·       Next, add the subnet associated zone. The zone must already exist for this command to work.

Add-DnsServerZoneScope -ZoneName “eacsdemo.online” -Name “Manchester” -PassThru

·       Add the DNS Resource Record

Add-DnsServerResourceRecord -ZoneName “eacsdemo.online” -A -Name “sts” -IPv4Address “52.169.178.129” -ZoneScope “Manchester” -PassThru

·       Add the Traffic Management Policy to route Manchester requests through to

Add-DnsServerQueryResolutionPolicy -Name “ManchesterPolicy” -Action ALLOW -ClientSubnet “eq,Manchester” -ZoneScope “Manchester,1” -ZoneName “eacsdemo.online” -PassThru

These policies are very versatile, allowing you to combine multiple parameters (using AND/OR) such as client subnet, protocol, or time of day to create complex policies which can help you direct clients to the correct location.

I’ll finish this post with a small tip; if you want to remove or get the policy, make sure you specify the zone name or a null value will be returned. For example:

Get-DnsServerQueryResolutionPolicy -ZoneName “misstech.co.uk” -PassThru

remove-DnsServerQueryResolutionPolicy -ZoneName “misstech.co.uk” -PassThru

 

Azure Classic to Resource Manager Migration – Validation failed

Leave a comment

I am starting to investigate the migration of resources from Azures Classic deployment mode into the shiny Azure Resource Manager mode.

The first step for me was to attempt to validate the VNET which I wanted to migrate to see if it was compatible. I ran the command listed on the following website (https://azure.microsoft.com/en-gb/documentation/articles/virtual-machines-windows-ps-migration-classic-resource-manager/)

    Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName

As I expected (nothing is ever simple is it?!) I received an error as shown below. The problem was that the validationmessages shown was limited and didn’t really show me any detail. In my case all it showed me was the name of my VNET.

Validation failed.  Please see ValidationMessages for details

In order to get some more detailed information out of the cmdlet, I ended up saving the validation command to a variable and then calling the variable, as shown below:

$validate = Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName -Verbose

$validate.validationmessages

This gave me lots of detail and I discovered that I had typed the VNET name incorrectly. D’oh! I forgot that when you create a Classic VNET in the new portal, the actual name of the VNET is not what you see in the new portal. You need to have a look in the old manage.windowsazure.com portal to see the actual name.

Hopefully this helps some folk out there!

Azure RMS – File Classification Infrastructure Fail

Leave a comment

I’ve been doing a bit of work recently with Azure RMS and FCI (using FSRM) to protect files located on traditional file servers.

One issue I came across whilst following various pieces of guidance which I found online was related to file classification. When attempting to run my File Management Task I was seeing no results.

I attempted to run the RMS protection script manually from PowerShell ISE (called RMS-Protect-FCI.ps1 in my case) and this returned an error as follows:

RMSProtection module not loaded

I had followed all the instructions I had seen so far, and luckily this error is quite descriptive. All I ended up having to do was to install the RMS Protection Tool, which can be found here: https://www.microsoft.com/en-us/download/details.aspx?id=47256

It’s important to remember to install the pre-requisites for this too, as otherwise you will receive another error about failure to connect using bpostenantid. The key element I missed out was the RMS Client, found here: https://www.microsoft.com/en-us/download/details.aspx?id=38396

Essentially I didn’t read the fine print and got lost in Powershell without installing the software I needed!

Some of the resources I used to configure this are listed below. All in all, FCI is a very powerful tool for protecting File Servers with RMS, but it has a lot of configuration steps and can appear (on the surface) very complex indeed!

https://docs.microsoft.com/en-us/information-protection/rms-client/configure-fci
https://technet.microsoft.com/library/hh847874.aspx
https://msdn.microsoft.com/library/mt433202.aspx
http://simon-may.com/setup-azure-rms-file-protection-encryption-file-classification-infrastructure-fci-prem-file-servers/
https://docs.microsoft.com/en-us/information-protection/deploy-use/configure-servers-rms-connector#configuring-a-file-server-for-file-classification-infrastructure-to-use-the-connector

 

 

 

Public Folder Migration Fail #2

1 Comment

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

6 Comments

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.