UPDATE: The post below was written 3 years ago and due to changes in Office 365 and Azure Active Directory the method described can no longer be relied upon to give correct results. I recommend reading this post and utilising the script provided.
In our world of shared hosted services, now known as Cloud customers often hear the term “tenant” being used. In the world of Office 365 we use this term quite a lot as it is a prime example of a multi-tenant system – much like an apartment block where we have our own space but share hallways, elevators, stairs, basement, etc.
As tenants in the Office 365 world we all get our own address space – usually denoted by .onmicrosoft.com. However as Office 365 shares a global name space, Company X in the US may already be on Office 365, so if Company X in Australia tries to register – they will not be able to use the same tenant name.
This wasn’t so much of an issue in BPOS (the predecessor to Office 365) as customers were separated into 3 global regions (microsoftonline.com, emea.microsoftonline.com, apac.microsoftonline.com) but as more people take up Office 365 the name space available gets smaller and smaller. Australian companies now find they need to add “au” at the end of their company name to form CompanyNameAU.onmicrosoft.com.
Honestly – why is all this an issue? Why does it warrant a blog post?
Because of SharePoint.
What customers don’t realise when signing up to Office 365 is that their tenant name (aka service domain) will also be used as their SharePoint URL. So signing up the full company name of ParadyneGlobalLogisticsSolutions.onmicrosoft.com also turns into ParadyneGlobalLogisticsSolutions.sharepoint.com – quite a mouthful!
An important note for customers looking at signing up to Office 365 is to choose their tenant domain carefully if they plan to use SharePoint Online. Using the above example a tenant name of PGLS.onmicrosoft.com might make more sense, translating into PGLS.sharepoint.com.
A question I’ve seen on the forums is when an organisation wants to find who owns a tenant name because it’s the same name as what they want to use – Microsoft will not help you here. Customers simply need to make do with what they can find available. Another common scenario is where a tenant name has been used for a 30-day trial but discontinued – these can take months to be purged from the system.
Unfortunately there is no way to see if a tenant domain is available before signing up. Well, not officially anyway.
We know that Office 365 automatically creates certain host records based on the tenant domain – so perhaps we could do some kind of search using DNS and see what we get back?
Two key DNS records are generated within Office 365, these are: CustomerDomain.onmicrosoft.com & CustomerDomain.sharepoint.com
As a first attempt we might try to see if CustomerDomain.onmicrosoft.com resolves to an IP address or host record – it doesn’t.
Our second thought would be to perform a simple ping against the CustomerDomain.sharepoint.com to see if that resolves (usually to prodnetXX.sharepointonline.com). However this theory falls over if the customer using that tenant domain doesn’t subscribe to the SharePoint Online product as a standalone or part of the bundle plans.
The reverse however is true. If a customer subscribes to only SharePoint Online or Lync Online – they are automatically provisioned in the *.onmicrosoft.com domain space for their MX (Mail eXchange) records.
Breaking it down – to check if a tenant domain is available in Office 365 without having to go through the sign-up process, just perform a MX record nslookup on the desired tenant domain. See below:
Step 1 – confirming that the tenant only has SharePoint Online licenses
Step 2 – showing the only domain in the tenant
Step 3 – the nslookup showing the MX record
Yep – that tenant name is in use!