This section highlights the assembly of the various roles that will be needed on the deployment team. This team should consist of 6 to 12 members. Be careful not to place too many roles on a single individual unless there is no other choice. Larger implementations may have more than 12 team members, but in such cases, roles need to be clearly detailed with expectations for how each person will contribute to the overall SharePoint Server 2007 deployment. These roles include the following:

If possible, we recommend including representatives from your business stakeholders who can be kept informed of the deployment process. Now, to be fair to Microsoft’s project plan, they may have intended stakeholders to be members of the communications team. But if not, we would strongly suggest that the stakeholders be involved at some level in the SharePoint deployment process.

We believe that the project manager should be the public face of the project team; thus, the communications role can filter through this position. We also believe that a technical writer or someone who can document the technical aspects of the deployment is a role that needs to be fulfilled on the overall deployment team.

The review of the technical requirements should be fairly straightforward. By the time the deployment plan is drawn up, the project charter should have been completed and the process for testing SharePoint Server 2007 against its competitors finished. The business requirements that translate into technical requirements should be well known to all now. The final agreement on the deployment between the technical staff and the business folks should have been firmed up. Reviewing the technical requirements should be done with a view to understanding and implementing—not with a view to changing or modifying—unless unforeseen context variables force the discussion and decision of change or modification.

Governance rules should have already been drawn up by this stage. You’ll use the governance rules to understand who in the organization can change the technical requirements and the methods that must be employed to have them changed.

There are a few specific tasks that need attention. The first task is determining the user experience requirement. What you should consider regarding this task is the determination of the types of customizations that are needed for various users who will be using SharePoint Server 2007. Accountants will need something different than salespeople. Executives will need a dashboard. Customizations will likely be a part of your deployment. Understanding and reviewing the customizations that will be needed is a part of this process. But you shouldn’t expect that all of your customization needs will be known in advance. As users use SharePoint Server 2007 and become more familiar with it, they will ask for more functionalities down the road, so you should be prepared to have development help available to you by hiring a consulting company or a full-time developer.

The second task that quietly appears in this list is to determine content migration requirements. Those who are migrating content to SharePoint Server 2007 well know that this is an entire project plan and effort in itself, and it often defines the entire deployment effort. If you have information from other sources that needs to be migrated, take your time to determine how this information should be imported into SharePoint Server 2007. For example, if you’re moving large sets of files from one location to SharePoint Server 2007, you’ll want to ensure that you have SharePoint Server 2007 set up correctly to receive those files.

Third, coupled with this migration strategy is the task to review the taxonomy and content type requirements. When moving information into SharePoint Server 2007, it is essential that the correct content types exist so that the documents can be described correctly via metadata assignments. Contrary to popular belief, moving documents into SharePoint Server 2007 does not make those documents more findable. The larger the document set that is migrated into SharePoint Server 2007, the more true that statement becomes.

Why? Because as the size of the document set grows, the meaning of individual words within the document set will become more randomized. Our natural use of language is to use the same words to mean different things. For example, if we were to look at a set of documents about music, the word "horn" would likely have a singular or very narrow meaning. But if we were to download all of the words from the United States Patent and Trademark Office (where the foci of documents is highly randomized), then the word "horn" would take on multiple meanings across the entire document set.

In most organizations, you’ll have documents that have widely divergent foci, and thus the same words within those documents will mean different things. If you index just their contents and then execute a query, you might receive a syntactically correct result set, but the meaning of those keywords will be widely divergent. It is a horn, a horn, or a horn?

The two tasks in this stage deal with communication and branding. First, the task of disseminating project information (presumably at the right time and to the right people) is essential to keeping everyone on the same page and reducing surprises as the rollout moves forward.

The second task is determining branding requirements. When you see this, think "master page customizations" because this is precisely why master pages were created in the first place. Farm-wide branding and navigation structures can be backed into the master page set so that certain elements appear across all or most sites in SharePoint Server 2007.

Several coexistence strategies need to be considered, but the most prominent one for our discussion is third-party software for SharePoint implementations.

