Thursday 22 September 2016

Validating email addresses for Exchange recipients before migrating to Exchange Online

This is now set to 400 from 200 as per this Microsoft article here. I've updated accordingly.

Recently Exchange Online has added a limit to the number of proxy addresses (email addresses) an object can have (mail enabled user or mailbox for example) in Exchange Online.

This has gone from a seemingly unlimited number to "400".

This poses a problem for any migrations, Hybrid or otherwise, where an on-premises mailbox has more than 200 email addresses assigned to it.

Microsoft has published this limiting change, although buried, here.

So before migrating to Exchange Online it may be wise to check for any recipients that have more than 200 email addresses; you can then resolve the issue and have a better migration experience.

To check:

Get-Recipient | Where {($_.EmailAddresses).count -gt 400}

In the example below I have used 'Get-Mailbox', but this is only to limit the number of returns for this blog post example. The first shows the command, the second shows the command bringing back any mailboxes with email addresses of more than 10, and finally in the third I am getting the all clear as none have over 200.

If you have over 1000 objects don't forget -ResultSize!

Get-Recipient -ResultSize unlimited | Where {($_.EmailAddresses).count -gt 400}

Have a great week!

Oliver Moazzezi
Twitter: @Olivermoazzezi

Friday 9 September 2016

Taking a peek at a UK provisioned Office 365 Tenant

Microsoft announced on the 7th of September that the UK datacentres for Office 365 and Azure services were now available to a great fanfare here and here.

But if you provision a UK tenant (which is as simple as selecting your region as 'United Kingdom' when you sign up - it's not so straight forward on getting an existing tenant moved - more on that in a future blog post soon) what exactly, is in the UK?

From a previous blog post you can see how we can identify the location of the service instances for your Office 365 tenant. So let's take a look!

At first glance it doesn't look much different to a normal 'EU/EMEA' provisioned tenant. But looking further we can see both Exchange Online and SharePoint Online are clearly UK based.

That's all well and good - but services like Exchange Online Protection still show their location as EMEA? Let's dig a little deeper to see if this is true.

Grabbing the MX records for the tenant I can look up the IP addresses against the RIPE database.

Looking on RIPE I can see that in fact, Exchange Online Protection is actually UK based also.

At this time, I haven't been able to confirm the location of Skype for Business Online - i'll update the post when I have dug a little deeper - but we can see your Exchange and SharePoint services are now hosted fully within the UK.

Sorry for the lack of posts for the last two months, I've become a father again and life is a little devoid of spare time (and sleep!) right now!

Update! You can view Microsoft datacentre regions here and it does appears that Skype for Business Online has not made it into the UK datacentres yet. The locales are London and Durham./

Have a a great week!
Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi

Thursday 23 June 2016

Office 365 Enterprise Mobility Suite overview

I don't normally mix work on my personal blog, but here's a webinar I did on Enterprise Mobility Suite with Office 365 which has some great information on the features below.

This covers, Azure AD Premium, Azure RMS Premium, Advanced Threat Analytics and Intune.

Have a a great week!

Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi

Friday 29 April 2016

Where are my Office 365 services located?

There’s been a few posts on this over the years, extracting information from Exchange Online for example and deducing the Data Centre locations and what respective rack or server you are on, but I came across this rather neat command the other day that I wanted to share that can give you an overview of all your Office 365 service locations.

Get-MsOlCompanyInformation is a standard Azure AD Powershell module command and mentioned here under MSDN, but the parameter I want doesn’t officially exist as a listed parameter when scrutinising TechNet/MSDN. It states that one of the things it does (in fact it’s the first thing on the list) that it gets “A list of the services for the company”. Interestingly it is mentioned in this Microsoft KB article “Directory Synchronisation for Office 365, Azure, or Intune can’t be activated or deactivated” – I presume so they can find the location of where the tenants service is running from, arming the caller when they phone through to Microsoft for support if there is a continuing issue with their Azure AD instance.

The parameter I am referring to is "AuthorizedServicesInstances", please take the time to read on.

So let’s first take a look at Get-MsOlCompanyInformation and see what it brings back.

You can see it doesn’t state any service location information, let’s see if we can expose anything else


An |FL brings back the same information, let’s try Get-MsOlCompanyInformation |select *


Aha lots more information that isn’t otherwise exposed by default.

So let’s take a look at those service instances using (Get-MsOlCompanyInformation).AuthorisedServiceInstances


You can see above it lists all the services for my tenant and brings insight into their respective locations.

Sway – North America
RMSOnline – in the EU
Yammer – North America
WindowsAzure – EMEA
Exchange Online Protection – EMEA
Microsoft Communications Online (This is Skype for Business Online) – EMEA
Microsoft Office – North America
Sharepoint – this tells us nothing to help us decipher location
Exchange Online – shows us it’s in Europe, we can further disseminate this using EXO powershell should we so wish

We then have a variety of under the hood services, some Access Control Services – all EU based like my tenant is, then BDM, SMIT, Metro and DirectoryToCosmos.

I have to admit DirectoryToCosmos really grabbed my attention, Metro is assumed to be the UI that is delivered to you to access your services, (screen shot below from this tenant). It is essentially the tiles experience and I assume still has its internal legacy name.


So back to Cosmos!

It makes sense that all data for an Office 365 tenant is stored somewhere, where else can we get all that good data that allows us to use products like Delve, Delve Analytics or Office 365 Reporting?

Searching the internet there’s a Microsoft Research document that relates to Cosmos, you can read it here, it’s fascinating. It’s the first result returned in Bing when searching ‘Cosmos Reporting’, I suggest searching yourself as other hits are returned.

So Microsoft creates Cosmos for Bing Data and Big Data Analytics. Makes sense right? It appears to be a ground up development for Bing, but has obviously evolved into something much much more.

The good news is that you can consume Cosmos yourself, it’s sold today in Azure as Azure Data Lake, and on that very front page mentions that it is consumed by Office 365 for Big Data and analytics, as well as serving other Microsoft platforms like Xbox Live and Skype among many others.

So what’s SMIT and BDM? No idea, answers on a postcard please, I’ll of course update the blog with any public information that’s available on them.

So want to check where you Office 365 services are located? Simply run in Azure AD Powershell once connected to your tenant (Get-MsOlCompanyInformation).AuthorisedServiceInstances

Have fun,

Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi

Thursday 24 March 2016 is now!

I've rebranded my blog!

As we embrace the cloud, I would imagine we won't see the traditional Microsoft waves anymore, but this will do for now until I rebrand once more.

More Office 365, Skype for Business, Exchange Server and Azure MFA posts coming soon. Maybe with a splash of EMS!

Take care,

Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi

Thursday 17 March 2016

Office 365 - Allow Distribution Groups to receive email externally

I published this script on the TechNet Gallery yesterday. You can find it here:

The script will connect to your tenant and allow each Distribution Group to receive email from an external address, rather than only from within your Org which is the default.

The script supports the –CSV parameter, this is for when you just want to externally enable a subset of distribution groups as you do actually want some to be internal only.

Anyhow here's a quick guide to the script in action.

Run the script

Take some time to read the intro – it does give you some good information like, for example, the –CSV switch. Hit Y to continue

Once you've said Y, it will ask you for the tenant domain, now I have done this because if you're using an account that isn't an admin of the tenant (or an account with the relevant RBAC rights), you can actually connect to a tenant under the Partner model

It will ask you to confirm you details, Y to continue

Enter your credentials for the tenant

It will now connect to Exchange Online

And prompt you to confirm you've connected to the right tenant (again if you're going in with your Partner Admin credentials over a tenant you are helping to administer)

