The cloud represents one of the most interesting topics of today's computing. The concept of practicing a centralized approach for information management that makes the cloud is not that new, and has been around since the beginning of systems interconnectivity. However, there are fundamental differences—present-day systems are being accessed by a much larger scope of clients, and the tools to manage the infrastructures are very different. Scalability, security, and mobility are required factors that have become the basics of technology meeting business requirements.
When it comes to the private cloud, it can certainly solve some problems we are facing, mainly scalability and flexibility in assigning physical resources appropriately. With virtualization being commonly present in most major infrastructures, it is becoming easier to deploy infrastructures and manage them under the same umbrella system. However, such implementations still require IT staff to deal with HA and security, as well as take care of overall health of the implementation. One example of a private cloud solution is the Microsoft System Center suite of products, which offers Virtual Machine Manager (VMM), an App Controller (cloud management tools); System Center Operations Manager (SCOM) for monitoring; Orchestrator for automation; Service Manager for IT management; and Data Protection Manager (DPM), a backup and recovery tool. These tools make a complete framework on which a private cloud can be built.
With a public cloud, managed by a third-party, many issues are solved, with the back-end administration being outsourced. Office 365 can provide benefits in scalability, security, high availability, and information access through a robust back-end platform, and is considered a reliable public cloud solution. Although the back-end is managed by Microsoft with its Azure platform, Office 365 allows a greater level of control of your resources suited to your particular needs.
Whether your organization chooses to deploy a private or public cloud infrastructure, it is certain that systems administration will change, which will require efforts by both IT staff and clients alike to adapt to this new kind of environment.
In this white paper, we will explore how one kind of public cloud system, Office 365, works. We will discover what steps your organization should choose to implement an infrastructure that is completely driven by Office 365, as well as in a scenario when some of your services need to remain within the premises of the organization, while the rest can be hosted outside the organization.
Office 365 is a set of products that works similarly to other already well-known Microsoft technology. It is delivered as a Software as a Service (SaaS) cloud solution, and uses the following products at its core:
The online version of these popular tools is made available through an Office 365 subscription, which also includes access to another popular Office application, the Office 365 ProPlus suite.
Optionally, it is possible to use the online version of the following products as well, which are available by acquiring the appropriate subscription plan:
In a standard on-premises scenario, it is often required to follow relatively complex licensing. There is a multilayered approach to take into consideration: from the base server to the application and the Client Access License (CAL).
The licensing model in Office 365 has been simplified to the point that there is no need to invest in any of these layers, except for the fee of the Office 365 subscription itself. One license is assigned to one user, and can be granted or revoked at any time.
Office 365 features are unlocked based on the licensing plan that is chosen. Each plan is specifically designed to cater to an organization's needs (e.g., access to Office applications, compliance, enterprise management) and limitations (e.g., the number of users supported for the plan. It is even possible to assign parts or functionalities provided by the licensing plan.
One particularly interesting option is the ability to run the full Office 365 ProPlus suite on up to five computers simultaneously. This comes with all plans except for Business Essentials and E1.
Companies are conducting different phases to implement a technology, and following a specific pattern in key milestones of implementation of a product. Following the conventional method of work can take a long time before it is possible to operate the new software. And you run the risk of acquiring a specific set of licensing options that you cannot immediately use. Office 365 changes this approach by introducing ways for companies to get access sooner, get the technology running quickly, and use different tools to gradually adopt enhancements and transitioning methods.
The idea is to use a three-step approach to effectively take advantage of the acquired technology:
Setting up an Office 365 does not take much time: the licensing model is chosen, a tenant account is created, and the rest takes only a few minutes to be built. Technically, it does not involve much from your end as a systems engineer because of the very few dependencies on the actual on-premises installation.
While the environment is being created, there are still a few tasks to perform before the first users can get migrated:
The DNS system is a critical part in configuring Office 365. You will likely need to alter DNS records of the zone for email, SharePoint, or Lync services.
When you register in Office 365, Microsoft assigns the .onmicrosoft.com to the external domain name you specify; for example, firstname.lastname@example.org. The onmicrosoft.com domain will remain a temporary domain until you change the DNS records of your native domain to point to Microsoft's servers for different online services.
In fact, you will need to add your own domains in Office by proving you are the owner of these (done through a TXT record verification). Thus, you will need access to the administration panel wherever it is registered.
One confusing aspect is the domain name vs. client login name. By default, any user created will take the default companyonmicrosoft.com suffix for logging in. However, over time this will change. As you add your native domain to Office 365, you will also need to change the login suffix to reflect the native domain.
Changing the suffix without an announcement to your users will make their login fail, as their identity will change, and they will no longer be able to use the companyonmicrosoft.com suffix. Thus, some planning is required here.
Another important consideration to keep in mind is Office 365's external UPN suffix must be the same as the primary internal UPN suffix. The popular .local or .private internal domains are not supported on Office 365, thus Directory Synchronization will fail.
The result of your login name can be: email@example.com (company.com being added as an owned domain will appear in the list of domains used for login suffixes).
Once you've proved you own the domain and configured user logins, you will need to alter DNS for different services as explained in the following section.
DNS servers will also reflect a certain change for email access, especially if the name of the internal domain is the same as the external name, which is represented as a split-brain DNS scenario. Basically, your internal canonical name (CNAME) records will always point to the alternate name of the services on Office 365:
Original ExchangeCNAME record
Target CNAME record
In case of a hybrid configuration and an Exchange system remains on-premises, the A/CNAME record pointing to the client access server/array will remain the same.
Notice there is no dedicated Outlook Web Access (OWA) fully qualified domain name (FQDN). Once a mailbox has been configured, users can access email from the portal.office.com webpage (generic Office 365 landing page) or directly through mail.office365.com.
Also, A records for CAS are not used.
For external email routing, mail exchange (MX) records have to be changed to reflect Microsoft's servers:
Original Exchange MX record
Target Exchange MX record
Internal routing and between on-premises and cloud (if used) does not conflict with these records, since MX records are not used for internal mail flow.
In a hybrid configuration, some scenarios might require inbound email to continue pointing to your on-premises servers. In such cases, no actions are required—email belonging to Office 365 users will be routed from your onpremises mail-flow servers to the cloud system.
Sender Policy Framework (SPF) records need to be changed to reflect the IP address of the MX record in case MX records are changed initially:
Original SPF record
Target SPF record
"v=spf1 +a +mx +ip4:(On-premises Exchange MX IP)?all"
"v=spf1 +a +mx +ip4:(Exchange online MX FQDN)?all"
Federation services records are used to connect the on-premises deployment to Office 365 in case of a hybrid deployment, as well as to help clients locate Exchange servers online. These records will need to point to the Office 365 system.
If the objective is to use Lync Online, records need to be altered to point to the Office 365 system. First, a federation between two SIP domains can be created:
Lync Online also uses Service (SRV) records to manage the client infrastructure:
Lync clients use CNAME records to locate their online service:
It is the same for mobile devices, but with a different FQDN:
If applicable to be migrated, SharePoint requires a CNAME that provides an FQDN for a website hosted on that platform. It does not require any other type of record. In case of split-DNS, you are required to change the IP address of the FQDN internally, to be pointed to the Office 365 infrastructure.
The core of the migration on Office 365 very often refers to Exchange, being probably the most important service you want to transfer or set up to work hybrid.
There are many possibilities, as some organizations decide to remove Exchange from the on-premises world completely, while in other cases that is not be possible due to compliance, regulations, or standards that specifically mention emails or archives that have to be stored/transported on-premises.
When the objective is to decommission the internal Exchange servers, a cut-over or staged migration is effective. Cut-over is done without coexistence, while a staged approach can be used as a mini-coexistence, without many features that are reflective of a true coexistence scenario.
Cut-over is suitable for direct transitioning, but only for a limited number of users (maximum two thousand). But, it is the simplest approach, as the migration of the mailboxes can be performed during a weekend, for example.
Due to the limited number of users that can be migrated, organizations often opt for the relatively simple staged approach. Mailboxes are moved in the same way as cut-over.
For both of these scenarios, an Office 365 account that has access to a mailbox using the Outlook Anywhere (RPC over HTTPS) will connect and retrieve the content of the mailbox and its settings, and transfer it over to a new Office 365 account.
There are a few prerequisites that have to be met:
A coexistence scenario is established when you plan to have both infrastructures running for a longer period of time. Certain regulations at the company level dictate that email (or parts of it) needs to stay local, for example. In this case, you can still take advantage of Office 365 Exchange system to offload some work, and create a trusted relationship between the components. All your servers become part of the same organisation, and you are able to route emails, share calendars, contacts, etc. between the two systems. It is also the step to take before migrating more than two thousand users.
In sum, much more integration is done between the two systems when this implementation is running. A unified management access; cross-platform mailbox transfer; OWA redirection; comprehensive delivery reports, including the two systems; and many other advantages exist when configuring an Exchange hybrid scenario.
This method also allows you to control mail flow. (If using Exchange Online, you can set Exchange Online to analyze and look for spam, and you can configure either the on-premises or cloud setup for outbound email.) It all depends on the policies that are set up at the organization level.
For email access such as OWA or Outlook, clients are redirected or proxied to whichever setup has its own mailbox. This scenario is conceptually similar to a configuration with two on-premises physical sites, where mail flow and client access is very much transparent, but can be customized to a certain extent.
There are less popular scenarios you can take advantage of to migrate your mailboxes to the cloud. If you are not using an Exchange solution internally, you can connect to that solution using the POP3 or IMAP protocol from Office 365, and proceed with extracting the content, more precisely the mailbox or messages only.
By using the PST Capture tool, you can also inject content of PST files into the Office 365 system if other methods fail or become non-applicable.
SharePoint features the very similar interface seen on-premises in the cloud. It integrates the known types of libraries, websites, lists, and other content, such as the OneDrive. Thus, you can decide to use the online version of the platform, and remove your on-premises installation completely.
In this case, moving content to SharePoint in the cloud can be performed in the following three ways:
Many organizations aim to preserve Lync on-premises, while adding the Office 365 to offload some of its functionality to cloud. A much greater level of control of that VoIP system is achieved when the on-premises part is not removed, if already existent.
There are two main ways to set up an on-premises Lync environment to work with Office 365:
AD FS is basically a single sign-on mechanism. It allows an on-premises client to authenticate to an Office 365 system without re-authenticating on that remote system.
A trust is built between a locally established AD FS Proxy and Microsoft's AD FS servers. Internally, users install the AD FS server itself, with few other prerequisites.
Once the trust is created, a specific token from the on-premises domain is sent to the Microsoft servers. At that point, the token validity and trust is verified, and the client presents claims that act as additional information about the account itself and where it came from.
AD FS requires careful planning, since the DirSync feature is needed to make it complete.
Installing AD FS features is done separately on dedicated servers. As this is a secure system by design, it also requires the configuration of a PKI and issuance of several types of certificates.
DirSync is designed to synchronize changes between the on-premises and Office 365. To import user accounts into Office 365, install the Directory Synchronization Tool to one of the servers being members of a domain, and then create a task to upload some of the AD objects directly to the cloud.
It is possible to take advantage of password replication as well, which eliminates issues with different logins (AD FS also partially resolves this). If you have a password replication configured with DirSync, you are fully able to authenticate back and forth between on-premises and Office 365 with simply one authentication prompt.
Office 365 has a vast array of features to explore. We've covered the basics of these features, as well as looked at some possibilities for integrating solutions within your own organization. A rich administration interface, streamlined security, and versatile migration options make this one of the most interesting products when it comes to an SaaS public cloud solution.
Boris Gigovic is a technical consultant and the CEO of Eccentrix, a training center and solutions provider that offers skills advancement solutions and consulting services in the main areas of information technology. As an active instructor for Global Knowledge, he specializes in networking courses as well as security.
As a technical resource, Boris helps organizations maximize their investment into technology products, as well as find the best way to leverage key functionalities of these solutions. His areas of expertise are numerous, and include planning and designing computer networks, major infrastructure upgrade projects, administration, and maintenance and support of these networks.
Being a Microsoft Certified Trainer, Boris delivers courses on various technologies, including Windows operating systems, messaging tools, and communication and collaboration platforms. He dedicates some of his time to security consulting (mostly security assessments), as well as VMware and Citrix software consulting.