More than a few third-party vendors make software that increases the value that SharePoint Server 2007 brings to your organization. These products vary in terms of quality and effectiveness, so you’ll need to test products you’re considering before you purchase them. When it comes to third-party software purchases, we find that it is a best practice to purchase third-party software that does not need to be restored as part of your overall farm restoration plan. In the event that you need to restore your farm, it would be better to simply restore your SharePoint Server 2007 farm and then have the option to restore the third-party software at a later time—perhaps a few days or even a few weeks later. We recommend this because not all third-party software platforms restore with the same quality and reliability as SharePoint Server 2007.

Products that install themselves in such a deeply nested way as to require a restore scenario where you must restore SharePoint Server 2007 should be thoroughly tested and approved before moving ahead with their purchase. In addition, look at the history of the third-party software company and ensure (as best you can in this cottage industry) that it has the stability and reliability to "be there" for the next release of SharePoint Products and Technologies.

We encounter customers who regularly tell us that, for various reasons, their management won’t pay for a lab environment in which they can test their SharePoint Server 2007 implementations. It is a best practice to have a lab environment where SharePoint Server 2007 can be tested and new ideas tried out before they are encountered in production. Not to have such a lab is analogous to a sports team not having a place to practice before it plays its games. Reasons to stand up and maintain a test environment include the following:

The reason that you do all of this in a lab environment is because you want to closely manage your changes in production. Effecting changes directly in production can have unforeseen side effects and can sometimes cause your production environment to be offline for a period of time. Proper change-control management dictates a testing environment of changes with evaluation and review before committing those changes to production. Don’t underestimate the value of having a test lab available to test changes to your production environment.

Every so often, our customers will ask us if SharePoint Server 2007 is really secure. Since this is a relative term, our answers tend to be given against a more defined context. What is meant by "secure?" Can the servers or farm be placed in a perimeter network? Where should extranet accounts reside? What is the level of risk that is assumed when SharePoint Server 2007 is opened to externally initiated connections?

What the administrator is really asking is this: Is SharePoint Server 2007 security implemented in such a way that it is difficult to hack from the outside? Our answer is yes, but like all products, it needs to undergo a security test or audit to ensure that it meets your security requirements. Every software product you purchase carries a certain level of risk. We do not believe that SharePoint Server 2007 is any more risky than any other Web-based software product. Properly implementing Internet Information Services (IIS) and your firewall has as much to do with securing your SharePoint Server 2007 content as properly securing SharePoint Server 2007 itself.

Traditional risk analysis involves the identification of three basic elements:

Like it or not, your users will likely upload highly sensitive information into their sites and use SharePoint Server 2007 as the collaboration platform in which this information is further developed and/or refined. Because of this, part of your governance and content planning should specify if there are any types of information that should not be hosted in SharePoint Server 2007. This isn’t a tacit admission that SharePoint Server 2007 is insecure. Instead, it is a recognition that some levels of information, based on their security clearance or method of authentication, are not appropriate for a Web-based information management system. Presumably, the same decision would be made regardless of which Web-based collaboration program was under consideration.

One risk factor for your deployment will be the level of education and expertise your farm administrators and developers have to support your deployment. Unwise administrators who make unwise decisions can cause significant difficulties for your deployment. Developers who write insecure code or write Web parts that cause significant rendering time and processor cycles can injure your deployment.

A potentially fatal risk factor is the absence of clear business and technical requirements for your SharePoint Server 2007 implementation. Closely associated with this risk factor is the absence of clear governance for your SharePoint Server 2007 implementation. Organizations that lack these three elements—clearly articulated business requirements, clearly articulated technical requirements, and clear governance standards—face a very high probability that their deployment will be, at best, minimally successful and, more likely, a failure.

Notes from the Field: Managing Resistance to Change

Every SharePoint Server 2007 implementation that we have seen represents significant change for everyone involved with the organization. When implementing change, one of the main aspects that you’ll need to understand is how to assess resistance to that change. You can consider both overt and covert resistance to the SharePoint Server 2007 deployment as a potentially fatal risk factor that must be managed. (Other risk factors that can originate within your organization are a lack of grassroots demand for a SharePoint Server 2007 deployment; lack of an approved, funded budget; lack of high-level support in your company [think vice president levels and higher]; and a lack of control over your project, its goals, its objectives, its measurements, and the hiring and firing of team members.)

