Take care when naming your Office 365 tenant

This content is 9 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

When signing up for Office 365 there are two really important decisions:

  1. Where will my tenant be homed (based on the region selected at sign-up)?
  2. What will my tenant be called?

The reason these are so important is because, once set, they cannot be changed.

I’ll write more about the home location of the tenant in a future post (why it matters in some ways, and why it doesn’t in others) but, for now, let’s look at the tenant name.

To explain what this is, when you sign up for Office 365, a new tenant is created and given a name in the form tenantname.onmicrosoft.com.

By default, users log on with username@tenantname.onmicrosoft.com and that becomes their email address too. Other domain names can be added to the tenant (I have markwilson.onmicrosoft.com but I’ve also associated the markwilson.co.uk, markwilson.it, wilsonfamily.org.uk and several other domain names with the tenant) after which the user name can be changed accordingly, as well as the email addresses. The initial tenantname.onmicrosoft.com name can’t be removed though.

Indeed, the only time you’ll see the tenant name is in the URIs for SharePoint Online and OneDrive for Business which are tenantname.sharepoint.com and tenantname-my.sharepoint.com respectively.

Pick your name carefully. What seems a good idea today may not seem so good further down the road. I recently worked with a customer who now regrets the NT domain name used for their Active Directory being named after the town where they are based but it’s too risky to change it now. Similarly your Office 365 tenant name (which is actually your Microsoft Online Services tenant name) needs to be chosen with care. Personally, I’d avoid putting 365 in it as the scope is potentially much broader. companyname.onmicrosoft.com is probably about the safest bet, at least until your company merges with another company! Or you could go with something completely ambiguous like ABC123…

Further reading

About your initial onmicrosoft.com domain in Office 365.

Short takes: PowerShell to examine Azure AD tenants; check which Office 365 datacentre you’re using

This content is 9 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

More snippets from my ever-growing browser full of tabs…

PowerShell to get your Azure Active Directory tenant ID

Whilst researching Office 365 tenant names and their significance, I stumbled across some potentially useful PowerShell to read your Azure Active Directory tenant ID.

Get-AzureAccount

I’m not sure how to map that tenant ID (or even the subscription ID, which doesn’t seem to relate to any of my Office 365 subscriptions) to something meaningful… but it might be useful one day…

Script to retrieve basic Office 365 tenant details

I also found a script on the Microsoft TechNet Gallery to retrieve basic details for an Office 365 tenant (using Get-MsolDomain, Get-MSolAccountSku and Get-MSRole).

Check which datacentre you’re connected to in Exchange Online

Office 365 uses some smart DNS tricks to point you at the nearest Microsoft datacentre and then route requests across the Microsoft network. If you want to try this out and see where your requests are heading, just ping outlook.office365.com and see the name of the host that replies:

Getting started with Yammer

This content is 9 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Yammer has been around for years but a while back it was purchased by Microsoft. It’s kind of like Facebook, but for businesses, and now that it’s included in certain Office 365 plans, I’m increasingly finding myself talking to customers about it as they look to see what it can offer.

The thing about Yammer though, is that it’s (still) not very tightly integrated with Office 365.  It’s getting closer in that Yammer can be used to replace the SharePoint newsfeed and that you can now log on to Yammer with Office 365 credentials (avoiding the need to have a directory synchronisation connector with an on-premises Active Directory) but it’s still very loosely coupled.

Yammer has a stealth model for building a user base or, as Microsoft puts it, the “unique adoption model” of Yammer allows organisations to become social. Most companies will already be using it in pockets, under the radar of the IT department (or at least without their explicit consent) because all that’s needed to sign up to Yammer is an email address.

As soon as two or more people with the same domain name sign up, you have a network, in Yammer terminology.

Yammer Basic

The free Yammer Basic service allows people to communicate within a network, structured around an activity feed, which is a rich microblog to track what colleagues are doing, get instant feedback on running conversations, share documents and information on projects people are working on. Users can like posts, reply, and use hashtags/topics for social linking, flag a post and point to someone in a reply. They can also create/respond to polls to get ad-hoc opinion on an issue.

