With Office 365 being available at the end of this month (28 June 2011), I have been looking at the impact it may have on an on-premises Active Directory and the issues that must be resolved in order for it to fully integrate with Office 365.

Single Label Domains:

Singles Label Domains (SLD’s) are not supported (e.g. or are, markparris. is not). Anyone with an SLD will have to migrate to a new forest to utilise Office 365.  See Microsoft Online Services compatibility with single-label domains, with disjoint namespaces, and with discontiguous namespaces

Forest Functional Level:

As far as I can ascertain the minimum supported Forest Functional Level should be Windows Server 2003 FFL (Level 2).  Even though DirSync and AD-FS support alternative FFL’s, the Microsoft Office 365 Beta Deployment Guide for Enterprises states this FFL level is required for Exchange 2010 SP1 hybrid mode coexistence and this is the lowest common denominator that Exchange 2010 SP1, DirSync and AD-FS all support.  If you don’t want to run Exchange 2010 SP1 in hybrid mode coexistence, then a lower FFL may be suitable. 

Email me at

Active Directory Schema:

If the organisation has a requirement for deploying Exchange hybrid mode coexistence, then the Exchange Server 2010 SP1 Schema will need to be deployed. In a global environment, that perhaps still has 32bit domain controllers with an NTDS.DIT greater than 4GB, then this schema extension may require some thought and planning, due to the additional load it may place on your DC’s.

Summary of Exchange Online Simple Coexistence and Exchange Hybrid Mode Coexistence Capabilities

Email me at

Number of Forests:

Office 365 will initially only support single sign on from a single forest. This may change moving forward, but if it does not then a forest rationalisation project may need to instigated. This could be a huge piece of work.

Domain Name:

To utilise AD-FS and single sign-on, the forest name or more specifically the UPN of the forest must be Internet routable. See: This could be a huge piece of work.

Active Directory Recycle Bin

If the Active Directory Recycle Bin has been enabled then this may impact your total object count quota for Directory Synchronization (in the beta this was 10000 objects). If the Active Directory Recycle Bin has not been enabled, this may be a factor in waiting before enabling it as it is an irreversible action.

Active Directory Cleanup:

Remove duplicate proxyAddress and userPrincipalName attributes.

Update blank and invalid userPrincipalName attributes with a valid userPrincipalName.

Ensure the attributes meet the requirements and remove invalid or questionable characters as detailed:


Maximum number of characters: 20

Invalid Active Directory characters: !#\$%\^&\{\}\\{`~"",\\/\[\]:@<>\+=;\?\* If a user has an invalid sAMAccountName but a valid userPrincipalName, the user account is created in Office 365.

If both the sAMAccountName and userPrincipalName are invalid, the on-premises Active Directory userPrincipalName must be updated.


Maximum number of characters: 64

Questionable characters: ?@\+

sn (surname) Maximum number of characters: 64

Questionable characters: ?@\+


Maximum number of characters: 256

Questionable characters: \?@\+


Maximum number of characters: 256

Invalid characters: [! #$ %&*+ / = ? ^ ` { }]

Duplicate values: The mail attribute cannot contain any duplicate values.

mailNickname Maximum number of characters: 64

Invalid characters: ""\\\[\]:><;


Maximum number of characters: 256

Invalid characters: \)\(;><\]\[\\,

userPrincipalName Maximum number of characters for username: 64

Maximum number of characters for domain name: 256

Invalid characters: }{ # ‗ $ % ~* + ) ( > < ! / \ = ? `

& character: Automatically changed to underscore

^ character: The value is automatically removed.

(_) character: This remains the same.

Duplicate proxies will be emailed as an error before any notification errors.

Additional requirements for a valid userPrincipalName:

@ character is required in each userPrincipalName value.

@ character cannot be first character in each userPrincipalName value.

Username cannot end with a period (.) an ampersand (&) a space ( ), or at sign (@)

Username cannot have a space ( ).

Routable domains must be used (.local or .internal cannot be used)

Unicode is converted to underscore characters.

userPrincipalName may not contain any duplicate values in the forest.


Mail-enabled character check: All mail-enabled groups must follow the pattern of *@*.

Contacts Mail-enabled character check: All mail-enabled contacts must follow the pattern of *@*.


Populate the following Username attributes:

First Name

Last Name

Display Name

For optimal use of the Global Address List (GAL), populate the following GAL attributes:

Job Title



Office Phone

Mobile Phone

Fax Number

Street Address


State or Province

Zip or Postal Code

Country or Region

Note:  This page will be regularly updated as my experience with Office 365 grows.


The week after Teched North America, Microsoft hosted 3 days of online training for its new Office 365 platform; these HD videos are aimed at the IT Professional and give an excellent insight into the product.

Microsoft since the release of Windows 2000 Server have recommended that any Windows Server environment promoted to host an Active Directory forest/domain should be configured with a registered Top Level Domain (TLD), such as .com, .net, .org etc.

Many companies have ignored this advice and taken the approach of, my internet presence is for example so I will therefore call my Active Directory forest markparris.local.

This approach to the .local namespace in Active Directory has caused no real issue, with exception of Apple Mac Integration into the environment (see below).

With the onset of the cloud, premises and off premises computing the .local namespace now causes a potential issue. The .local namespace issue may be resolved with a simple fix or it could involve a fair amount of remediation work.

In order to use Microsoft Office 365 Cloud Services with an on premise Active Directory synchronised via DirSync to the "Microsoft Cloud" the forests namespace or to be more precise the users UPN (User Principal Name) must be an internet registered TLD.   In most companies this can be easily achieved by setting all cloud users UPN’s to their email address (or another registered namespace) and then this is what the user presents to Microsoft, to be authenticated/validated.

In some companies, the .local UPN namespace may already be in use for something else and a UPN remediation project may need to be completed prior to any Microsoft cloud integration. This could again be a simple resolution or a huge global project.

So to summarise, the recommendation is still not to use the .local namespace in any new Active Directory implementation, if you have utilised the .local namespace and you have a requirement to implement Office 365, then identify and configure a registered UPN for the affected accounts.

To be fair to Microsoft, they did tell you.

DNS name registration with an Internet registrar

We recommend that you register DNS names for the top-most internal and external DNS namespaces with an Internet registrar. This includes the forest root domain of any Active Directory forests unless such names are sub-domains of DNS names that are registered by your organization name (For example, the forest root domain "" is a sub-domain of an internal "" namespace.) Article ID: 300684 – Last Review: February 16, 2011 – Revision: 25.1.

As I put my thoughts down, it has also become apparent to me that anyone with an Active Directory namespace that uses a TLD namespace that is not registered to them will also have this same issue and will also need to configure new UPN’s.

Apple Issues

Mac OS X: About Multicast DNS

You receive an "unexpected error occurred" error message when you try to access resources on a Windows-based network from your Macintosh computer