Resistance can be assessed and managed by proactively mapping the influence landscape. This means that you identify who needs to be persuaded and how they can be influenced. This will involve mapping the key groups and subgroups that will need to be influenced, along with any groups that are already positive toward a SharePoint Server 2007 implementation. Be sure to work with opinion leaders in your organization because they often exert a disproportionate amount of influence on others’ opinions and decisions. Chapter 2, discusses how early adopters also serve as opinion leaders within an organization.

The source of resistance varies:

• Loss of comfortable status quo: The users see no reason to change in ways that might force them work harder or differently.

• Loss of a sense of competence: The users will feel less competent working with new technology and will be unable to perform as required in the post-change environment. This may cause them mistakenly to assume that the new technology is too difficult to learn (think about all the tasks and responsibilities of a site administrator and/or site collection administrator).

• Loss of security due to uncertainty about their future: If the proposed change is implemented and users are unable to adapt, will their jobs be at stake?

• Negative consequences for key allies: They fear the consequences for others they care about within the organization who they feel may not be able to adapt to the new technology.

The key to dealing with resistance is to understand driving and restraining forces. Driving forces push users in the direction of adopting new technology. Restraining forces push users to resist new technology. The key is to identify both the driving and restraining forces and then find ways to strengthen the driving forces, weaken the restraining forces, or both.

Your users may face a "force-field" something like the following:

Assessing the driving and restraining forces to a SharePoint Server 2007 deployment will help you understand how to address users’ covert and overt resistance. In many cases, training, education, and an insidious (as opposed to acute) onset of the technology’s use will help lower resistance. Users may not see the driving forces as adequate tradeoffs for the restraining forces. They won’t think of it in these terms, but they’ll still do the cost/benefit analysis. Your job (or someone on your team) is to help them see that the perceived tradeoffs can be turned into a win/win for them personally as well as for the organization. No small task, we understand, but an important one that must be accomplished nevertheless.

One other note: Accentuating the positive outcomes that SharePoint Server 2007 brings to your organization in fulfilling business and technology requirements will go a long way toward answering users’ "why" questions.

Mark Schneider, PMP, sharepointplan.com

Writing an effective communications plan is an essential part of a successful SharePoint Server 2007 deployment. This plan needs to be understood and agreed upon as part of the project plan, and it needs to be faithfully followed. The guidelines of a solid communications plan include the following elements:

Table 6-1 offers an example of a communications matrix.

As you can see, this communications plan can become somewhat complex, but if followed, it will help everyone affected by the deployment to be informed as events that affect them occur. Possible groups that will need to be informed of deployment options include the following:

The types of messages that need to be communicated include the following:

This list is not exhaustive, but it is a starting point for your effort to build out a good communications plan. Be sure not to bypass this step of creating a good communications plan in your overall project deployment plan.

One of the aspects of Windows SharePoint Services and SharePoint Server 2007 that caught many off guard was the pervasive need for education across all groups at all levels within an organization that was adopting SharePoint Server 2007. It is not uncommon for us to hear about how intuitive the interface is to use, and it is true that the interface, in and of itself, is intuitive to use. But understanding the how of completing a task is vastly different and less important than understanding the why of engaging in the task in the first place.

While some education needs to focus on how-to topics, much of it needs to focus on the integration of how the product works with your governance and use policies. For example, you might turn on Self Service Site Management, which allows everyone with permissions to create new site collections within one or more managed paths. Yet, in order to control the growth of the site collections in your farm, you may need to propagate business case criteria for when a new site collection is created. So not only does your education need to inform users about how to create a site collection, it should also inform them about your organization’s policies on when to create new site collections.

We find that the following groups need education:

Now, you might wonder who in your organization will need which levels of education. Best practice is to err on the side of offering too much education as opposed to too little. For example, once you open up My Sites, you’ll find that every person who creates their own My Site will automatically become a site collection administrator because each My Site is a separate site collection. Site collection administrators will be able to manage individual sites, so they will need site administration training, too. In many organizations, we find that the vast majority of users will be both site collection administrators and site administrators within the first two years of SharePoint Server 2007 implementation. Of course, this isn’t true for all organizations, but it is certainly true of those who are content-centric where information is created, managed, modified, and used by the wide majority of users within the company.

