Home » The Big Bang » Preparing Your Office 365 Deployment » Preventing Deployment Disasters

Preventing Deployment Disasters

So you’re sold on Office 365, you have executive buy-in, and you secured a healthy budget. It’s time to plan your deployment! At COMPAREX, we’ve seen an unfortunate number of deployment disasters (particularly from companies who try to do this alone). Before you get started, we recommend making a few considerations to help make your process as smooth as possible.

It all begins with Office 365 licensing, so let’s start there. We mentioned previously that you need to consider license type per user ahead of time, but you also need to keep track of who has what features turned on and in what license level once deployed. We’ve seen many Admins accidentally replace Office 365 licenses with specific application licenses rather than just add the application license.

The most common scenario: you have E3 licenses deployed across the company, then Microsoft launches E5, which your leadership team wants to utilize. Since E3 has a plethora of services to turn on and off, you cannot simply add E5 where needed or you’ll be conflicting with what was deployed in E3. Don’t let licensing become a nightmare. (Work with a partner and we’ll take care of it for you – or be super, duper careful when doing it on your own!)

From licensing we move to identity. Nine times out of ten, companies setup ADFS and make it redundant with load balancers and multiple servers. Good idea, but the problem is that it’s all in one building. If internet goes out in that building, no one can login to anything. We suggest using multiple locations or deploying elastic load balancers on-premise and in Azure. You may also consider two popular alternatives:

  • Password Sync provides real-time (within a minute) on-premise passwords from Active Directory that are double hashed and copied to Microsoft, which means you can leverage Same Sign On for logging into Office 365 services.
  • Pass-Through Authentication is the newest practice that provides an easy and secure way to connect your Active Directory to Azure and/or Office 365 without the need for maintaining ADFS. Using this option reduces your on-premise footprint, offers additional scalability and provides Single Sign On to your users.

Pro Tip!

Make sure you have accounts not enabled for Single Sign On (like admin accounts) in the default tenant space so that if something happens to ADFS or Pass-Through Authentication, you can still sign in to fix any errors.

Finally, we come to email. As an IT Admin, if there’s one thing you don’t want to mess up, it’s end user email access. Let’s take a look at the three biggest mistakes we’ve seen:

  1. Mail flow cut-over prior to migrating any data into the system: all new mail was going to Office 365, but users were still connected to and using the legacy server. Without access to the new Office 365 accounts, they could not access any new mail.
  2. In an attempt to decommission the old Exchange server, all Office 365 users were accidentally deleted, which means every user was left without mail – old and new.
  3. Improper upgrades: if you don’t have a currently supported Office version and you cut over before upgrading, users will not be able to connect Outlook to Office 365.

At this point you may be thinking there’s no way you could make a mistake like these, but even the most seasoned IT vet can make mistakes, especially when single-handedly taking on a project as large as porting over an entire organization’s email server and deploying several brand new applications. That’s why we highly recommend leaving yourself adequate time for your deployment (at least a week) and doing a pilot migration for troubleshooting early errors.

Read on to fully prepare yourself against major deployment disasters:

Want help with your deployment? Click here! Have questions? Fill out the form below and we’ll be happy to help sort things out.


Check out the next article in this chapter

Home » The Big Bang » Preparing Your Office 365 Deployment » Preventing Deployment Disasters
Share This