10 things you should know about deploying Office 365

If you're gearing up for Office 365, you'll want to be prepared for some of the trickier aspects of deployment. Brien Posey looks at some of the requirements you should be aware of.

Now that the Office 365 beta is available to the public (with the RTM release expected later this year), numerous organizations have expressed interest in decreasing their operating costs by using the service. Organizations that have an existing Active Directory infrastructure in place will typically need to begin the process by using Active Directory federation and directory synchronization to facilitate single sign-on for their users. This article explains 10 things you will need to watch out for when preparing your organization to begin using Office 365.

Note: This article is also available as a PDF download.

1: The instructions are a little sketchy

Even though Microsoft does provide numerous TechNet articles designed to get you up and running, the step-by-step guide isn't exactly step-by-step. In fact, there is not presently a single set of instructions on TechNet you can follow in an effort to establish Active Directory federation with Microsoft Office 365. TechNet does provide clues that someone with a reasonable amount of networking experience should be able to work from, but don't expect to be able to sit down and follow a simple set of instructions.

2: You will need to prove that you own your domain name

One of the first things you will have to do in establishing Active Directory federation is prove that you own your external domain name. When you register this domain name with Microsoft Office 365, the Office 365 Web site will provide you with a special DNS entry that you must add to your external DNS server. Office 365 then verifies that the record has been added as a way of making sure that you own the domain that you are registering. Later on in the configuration process, you will have to add more DNS entries pertaining to Exchange Server and Microsoft Lync Server.

3: Your domain controllers must run Windows Server 2003 or higher

The domain controllers in your existing Active Directory environment must all be running Windows Server 2003 or higher. If you need to retain some legacy functionality, it's okay to operate your domain controllers in mixed mode. But you can't have Windows 2000 domain controllers on your network.

4: Be prepared to add UPN suffixes to your network

Office 365 uses user principal names (UPNs) to identify users. Therefore, if your external domain name is different from your internal domain name, you will have to add UPN suffixes to your user accounts. The UPN suffixes must match the name of your external domain name. This allows Office 365 to associate your local user accounts with your external domain name.

5: Getting the certificates right can be tricky

I recently had someone at Microsoft to tell me that the single biggest technical support issue they receive with regard to Active Directory federation with Office 365 has to do with certificates. Unless the certificates are set up correctly, the entire process will fail. Office 365 uses certificates for SSL encryption, token signing, and client authentication.

Because all parties involved need to trust the certificate authority that issued the certificates, Microsoft recommends getting your certificates from a well-known commercial certificate authority. When you apply for the certificates, the subject name must match your external domain name.

6: You need the right version of the Active Directory Federation Services

You can achieve Active Directory federation with Microsoft Office 365 only by using version 2.0 of the Active Directory Federation Services. This is different from the version that is included with Windows Server 2008 and Windows Server 2008 R2. You can download the correct version here.

7: Pay attention to the Directory Synchronization Server requirements

The Active Directory federation process requires that you use a Directory Synchronization Server to synchronize your local user accounts with the Office 365 directory. Although Microsoft provides the directory synchronization software free, it has some rather unexpected requirements.

The directory synchronization software must be run on Windows Server 2003 SP2 or higher. The server you use must be running a 32-bit version of Windows. 64-bit operating systems are not supported. Furthermore, you can't run the directory synchronization software on a domain controller.

8: You can only manage Active Directory accounts locally

After you have established synchronization between your local Active Directory and the Microsoft Office 365 directory, you need to know that the synchronization works only one way. You will still have to manage your user accounts locally. For example, if you need to populate an Active Directory attribute, you must do so through a local domain controller.

9: You should avoid activating all your Active Directory accounts

After your domain accounts have been synchronized to the Office 365 environment, they must be activated before they can be used with Office 365. However, you should avoid blindly activating all your accounts. Microsoft requires you to license every user you activate. Some accounts, such as the domain Administrator account and your service accounts, have no use in an Office 365 environment. Therefore, if you activate every account, you'll be spending money to activate accounts that will not receive any benefit from Office 365.

10: Synchronization can take a while

Finally, you need to know that the directory synchronization process can take a while to complete. The first time I set up directory synchronization, I thought I had configured something incorrectly because my accounts did not immediately begin synchronizing with Office 365. However, the synchronization does not happen right away. In my lab environment, it took three or four minutes before the first account was synchronized. According to Microsoft, it can take up to 24 hours for the entire synchronization process to complete.


Brien Posey is a seven-time Microsoft MVP. He has written thousands of articles and written or contributed to dozens of books on a variety of IT subjects.


Very useful ten tips. Thank you for posting.

Awahili Guni
Awahili Guni

Honestly, after hearing complaints from those in BETA; then again keep in mind ---> it is B E T A as in Test Phase / Mode. It seems to be more geared for those in 64 bit OS with Servers. Of interest, there is a Microsoft's plan here at this link which is the Microsoft's Office 2010 Developer's Poster (Map) of exactly what they are doing with everything, you are encouraged to download this map and you can see the Office 365 and everything else and the expectant goal, et al at this link


I am now looking in to from Apple. I don't own any Macs and never have but that may soon change. It looks like a better solution but it is missing some features found in Office 365. The ability to edit files on-line is the big difference and as I said that is something that Office does but it doesn't do it well. Apple did not try to implement this feature and I suspect that it is because it would be an inferior experience to off-line editing.


And I am not impressed. DNS is a big issue. It's not that they want you to add DNS entries to your external domain, which they do but just for verification of ownership. Once that step is complete the next thing they ask for is to transfer DNS for your external domain to Microsoft's DNS servers. This is where I hit cancel. I already have a website and other things that use this domain and it's DNS. Then I noticed a section of the Admin panel that allows you to "edit your company website" and it does come with an ugly default one that is already public facing. So if you already have a website be prepared to switch your web hosting and DNS to Microsoft or buy a new domain name that you only use for Office 365. If you don't realize this you could end up with your website being replaced by the Microsoft default "company website" when the DNS switches over to their control. I tried giving it a subdomain off of my current host to avoid this and it specifically said it would not accept a subdomain and wanted full control of the whole domain. The other issue is the "Office Live" that it comes with. Seems like a good idea but this is Microsoft. When you open a document on the sharepoint site it automatically opens in to a web app that looks just like the office 2010 equivalent. You can view and edit without having office installed on your computer. At first I thought this was pretty cool until I realized that I can't right click because it's a web app. Say goodbye to all your macros and any other features that the offline version would obviously do better. I can't wait to see how the web version handles the various bugs that are bound to pop up. I hope you have an offline copy of the file you are working on. It's a beta and the tech is not yet mature. I would steer clear of this for a few years. It has potential but I cannot recommend it to anyone at the moment.


The editor did not pick up on a mistake. UPN stands for User Principal Name.


I'm currently using a different Exchange/SharePoint host. The way this one works (and I believe the way SharePoint is supposed to work) is if you have Office installed, it should open docs in the real app, if you don't have Office installed it opens in the Web app. Do you have Office installed? If so, this is definitely a problem.

Editor's Picks