We strongly recommend a robust training program for everyone in your company. In fact, in many situations, if a company can train its workforce appropriately, we find that the company’s need for consulting services diminishes significantly. Training that teaches you to know more so that you can do more is the type of training that you should pursue.

In this section, the most often-asked question that we receive is whether a company should upgrade to Microsoft Office 2007 at the desktop. Our response is that those companies that are running Office 2007 at the desktop will experience a higher return on investment (ROI) for their SharePoint Server 2007 implementations than those who remain at Microsoft Office 2003 or earlier.

One of the main reasons for upgrading to Office 2007 is the existence of the Document Information Panel (DIP), which interacts with the content types in SharePoint Server 2007 to ensure that required document metadata information is input before the document can be uploaded or utilized by others within SharePoint Server 2007. Note that the DIP doesn’t ensure that site columns in the library are populated when the document is uploaded. The DIP is intended to populate document metadata that is attached directly to the document through its content type or through customized metadata fields embedded in the document.

There are other points of integration between SharePoint Server 2007 and Office 2007, but this is an obvious feature that might drive an upgrade to Office 2007 as part of a larger, overall SharePoint Server 2007 deployment. One other obvious integration point between Microsoft Office 2007 and SharePoint Server 2007 is the list synchronization between Office Outlook 2007 and SharePoint Server 2007.

It is a worst practice to upgrade to Office 2007 at the same time that SharePoint Server 2007 is being deployed. This is too much change for your end-users to assimilate at one time. Instead, conduct the Office 2007 upgrade either before or after the SharePoint Server 2007 deployment so that the change the users encounter can be spread across a longer timeline.

Even though most of Microsoft’s sample plan has a planning task at this stage of the deployment process, the creation of a governance plan should be in place before starting your SharePoint Server 2007 deployment. The governance plan need not be complete, but the high-level standards need to be in place. More importantly, the process for gathering and evaluating new standards from your users needs to be settled.

There is a range of decisions to be made in this area—not just about hardware and server roles, but about other configurations for your deployment. In fact, any configuration that can be effected in Central Administration or a Shared Services Provider could be included in this section. These decision points include elements such as the following:

Many of these decisions are discussed in other parts of this book. But suffice it to say that each decision should be measured in light of whether it supports, either indirectly or directly, the business and technology requirements as well as whether it is in line with the governance standards that have been established.

Probably the largest consideration when planning for security is the interaction of how you’ll configure authentication providers for Web applications, the zones to which each Web application and its extended Web application are assigned, and the security policies for users and groups that you’ll assign to the zones and Web applications. With the appropriate use of policies that are applied to zones, you can tightly define who has access to which content and the level of access they have.

Best practice is to identify certain users who must have or must not have access to certain content and then use policies and zones to achieve the configured security that you need.

In addition, how users will secure their sites is an important discussion. By default, site administrators have the ability to secure objects within their sites using either Active Directory directory services group or user accounts. IT administrators who like to "lock down" their SharePoint Server 2007 deployments prefer to use group accounts instead of user accounts because the group accounts can be assigned once and user access can be controlled through group membership assigned in Active Directory. Users like to user accounts because they often don’t understand the group account naming convention in Active Directory and can’t enumerate that group’s memberships. Therefore, it’s easier to use user accounts to assign permissions, even if this means assigning more than a few users to an object.

On the face of it, assigning permissions using group accounts seems to be the fastest, easiest, and best way to manage permissions. The groups are already familiar to IT personnel. They know how to assign permissions in SharePoint Server 2007 (presumably), so it seems a natural, logical extension of their functions.

But upon closer examination, using groups to secure objects in SharePoint Server 2007 is fraught with opportunities for mistakes. Because site administrators cannot enumerate group memberships in Active Directory, there is an inherent opportunity for miscommunication to occur between the Active Directory administrator and the site administrator. Let’s assume that the site administrator needs 70 people to have various levels of access to her site. First, she needs five people to be site administrators, so she and the Active Directory administrator will need to communicate and set up an Active Directory group with herself and the five other members. Then, she needs 30 of those 70 people to be members in the site with collaboration permissions, so she needs to communicate to the Active Directory administrator a second Active Directory group that needs to be created for the members in the site. Third, the other 40 members need to be placed in the visitors group, so she communicates the membership to the Active Directory administrator and has a third Active Directory group created.

