DR and the Cloud
Cloud computing has finally matured enough that the time has come to properly understand what benefit it could provide to SharePoint owners. The SharePoint owner in your organization will still ultimately have responsibility for users’ content despite the fact that the infrastructure is owned by an external third party. There will also be the responsibility for credential federation and single sign-on. SharePoint in the cloud is available on dedicated hardware as well as in multi-tenancy environments. In either case, the administrator has to adapt or replace existing plans and procedures for HA and DR. These concepts have to be thought about differently now because some aspects of the HA and DR are in the hands of a third party and a whole new raft of servers will have to be managed if you want single sign-on.
The cloud in relation to SharePoint mainly means SharePoint Online as part of Office 365 hosted by Microsoft, but it can also mean services provided by other cloud hosting companies, such as Rackspace or Amazon, who will provide you with physical or virtual off-premises hosting services. The focus here will be on SharePoint Online as it will be the most common option taken. There is also the option of a hybrid solution where some of your content is in the cloud and some is on site. This is currently the most common situation as organizations gradually transition to cloud-based services. But in this case it is as a result of a phased migration rather than a plan to keep the valuable, mission critical, or sensitive content more securely on site while less valuable, mission critical, or sensitive information is hosted more cheaply off site.
In this chapter I will look at
- How SharePoint has gradually become a more “cloud ready” application,
- Cloud options (private, public, and hybrid cloud architectures), and
- The steps for adding resilience and redundancy in cloud scenarios.
By the end of this chapter you will see that single sign-on and active directory synchronization still mean you will be planning, installing, and configuring new servers on your domain. You will also still be planning, installing, and configuring software on your users’ client machines. You will also still be patching and updating these components. You can’t simply accept the marketing promises. I’ll begin by showing how SharePoint has been rising into the clouds for years and how it’s almost there now.
Let’s look at SharePoint in the past to see how it has evolved to where it is now. SharePoint had modest beginnings in 2001, at a time when the Internet was finally being noticed by the business community as something that could enhance communication and sharing within their organizations, similar to the way academic institutions around the world had used it for years. At first, the rush was simply to build web sites that were no more than elaborate business cards for the organizations that commissioned them. There were very few real web applications. There was no concept of Infrastructure as a Service or Software as a Service.
Then companies like Amazon started to make real money online. Amazon was also one of the first companies to see the potential of cloud hosting and is now a major player in this area as a result. Amazon invested in becoming more than just a retailer by leveraging its knowledge of creating huge infrastructures in online retail to creating a cloud platform.
Microsoft also saw the importance of the Internet and how it would replace the PC as the location of applications just as the PC had replaced the mainframe. Microsoft was busy looking for ways to create distributed applications over the Internet. The Windows Azure platform is the culmination of this work, but I don’t think Microsoft even realized how successful browser-based applications like SharePoint could be. SharePoint was the fastest Microsoft product to reach $1 billion in revenue at a time when Microsoft was perceived as becoming less relevant in the online world. Companies like Google and Facebook now have the challenge of finding a way to diversify like Amazon did. Otherwise they will eventually be surpassed by younger, leaner competitors. Both companies still only have a limited source of revenue and have not diversified successfully. In business, the ability to adapt and change beyond your origins is crucial. By contrast, Apple, which began at the same time as Microsoft, will become a bigger player in the cloud arena, and Amazon will also become even more important in this arena because of its ability to adapt to new opportunities. Google and Facebook still only make money from advertising. If people stop using them, they will quickly die off.
When I chose to specialize in SharePoint in 2001, it was because I saw it as the best way to successfully monetize my Internet skills. I had already worked in the Internet area for four years, but I saw that creating web sites was no longer a viable business direction. There were too many small competitors doing web sites for free or big companies who had many more resources. I wanted to remain an independent consultant with valuable skills, and I saw that SharePoint had the potential to allow me to make a living doing so. It has taken 10 years for SharePoint to reach the point where it can be called a true Internet application. It still has to bridge a few more gaps to achieve its full potential, however, and I’ll talk a bit more about where it is going later in this chapter.
SharePoint Past
When SharePoint came about, it was behind the curve compared to more mature collaboration offerings like Lotus Notes, which combined workspaces and e-mail well. Lotus Notes was and still is a more centralized system, and that is why I think it was surpassed by SharePoint. SharePoint also had the advantage of integrating better with Windows and Office. It held the promise of being a full web application but was still wrapped in the vestiges of a compiled application. You still purchased it on a CD and someone with server administrator privileges installed it on a server. You patched that server yourself also. Users did access the application via a web browser (Figure 10-1), so in that sense it was a web application. But the limitations of how it was implemented soon became clear. Users could only authenticate and access it if they had a Windows account. They also needed to be logged in at a computer on the network. They were tethered to that Windows account. They could only access SharePoint from outside the office by extending the network securely using encryption technology like VPN. Otherwise, it was possible to give a SharePoint server an external IP address, a fully qualified domain name (FQDN), and make it available through anonymous or basic authentication, but this was very insecure and no business wanted to do it.
Figure 10-1. The SharePoint 2001 user interface
Data in SharePoint could not be easily shared outside the office, and data outside could not easily be shared in SharePoint. It looked like a web application but acted like a typical Windows application: once you put content in there, you couldn’t access it from other applications and you couldn’t draw in content from other locations easily. Options like Really Simple Syndication (RSS) were a way for other companies to share their content, but you had to write the Web Part and the XSL to read the RSS feed (an XML file) yourself. SharePoint did not become RSS enabled until 2007 (Figure 10-2), even though RSS had been available since the mid-90s. Now you could view SharePoint list data in other applications and vice versa, but it was still very basic and weak, and it was hampered by not having a simple and secure authentication mechanism.
Figure 10-2. RSS in SharePoint 2007
Gradually, things changed, but I still think there is a long way to go. Sharing data between applications (between SAP and SharePoint, for example) means building more infrastructure and learning arcane knowledge like SPNego, BSPs, and WebDynPro. Web services and Business Connectivity Services (BCS) have helped with data sharing, but it is still a very technical domain.
SharePoint clearly used to be just another Windows application that happened to use web pages when you tried to extend it with new functionality. New code had to be manually installed directly onto the servers. It was very difficult to install, uninstall, proactively upgrade, or retract. Developing for SharePoint 2001 meant writing WebDAV and some XML/XSL, HTML, and JavaScript. ASP pages existed but could only be shown in iFrames in SharePoint 2001. Gradually, the .NET Framework and the SharePoint development platform became more like one platform. In 2007, ASP.NET Web Parts were not the same as SharePoint Web Parts. Development with Visual Studio in 2005 required adding third-party add-ons to automate packaging and deploying code to your SharePoint farm. Finally, because solutions and features are more mature today, you can deploy code to SharePoint, retract, and update it more easily.
The front end used to look more like a web site, so it appeared that if you knew Internet scripting languages like HTML or JavaScript you could easily customize it. The reality was that important parts like the navigation controls were locked black boxes or implemented in noncompliant, messy ways. Gradually, with themes and more support for cross-platform web design technology like CSS, AJAX, and REST, SharePoint now gives designers more free rein over the look of the interface.
Authentication
Verifying who users are (authentication) and what they are allowed to do (authorization) has always been something people using the Internet needed, and it has only grown more complex as the business world has gotten smaller and more connected. Even within a single, large, global organization it is a challenge to maintain one unique identifier for a member of staff across multiple domains within Windows. It becomes exponentially more complex when you want to share those credentials with other systems like SAP. Moving users to the cloud abstracts that complexity by creating a new platform for managing access, but there is still the issue of synchronizing those credentials with the existing ones in Windows. This can lead to greater complexity and insecurity when keeping your network connected to the cloud. I’ll discuss this more later.
SharePoint Present
With subsequent versions in 2003 and 2007, SharePoint gradually evolved and improved. The current version of SharePoint (2013) has become more like a real Internet application. It can be used to host a web site with anonymous pages, it supports multiple authentication methods such as forms-based authentication, and it can share and access information more easily with web services and BCS. More external companies provide multi-tenancy so that they can offer SharePoint to multiple customers on the same servers off premises cheaply with minimum setup planning. It can bring in data from other systems more easily using BCS and SharePoint Designer (see Figure 10-3).
Figure 10-3. Creating BCS connections for SharePoint
Finally, Business Productivity Online Services (BPOS) and now Office 365 including SharePoint Online became available. SharePoint has actually escaped the shackles of its network application ancestry and fulfilled its promise to become a real web application. SharePoint Online means your SharePoint content is hosted on infrastructure you don’t own or have responsibility for patching, backing up, or managing in general. You can provision new user accounts immediately to anyone, even people outside your network, and then simply pay a monthly fee for the account license. SharePoint grew from being a simple implementation of Exchange and IIS on one or two servers in 2001 to a large, complex conglomeration of many servers running many service applications. The availability of SharePoint Online is timely because SharePoint for the Enterprise has become a very complex environment, and being able to move the burden of managing that off site will be a great option for many organizations. SharePoint is now in the cloud at last.
Getting used to SharePoint Online will take some adjustment for many of us owners of SharePoint farms. If we want to find out when updates are going to be made to the system, we have to wait for the information to be posted by Microsoft, most likely at http://community.office365.com/en-us/b/office_365_technical_blog/default.aspx. The frequency of these updates is not predictable but will likely be every six to nine months.
When hosting your own infrastructure off premises with Microsoft you will have more control. For example, you will be able to host a different version of SharePoint than the latest. The change management processes you use in your organization for deploying to SharePoint will be mainly the same, but you will likely maintain an online test environment for your features and solutions rather than on premises so that the test environment resembles production as closely as possible. Since SharePoint Online is still relatively new, the main source of guidance for moving to SharePoint Online is still Microsoft when writing your high-level design document. That being said, there are more and more excellent consultancies with skills and experience to offer in this area.
There is still room for improvement in relation to SharePoint and the cloud. The main areas are in interoperability with other systems to share data and in making the sharing of credentials more seamless. More organizations moving to the cloud will gradually facilitate this as they will be on a shared platform. So eventually it will be possible, for example, to create SharePoint sites that two different organizations can access using their own credentials. Eventually, with technologies like SharePoint, dreams like having one virtual medical record you can share immediately with any doctor in the world will become more possible. The browser itself is a barrier to the spread of SharePoint to different platforms such as smartphones and tablets. The reliance on a WIMP (Windows, Icons, Menus Pointing Device) interface to interact with SharePoint means heavy customization is needed to make SharePoint work with touch screens. Microsoft is reacting to this need; in Windows 8 this situation has improved.
Data center walls will replace server towers as the barriers to integration, but eventually these will dissolve, too. In the meantime, building the most available and disaster-recoverable SharePoint architecture that includes a cloud element still requires careful planning, but there are many more possibilities than 10 years ago when SharePoint started.
Cloud Benefits
First, let’s look at the rationale of deploying SharePoint into the cloud rather than on premises. In this section, I’ll talk about capacity- and agility-related benefits of the cloud. There are, of course, many benefits to cloud hosting that are not directly related to HA, and I won’t talk about all of them here. However, do keep in mind that there are a number of indirect HA benefits. For example, low cost of ownership means SharePoint is less likely to be a budget-cut victim, thereby making low cost a resilience benefit.
Great minds think alike, but fools seldom differ.
—English proverb
Every business that has an open door to the public or even to its own staff has to have a process to deal with the problem of load variation. Your SharePoint servers have to be available when no one is using them or when hundreds or thousands of people suddenly decide to use the system for the same thing at the same time. This section shows how the cloud has made addressing this variability more possible.
Load variation is also known as bursting. Take the example of a coffee shop in a train station. The staff at the registers sits idle until a train comes in, then 300 people have to queue for 10 minutes to get their morning caffeine fix. Then those people leave and the staff is idle again until the next train arrives. The same thing happens with servers: the load can be very high first thing in the morning and again just after lunch. The rest of the day it is quiet. Another example I saw recently was a company who made it possible for staff to request a new smartphone via an InfoPath form on the SharePoint intranet. Once the e-mail went out linking to this form, the load on the server increased 500%, performance crawled, and the staff was frustrated.
The problem with this peaking of load from a SharePoint point of view is the same as for the train station coffee shop. It takes time and money to procure and retain servers (both of coffee and SharePoint pages). It is a waste of resources if they are idle 90% of the time. For the coffee shop owner, the ideal situation would be able to hire 20 servers for the morning rush, pay them for 2 hours, then send 19 of them home at 9:30 a.m. But people don’t want to work like that, unless they are paid for the whole day, and no employer wants to do that.
The cloud, however, can support spinning up a set of new servers and then turning them off again after they’re no longer needed. Additionally, most providers only charge you for the time the servers are running. They don’t charge you for the procurement process or storing the servers when they are not in use because they are invariably virtual and the resources can be reallocated to another customer relatively instantly.
Managing the Unpredictable
The example I gave of a company offering staff a smartphone was one of predictable bursting, like knowing the 8:50 train will be full every business day. A benefit of the cloud in the case of the smartphone offer is you would be able to spin up new infrastructure to support the influx of load for just the first week. Most cloud providers also make real-time monitoring simple, so as the demand falls, you can offload the additional resources and thus only pay for it as long as it is needed. The availability benefit here is clear and one not to be underestimated.
However, bursting is oftentimes unpredictable, and it’s with unpredictable bursting that cloud computing really makes its availability, reliability, and resilience clear. Cloud providers all allow you to specify events when the system will automatically scale out to handle the demand. For example, you could specify an event where if the CPU loads of the front-end web servers are all averaging over 50%, the cloud provider will automatically add a new front-end server into the farm to help with the increasing load. This works 24 hours a day, every day of the week, anywhere in the world. Many businesses don’t have adequate coverage outside standard business hours in one country, but the Internet is global and 24 hours a day, every day of the year, irrespective of national or religious holidays. Whenever the spike happens, the farm will automatically scale out to handle the new unexpected load and then scale back again after the levels die off.
SharePoint can be a victim of its own success. There is usually a pent-up demand of a collaborative solution like SharePoint in a business, and once IT can meet the business demands and match their requirements, it will grow fast. This growth comes as a surprise to some organizations; they roll out a pilot environment and see teams leap on it, demanding access. Storage is rapidly filled to capacity because no allowance was made for real production usage and so no capacity planning was done. Users are given sites without any guidance; some see it as a substitute for dwindling network capacity and thus dump content into this new storage space. SharePoint in the cloud has a significant advantage over a slow-moving internal procurement department. Though this is no substitute for good governance and planning, a cloud provider can allocate more virtual resources and spin up new virtual servers to accommodate the load because their capacity should be and usually is far greater than any one company can generate. This is not to say Microsoft, Amazon, or Rackspace don’t oversubscribe their capacity; they inevitably do, but they are not in the business of wasting money either. Oversubscription is not the same as overcapacity. It is fair to say that your problem of procuring enough hardware to cope with demand hasn’t gone away; you have just transferred it to your cloud provider. There is no such thing as infinite capacity, but a cloud provider can dynamically reallocate resources and so offer more than they actually have.
Let’s use the example of the coffee shop owner in the train station. Imagine he also owns the shoe repair and dry-cleaning services in the station. Once the coffee rush is over, he can reallocate his staff to fix the pile of shoes and clean the pile of clothes that have arrived at the other two businesses. Customers of coffee don’t need to know he’s using the person who serves their coffee with a smile every morning to clean someone else’s suit. Cloud providers can promise people resources to meet any demand so long as everyone doesn’t demand resources at the same time.
You can have your users using SharePoint Online in a fraction of the time it takes to plan, requisition, install, and configure a SharePoint farm on your network. Of course, if you want to add branding, the sync with your Active Directory accounts will add time, but the basic idea is that you can get everyone in your organization onto SharePoint Online in the time it takes to sign up and create their accounts. This is very compelling for any organization. Users generally ask for something when they need it, not weeks or months in advance of when they will need it. This is simply because they don’t know what they’ll need when; they are invariably reacting to a change in the market such as the demands of customers. The organization that reacts fastest, especially if it means responding to the needs of the customer before a competitor can, will be the one to succeed in the long run.
SharePoint Online also has a much more reasonable cost of entry for small businesses. Building redundant servers as well as development, staging, and production farms is too costly for the majority of organizations. I have described all of the requirements in previous chapters. Using the cloud means the responsibilities for these things are mainly passed to your cloud provider. To recap, just to achieve most RTO and RPOs you’d need the following:
- Well-documented disaster planning and a process to activate it.
- Multiple load-balanced and redundant front-end web servers.
- Redundancy for the servers running your service application instances.
- Redundancy of network components: switches, NICs, reverse proxies, and load balancers, to name a few.
- Database server–level redundancy using clustering, mirroring, and/or log shipping.
- Storage redundancy such as SAN replication and disk striping with RAID.
- Datacenter redundancy, meaning all the above in a second failover datacenter.
- A well-tested and documented backup process.
Most cloud providers include all of this even if you have only created a SharePoint site for one user for one month. It makes it very tempting to not have to consider all the information this book makes you consider.
What if your organization does buy all this hardware and makes all this effort and it still doesn’t meet the users’ needs, or their needs have changed by the time the servers are ready? And what if the farm is set up and deployed incorrectly and so is a waste of money? Using cloud providers like SharePoint Online makes the cost of trying SharePoint smaller and thus the potential loss far less. With cloud providers in general, you pay monthly for what you use; if you decide to finish with the service, you only have to pay for what you have used up to that day (or month, at worst).
Cloud Architectures
You can’t classify your cloud architecture simply by where the services you offer are hosted (on or off premises) because it’s possible to have an on- or off-premises cloud and a combination of the two. When contemplating which option is better, the distinctions come down to cost and control. The differences are as true of SharePoint in the cloud as they are of all out-of-the-box (OOB) solutions versus fully customized solutions: for greater cost you gain greater control, but it takes much more work and time to complete. Think of the example shown in Figure 10-4: if you have a suit designed by a tailor to fit you, it will be exactly what you want but will take much more of your time and money to get. The risk is that the suit will be out of fashion or you will have put on weight by the time it is finished. If you buy a suit off the peg, it is cheap and fast and it will meet your basic requirements. If you don’t like it, you can just throw it away and buy another with little lost. There is always a perfect balance between your available resources and requirements. The more unique your requirements are, the higher the cost. This is as true of SharePoint as it is of suits. If you are now on premises only and want to change, you have to factor in the level of cost and control your organization needs.
Figure 10-4. Bespoke means cost
Public Cloud
With a public cloud, your whole SharePoint deployment is hosted externally to your organization. This model has all the benefits described previously. The disadvantages from the point of view of hardware and software are the lack of direct control over the infrastructure, which limits your control in the event of an outage, and the degree to which you can customize the application. SharePoint Online Standard and Dedicated (a.k.a. Enterprise) editions are the best examples of SharePoint in a public cloud. SharePoint Online Standard means your sites share the same hardware as other clients; this is also referred to as multi-tenancy. With the Dedicated edition, you have your own hardware, which may be necessary from a security or compliance standpoint. It also gives a greater sense of control over the farm to the business and administrators. Dedicated plans also have better RTOs and RPOs in the SLAs from Microsoft: http://technet.microsoft.com/en-us/library/sharepoint-online-service-description.aspx
- “SharePoint Online Dedicated Service Description Single Page” at http://technet.microsoft.com/en-us/library/dn275923.aspx .
- “Microsoft SharePoint Online Standard Service Description” at http://technet.microsoft.com/en-us/library/sharepoint-online-service-description.aspx.
In summary, the RPO for Dedicated SharePoint Online is 45 minutes or less and the RTO is 2 hours or less (the 2 hours don’t include scheduled outage time). With Standard, it is 12 hours RPO and RTO is 24 hours. That’s a large difference.
Private Cloud
A private cloud is where a large company’s IT team acts like a public cloud provider and sells services to the divisions, departments, and teams within the organization. It makes tracking the cost and earnings of the IT department easier. IT acts more like an independent business by reducing costs and maximizing profitability. They are, in a sense, competing with external public clouds because the business could choose not to buy from them and go outside. Even if they can’t, they can compare prices. There are economies of scale associated with cloud computing: only very large enterprises can afford the upfront cost of setting up and maintaining a private cloud, but it can create a leaner and more efficient IT department and make the business appreciate the costs involved in providing IT services. This means less waste and ultimately more savings for the company. A private cloud can also have different policies and rules that reflect specific needs. It’s like making your own suit: it’s better suited to you than one from off the rack, but it’s expensive in terms of time and effort to create and maintain.
Just because all your SharePoint servers are virtualized doesn’t mean you have a private cloud. Virtual infrastructure requires just as much administration as physical infrastructure. Clouds are more automated. This automation is what makes the cloud available, scalable, and even self-managing. In addition to this infrastructure automation, clouds are designed to host multiple tenants that are separate from one another logically if not physically. SharePoint has built-in features that help maintain hundreds or thousands of these. Being built on separate tenancies is very important to the cloud concept. It means that SharePoint can support sandboxed groups of users whereby one group can’t see the data of another; these groups can be business units, divisions, offices, teams departments, et cetera. It also means if one group creates a performance issue, it will not negatively impact the performance or availability of potentially thousands of other groups. This ability to separate and automate is what makes SharePoint cloud capable, unlike the previous versions.
Microsoft uses the term hybrid to describe a mixture of a public and private cloud. I think the hybrid model is less a mix of two models and more a truly transition model, like the Archaeopteryx, which was a transition between dinosaurs and birds. The hybrid model is for an organization to gradually transition to the cloud while slowly scaling down the on-premises architecture.
Technology has become smaller, cheaper, and more mobile. It has also become virtual. On-premises server farms are like dinosaurs: they require too many resources to live. The smaller, fitter creatures will survive. The Archaeopteryx got off the ground and up into the clouds. It and creatures like it evolved into the 10,000 or so bird species that exist today. This is the transition SharePoint is making now, too. My view is a hybrid environment has limitations that make it less compelling than a full move into the cloud. It makes more sense to simply use the cloud for simple, non–mission critical and nonconfidential sharing and collaboration. Keep the more sensitive and valuable material on site. In the end a hybrid has the strengths of both its predecessors, but it still has the weaknesses of both.
Migration
It is a common requirement of the business to migrate content from one location to the other. In my opinion, it’s more important to migrate processes to the utility of the public cloud than to migrate data. Focusing on the content generated in the past is usually a reflex defense mechanism, a generally unconscious fear of change. There is generally no need to migrate 95% of old content to the new platform. That doesn’t mean it should be deleted. The on-premises architecture can be slowly marked as read-only so it will not continue to grow. Some can be archived and eventually most can be deleted. There is more information on migration best practices in Chapter 11.
A reality I constantly meet when consulting for organizations is that users don’t readily accept that the majority of the content they generate is only useful during the initial collaboration phase. Much of it is a by-product of a larger effort such as documenting a decision or process. These records can be transitioned to the cloud, but this is best done by the business itself, not IT or via a third-party tool. Either way, transitioning such content is slower and more expensive than the benefits.
Users have to own their own content. If they really must preserve something, it can be easily moved from one environment to the other either by them gradually or perhaps with a tool. The real work in migration is
- Planning and coordinating the migration
- Identifying who owns what content
- Choosing what content to preserve
- Defining what metadata to apply to it
- Deciding what structure to put it in: sites, lists, and libraries
- Deciding what security to apply to the content
A tool can only apply what users have chosen. The majority of content no longer has an owner, has no metadata, and is unstructured, so it is impossible to know its future value to the business.
Evolution, like collaboration with SharePoint, is a process, and user processes can be quickly moved to a new platform. One of the strengths of SharePoint is rapid creation of new collaboration spaces, workflows, forms, and sites. This is where the potential benefits of the migration to the cloud lie. Moving large amounts of less current data is costly in terms of resources: hardware, software, and the time and effort of IT and business people. This is a reality rarely understood, but the real opportunity is in migrating business processes. Older information is still valuable but could be archived or kept on the older platform in read-only mode for reference.
Architecting for Disaster Recovery in the Cloud
In this section I will show how SharePoint in the cloud is possible. The key point is that the content, users, and code from different tenants can be isolated from one another. Tenants who opt for dedicated hardware are treated better than those who share space with others: Standard SharePoint Online only supports a 30-day Recycle Bin and 14-day DR backup to tape. Full backups are only done every 12 hours and stored for 14 days. Dedicated SharePoint Online gives you 30 days backed up to tape. This is a large difference. In either case, once those 14 or 30 days have elapsed, there is no way to retrieve lost data. If that is not enough, the SharePoint Online cloud is not for you. Still, there are always third-party hosts like Amazon or Rackspace where you can arrange to back up on any schedule you want so long as you pay for the capacity. Let’s look in more detail at how SharePoint Online does multi-tenancy.
Multi-Tenancy
To understand how you would view disaster recovery in a cloud scenario, public or private, you have to understand how multi-tenancy divisions content physically and logically in SharePoint. The metaphor of tenancy is used because the system is logically similar to how apartment buildings are organized. A given tenant only has access to their own space within the overall structure. They are, however, in the same building and they do share common infrastructure such as hallways, stairs, and elevators (or lifts, as we call them on my side of the Atlantic). Multi-tenancy capabilities in SharePoint follow a similar logic. The logical containers for tenants’ content are site collections. Think of them as rooms. Tenants can have multiple rooms in the overall building.
In SharePoint 2007, tenants could only be logically separated by web applications, and there is a limit to how many of these you can have in a SharePoint farm. It’s in the hundreds. Think of it as the maximum number of floors you can have in an apartment building. The same tenants can’t be on the same floor. Now, however, SharePoint 2013 and later allows multiple tenants in the same web application or floor. Here are the reasons why this is possible.
Subscriptions
A site subscription sounds like something related to alerts, but it’s a piece of site metadata in the form of a unique GUID that associates it with a specific tenant. Think of it as a way of knowing which room in the building is being used by whom. Site subscriptions are created via PowerShell. The owner of the cloud creates a new tenancy for a new tenant and can then associate site collections with that GUID.
This subscription GUID means a tenant can manage their site collections through their own administration site called the Administration Center. The Tenant Administration Site (Figure 10-5) is used to perform global configuration or structure changes such as creating further site collections, managing user profiles, term store, and other service applications.
Figure 10-5. SharePoint Online Administration Center
Feature Packs
Feature packs are groups of features associated with one tenant. This is done the same way as site subscriptions: a GUID is associated with the feature to connect it to a tenant. This allows the cloud administrator or tenant to activate or deactivate features just for their site collections. It also creates the potential for an app store–like marketplace where cloud providers can sell or rent features to tenants. Tenants can also create stores in their own spaces. Features can be activated or deactivated through the web UI (Figure 10-6).
Figure 10-6. Managing features
Host Header Site Collections
Host header site collections also existed in SharePoint 2007, but they are still an essential method to sandbox tenant sites. Host header site collections enable the cloud administrator to assign multiple vanity domains within a given web application (Figure 10-7). This will allow you to give each tenant in the web application its own root level domain. For example, if the web application has a URL of http://intranet.spsfaq.com, a site collection at http://intranet.spsfaq.com/sites/hr can be accessible via http://hr.share1point.com.
Figure 10-7. Adding your domains
As mentioned in relation to tenant administration sites, service applications can be deployed in what is called partitioned mode. This means the service application is associated with a specific web application that contains tenants, and each tenant will see their own administrative interface to configure that service application. This is especially powerful with service applications such as user profiles and the term store. This would not have been possible in SharePoint 2007 because of the limited scope for dividing up Shared Service Providers.
Sandboxed Solutions and SharePoint Apps
Sandboxed solutions mean two things that are essential to facilitating custom development in an environment where tenants are sharing the same resources. Previously, tenant’s apartments seemed isolated, but if one tenant left their bath running and it overflowed, it would spill into multiple apartments below it and ruin them, too. SharePoint now runs custom code in its own memory space so that if the code demands too many resources or crashes, it only impacts the tenant. SharePoint 2010/13 also allows tenants to allocate different portions of their apportioned resources to different solutions.
In SharePoint 2013 and SharePoint Online, sandboxed solutions are being deprecated in favor of Apps. These are even more sandboxed than sandboxed solutions and as such are safer for the stability of a tenant-based platform. Like with Apple’s App store, they add to what the SharePoint platform can offer the business but without compromising its integrity.
As you can see, multi-tenancy places the responsibility for much of the availability and resource management with your cloud provider, but certain parts can now be managed by the tenant and that applies to a public or private cloud. The greater complexity comes in planning single sign-on between your cloud and your Windows network.
Even if you create user accounts in the cloud for your users, these accounts will not automatically map to the user accounts your staff uses to log into Windows. As a result, they will be prompted to enter their cloud credentials when they visit. The solution is to connect your Windows Active Directory to the cloud via Active Directory Federation Services. This brings its own risks from a disaster planning perspective, so I will deal with it next.
While your new cloud may be floating high above your network, your user’s Active Directory is still tied to the ground. This means you will still have to add infrastructure to your network if you want to keep your users’ network accounts in sync with their cloud accounts. If you don’t, users will have to keep logging in when they visit the cloud site, rather than having it just open because it picks up their credentials from Windows. If you do set up this type of identity federation, there are HA considerations. While it is beyond the scope of this book to detail all the steps in planning and deploying identity federation, I will detail it enough so you know what to do to ensure the architecture is resistant to failure.
Active Directory Federation Services 2.0 (ADFS) is a Windows (as opposed to a SharePoint) service that you install to federate your Windows users’ credentials to your cloud. ADFS 2.0 is a central piece of Microsoft’s identity management strategy, providing a two-way gateway for sending and receiving claims-based requests, using SAML-based tokens containing information about users and what they want in terms of information and access. Security Assertion Markup Language (SAML) is an XML-based open standard for exchanging authentication and authorization data between security domains. The key point is that it is not a Microsoft-only technology. Its role is to communicate identity data in a structured way between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). Another important note is that this must be a single forest.
There are two types of forest topologies: the single forest and the multiple forest. A forest represents the outermost boundary of the directory service. All resources in a forest implicitly trust each other regardless of where in the forest they are located. Within each forest, there is a common directory schema and configuration of the directory service. One or more domains can comprise a forest. Single sign-on with SharePoint Online (as part of Office 365) doesn’t support multiple forests. In terms of credentials and prerequisites, before you add this role to your domain, ensure you have installed .NET 3.5 SP1 and that you are logged in as a domain administrator.
You will install this server role on more than one server on your domain to provide redundancy. Collectively you’ll refer to these as your federation farm. You’ll place all these federation servers in your internal domain behind a firewall and use a NLB host to create a cluster with a dedicated cluster DNS name and cluster IP address. When you create your federation service you’ll want to use the same FQDN as your NLB cluster’s DNS name. This will give you redundancy at the server level. Also, from a resilience standpoint, the cluster DNS name and the federation service name must be the same, such as fs.share1point.com. The FQDN must also be Internet routable through your preferred third-party domain registrar.
Federation Proxy Servers
Federation proxy servers redirect client authentication requests coming from SharePoint Online in the cloud into your organization’s internal domain. These servers are most commonly placed in a DMZ that is segregated from your internal network. In addition to the redundant ADFS servers in your federation server farm on your internal network, you’ll need at least two more ADFS servers (proxies) for hardware and DNS redundancy as well as another dedicated NLB cluster. Having another AD domain is optional, but it is common to join the proxies to an external domain rather than your internal one.
This second NLB in the DMZ must be configured with an external IP address that the domain is registered to use. For example, you would want to register a domain similar to fs.spsfaq.com with your registrar, then point it to the NLB cluster in your DMZ. The NLB cluster FQDN also must use the same cluster domain name as the internal NLB cluster domain name. For example, both clusters as well as the federation service will use the same FQDN (fs.spsfaq.com). Also, the federation proxy servers themselves must be configured with Internet-accessible IP addresses. You’ll also need to set up redundancy at the database level during installation, which I will discuss next.
All ADFS traffic that communicates through the firewall uses HTTPS on port 443 by default, so you’ll need to purchase a certificate to make the traffic encrypted and therefore secure. Otherwise, someone could intercept the packages and read your users’ credentials. Most organizations use the same certificate they use in their internal network.
In the planning phase, you need to understand which database mode you should choose during installation. ADFS is set up separately from Active Directory; it’s just able to communicate with it. When you install ADFS, it creates a configuration database; this can be a Windows Internal Database (WID) or a SQL server database. From a redundancy point of view, SQL is the better option. That is because with a WID, there is only one primary copy on one server where you write changes. The others simply receive propagated copies of the changes. You can only write to the primary; the others are read-only. Therefore, if you make a change to the configuration, that change has to be propagated to the secondary servers.
With SQL Server you have more control and there is only one central database. This means that you can use any server to make configuration changes and there is no propagation delay. Because your data is in SQL Server, you now have all the benefits of scalability and high availability you have applied to your other SharePoint databases. You can use SQL Server’s clustering and mirroring capabilities for HA and you can add more SQL Servers to the cluster to increase throughput.
WID also has a scale limitation that may or may not affect you: you have a maximum of five servers in the federation farm. Five servers can support up to 60,000 users. If your organization has more than 60,000 users, you’ll need to use SQL Server so you can add more than five servers in your federation farm. Even though SQL has many benefits not available to WID, most ADFS installations still use WID because it’s so easy to configure. Irrespective of the users you have in your organization, I would recommend you have at least two federation servers to make them redundant. Also, if those servers are virtual, make sure they are split across two physical servers to prevent the host server becoming a single point of failure.
Further Considerations
You may have thought that setting up a cloud version of SharePoint would mean no longer having to plan or implement this level of technically complex infrastructure. It is possible to use SharePoint in the cloud without having identity federation. It just means users have to explicitly log on occasionally. SharePoint Online does do a limited amount of cookie caching so the user’s identity is retained between browser sessions, so this is not as inconvenient as it sounds. As well as setting up this federation farm, you can use the Microsoft Online Services Module for Windows PowerShell to establish a trust with Office 365. The Microsoft Online Services Module for Windows PowerShell is a download that comes with Office 365. This module installs a set of cmdlets to Windows PowerShell; you run those cmdlets to set up single sign-on for Office 365. Microsoft recommend you set up single sign-on before you set up Active Directory synchronization.
Microsoft also points out that activating directory synchronization is a one-way street. You can’t currently deactivate directory synchronization. Once you have activated directory synchronization, you can only edit synchronized objects using on-premises applications.
Additionally, there is the task of ensuring user client machines are ready for Office 365. This means installing the required updates for Office 365 from the Office 365 downloads page to ensure that your users are running the latest Windows updates.
In Office 365 Community, Microsoft also recommends all client machines install the Microsoft Online Services Sign-In Assistant (MOS SIA). “This provides the end user with sign-in capabilities to Microsoft Online Services like Microsoft Office 365. The MOS SIA installs client components that allow desktop applications like Microsoft Outlook and Microsoft Lync to authenticate to Microsoft Online Services. The MOS SIA also provides an improved sign-in experience so users can access Microsoft Online Services without re-entering their usernames or passwords.” There is a lot to consider beyond just the HA consideration I have detailed here.
Summary
So how is this cloud computing? It sounds like you are just as tied to servers and client machine installs as ever before. The important thing is not to believe the marketing hype. There is still a great deal of planning involved in moving to the cloud. Microsoft can consult with you to help with this transition, and there are more and more third parties that can help, too. But it should be clear that while cloud computing has many benefits, it also still has responsibilities.
This chapter has looked at the following:
- The process by which SharePoint developed into its current form.
- How cloud architecture options come down to cost and control.
- Multi-tenancy and planning federation: key aspects of SharePoint in the cloud.
SharePoint has come a long way, but right now it feels like a transitional species, halfway between dinosaur and bird. It has taken wing, it is in the clouds, but it is still being pulled to earth by its history. Maybe in another version or two it will have fully made the move.