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.
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
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)
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 then this script isn't for you, you must make the change on-premises and the change will be synchronised to Exchange Online.
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 'dkimtest.c3365labs.co.uk' 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.
There are a lot of articles out there at the moment talking about ReFS and using this file system with Exchange, highlighting where appropriate, the supportability of doing so. I love the fact people are blogging and getting this information out there.
I think it's a great technology and have been using it for some time for Exchange 2013 and also Exchange 2016. But rather than concentrate on what others have already posted. I thought I'd highlight another important area.
In this post I want to highlight what most people haven't – ReFS when using Exchange AutoReseed.
Let's take a look at two DAGs, using Get-DatabaseAvailabilityGroup. One is Exchange 2013 and the other Exchange 2016:
Fantastic. That doesn't tell us too much though.
Let's see what Autoreseed settings are present :
Fantastic. That still doesn't tell us much though about anything to do with the file system you are using for your Exchange databases.
Let's take a look at all Auto* settings:
Again we get more information, including FIPS and BitLocker information but this still doesn't show us that AutoReseed is clear about what file system is in use.
So let's sit back and think about AutoReseed. It will take a spare disk (RAID/JBOD) and format it and basically auto reseed the database that has just disappeared due to a failed disk in your Exchange Mailbox server.
It's a fantastic concept, although admittedly something that's used in larger Enterprise Organisations (and was no doubt conceived in Office 365).
So... You're using AutoReseed. You've made a decision to go with ReFS. So how does AutoReseed know what file system to format the disk in? Well that's down to DiskReclaimer. We can look at the following Technet Article for a breakdown of AutoReseed and DiskReclaimer:
We can see both DAGs are using NTFS, this is what DiskReclaimer will look to when formatting a disk for AutoReseed.
Let's look at the file system in use for the Exchange 2016 DAG databases on one of the Mailbox Servers:
We can see we are using ReFS.
Therefore we need to ensure the –FileSystem parameter for our Exchange 2016 DAG is set to use ReFS.
Let's update it.
Set-DatabaseAvailabilityGroup "your Exchange 2013 or 2016 DAG here" –FileSystem ReFS
We can now see that the Exchange 2016 DAG in question, which is using ReFS for its Exchange Database and Log disks, is set correctly. This will ensure AutoReseed formats any spares correctly in the event of failed disks.
What happens if this isn't set correctly? Of course it will still work, having some disks as NTFS and some as ReFS – but that's not exactly a great consistent platform to have, and this should be set as part of your Administrative ownership where AutoReseed is used.
You can of course deviate from the default setting and disable DiskReclaimer and format your drives manually – but where's the fun in that?
This allowed you to simply and easily copy your existing Activesync policies to your Exchange Online tenant in Office 365 rather than having to setup them up again. This was always very useful in a perpetual Hybrid environment where co-existence may be ultimately permanent, or indeed if you're just simply migrating all users and removing your Exchange on premise presence.
I am pleased to announce the next release today, ApplyEASMailboxPolicy2EXO.ps1.
This script will take your on premise users Activesync Mailbox Policy that is assigned to them, and then apply the policy once the user has been moved in a Cutover, Staged, Hybrid or third party migration to Exchange Online.
It will also check to see if the user actually has Activesync enabled, if the user is disabled, it will disable it for their Exchange Online mailbox also.
This simplifies mobile device access in a Mobile First, Cloud First Office 365 engagement.
If you are performing a 'Cutover' migration, either natively or using third party tools (you are moving all mailboxes to Exchange Online at once) simply run the script. If this is more than 1000 users you can specify a higher setting with the –ResultSize switch parameter.
If you are performing a 'Staged' migration, or moving select mailboxes in a Hybrid state or indeed select mailboxes with a third party, then you can pipe a csv file with the users that have moved using the –Staged switch parameter.
I'll run you through both scenarios.
So first of all let's look at the Activesync Mailbox Policy applied to the users on premise. We can see that each user has a specific policy and that infact 'New User 3' has Activesync disabled.
Let's look in Exchange Online as we have just performed a Cutover Migration – all users should have the Default policy applied and be enabled for Activesync.
Ok so let's start running the script. We have already created the Activesync Mailbox Policies using my previous script here Open a PS window and run the PS1 script.
The accompanying text will explain the switches to you. As this is a Cutover (you have moved all users at once) we simply press Y to proceed.
It will now do two things. The first thing it will do is gather which Activesync Policy is applied to your on premise users. It will collate the information into a locally saved CSV file that will be created in the same location the PS1 file is run from.
Once this has been collected it will then ask for your Office 365 tenants admin credentials. Enter an account that has the necessary Exchange permissions.
It will then import the configuration file, inform you of the total number of mailboxes to configure, and start configuring your Exchange Online mailboxes.
Once it has completed, it will inform you and then disconnect your Exchange Online PS session.
It will then inform you that you can then close the PS window.
So let's look at them in Exchange Online. Has the change been implemented? You bet!
So what happens if you aren't moving all mailboxes at once? For example a staged migration? Well you can input a CSV of the mailboxes you have moved into the script. Let's take a look.
Run the script with the –Staged parameter and specify your CSV.
Specify Yes to continue.
You will this time be asked for your Staged migration CSV file.
Enter your CSV path, note that you can enter multiples if you so wish, to finish simply press Enter without adding another CSV.
Once it has informed you it has ingested the CSV file it will then make a connection to Exchange Online. Enter your tenant admin credentials with relevant Exchange Online permissions.
It will now make the connection to Exchange Online and perform the necessary changes on those specific mailboxes. Note that this time it says there's only 2 mailboxes to change. That is because only 2 mailboxes were in my staged CSV file.