Yammer Groups allow for scoped topics of conversation – for example around a project, or a social activity. Users can follow other users or groups to select information that’s interesting to them – and Yammer will suggest people/groups to follow.

Yammer Enterprise

When an organisation is ready to adopt and manage Yammer centrally, they can add IT controls (essentially, bring it under control of an administrator who controls the creation of groups, membership of those groups, and many other settings).  This is done by upgrading to the Yammer Enterprise product, either as a standalone service or, more typically these days, integrated with an Office 365 subscription (typically an enterprise plan, but other plans are available).

In theory, activating Yammer on your Office 365 subscription is a simple step (described by Jethro Segers in his Office 365 tip of the day post). Unfortunately, when I tried with a customer last week it took over an hour (with the page telling me it would take between 1 and 30 minutes, so be patient! It also needs the domain name to be verified in the tenant, which may already be the case for other services, or may require some additional steps. The whole process is described in a Microsoft blog post from the French SharePoint GBS team.

Each Yammer network has its own URI. In the case of a company network it will be yammer.com/companyname, based on the email address used to create the network.  If multiple domain names are in use, they can be linked to the same network but the network will always be private to the company that owns it. Also, I found that one of my customers had two domains registered in Office 365 so we used the one associated with the parent (holding) company for yammer, and until we repeat the process to bring in the other domains, users are authenticating with their @holdingcompanyname.com addresses.

External networks

External networks can be created for collaboration outside the company – e.g. to business partners and I have started to create them with my customers for collaborating around projects, getting them used to using Yammer as we work together on an Office 365 pilot, for example. Access to external networks is by invitation only, but can include users from multiple organisations. Each external network has a parent, which retains overall control.

Wrap-up

In this post, I’ve described the basics of Yammer. I’m sure there are many other elements to consider but this is enough to be getting started with. I’m sure I’ll post some more as I find answers to my customers’ questions over the coming months and some of my colleagues hosted a webcast on Yammer recently, which can be viewed below:

For more information, check out:

Importing users to Office 365 from CSV file – username must be in UPN format

This content is 9 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Every now and again, I come across a piece of advice on the net from seemingly authoritative sources that’s just plain wrong. Or at least it’s factually correct but doesn’t answer the question that was asked.  One such example was a few weeks ago when I was uploading user details via CSV to bulk provision cloud accounts in Office 365.

The import was failing, telling me that “The user name is not valid. You can only use letters and numbers. No spaces”. Except that’s not really the problem here – we were using the CSV template downloaded from the Office 365 Admin Center and there were no letters and spaces.

Stupidly, I’d put in the user names – like MarkWilson – but of course Office 365 usernames are in UPN format.  What the message could (more helpfully) have said is “The user name is not valid. It should be in the format username@fullyqualifieddomainname”.

Unfortunately, there is a “verified answer” on a Microsoft Community forum post that is incorrect. It tells the original poster to download a blank CSV file from the portal and to populate that but that’s exactly what they (and I) did. The correct answer (which is a “suggested answer”, but not a “verified answer”) says to include the @domainname in the user name field in the CSV file. In my example, that would be markwilson@tenantname.onmicrosoft.com (assuming no other domain names have been associated with the tenant). So far, my requests for Microsoft to get this fixed have failed… here’s hoping that my blog post comes up in the next person’s Google/Bing search…

Short takes: @ in DNS records; are ‘ and & legal in an email address?; changing the search base for IDfix

This content is 9 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few short items that don’t quite warrant their own blog post…

@ in DNS records

Whilst working with a customer on their Office 365 integration recently, we had a requirement to add various DNS records, including the TXT record for domain verification which included an @ symbol. The DNS provider’s systems didn’t allow us to do this, or to use a space instead to denote the origin of the domain. Try googling for @ and you’ll have some challenges too…

One support call later and we had the answer… use a *.  It seemed to do the trick as soon after that the Microsoft servers were able to recognise our record and we continues with the domain configuration.

Are ‘ and & “legal” in an email address?

Another interesting item that came up was from running the IDfix domain synchronisation error remediation tool to check the on-premises directory before synchronisation.  Some of the objects it flagged as requiring remediation were distribution groups with apostrophes (‘) or ampersands (&) in their SMTP addresses. Fair enough, but that got me wondering how/why those addresses ever worked at all (I once had an argument with someone who alleged that the hyphen in my wife’s domain name was an “illegal” character). Well, it seems that, technically, they are allowable in SMTP (I struggled reading the RFCs, but Wikipedia makes it clearer) but certainly not good practice… and definitely not for synchronisation with Azure AD.

Changing the search base for IDfix

I mentioned the IDfix tool above and, sometimes, running it against a whole domain can be difficult to cope with the results.  As we planned to filter directory synchronisation on certain organizational units (OUs), it made sense to query the domain for issues on those same OUs. This is possible in the settings for IDfix, where the LDAP query for the search base can be changed.

The OneDrive that’s really two drives…

This content is 9 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Jamie Thomson and I have long since lamented the challenges of Microsoft’s two directories for cloud services and it doesn’t stop there. Take a look at cloud storage:

  • OneDrive is Microsoft’s cloud-based storage offering, accessed with a Microsoft Account (formerly a Windows Live ID, or a Passport if you go back far enough…)
  • OneDrive for Business is Microsoft’s cloud-based storage offering, accessed with an Organizational Account (which lives in Microsoft Azure AD)

Similar names, similar purpose, totally different implementation – as the OneDrive for Business product is still Groove (which later became SharePoint Workspace) under the covers (have a look at the filename when you download the client).

And look what happens when you have both products with the same email address used to access them:

Still, at least the site detects that this has happened and gives you the choice. And there is some hope for future convergence as Jamie highlights in this blog post from earlier in the year.

Earlier this week, I was helping a customer to get ready for an Office 365 pilot and they were having challenges with the OneDrive client. The version available for download from the Office 365 portal is a click-to-run installation and it didn’t want to play nicely with their .MSI-based Office 2013 installation (which should already include the client anyway). Actually, that didn’t really matter because the OneDrive client is also included in Windows 8.1, which was the operating system being used.

The confusion came with setting up the connected services inside Office:

  • To set up a OneDrive account, click on OneDrive – but that will only accept Microsoft Account credentials and, after configuration it will show as something like “OneDrive – Personal”.
  • To set up OneDrive for Business, don’t click OneDrive but select SharePoint instead. After logging on with your Organizational Account credentials, that will be displayed as “OneDrive – organisation name” (with SharePoint sites appearing as “Sites – organisation name”).

Some illustration might help so, below is a shot of my connected services. Because I’m connected to multiple Office 365 tenants, you can see that I have multiple OneDrive [for Business] and Sites entries:

If you’re trying to get hold of the OneDrive for Business sync client for SharePoint 2013 and SharePoint Online, Microsoft knowledge base article 2903984 has the links for the click-to-run install.  If you want an MSI version, then you’re out of luck – but you can create a customised Office 2013 installation instead as OneDrive for Business (formerly SkyDrive Pro) was originally released as part of several Office 2013 suites (as described in Microsoft knowledge base article 2904296.

Finally, if you’re trying to work out how to get a OneDrive for Business app on Windows Phone, the OneDrive app can connect to both OneDrive and OneDrive for Business.

Confused?

Some patience required when changing a display name for an Exchange Online mailbox

This content is 9 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Mrs W and I have been married for a long time but, until last week, she was still using her maiden name for work. Now, for a variety of reasons, is a good time for her to switch and, as we use Office 365 for her business email, I said “Yeah, it’s really simple; just let me know when you’ve told your contacts about the name change and I’ll switch it over.”

So, when the time came, I changed the display name in the Exchange Online Exchange Admin Center (no changes to her SMTP addresses were needed) and thought that would be it. Nope. Test emails sent came from the original display name. The same happened with another account that I changed the name on. Wondering if this was an Outlook issue, I tried from Outlook Web App: no difference. Test emails were sent back and forth to email addresses outside our Office 365 tenant (like my work account) and the original name stubbornly stuck – I even looked in the message headers and, there it was.

I’m not sure, but I think the issue was related to the offline address book as, the GAL reflected the change immediately but the offline GAL was still showing the old display name.

Unlike in an on-premises Exchange installation, I couldn’t update the address book: connecting to Exchange Online via PowerShell and asking for Get-Command *Offline* told me that the Update-OfflineAddressBook cmdlet is not available in Exchange Online (confirmed in the TechNet reference, which only refers to Exchange Server 2013).

Like so many things in Exchange (and I remember this from my original Exchange 4.0 training course in 1996), it proved to be one issue that’s best left for a few hours to fix itself. The offline GAL updated overnight and emails were then sent with the new display name (not sure why this affected OWA though…).

Office 365 and the hybrid cloud

This content is 9 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Cloud, cloud, cloud. The buzzword of a few years ago is becoming reality for many organisations today but there are still some industries and use cases that have significant obstacles to overcome. Recent research from one hosting company suggests that this is changing though – with public cloud usage set to double from 7% to 14% and hybrid cloud growth to almost triple from 10% to 28% over the next three years.

Hybrid cloud is a term used to describe an architecture with elements of the solution provided from the public cloud (e.g. Microsoft Azure or Office 365) in conjunction with elements delivered on-premises (i.e. in a customer or managed service provider’s datacentre).

Whilst some cloud providers consider hybrid as little more than a tactical bridge to help with transition to their infrastructure as a service (IaaS) and platform as a service (PaaS) solutions, those using software as a service (SaaS) are really embracing a hybrid cloud as part of their architecture.

For users of Microsoft’s Office 365 productivity services, hybrid cloud offers some real opportunities, partly because the online services have grown from an established on-premises suite of software applications so the user experience with Exchange, Skype for Business or SharePoint is similar regardless of where the service is running.

In this blog post, I’m going to examine some of the scenarios where a hybrid cloud solution might be used with the common Office 365 workloads.

Exchange Hybrid

Whilst Office 365 is highly configurable, it’s not customisable. The Office 365 service descriptions are fixed – that is to say that the service described is standard to all customers (unless they have a dedicated tenant) – and, whilst an administrator can change the configuration, certain levels of control require an on-premises infrastructure.

For example, hosting mailboxes in the UK, installing tightly-coupled applications that need access to Exchange Servers, or anything that goes outside the boundary of the standard Exchange Online service would need on-premises Exchange servers to meet the requirements. However, if the restrictions that prevented all users from moving to the cloud only affected a portion of the organisation, there could still be advantages in moving other groups of users.

A hybrid deployment provides a seamless look and feel of a single Exchange organization when there’s actually two: an on-premises Exchange Server 2013 organization and Exchange Online in Office 365. Hybrid Exchange enables:

  • Secure mail routing between on-premises Exchange and Exchange Online with a shared namespace, together with centralised control of the inbound and outbound mail flow
  • A unified global address list (GAL), free/busy and calendar sharing, a single Outlook WebApp URL, message tracking, MailTips and multi-mailbox search for both organizations.
  • The ability to move mailboxes back and forth between the on-premises and cloud organizations.
  • Centralised mailbox management using the on-premises Exchange Admin Center (EAC).
  • Cloud-based messaging archiving for on-premises Exchange mailboxes.

Exchange Server 2013 now includes a Hybrid Configuration Wizard (HCW) which does the heavy lifting to set up a hybrid Exchange environment (previously it required manual configuration). There are some limitations to consider around inherited and delegated permissions and multi-forest Exchange organizations with legacy versions of Exchange. More details are available on TechNet.

Lync Skype for Business Hybrid

Skype for Business Online doesn’t currently include any enterprise voice capabilities. Users can host meetings, send/receive instant messages, publish presence, conduct direct peer-to-peer conversations through the Lync or Skype for Business clients and even dial-in to conferences (when integrated with a qualified audio conferencing provider) but there is no integration with PBX telephony systems.

One way around this is to run on-premises Lync or Skype for Business servers for enterprise voice, sharing a SIP namespace with the cloud tenant. This is also known as a “split domain” scenario.

Skype for Business Hybrid should not be confused with the Lync Online “hybrid voice” option that was withdrawn in 2013. Whereas hybrid voice allowed cloud users to break-out to on-premises solutions for voice, in a split domain scenario:

  • Voice-enabled users are hosted on-premises for all of their Lync/Skype for Business services.
  • Users who don’t need enterprise voice capabilities can be hosted in Skype for Business Online.
  • Both sets of users can collaborate as though they were in the same Skype for Business organisation.

More details are available on TechNet and it’s also worth noting that, in order to facilitate Skype for Business hybrid scenarios, Office 365 E4 subscriptions include licenses for running on-premises Lync/Skype for Business infrastructure.

SharePoint Hybrid

A SharePoint Hybrid solution allows some data to exist in the cloud with some data retained on premises, perhaps for compliance reasons, during a staged migration, or for connectivity with business applications. There are various topologies available around search and business connectivity services (BCS).

  • One-way outbound search allows SharePoint Server 2013 on-premises to query the SharePoint Online search index and return federated results.
  • One-way inbound search is the equivalent but with on-premises results returned to the SharePoint Online search.
  • Two-way search allows both environments to query each other’s indices and return federated results.
  • One-way inbound or two-way BCS solutions allow SharePoint Online to connect to on-premises SharePoint Server 2013 and onwards to OData service endpoints.

More details are available on TechNet.

In conclusion

Adopting Office 365 doesn’t have to be a cloud-only solution – customers can choose to run some workloads on-premises alongside other workloads in the public cloud (e.g. SharePoint on-premises with Exchange Online), or the hybrid scenarios described above may offer additional flexibility.

For some workloads, e.g. Yammer, there is no on-premises equivalent and it seems certain that in some point in the future we’ll only be considering public cloud solutions. That day is still some way off though and with Microsoft releasing Skype for Business Server 2015 and prepping Exchange Server 2016 and SharePoint Server 2016, the use of on-premises infrastructure in a hybrid configuration looks to offer the best of both worlds for the time being.

This post originally appeared on the Microsoft TechNet UK blog.

Self service password reset is not available for users on a trial Office 365 tenant

This content is 10 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

One of my customers is currently running an Office 365 pilot using a trial E3 tenant.  When Microsoft announced that self-service password reset is to be made available to cloud-based Office 365 users without the need for a separate Azure AD basic or premium subscription it sounded great to us as the requirement for users to reset their own passwords was one of the challenges we faced.  Unfortunately it’s not quite so simple – or at least not if you are not using a paid product (for example if you’re on an Office 365 trial).

Just to be clear, self-service password reset is still available for Global Administrators in Office 365 – it has been as long as I’ve been working with the product – I’m talking here about “normal” users.  In the Office 365 Admin Center, listed under Service Settings, Passwords is a section titled “let your people reset their own passwords” – but the feature is not actually controlled from within the Office 365 Admin Center – it redirects to the Azure AD Admin Center:

In my own tenant, that led to a simple sign-up for a $0 Azure subscription following which I can see my directory (remember Office 365 uses Azure AD for authentication), complete with all the domains and settings I configured via the Office 365 Admin Center over the years.  Dig a little deeper and in the configure screen is the ability to customise branding and to set the user password reset policy:

After enabling self-service password reset there are more options to control the experience (for example the available authentication methods) and a link to allow users to set up their details.  Unfortunately, none of this is available with a trial tenant and, when I tried to configure it, setting up an Azure subscription failed at the mobile verification stage and a service request raised with Microsoft Office 365 support confirmed that this is by design.

The relationship between Microsoft Office 365 and Azure

This content is 10 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

At a recent partner event, Microsoft Partner Technical Specialist, Robert-Jan Gerrits, answered a question that many people ask: does Office 365 run on Azure?

The short answer is “no” – the Office 365 infrastructure is dedicated – i.e. it’s not a bunch of VMs running on Azure; however there is a slightly longer answer.

Office 365 uses Azure for:

  • Office 365 video (media)
  • Azure blob storage (storage)
  • Azure AD for identity (identity)
  • Power BI app (cloud services)
  • Access services (storage)

Over time, we can expect to see more and more Office 365 components using Azure services but, for now, Office 365 is (almost) a standalone environment.