Now let’s assume that four of the visitors need to be upgraded with member permissions in the site. The site administrator communicates this to the Active Directory administrator, who then removes them from the visitor’s Active Directory group and adds them to the members group for the site. A few days later, three people leave the company and four more are hired, so the three who were members of the visitors group need to be removed in Active Directory and the four who were hired need to be added to one of the groups in the site. So the Active Directory administrator must communicate with the site administrator about which Active Directory groups in which to add these four new people, and the site administrator communicates this back to the Active Directory administrator.

Now let’s assume that 15 of the 30 users in the members group need to be given permissions to create subsites. The site administrator creates a new SharePoint group for this group of 15 users and communicates this to the Active Directory administrator, who in turn removes them from the members Active Directory group and adds them into the newly created Active Directory group for members who can also create subsites.

Five of the users go off and create new subsites, which would be expected behavior. However, they decide to break permissions inheritance and thus become the sole administrators of their subsites. They need to add users into their sites, so they send an e-mail to the Active Directory administrator requesting new Active Directory groups with a list of users for each group. Now the Active Directory administrator is working with at least six different site administrators to keep permissions consistent between the group memberships in Active Directory and the needed permission assignments at the site level.

In this scenario, the administrators of all of these sites have no method of remembering who is in which Active Directory group, so the Active Directory administrator will be responsible to help the site administrators understand who has been added to which Active Directory group so that the site administrator can responsibly administrate security within her site. Unless the site administrator manually tracks who is in which Active Directory group, she will sometimes forget the Active Directory group’s membership and will need to have those members re-enumerated. This will add administrative effort for security management for both your site administrators as well as your Active Directory administrator(s).

Multiply this by 1,000, 5,000, or even 10,000 sites, and you soon realize that, unless you’re prepared to hire additional full-time staff for your Active Directory team, implement a robust permissions workflow between your Active Directory administrators and your site administrators, and implement some type of Active Directory group membership enumeration that can be accessed by the site administrators without involving the Active Directory administrator, this scenario will grow out of control pretty quickly. While the use of groups to manage sites seems best in most cases, the workload on the Active Directory staff becomes overly burdensome, and the workflow to get new groups created that match the needs of the site administrator becomes too cumbersome.

It is best practice to allow site administrators to assign permissions directly, offering them some global groups that have wide memberships in case they want to expose portions of their sites to the rest of the organization. It is a best practice to place all of your Active Directory groups that will be used exclusively in your SharePoint Server 2007 implementation inside their own organizational unit (OU). Through the use of third-party permissions control software, site collection administrators and site administrators can effectively control all of the permissions for those sites that they administrate.

Managing Permissions Using Active Directory Groups versus Active Directory User Accounts

Even though we have argued that it is a best practice to use individual user accounts to manage permissions at the site and object layer, this method is not without its problems and drawbacks. Without the use of third-party software, user permission management is randomized and highly dependent on each site administrator being proactive to keep permission assignments up to date. What follows in Table 6-2 is an overview of the advantages and disadvantages of permissions management in SharePoint Server 2007.

Table 6-2. Permissions Management Tradeoffs

Scenario	Active Directory Groups	Active Directory User Accounts	Tradeoff
A new site collection needs to be created.	The root site’s template will have various permission levels as part of the template. New Active Directory groups will need to be created for the root site and any sites that will inherit permissions from this site. When permission inheritance is broken within the site collection, a new set of Active Directory groups will be need be created for the new subsite that has broken inheritance.	Users are added directly to the default SharePoint groups.	If you are using Active Directory groups, the creation of a new site collection is throttled by the need to loop through the Active Directory administrator to create the new Active Directory groups that will correspond to the permission levels in the site. For example, if you’ll have administrators, members, and visitors, then three Active Directory groups will need to be created to accommodate those three permission levels.
A new subsite within a site collection needs to be created, or inheritance needs to be broken between a parent site and a subsite.	The Active Directory administration will need to be notified, and a new set of Active Directory groups will need to be created for this site if permissions are not inherited.	The new subsite can be quickly and easily created by the users themselves without looping through the Active Directory administrator.	The use of Active Directory groups to secure sites will hamper the self-organization features of SharePoint Server 2007 and likely will create bottlenecks in the security assignments for each site.
A user needs to be added to a site at a certain permission level.	The Active Directory administrator needs to be notified to add this user to the appropriate group in Active Directory.	The site administrator adds the user to the SharePoint group directly without looping through IT personnel.	The user account method is faster with a much lower transaction cost. The Active Directory group method keeps IT in the loop and makes them responsible for the security on the site.
A user needs to be added to the site collection as a site collection administrator.	Groups cannot be added as site collection administrators.	User accounts must be used for site collection administrators.
A user needs to be given unique permissions within the site.	A new Active Directory group must be created and the user’s account added to the group. Then the site administrator must add the Active Directory group to the newly created SharePoint group.	The user account can be assigned unique permissions directly by the site administrator.	The user account method is faster with a much lower transaction cost. The Active Directory group method keeps IT in the loop and makes them responsible for the security on the site.
A user leaves the company or is transferred outside the "scope" of the SharePoint Server 2007 farm.	The Active Directory administrator disables the user account and eventually removes the account from Active Directory completely. There are no "left-over" accounts in SharePoint to clean up.	Each administrator must be notified or otherwise learn that the user has left the company and then must go through each site with explicit permissions and remove the user’s account manually.	Most site administrators will not take the time to methodically remove user accounts. In most cases, the user account will persist in SharePoint Server 2007. This does not represent a security problem because SharePoint Server 2007 only performs authorization based on authenticated accounts, but it may place your SharePoint Server 2007 implementation outside of compliance with current laws and regulations.
Need to discover permissions on an individual user farm-wide.	Active Directory administrators can manually report in which Active Directory groups the user is a member. Complete reporting would depend on up-to-date documentation that reports which Active Directory group has been assigned to which SharePoint group. Also, documentation would be needed to disclose which Active Directory groups are nested within which Active Directory groups and then which nested Active Directory groups have been assigned to which SharePoint groups.	There is no method to discover user permissions within SharePoint Server 2007 outside the view of the permissions for the current object in focus.	Third-party software will need to be utilized to provide a thorough reporting capability.
Need to discover who has permissions to an individual object, such as a document or library.	The Active Directory administrator cannot provide this information because his responsibility stops at creating Active Directory groups and populating them as requested by the site administrator.	The site administrator can see who has permissions to a document or library, but cannot know if any Active Directory groups are nested within the Active Directory groups that have been assigned permission to the object.	This functionality is best served through the use of third-party software.
There are 50 subsites within a site collection. The site collection administrator needs to know where permissions inheritance has been broken.	The Active Directory administrator will not be able to provide assistance in this scenario.	There is no method native in SharePoint Server 2007 to provide this functionality.	Third-party software must be utilized to display where permissions inheritance has been broken within a site collection.
The site administrator has lost track of which users are members of which Active Directory groups.	The Active Directory administrator will need to provide this information to the site administrator, and/or the site administrator must manually keep track of who is a member of each Active Directory group and regularly "sync up" her list with the Active Directory group membership assignments in Active Directory.	The site interface will inform the site administrator about which Active Directory groups have been assigned permissions but will not enumerate the group’s membership in the display. The use of individual user accounts can immediately inform the site administrator of permission assignments.	This is probably the most thorny aspect of using Active Directory groups to secure sites in SharePoint. The lack of local security control by the site administrator places her in a position of being responsible for the site’s security but not directly having the power and control to secure the site properly.
The site collection administrators need to swiftly secure a site in an urgent or emergency situation by removing all permissions and assigning themselves only to the site’s permission structure.	For each unique set of site collection administrators, an Active Directory group will need to have been created in anticipation of this scenario. If Self Service Site Management is turned on, a manual workflow will need to be created to ensure that each new site collection’s ownership assignments are reflected in an Active Directory group. As site collection owners are added later, the workflow will need to ensure that additional users are added to the Active Directory group. Note that Active Directory groups cannot be added as site collection owners.	The site collection owners simply go into the site, give themselves full permissions, and then remove everyone else from the site.	It is highly unlikely that most users will pay attention to this type of workflow and participate in it, in part because this scenario will seldom be a reality. In addition, enumerating, tracking, and "syncing up" the site collection ownership assignments to their Active Directory groups would be difficult to achieve outside a manual process. It would almost certainly require custom code of some type.
By default, each My Site is considered a site collection and is secured with the NT_Authenticated Users group having full read permissions and the individual user having full ownership permissions.	When a user creates her My Site, the user’s account is placed into an Active Directory group for that site collection and then is assigned the proper permissions in the My Site by the Active Directory administrator or the user herself.	Users can directly assign permissions to individual users without having to loop through the Active Directory administrator.	The use of Active Directory groups to secure objects in My Sites is cumbersome and will require custom code.
A user creates a subsite in his My Site and needs to add three co-workers to the site.	A manual workflow process will need to be created that allows the individual user to either request or create a new Active Directory group with himself and his three co-workers added to the group.	The user is able to add these three co-workers directly without looping through the Active Directory administrator, thereby making the new collaboration space truly self-organizing with a low transaction cost.	The potential for backlog requests to pile up for the Active Directory administrator is high. If you have 2,500 users, each of whom have a My Site, plus another 5,000 site collections in your implementation, the sheer number of requests for new Active Directory groups and modifications to current group membership will likely be very, very high. As your implementation grows, the number of requests will grow because nearly every user in the company will, at one time or another, make a security request to the Active Directory administrator.

As you can see, permissions management in SharePoint Server 2007 is difficult at best because the normal tools that you would use are not available in SharePoint Server 2007, and the substitution of Active Directory groups for user accounts does little to solve the overall permissions problem. The federated, decentralized design for administration in SharePoint Server 2007 also means that the security management of information in SharePoint Server 2007 is also federated and decentralized. No matter how much you try to centralize it, you’ll probably fail without extremely tight controls and additional IT personnel to manage it all.

Another area of security to consider is the use of Secure Sockets Layer (SSL) certificates for your SharePoint Server 2007 Web applications. SSL certificates have to be assigned to the Web applications after they have been created. There is no place in the interface to specify an SSL certificate as part of the Web application creation process. Likewise, for those who need to use IP-bound Web applications, you’ll find yourself unable to assign an IP address to the Web application during its creation process.

When a Web application is created, the information that you enter on the extendvs.aspx (Figure 6-1) page is downloaded into the configuration database. After being written to the configuration database, it is then pulled back into memory on the Web servers and used to create the Web site in IIS and then extend it with Windows SharePoint Services to create what we know as a Web application.

Figure 6-1. Extendvs.aspx page

If the Windows SharePoint Services Web application service (Figure 6-2) is stopped, all of the Web sites and their configurations will be deleted from the SharePoint Server 2007 server. This happens by design because only those servers fulfilling the Web role need to have Web sites installed on them. If the service is then restarted, the Web sites will be rebuilt using only the information they can find in the configuration database. This means that any customizations or modifications you made to each Web application after it was created will need to be reapplied to the Web application, including IP address assignments, SSL certificate assignments, customizations for the web.config files, and any other file customizations or additions to the Web application’s files.

Figure 6-2. Server service page in Central Administration

Note

The Web applications are not removed and rebuilt during a reboot of the server or during the running of the IISRESET command.

Given all this, best practice is to completely document any changes you make to your Web applications in IIS after the Web applications have been created.

We think that most readers will stipulate the argument that planning for performance is a good idea. What most will want to know are the performance benchmarks that should be considered in regard to SharePoint Server 2007 servers.

Unfortunately, that type of benchmark data is difficult to find and even more difficult to generalize because networks are as unique as they are numerous. What would be considered a bottleneck number for an individual counter in one network wouldn’t be considered as such in another. This is due to differences in hardware, network equipment, user demand, and services running on each server.

Best practice is to use the information found in Chapter 23, to help you develop your own baseline of counters that you consistently log for the same period of time each month. After a few months, you’ll have baseline counters from which to predict future usage given different sets of variables. While we can’t say what numbers will represent a best practice for your organization, we can say that monitoring your farm to build out a baseline set of numbers is a best practice, both for performance and for capacity planning.

Obviously, backup and restore are an essential part of any software deployment model. SharePoint Server 2007 is no exception. The most thorny problems that we encounter are those with geographically dispersed environments trying to figure out how to failover SharePoint Server 2007 from one datacenter to another. The problem with planning a failover for SharePoint Server 2007 is that SharePoint Server 2007 itself isn’t written to work in a clustered environment. Microsoft SQL Server 2005 is, but SharePoint Server 2007 is not. So, it’s wrong to say that SharePoint Server 2007 can failover in a clustered environment because it can’t. It’s not written to do this.

Any way you look at it, the failover capabilities apply only to SQL Server 2005 and its databases. While this will work for the content, you still need to contend with a failover plan for everything else in SharePoint Server 2007, including the Web application and its files, the metabase (or configuration files if running IIS 7.0 or later), the SharePoint Server 2007 binaries, the 12 hive where most of the farm’s files are placed, the index and any customized Web part assemblies, or application-specific files and information. Failing over all of this, which in our minds represents the entire farm, is not easy. To our knowledge, there is no built-in or third-party tool that will handle all of this for you easily, seamlessly, and quickly.

So, you will need to ensure that the various parts of SharePoint Server 2007 are synchronized on a regular basis between your data centers. To be specific, the parts that need synchronization are as follows:

Variations can be used to publish site templates in different languages if you need to expose different sites in your farm or a different farm using different languages. However, you need to know that the publishing of content in different languages will need to be routed through a human workflow for translation of the content. You can also check for third-party products that might translate the content for you before it appears on the target site in a different language.

Because variations depend on different language packs being in existence, best practice is to install the language packs early in your deployment.

The sample project plan lists the following integration points with SharePoint Server 2007:

Interestingly enough, the project plan doesn’t include the following:

Regardless of which product we include in the interoperability matrix, it is essential to understand what SharePoint Server 2007 doesn’t do. After your business requirements and technical requirements have been established, it may be that in order to meet all of the requirements, you might need to plan a deployment of several products, not just SharePoint Server 2007. Having said that, however, much of the functionality you’ll want will be found in SharePoint Server 2007, which means that the more specialized functions of project management or business intelligence will be found in add-on server products such as Office Project Server 2007 and Office PerformancePoint Server 2007.

Best practices are obvious here: Test, test, and test some more when integrating these different server products into a common solution. First install the base solution, SharePoint Server 2007, then install the other products and add them over time. Give your project plan room to rest between finishing the installation and deployment of one product and beginning the next product’s installation and deployment. Give yourself time to stabilize, evaluate, and assess before moving along to the next software implementation.

Just because you initially configure and deploy SharePoint Server 2007 correctly doesn’t mean that it won’t need care and feeding in order to remain in top performance condition. This part of the plan should detail the regular maintenance activities for your SharePoint Server 2007 farm.

Many of these activities are already built in to your timer jobs in Central Administration. Most run at the site collection level, but others run at the Web services level. All of the jobs should be allowed to run based on their schedule, and of all the jobs are necessary to run—even if you don’t understand them all. Don’t delete them. They are there for a reason and need to run.

Other maintenance activities are built off of your deployment configuration choices. For example, if your deployment doesn’t allow databases to grow beyond 50 GB, then a routine check of database sizes would seem to make sense. Creating new databases to accept the new site collections and their information would also be in order when the current content databases reach a certain level, such as 80 percent capacity.

As you grow in your experience and knowledge of SharePoint Server 2007, you’ll find that this ongoing maintenance plan will be refined and tailored to meet your organization’s individual needs. The best practice for this section is to ensure that you have a regular maintenance plan and that you’re methodically and routinely working it.

Regarding plan content and navigation structure, we believe that Microsoft has repeated itself in its project plan. The planning of URLs, custom master pages, and the overall taxonomy of your SharePoint Server 2007 deployment has been covered in other sections of the project plan. We suggest that your plan either move these previously discussed topics to this part of the plan or move the tasks within this part of the plan to an earlier part of the overall deployment, such as that discussed in the "Determine Preliminary Design Objectives" section.