If IT staff in your company is comfortable installing, configuring, and maintaining a computer server, you might decide on an on-premises installation. In such a situation, the computers running SharePoint 2013 are located within your business or maintained at an off-site data center.

On-premises installs are typically how the majority of SharePoint sites have been implemented. When set up with great in-house IT support and dedicated resources, SharePoint has proven to be a reliable and worthwhile addition to the server rooms of many organizations.

A hosted SharePoint server is an opportunity to both get started quickly and have a website that is highly available for those who depend on it. If SharePoint isn’t running on computers at your business location, you can take advantage of a growing number of online service offerings.

Microsoft introduced the Microsoft Office 365 service with SharePoint Online powered by SharePoint 2010, and Office 365 has recently been updated to SharePoint 2013. For a low fee per user per month, you can use servers at a Microsoft data center to host your collaboration site on a SharePoint installation that Microsoft engineers will maintain for you. SharePoint’s ability to support many different organizations on one SharePoint farm is supported by a feature set added in SharePoint 2010 called multi-tenancy. Multi-tenancy features have been improved in SharePoint 2013 and benefit from what was learned by deploying and maintaining SharePoint Online.

The designers of SharePoint 2013 specifically had this “hosted SharePoint” design in mind to allow more people access to SharePoint without the need for dedicated in-house IT support staff and the specialized skills required to install and configure SharePoint.

Figure 2-1 summarizes the key strategic considerations when choosing on-premises versus hosted SharePoint.

Figure 2-1. SharePoint installation models: on-premises versus hosted installations.

Let us first consider the case of backing up and restoring the content of your intranet in this example. A successful SharePoint implementation with a SharePoint structure like this can result in a database measured in terabytes of storage space. If you’ve ever tried to back up a 200-GB hard disk, you understand the amount of time required to save your important information.

The amount of time it takes to back up data is affected by two critical restore parameters. The first is how often data can be backed up; if it takes eight hours to back up the content database and you run only one backup at a time, your SharePoint content will be safely backed up only once during a business day. For certain tasks at some organizations, it is acceptable to lose a day’s worth of information; for others, losing even a minute of information could be trouble.

The second restore parameter affected by large content databases is the amount of time it takes to restore. Again, it is up to the task and the organization to determine how long is too long. However, in some situations, waiting a day for SharePoint to be restored after a disaster or an unexpected failure is just too long.

Next, let’s consider the case of disorganization of information. This one is probably not hard to imagine if you’ve been using a computer for many years and you’ve ever lost a file on your hard disk or a file share. Over time, file storage tends to become filled with documents that are rarely accessed and out of date. The same can happen to any kind of content in a SharePoint site. Remember that a SharePoint site is intended to be dynamic; therefore, you need to plan accordingly. Identify the areas that are important to the users of your site. Plan to repeatedly highlight timely, relevant information. Collect feedback from your users on organization and usefulness to ensure that your growing site meets not just your needs, but the needs of your collaborators as well.

The best-case scenario for your organization is to plan ahead of time and accommodate growth where anticipated. SharePoint sites intended for team collaboration and document sharing tend to grow in database size over time. Document sharing sites are popular, but they can often be isolated into site collections by audience. Site collections are natural security and audience boundaries. Interaction within a legal team, for example, deserves this type of isolation for the sensitivity of the information alone. However, other teams can also follow the model, whereby internally important information is contributed to one site collection and more generally interesting information is uploaded to a shared portal. Again, if we look to the SharePoint Product Team’s example of building out My Sites in SharePoint Server, we see this model in its extreme. A My Site gives a user a place to upload content and control access in his own site collection. If the team designing SharePoint puts that architecture forward as a model, you can feel safe in assigning small- to medium-sized project teams similar workspaces that they can control.

Creating site collections for unique audiences reduces the amount of content in each site collection. The added benefit beyond security is added mobility of the content within the content database. Individual site collections can be moved between content databases with more flexibility than sites or lists. Also, storage size quotas can be placed on site collections, but not sites or lists. If the size of a content database becomes an operational issue, the ability to move content to reduce the size of existing databases becomes a big benefit.

If you find yourself in the situation where too much content has been added too quickly, there is good news. Others have been through this before, and strategies have been developed to overcome all three of these issues related to the inevitable growth in a successful SharePoint implementation. For example, if you find that you want to reduce your backup or restore period time, there are two possible paths. Starting with IT professional analysis, identify if the current read or write speed for your content database storage, your backup storage, or the network in between can be increased by purchase of new hardware or optimization of the current hardware.

At the same time, use your understanding of the SharePoint structure to look at how you might reorganize your sites to meet your goals. If all your sites are currently held in one site collection and subsequently one content database, you have an opportunity to create a new site collection, in a new content database where existing sites can be moved. However, moving is always stressful and sometimes items become lost in the move. Professional tools and consultants will help you move more quickly with less loss, but there is always a cost associated with that kind of help. The best strategy is to be proactive and move early. If you identify the level of service you need from SharePoint and you can estimate when potential support milestones will be hit, you can build a roadmap for potential changes ahead.

The amount of time that a backup or restore takes to complete is a common service-level requirement for electronic information. When you use the site collection as a mobile unit of SharePoint content, you can arrange your content databases to accomplish your service-level requirements. In a common method of backup, the content database is the container that is backed up or restored. Moving your most critical site collections to a new content database will allow your IT professionals to back up and restore those sites more quickly. If you consider this type of reorganization, keep in mind that you can host multiple site collections under one web application. In that way, you can maintain one base web address for multiple site collections and reduce the backup and restore time of your most critical information.

Classic Windows integrated authentication is no longer the default option when your IT administrator is creating a new web application. It won’t be commonly in use for new web applications, but it is an important consideration for migrations from older versions of SharePoint. (Upgrades and migrations are covered in the “Upgrades and migrations” section later in this chapter.)

Claims-based authentication was new for SharePoint 2010, but it takes a more important role in SharePoint 2013. All web applications created in SharePoint 2013 through Central Administration will use claims authentication. Upgrades from SharePoint 2010 can also use this setting, but if customizations are being upgraded, they might need code changes to work with the new security model.

Forms-based authentication can only be enabled with claims in SharePoint 2013. This type of authentication is popular in extranet scenarios because it doesn’t require an Active Directory account for each authenticated user. However, you might find that certain features don’t work as well with this setup. Particularly challenging is Office integration without the latest versions of the Office clients.

Claims-based without Windows authentication was also introduced with SharePoint 2010. This new authentication method was much different than anything available in the previous version of the product. For SharePoint 2013, claims-based without Windows authentication remains an important part of many deployments. This authentication method allows some advanced scenarios but also requires more complexity on the back end. If you require claims-based authentication without Windows integration, keep in mind that this is a new technology, and it might take some time for the administration best practices to be established. If you need to integrate with some external types of identification systems, like Windows Live authentication, claims-based authentication is the answer.

Anonymous access is most commonly used with publishing sites that are public facing, but might also make sense within a large organization where many readers access the site, but only a few content authors publish information. Anonymous access can be used in combination with the previous four authentication types on one web application. Be sure to provide your content publishers with a way to log on through a link published on your intranet or on the page in the public site. In addition to the IT settings for the web application, ensure that you enable your site for anonymous access in the permissions settings of your site collection settings.

In the first scenario, your web application might be configured by IT for both anonymous access, for readers, and authenticated access of any type, for content authors. If your business needs demand extra security through separation of authoring from reading environments, you would need two separate web applications—possibly in different SharePoint farms—and you would need a method to copy the content between the two.

Secured intranets are probably the most common use of SharePoint technologies over all versions of the product. Windows integrated authentication is a great choice for this scenario because it provides a great user experience. When all the users of a SharePoint installation are members of the Active Directory domain, you can avoid logon prompts in many scenarios. Also, a secured intranet environment is most likely to benefit from the maturity of the Office client integration with SharePoint when combined with Windows integrated authentication. The other types of authentication will also work in this scenario, but they do increase the complexity of the configuration for the SharePoint farm’s host IT staff.

Secured extranets are a special case because they often involve collaboration between members of more than one organization. This scenario, in particular, is a great example for the use of claims-based authentication and how it might be of the most use to you.

The implementation of claims in SharePoint uses open standards. The use of open standards for authentication allows integration with a wide and growing amount of identification systems. So, when you use claims to authenticate your SharePoint web application, you might be able to allow more users from outside organizations with greater ease.

As mentioned earlier, forms-based authentication has historically been a popular option for extranets because it provides the option to use an account database to store user account information (instead of Active Directory). Whether you use forms-based authentication with Active Directory or another user directory, you might want to invest in a firewall such as Microsoft Unified Access Gateway (UAG) 2010. UAG integrates well with SharePoint and provides an extra layer of protection beyond the security provided through SharePoint and Windows Server.

In some cases, you might need more than one method of authentication for your SharePoint sites. The previous section described the authentication options that are available for your web application. Public websites can allow anonymous authentication and another method, but other combinations require some additional changes.

For example, you might want multiple forms of authentication for an extranet. You might use forms-based authentication for extranet users outside your organization so that you don’t need to add them to your internal directory. You also might use your existing Active Directory to provide identification for your internal users so that they don’t have to learn a new password.

In this case, you would like your IT staff to extend the web application to include an additional authentication method at a new web address. In this way, you effectively have two doors into your SharePoint house. One is locked with Active Directory, the other with a database of external user names and passwords.

In the previous section, authentication is described as the way of identifying the person who has logged on to your SharePoint site; authorization defines what SharePoint resources the identified person is allowed to access. You can read about controlling permissions for site collections, sites, lists, libraries, and individual content items later in this book.

The User Policy setting is an important authorization setting that affects authorization on your sites; configuration of this setting is left up to the IT staff supporting your SharePoint web application. The User Policy setting defines global authorization rights to a user for all the site collections in a web application.

An IT professional can enable Self-Service Site Creation on each web application individually. This will give the specified users permission to create new site collections in a web application. Did you notice the disconnect between the last two sentences? The former uses the word site and the latter the words site collection. The former is the wording used in Central Administration, but it would be clearer if it used the words site collection in the place of the word site.

There is a big difference between creating a site collection and a site. Acting as a site administrator, you control the permission of users to create new sites as child sites or subsites to yours; however, those sites are all contained within one collection of sites. On the other hand, allowing creation of site collections can be useful as well. Each site collection provides a unique security boundary, a storage quota, and a context boundary. Often, Self-Service Site Collection Creation is extended with customizations. For example, it might be useful to track the reasons that the site collection is needed and the length of time it will be needed for. My Sites can serve as an example of this type of customization. To start, each My Site is provisioned through Self-Service Site Creation when first accessed by the owner of the site. SharePoint Server includes a workflow for decommissioning the site when the user is deactivated in Active Directory. By automating site-collection creation and removal, the My Site model both enables users and conserves resources.

Forms-based authentication can be useful, as described in the “Types of authentication” section earlier in this chapter. However, it doesn’t work well in some situations, such as SharePoint integration with older versions of Office. If your site uses forms-based authentication and the visitors to your site encounter problems with older versions of Office, you can ask to have this setting disabled at the web-application level. Disabling client integration can prevent errors that otherwise are confusing. However, some features, such as the Edit-In-Datasheet option for lists in the browser will also be disabled for all users when client integration is disabled.

You’re probably familiar with encryption for purposes such as securing online banking accounts. Banks add this layer of security because without it, all information passed over the Internet is sent in clear text that can be captured and read by anyone between you and your bank. If your SharePoint site contains information that is sensitive, you will want encryption configured for your web application. Ask your IT staff to purchase and install a Secure Sockets Layer (SSL) certificate on the web servers and configure your web application for encryption. You will know when you are accessing an encrypted site when the web address begins with https:// instead of the normal https:// prefix.

