What’s in a (tenant) name?

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!

 


Discover more from Loryan Strant, Microsoft 365 MVP

Subscribe to get the latest posts to your email.

14 comments

  1. How about just adding a cname record in public dns. That way you can create whatever name you want and point it the sp address.

    1. Adding a CNAME and pointing it to your SharePoint Online URL wouldn’t work (except in the case of public facing websites) as the host on the Microsoft end is looking for “tenantname.sharepoint.com” and won’t understand requests for “intranet.yourdomain.com”.

      1. some 2years old post, but is it not possible to add alternate url in sharepoint or hostheader in iis to accept another cname

      2. That’s not an option in SharePoint Online as you don’t have access to the server.

  2. Microsoft is quite the pain on this. We have found two “shadow IT” deployments from our company. Microsoft has verified that they were deployed using our company name and our companies address. Even though we have a big EA with them, and they know we are responsible for the companies IT, they will not give us any more information on the tenant spaces except that they belong to our company. So, two of the tenant names we would like to use have been snagged by non IT departments and we cannot even discuss it with them since we can’t find out who they are.

    1. A frustrating point.
      Microsoft have introduced some functionality where you try to verify a vanity domain name in a tenant – it now tells you which tenant it’s already in.
      However finding out who else has used the tenant domain I believe will remain as it is now due to privacy reasons. It’s possible that the person signed up using a trial so it’s not linked to your organisation specifically.
      I’d suggest getting your account manager to escalate internally.

  3. One of our staff used our org name on their MSDN trial and now we’re ramping up for a O365 project. I fear where this is headed…

    Next we’ll be hearing about domain squatting within the onMicrosoft name space. Very sad.

    Why ON EARTH did MS rush to market with the HNSC model for enterprise tenants?!

  4. Even if the domain appears available in the nslookup example, the domain might still be taken by Azure AD – which won’t automatically have MX records.

    1. True. This blog post comes from a simpler time when they did automatically have them. 🙂

Leave a Reply to MattCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from Loryan Strant, Microsoft 365 MVP

Subscribe now to keep reading and get access to the full archive.

Continue reading