If you would like to read the other parts in this article series please go to:
This article concludes my interview on Office 365 migration considerations with Kelsey Epps, a Technical Consultant with Concepps Group and a Microsoft MVP for Office365 who runs a blog called the Office 365 Technical Support Blog at http://office365support.ca.
Mitch: I understand that you need to verify your DNS domain before you can use it with Office 365, why is that?
Kelsey: Domain verification is a small step in the process, but one that is very important. This is a mechanism that protects you and Microsoft, where you basically prove domain ownership. The process is simple; when you add your domain to Office 365, they will generate a random value. You add this value, as a TXT record, to your public DNS. Microsoft will then verify the value they supplied and the value you entered. If they match, the domain is registered for use with Office 365. Given the immense size of Office 365, processes like domain verification are automated. If this was not part of the process, there is nothing stopping me from adding any domain I want to my tenant account. Once a domain is added to the tenant account, it cannot be added to another one, unless it’s removed from the first one. If this was allowed to happen, it would be a complete pain for you and Microsoft.
I have documented the process of adding a domain to Office 365. Check out my BLOG post – Adding and Verifying a Domain for the NEW Office 365.
Mitch: I also understand you have to enter your public DNS records before you can use your domain with Office 365. Why is this necessary?
Kelsey: DNS records are vital to the function of Office 365. They tell your client machine where the service is located and how to access it. These DNS records have to entered into your public DNS and into your private DNS (if required). Microsoft makes use of MX, CNAME, TXT and SRV records for Exchange and Lync Services. When you add your domain to Office 365, you are presented a list of DNS records. One warning – Make sure that you take caution with entering the DNS records. If you are in a production situation, then make sure you know what each DNS value is and what it does. Changing the MX record too early can result in lost email and NDRs being returned to the clients. Changing the Autodiscover CNAME will result in numerous connection issues with Exchange, if you have Exchange 2007, 2010 or 2013 already in place on-premise. Changing the Lync SRV and CNAME records will result in numerous service and connection issues, if you have Lync 2012, Lync 2013 or OCS 2007 deployed on-premise. Remember that DNS is key to service and client connectivity.
I have documented the process of adding a domain to Office 365, which includes adding DNS records. Check out my BLOG post – Adding and Verifying a Domain for the NEW Office 365.
Mitch: What is single-sign on and how does it work with Office 365?
Kelsey: This is a tricky question, because most people assume that single sign-on means that you sign on once and that’s it. This is not the case, because with Office 365 you will still be prompted for credentials for certain services. What single sign-on allows you to do is use a single account and password to access all services. This account, in the case of Office 365, is your local domain account. This is achieved with the use of the Active Directory UPN account name ([email protected]) . Single sign-on is a basic service that runs on IIS and uses SSL certificates. The networking is simple as it’s limited to using SSL (port 443) from the internet to the DMZ and then from the DMZ to internal. When SSO is enabled, with Office 365, you require three services to be installed into your local Active Directory domain.
- AD FS Server – Active Directory Federation Services Server is a server place on the same network as your AD Domain Controller. It is the link between your AD and the Federated partner. You will require a third party SSL certificate on this server. This service can be made highly available, when configured into a farm configuration and network load balanced. For the purposes of Office 365, I always recommend two AD FS servers (virtual) placed on separate Hyper-V servers. Keep in mind that you are authenticating with your local credentials to services in Office 365. If this service goes down, you will not have access to Office 365. This server is domain joined.
- AD FS Proxy Server – This is a server that is used to proxy client authentication traffic from remote users (internet) to your internal AD FS server. This server is placed in the DMZ and must be publicly resolvable to the name on the SSL certificate. It’s recommended to use the same SSL certificate as you used on the AD FS server. This role is optional, but if you don’t deploy it, then all remote services (mobile Devices, OWA, Outlook Anywhere, ect…) will not have any mechanism to authenticate to the services in Office 365. Since the standard office has changed so much and many people work remotely or from a mobile device; I also recommend that this service is set up like the internal AD FS servers. Implement at least two AD FS proxy servers (virtual) that are network load balanced, on separate Hyper-V servers. This server is not domain joined.
- Directory Synchronization – Directory Sync is a service that replicates your AD objects (users accounts and groups) (up to 50,000) or a subset of objects to your tenant account in Office 365. Once in the cloud we can apply a license to the account and service is granted based on the license applied. Directory sync is installed as a single server and cannot be made highly available, because after the initial sync, it’s not mission critical. If the Directory Sync server goes down for a period of time, service is still maintained, because passwords are not replicated. The only effect of the service being down is that new objects and deleted objects are not replicated to Office 365.
This diagram shows a standard Single Sign-on solution for Office 365. The AD FS and AD FS Proxy servers are redundant and network load balanced. The AD FS servers are in you internal network and the AD FS proxy servers are in your DMZ. The firewall handles routing between the two zones and allows traffic to communicate on port 443. The internet never talks directly to the AD FS servers, they requests relayed through the AD FS Proxy servers. Directory Sync is a single server sitting in your internal network.
Figure 1: A standard Single Sign-on solution for Office 365
Mitch: Just one more question Kelsey, I understand that you recently received the Microsoft Most Valuable Professional (MVP) award from Microsoft. How does it feel to be singled out as one of only 5,000 individuals worldwide who currently hold this award?
Kelsey: Yes, I was award the MVP on April 1st 2013. It’s a real honor and an award that I take really seriously. I have put in countless hours on my BLOG, the Office 365 user community and with clients; spreading the good word of Office 365. I really love the product as it allows little guys, like me, to have enterprise services for a small price.
Mitch: Thanks Kelsey!
Kelsey Epps is a Technical Consultant with Concepps Group and a Microsoft MVP for Office365 who runs a blog called the Office 365 Technical Support Blog at http://office365support.ca.
If you would like to read the other parts in this article series please go to:
