For those who are new to SharePoint, an immediate change will be how documents are accessed and consumed. At present, many companies have shared network drives that host large data sets with hundreds or even thousands of folders with tens of thousands of documents. It is not uncommon to hear of shared network drives that host a terabyte or more of data, much of it redundant, old, outdated, and unusable. So, two problems immediately present themselves in this scenario.

First, as SharePoint is increasingly used, users will not access the shared network drive to work with a document. Instead, they will access the document using a URL namespace via their browser or their Office client. The catch is that it’s difficult to use the Office client to access a document library until the user has manually created a Web folder client connection to the document library, or the user has created a mapped drive to the document library, or the user has visited the library and worked with documents in such a manner as to have the Web folder client connection automatically created in their My Network Places on their desktop. This need to "visit-first" in order to obtain a shortcut route to the document library can be frustrating for your users.

Logically, the shared drive’s contents will likely not be hosted in the same document library. In nearly all scenarios, this shared drive’s content will be re-hosted in SharePoint spanning many, many document libraries. So, what once was a single drive mapping for the end-user that resulted in wading through countless folders to find their documents now becomes accessing information through a plethora of Web folder client connections while learning to manage documents across many different document libraries and sites.

Our recommendation is that users be taught how to use Favorites, My Links, and shortcuts to help them organize the document libraries for quick access to these locations. In addition, we recommend that users be taught how to create mapped drives for certain document libraries in which they will be working most often.

A second scenario that we commonly encounter is department-level file servers. Similar to a shared network drive, users work on documents that are hosted on a local file server. From a user’s perspective, this scenario is similar to the shared network drive scenario. But from a manager’s perspective, this scenario might result in change, power, and conflict issues. Consider a manager who believes her department’s information is her information. In other words, she believes that what she and her department users produce belongs to her department first. This manager is likely to resist having that information placed in some remote, Web-based collaboration system on servers that she can’t control. Sound familiar? Many of you are undoubtedly nodding your head "yes."

This type of scenario, whether it be a manager or single end-user or a project team, represents a power issue. If these folks believe that SharePoint will infringe on their ownership and manageability of the information, they will see it as a direct threat to their power over the information. You’ll need to work with them to help them see that they still maintain power and control over the information if it is hosted in SharePoint through site collection and Web management.

Nearly everyone who is reading this chapter has had the experience of collaborating on the development of a new document. For many years, we have e-mailed documents back and forth, putting version numbers inside the document and/or in the name of the document while implementing a manual workflow to gain approval for the finished version of the document.

SharePoint represents a new collaboration path for documents that are in development. Having written several books using SharePoint as our back-end system, we can attest that even those whom you would not suspect will have a difficult time remembering to use the check out/check in features for simple document collaboration. The culture change of not e-mailing documents to team members for their consideration is huge. The idea of putting a document in a team site and then inviting others to the site so they can check out, read, modify, and check in a document is vastly different from the immediate gratification of sending an e-mail with instructions about the attached document.

Don’t assume that simple document collaboration will be understood or will be intuitive for even your advanced users. Best practice is to ensure your users have received collaboration and governance training on how to work with documents in SharePoint. Since document collaboration is one of the key selling points for SharePoint, making document collaboration training a core part of their training experience is smart.

SharePoint is designed to have both a centralized administrative architecture that parallels a distributed administrative architecture. Some functions, such as Web application creation, alternate access mappings, or configuring policies for Web applications, are reserved for those who manage the SharePoint farm from a central location. These functions are grouped under the Central Administration site.

All other administrative functions—at the site collection level as well as the site level—are distributed to those who create and manage sites and site collections. In the vast majority of implementations, these two levels of management are performed by non-technical, non-IT users who happen to have some technical acuities and interests.

Having said this, it is important to note that once you open up My Sites to the masses in your organization, each person who is able to create a My Site also becomes both a site collection administrator as well as a site administrator. This is because each My Site is a separate site collection. So, in the long run, everyone who has a My Site will need education on how to manage and utilize the features in their My Site as well as more generic site collection and site administration. Failure to do this will result in both a lower ROI (Return on Investment) as well as increased help desk calls asking about how to use this or that feature or administrative link.

We often have customers whose SharePoint farm administrators want to "lock down" their SharePoint implementation. They want to retain centralized administrative and security controls over all of the site collections and sites within SharePoint. Often, they use global groups from Active Directory to centralize their security control and force users to request new sites each time a new collaboration space is needed. They have very little trust in their end-users and usually are rather cynical about their users’ abilities to manage a Web site. They conclude that by retaining centralized control, they will avoid a number of support incidents that would otherwise be created by users who might commit unwise actions with the site.