Another situation for which encryption is important is when your site’s authentication doesn’t encrypt user names and passwords. For example, forms-based authentication should always be used in combination with encryption to ensure the security of your SharePoint sites. You are using forms-based authentication when you type your user name and password directly into a webpage rather than a Windows Security dialog box.

If you’ve read the section “The SharePoint structure” earlier in this chapter, you’ve seen one explanation of the connection between the content database and SharePoint sites.

All the information you see when you use your SharePoint site is held in a content database as follows:

The one upgrade approach in SharePoint 2013 is called a content database upgrade because each content database can be upgraded individually.

When IT executes an upgrade from SharePoint 2010, you can choose not to upgrade every content database in a farm at the same time. If you have more than one content database, this offers some flexibility for a phased upgrade.

For example, you might choose to move the database containing your most important sites first. Alternatively, you might choose a less important database as a first upgrade to refine your process and become more familiar with the steps involved.

A benefit of the content database upgrade approach is the option to leave the existing content available for viewing only while the upgrade is being performed. Because the content database can be copied to the new server, the original copy is still available for read-only use while the new copy is being converted to the SharePoint 2013 format. This is especially helpful for large content databases that require a long time to upgrade.

This approach requires that the customizations applied to your SharePoint 2013 installation are well documented and ready to move to the new environment. It also requires a strong understanding of the configuration settings on the farm and web-application level. In many organizations, this might not be a problem because configuration and customization documentation are also both required for disaster recovery.

The content database upgrade occurs on a new SharePoint 2013 farm. This means that additional hardware is required besides the hardware currently running your SharePoint 2010 farm. Besides being a requirement, it is also a benefit to have two environments available because the upgrade can be tested and repeated on the new hardware before committing to the final move from the old hardware.

Deferred Site Collection Upgrade is a new feature of the SharePoint 2013 products that can keep your upgraded site looking a lot like your old site.

When a content database is upgraded to 2013, site collections can be left running in SharePoint 2010 mode on the new SharePoint 2013 farm. The reason for this mode in your new upgrade is to allow time to update your old sites to the new features of SharePoint 2013.

SharePoint 2013 makes some important and wide-ranging changes to the pages on a site. It may take some work to transition from your old site. You can test your upgraded sites in SharePoint 2013 with a copy of the site collection before making the permanent move to SharePoint 2013 mode.

For sites that have a small amount of content, manual migration can be a good option. You might choose to replicate the previous sites as closely as possible through the creation of lists and libraries first and the addition of content second. Alternatively, you can take the chance to redesign the information architecture of your site. If you take the time to review the site to be upgraded, you might find that you only need to move over a small amount of information that is still relevant and useful to you and your users now.

Manual migration is often a team effort. You might want to involve site designers to work on a new look that matches or builds on the previous look. You want to plan for some testing, even if it’s just to get a second set of eyes on the work you do yourself. Breaking up the repetitive parts, like copying and pasting documents or text from old to new, can help make this go faster.

Many migration tools are specifically built to move content into new SharePoint 2013 sites. The basic premise of migration is no different than that of the manual migration. You can still choose to try to replicate the site that you are migrating from or you can take the opportunity to reassess your site and build into a new design that fits SharePoint 2013 better.

The big difference is that migration tools help do some of the repetitive, manual work that is involved in migrating to SharePoint. In fact, you might find yourself appreciating one of these tools so much that you keep it around to help you reorganize your content in SharePoint long after the initial migration is complete.

There are two kinds of third-party migration tools available. The simplest kind treats the source website as a collection of HTML webpages. Using this kind of tool, you move each page over, one by one, into a document library in SharePoint. That method really works only if all you have is content in pages, as opposed to items in lists or documents in libraries.

On the other hand, many of the third-party tools have specific features that target particular sources of information from which to migrate. You can find tools that help you pull data from older versions of SharePoint, competing products like Lotus Notes, and other technologies used to share information like Networked File Shares and Exchange Public Folders.

Each tool available works a little differently, so it’s best to go to the vendor for information on how to use the tool you choose. They are all happy to provide product demonstrations, and many provide trial versions of their products so that you can test them out on your actual content.