Hit Y to start making the changes

Once it has completed it will give you a summary of the total number of distribution groups found, and the changes made, and also give you a total of any that have not had any changes made (which will be ZERO unless you have used the –CSV option)

That's it!

If you want to only enable it for certain distribution groups use the –CSV switch and create a CSV with a column for 'Identity' and the names of the Distribution Groups.

If you are running direction synchronisation with AADSync or AADConnect, and synchronising Groups, then this script isn't for you, you must make the change on-premises and the change will be synchronised to Exchange Online. If your Groups are Cloud based however, and you're only synchronising Users - then this will work for you.

Take care,

Oliver Moazzezi – MVP Exchange Server
Twitter: @Olivermoazzezi

Friday 11 March 2016

Office 365 DKIM: No DKIM keys saved for this domain

I had the pleasure of enabling DKIM for an Office 365 tenant yesterday. I won't go into any details on how you do it, as that's been covered many times by various bloggers out on the internet.

One thing did get when enabling it however, was that a domain that was added to the tenant afterwards, wasn't able to be enabled for DKIM. It simply sat there stating "No DKIM keys saved for this domain".

This post is on how you resolve it.

So let's take a look at the issue. I login to the Exchange Admin Center, select |Protection, then |dkim

You can see the domain status states "No DKIM keys saved for this domain". If I check others you can see they are either in an enabled state, or available to be enabled:

So how do we resolve it? Well you'll need to use Powershell.

Let's open a session to the tenant and check the status of DKIM signing for all domains by using Get-DkimSigningConfig. You can see in the below Powershell window the domain isn't stated at all.

As '' simply isn't there, we need to add it. To forcefully add it and get Office 365 to realise it's there to use, let's run this Powershell command:

New-DkimSigningConfig –DomainName "The domain that has the error message" –Enabled $true

We will get a CNAME error if we haven't set the CNAME records up, which isn't an issue, just means we'll have to do them before we can enable it.

So what's the status of this domain look like in the EAC now?

Fantastic! You can see the error "No DKIM keys saved for this domain" is removed and we can enable it (once we've done those CNAME records!!)

Out of interest, running Get-DkimSigningConfig now shows the domain in the list and set as disabled.

Oliver Moazzezi – MVP Exchange Server
Twitter: @Olivermoazzezi