While we believe that much of the "lock down" mentality is more emotionally driven based on poor end-user support experiences, we have found there are some scenarios where this type of implementation makes sense. Usually, these scenarios have some or all of the following characteristics:

What is helpful to understand is that all of these characteristics are either function specific or time specific. And in nearly all of these scenarios, we find that while there is justification for locking down these sites, there is also justification for having other parts of the deployment more open to end-user control. Rarely do our designs for customers fall 100 percent in either the "open" or "locked down" camps. Commonly, a combination of both aspects is included in a complete design.

So, don’t be afraid to lock down those sites that should be locked down by having your IT staff centrally control the security and functionality in the site. But also, don’t shy away from having some areas where the collaboration sites can be self-created and self-organized by the end-users without looping through your IT staff. One of the hallmarks of a highly collaborative system is that the collaboration spaces are self-organizing with a low transaction cost. SharePoint has the flexibility to provide both centrally secured sites alongside user-created and secured sites.

Also, from a sheer workload perspective, it is often unwise to have IT manage all of the sites. For example, let’s assume that your implementation calls for seven Web applications and that, over a period of one year, each Web application has an average of 40 site collections with an average of four sites within each site collection.

If we do the math correctly, that will mean a total of 1,120 different Webs within your farm. With an average of 11 Web parts and lists per Web, that’s a total of 12,320 lists. If each site has an average of four different SharePoint groups and each group is secured by a corresponding global group in Active Directory, this would mean creating 4,480 global groups in Active Directory. So, for IT to granularly manage the security for each site, your IT staff would have to pay attention to 1,120 different Web sites and potentially secure thousands of lists while creating, populating, and managing nearly 5,000 global groups. By any standard, this would represent enough of an additional workload on your IT staff that you would need to hire additional employees to keep up with the SharePoint management tasks. And the coordination of efforts across all the sites and Active Directory groups would be substantial too.

Now, we realize that some will find this illustration a bit absurd, but in our customer work, we encounter those who seriously think about doing this. But when we illustrate what this really means in terms of objects managed, the number becomes overwhelming and, usually, customers end up deciding to allow their users to manage a significant portion of their implementation.

Like it or not, SharePoint Products and Technologies is an administrative-heavy platform that doesn’t appear to be so mainly because the administrative workload is distributed across many end-users at the desktop. Centralization of the administrative workload will require additional full-time employees that will need to increase in number as your SharePoint deployment increases in scope.

So, best practice is to train a sub-set of your end-users to be SharePoint Power Users (or whatever title you wish to give them) who can effectively administrate and secure major portions of your SharePoint deployment, including site collection administration. We feel it is simply impractical to centrally administrate a SharePoint farm in all but the smallest of deployments.

What sends some Type-A administrators into a panic is when they realize, for the first time, that their users will become the masters of their documents, not only in terms of the documents’ management, but more so in terms of securing those documents. More than once, we have engaged in extended discussions about the potential exposure to legal liability should a document containing sensitive information be made available to the wrong person(s).

It’s interesting how users react to this newfound responsibility. Some become much more ferocious about securing their information than their system administrators ever were. It’s as if they (finally) have ownership of their documents and are making the most of their ability to secure their information. Some take the responsibility in stride and correctly secure their documents without any need to feel as if they "owned" their content. Still others appear to secure their documents but sometimes let the wrong people in for a few minutes, which results in the information being exposed to the wrong people.

But there will always be a few individuals in your organization who will quietly break the security rules now and then. It may be only.01 percent of your user base, but some of them will do it. Most will unwittingly expose information to the wrong individuals, but others will purposefully engage in this activity.

For this reason, best practice is to have a serious discussion with your legal team about the potential problems of having the different types of information exposed to the wrong people and how that information should be managed. Don’t allow highly sensitive information to be secured by anyone who hasn’t been properly trained and who meets other criteria that you might need to implement for your environment.

Another best practice will be for your information security policies to explicitly call out how documents are secured within your SharePoint environment and who is responsible for securing them. Content owners should be named for content that is hosted within SharePoint, and those owners should be the site collection owners and/or site administrators who are responsible for securing that content. Penalties should also be called out in the policy and then enforced when broken.

Finally, there needs to be a culture shift in how your organization thinks about information security. Your organization needs to understand that they should not look to IT to secure information that is hosted by SharePoint (except in highly centralized deployments) and should not hold the IT staff responsible for information that is wrongly secured and exposed.