How 3 Simple Non Technical Mistakes Can Derail Your Office 365 Deployment How 3 Simple Non-technical Mistakes Can Derail Your Office 365 Deployment

Over the course of my work with O365 deployments, I noticed that there are 3 quite simple, non-technical mistakes that can derail the entire implementation process. Read on to find out what they are and how you can avoid them.

I’ve been working long enough on Office 365 deployments to know that the process is never cut and dry. It’s often long and complicated, with the legal and technical aspects needing thorough analysis and investigation. Then of course there is estimating the ROI and TCO. In fact, after years with different clients, I noticed that making any of the 3 non-technical mistakes below could derail your deployment efforts. I’m sharing their stories with you, so you can avoid them in your business. Read on…

Mistake #1: Location, location, location!

A few years ago we helped a company deploy and adopt a Yammer social network. The business goal of the project was to engage experts and high performers to share their knowledge and experience with others.

The client bought Office 365 and wanted it integrated with Yammer. The project went flawlessly – on time and on budget. We met the goal! I like to give this as an example of a great enterprise social network adoption story. I mean, there was high management and user support, a great communication strategy, and of course a flawless execution.

We were feeling pretty good about ourselves until one day our client asked:

Let me tell you, no one wants to hear those words. The thing is, this company is based outside the US and having their data stored in the US was a huge legal problem for them. Oops.

Solution:

The point I’m trying to make here is to always check your data storage location – before starting an Office 365 deployment.

When you create your Office 365 tenant – your location determines where your data will be stored and what services are available. If, for example, you are in Europe and set your location to the United States during a tenant creation – majority of your information will be held in US data centers. It is not possible to change that parameter. And this can pose to be a huge legal problem. The only way to change the location is a new tenant creation and data migration. This is a whole lot of extra work that can easily be avoided.

Fig. 1: Remember to set the right location, otherwise you might have a problem

Mistake #2: Lost in translation

I remember when we assisted a client with an Office 365 adoption, one of the first questions asked was:

It appeared that English was the default for the whole tenant. In theory this isn’t a problem, it’s just the language setting, and you can change it, right? Well, not really.

Unfortunately there is no explicit field to choose a language for your Office 365 tenant. The language is taken from your system settings. Tell me – do you have Windows set up in a different language (let’s say, English) than your native language? If so, when creating a tenant, it will be in English by default and you will end up in the same boat as my clients above.

Fig. 2: Check your URL to know your default language

Solution

Always check the language in the URL (see figure 2 above) if you aren’t sure of your current setting. Not doing so might mean a lot of additional work of having to change the language setting in each of the services offered, and you can run the risk of missing a service or two.

Technically, it’s not too bad if you don’t have any data in your tenant (even the test one) but if you already have some data, remember that:

• In Exchange – it’s not a big problem, you can change the default language for users and translate names of default folders such as Inbox.
• In OneDrive – check the language of OneDrive for Business sites. It should have the default language set to the one preferred by the user. Otherwise, when you have hundreds of users, it’s challenging to manage. It’s possible to turn on alternative languages, but it doesn’t work predictably from the users perspective.
• In SharePoint – all important sites should be created with the default language set to the preferred language of the majority of users.
• In Project – the language must be set to the one preferred by the majority of users because there are some parts that don’t support alternative languages.

Mistake #3: What’s in a name?

Fig. 3: Remember to choose your tenant name carefully

The tenant name isn’t something us IT folks usually fuss about, but if we want to play nice with other departments like Marketing/Communications, then it’s important to choose a tenant name carefully.

Otherwise you might end up with a strange name like, ‘production-contoso.onmicrosoft.com’. And since you can’t change the DNS domain, the only way to fix this is to do a tenant to tenant migration – not exactly a bundle of laughs.

Solution

It’s always good to check-in before setting a tenant name. If the tenant name you want seems unavailable – contact us. We know how to check if it’s registered by someone from your company. If so, then it’s possible to get the tenant name back.

I hope the stories above helped you prevent non-technical mistakes and instead has helped to deliver a great user experience.