I fully realize this is a stab in the dark at the actual Top 25 (they are in no particular order), but it is a compilation of questions from customers, students, conferences, blogs, and emails about the SharePoint Server 2007 Best Practices book. Additionally, I am not talking about development topics, because that would a whole 'nother animal (and I am not a developer) In other words, if you disagree with them actually being the top 25, that's ok :-) Because it is impossible to list every design variable for every SharePoint Server 2007 installation, I'm basically going to explain how to find the answer for your implementation. You will be provided with a foundation to go research each of these design questions for your environment. If you want to know more about these, come see us at the conference! I'm sure you can get your answers there.

#1 - Should I migrate all of my content to SharePoint Server 2007? A common mistake is moving lots of file share content, from tens or hundreds of files shares and systems to tens or hundreds of SharePoint Server 2007 sites, without a plan. If you move disorganized content to SharePoint Server 2007 without a plan, you will simply have disorganized content in SharePoint Server 2007! Except now you have probably tripled your per-bit cost! Part of your content migration plan should be an information architecture design. More importantly, you must educate your users on the correct way to store and retrieve content, or your well-laid plans can quickly erode. Planning and Governance are critical to successful content migration. Otherwise, you will simply have CHAOS! If you can, check out Joel Oleson's SharePoint Governance: From Chaos to Success in 10 Steps at 2009 Fall Dev Connections (he'll be co-presenting with another awesome MVP Dan Holme). Also, Robert Bogue has some great stuff on Governance (older, but useful Part 1 and Part 2, and a newer one with a presentation) , as does Mark Schneider (Mark also has Taxonomy tips and tricks, including 'When Taxonomies are Evil'). Train your users how to migrate data, tell them what to migrate, and archive the rest. I'll challenge you that less than 50% of your current file share content is actually needed. So go ahead and delete it! Whoa you say? Don't worry, I wouldn't delete it either! Not me! No way! Unless you have great metadata on your unstructured file share content (and I bet you don't) then the only folks who know whether or not you need the content are the Data Owners. We're all afraid to delete someone else's data for fear it will then be needed. File shares aren't dead, btw - I've seen that SMB 2.0 is greatly improved over the last version and will help with DFS over the WAN. This reduces the driving factor in some organizations to move everything into SharePoint for sharing. Basically - put 'stuff' into SharePoint when you need SharePoint functionality - like versioning, workflows, policies, templates, publishing, etc. If you aren't going to collaborate on the content, you might consider leaving it on a file share.

#2 - How large can my content databases be? That is a very common question that is mostly related to you service level agreements (SLAs). An SLA defines, among other things, the maximum time to return your application to service. If you do not have an SLA, you should ask the stakeholders how long your system can be down in the event of failure. You must take the maximum amount of time you can be down and calculate how long it will take you to restore a database in the event of a problem. For example, if your SLA defined four hours as the maximum down time, you would need content databases no larger than about 150GB with the average tape system on the market today. You should test your backup and restore speeds to a SQL Server instance to benchmark performance for your system. Once you have calculated the maximum size your content

databases can grow to, divide that size by the site quotas used in the Web application associated with those content databases. Here is an example of calculating content database size:

(Site Quota) x (Number of Site per Database) x (% of 2nd Stage Recycle Bin) = Maximum Database size

You must estimate your backup throughput, populate content databases with information and test in your environment. Nobody can tell you exactly what your numbers should be. But I can assure you that the default settings of 9,000 sites before a warning and 15,000 sites maximum are unlikely to be accurate in your environment. If you thoughtfully set these, you will assuredly have multiple content databases per Web application.

Another size issue to not overlook is database locking, which can cause blocking. Microsoft has recommended that databases not be larger than 100GB, but it seems they are simply hedging their bets in regards to database blocking. Essentially, that limits the I/O of SQL Server and reduces the chance blocking will occur. I have recently confirmed that large site collections are a bad idea and can cause database blocking. Imagine this - You have 200 sub-sites in a Site Collection. Because the entire Site Collection is a single table, a large transaction that must lock the table now blocked all 200 sub-sites! So, use your head when architecting databases/site collections and don't smoke crack. I've even said you can have monster content databases in the past - I was wrong. The only way I would now architect large content databases would be for fairly static data that did not have a large collaborative user population. Joel blogged on blocking/locking a bit and so did Mike Watson. If you want to know more - get them to write more about it. They know tons more about the issue than I. Beware you won't get event or trace errors when blocking occurs because nothing is wrong. If you are getting errors, you may simply have an I/O overload on SQL or WFE Server.

#3 - How many Web applications do I need? This will be very different for every installation, but there are some general guidelines to follow. A good rule of thumb is that fewer are better. Keep it simple and create new Web applications only when necessary. In the beginning, most organizations will have at least the following:

Portal - A Web application is usually created for your intranet, regardless if it is actually called a portal. It is a centralized, governed Web application where content is aggregated. Unless you have specific requirements to do otherwise, this is also a good place for your collaborative site collections.

Shared Services Provider Administration Web Application - While it is not required that you have another Shared Services Web application to host Shared Services Administration, it is useful for the purposes of backup and restore and application isolation. This is not a Shared Services Provider! This is simply a Web application, with a site collection contained therein to manage your Shared Services Provider.

My Sites Web Application - It is also not required that you create a dedicated Web application to host My Sites. But doing so eases administration of My Sites in that you can leverage Web application permission levels, policies, and authentication for the hosting Web application. If you choose to host My Sites in another Web application, be sure to install the My Site Host template in the same Web application. This specialized site collection is used for default settings and for the crawler to index profile settings for people search functionality. I disagree with a couple of SharePoint folks I highly respect, in that they don't like a dedicated Web application. Here is why I think you should dedicate a My Site Web application:

·       You can easily leverage Web application policies to define security levels for all My Sites in a given Web application.

·       You can change the available permission levels to all My Sites from Central Administration.

·       You can more easily define content database design.

·       Backup and Restore is simplified because portal and team sites are not in the same Web application as My Sites.

·       You can create zones for the My Site Web application to allow modified access externally, via a different URL.

·       Your users can browse to the root (like http://my) and automatically be redirected to their respective My Site.

Central Administration - The best practice is to always have Central Administration in its own Web application. This is the default setting. You should not use Central Administration to host any other services.

Unfortunately, additional Web applications are often created due to politics within an organization. While a managed path is usually sufficient to meet a requirement, customers and executives sometimes drive designs that are needlessly complex. For example, you might have a Human Resources executive who demands a Web application named http://HR, when a sub-site or embedded managed path site collection in the corporate portal named http://portal/HR would work just as well. Another Web application usually means more resources, additional content databases, and additional IIS Server configuration. But even after explaining the benefits of not creating another Web application, you may still be forced to create the http://HR Web application. That's OK; just try to keep them to a minimum.

#4 - How do I enable intranet/extranet access to content? A major question from many is, "How can I securely access my content from either the intranet or Internet?" This is such an important topic that an entire chapter, Chapter 20 "Intranet, Extranet, and Internet Scenarios," was dedicated in the Best Practices book. But I'll at least cover the general concepts in this blog. First of all, you can extend an existing Web application, http://portal.contoso.msft, for example, to use another IIS Web application and additional URL http://portal-ext.contoso.msft. Using Web application policies and zones, you can restrict access based on the URL. While this isn't a bulletproof security model, it is useful for many organizations. There are other options as well, such as legacy virtual private network (VPN) access and, more recently, SSL VPN access. Even the most skeptical SharePoint security person (yes, I linked to Spencer Harbar - check out his blogs for SharePoint security info) would consider VPNs reasonable security. I like Layer7 VPNs like IAG and others. Very nice, no thick client, kerberos authN, etc.

#5 - What level of content type planning must I do? Content types are a very important part of SharePoint Server 2007. In fact, every Web page, document, task item, meeting request—virtually everything stored in the database—is a content type. You can use the default content types in the beginning and methodically expand your usage, but depending on your organization's policies, judicial use of content types from the beginning may be needed. An example of this would be requiring metadata collection as part of a content type. You may need to know if an item is confidential, secure, belongs to a division, or has a project identification code. You can always go back and tag items later with metadata values, but defining them in the beginning can make your content management easier down the road. My experience has been that you are better to use the defaults than to set them up incorrectly. One of the challenges of SharePoint document management is centralizing the control of metadata. Metadata is KING when architecting a SharePoint document management and/or Search and Findability solution. Note: I'll be presenting a pre-conference at Dev Connections on SharePoint Server Document Management Best Practices, November 10 if you are looking for an in-depth discussion. If you want to control metadata throughout your enterprise, I would consider a globally stapled default content type. This content type (or multiple if needed) can be automatically added to every library created. Here's a sample project you can download that does exactly this - Mark Ferraz's global content type stapler. I think this is way better than using custom list definitions. Basically, it is a user control that runs once when you create the library, adds the content type, then hides itself. Very slick.

#6 - Do I need an information architecture plan? The short answer is YES. Without some planning of the Web application, managed paths, and site collection structure, you could easily end up with a mess that cannot easily be fixed. Information architecture is a lengthy topic, and is covered in the Best Practices Book Chapter 7 "Developing an Information Architecture." For the sake of designing in the context of this blog, you simply need to gather input from the stakeholders on how your Web application, managed path, and top-level site structure will be. Try to help your stakeholders understand the importance of getting it right from the very beginning. A mistake with your information architecture in the beginning can make corrections later very difficult. Ok, it's almost impossible! DON'T OVERLOOK YOUR INFORMATION ARCHITECTURE! A simple google (or live.com J) query on SharePoint Information Architecture will yield a ton of results.

#7 - Do I need records management? If your stakeholders require records management for legal or regulatory compliance, then you should consider implementing a records center. Otherwise, you should attempt to manage your document life cycle in-place. Most organizations will be fine using information management (IM) policies via content types and lists. IM policies include auditing, labeling, expiration, programmatic workflows, time-based approvals, and barcodes. Creating a records center usually complicates your administration more than it resolves issues. If you do require a records center for compliance, plan for the additional Web application and Shared Services Provider needed for proper isolation. Why another SSP? Because you probably aren't supposed to have your official records indexed along with the rest of your content, and because you can only have one Index per SSP, you'll need another SSP for the sole purpose of hosting a Records Center index. This will allow you to place holds on large numbers of records via Search.

#8 - Do I need search? This should be an obvious Yes in this day and age, but many folks overcomplicate this in the beginning. You needn't have a robust search topology and plan before implementing SharePoint Server 2007. Search will benefit you greatly, but don't let the fear of planning search stymie your plans for SharePoint Server 2007. In the beginning, just use the native search functionality, and expand as your knowledge and requirements increase. One word of caution — because your users have been trained by Internet search engines to find what they need via search, you do need a reliable search center in the very beginning. You want your users to trust SharePoint Server 2007 search early, because otherwise it is very hard to gain back their trust. Trust me, if you are new to SharePoint Server just get search working with SharePoint content first.

#9 - Should I configure version pruning policies? You should decide what the official policy is on version pruning. If you leave it completely up to your users, they could turn on versioning with no limits. This action leaves you in the same state as SharePoint Portal Server 2003 and means there is no limit to the number of versions in document libraries. This is generally bad practice because it can dramatically increase your disk space usage. But before you freak out too much about versioning, your users are probably already versioning on the file shares. More often than not, we see important documents named 20 different things on the file share, each essentially a different version. You should decide how many major versions to maintain, how many major versions you will keep minor versions for, and what the security will be on each. (You can't limit the number of Minor versions - read the UI carefully - you can only limit how many major versions you will keep ALL minor versions for!) These decisions will vary greatly depending on your requirements, but at least one major version is recommended for content recovery due to user error and data corruption.

#10 - Will you allow users to modify sites with SharePoint Designer? With proper training, your users can modify sites with SharePoint Designer 2007 and produce very elegant, customized SharePoint Server 2007 sites. Without proper training, your users can break sites and pages, customize pages that should not be customized, and affect overall server performance. A best practice is to provide the SharePoint Designer tool only after users have received the proper training. Check out Heather Solomon's blog for SharePoint Designer tips and tricks.

#12 - What content will you crawl? From a technical perspective, you should define what content sources you will crawl. You should always crawl your local SharePoint Server 2007 content including My Sites. But you may need to crawl additional sites from the very beginning, such as file shares and Web servers. Be sure to apply search best practices when doing so and plan for crawler authentication. Also, be careful when crawling file shares because you may expose information that was previously secured through obscurity. You need to include your business team when creating new content sources. Help them understand that SharePoint Server search is security trimmed, and it works very well J For example, let's say an administrative assistant was trying share salary information with executives, but could not figure out the correct permissions. We all know what happens next, right? Of course! They could just say 'Everyone, Full Control'! So then the crawler indexes that information, and 'knows' that everyone has access to that search result. Common users could now see all of the salary information. The best practice here is to run an ACL audit before crawling any content outside of SharePoint.

#13 - How many Shared Services Providers will you have? You should plan for the number of Shared Services Providers you will have. Most installations should have only one. You can safely assume the best practice is s single Shared Services Provider. If you are not sure know why to create more than one—don't. If you still want to create more than one, read the SSP section on TechNet, or the SSP chapter in the Best Practices book.

#14 - Who will create new site collections? This is really part of your governance strategy, but suffice it to say that SharePoint Server 2007 was designed to allow users to manage their own destiny in regard to workspaces. Your goal should be to train users and allow them to create their own site collections. If you choose to do otherwise, you should seriously consider training a set of site collection administrators to perform the creation and management. Otherwise, the IT department will end up with more work than they can do, and delay site collection creation for users. I'm not saying all users should have the ability to create Site Collections, but I would train folks outside of your SharePoint administration staff to do this. Trust me, you'll be glad you did.

#15 - Will you enable incoming e-mail for lists? Incoming email is a very cool feature that allows you to define an email address for a list, thus enabling inbound email to that list, i.e. Account.Doc.Libary@contoso.msft. But, enabling incoming e-mail for lists and libraries isn't as simple as selecting the option in Central Administration and the target list. You must install an SMTP server, configure DNS, and allow the proper security in your network and e-mail server. Additionally, users get to create these Contacts (that's all they are) in Active Directory automatically if you enabled the Directory Management Services, and name them anything they want. So do yourself a favor, and create a dedicated OU for these contacts. But if you don't enable the directory management service, you will have to manually create each entry for every mail-enabled list. You should work with the respective teams and explain the functionality and requirements of incoming e-mail. Incoming email is a very cool feature for sending meeting requests to calendars, discussion lists, workflows, and more. But before you implement in your production server farm, be sure to test it first! It would be sub-optimal if a document library or list started receiving spam J There are several security settings in Central Administration to limit the email source. Additionally, I would limit the server that could send mail via Windows Server and your email server. One last thing, custom lists can't be mail-enabled by default. You'll have to get your softie to code it up for you.

#16 - Will you mail-enable SharePoint groups? Mail-enabling SharePoint Server 2007 groups allows SharePoint to create and synchronize Active Directory distribution lists with your SharePoint groups. Have you ever wanted to mail all contributors for a site collection, but you had to enter each person individually? Well, mail-enabling SP groups will create a DL and keep it sync'd has you add users to the SP group. Be forewarned that while there is an approval mechanism in Central Administration, users can name these DLs anything they want. So much like incoming email, you should have these created in a dedicated OU in Active Directory.

#17 - Do you have workflows that should be created organization-wide? If you have workflows that are needed in all or many sites, consider creating the workflows in Visual Studio and deploying them as features. A best practice is to create workflows as needed, and only deploy globally after verifying their need and functionality in a prototyped site.

#18 - Who will manage your code access security? Code access security (CAS) is widely regarded as a developer responsibility and not an administrator responsibility. But the best practice has been proven to be the opposite. Developers (of course, none of the SharePoint MVPs before you start to flame me ;-) ) often create code in a "full control" environment to ease application development. But writing code with no security boundaries can be a vulnerability when deployed. You need to decide who will manage code access security and how it will be audited. I say it's the Operations staff that manages CAS. Check out Brett Lonsdale's CAS blog here.

#19 - What logging and auditing policies do you need? As outlined in the Microsoft Share-Point Products and Technologies Administrator's Pocket Consultant, defining and setting logging and auditing policies is an important exercise when implementing SharePoint Server 2007. If you don't set your policies, the defaults are rarely enough to help when a problem arises, yet impact server performance. Don't simply set your logging levels to Verbose; you should make informed decisions about logging and auditing settings. Many SharePoint Server 2007 administrators set logging levels only to report errors, and increase the level of auditing when troubleshooting an error. This has proven to be a good starting point. If you want an easy to use script to set your logging, check out my free logging excel sheet generator on Mindsharp's premium content area. It's free, you just have to register. This script will include the 60something hidden logging values as well (like all the cool Search tracing and event logging counters).

#20 - How will you monitor your solution? You should decide what to monitor, and to what level you will monitor services in your SharePoint Server 2007 server farm. Too much system monitoring, and you could miss important facts because of too much information. Too little monitoring or the using wrong performance counters will have the same

result. At the 2009 Best Practices SharePoint Conference, we'll have presentations from Mike Watson on capacity planning and monitoring. It won't get any better than that!

#21 - How will you backup and restore your content? The best time to plan for content recovery is before you implement SharePoint Server 2007. Much of your content recovery plan depends on how your SharePoint Server 2007 server farm is implemented. A common bad practice is trying to force stringent recovery objectives from system that was poorly installed. Doing so is a lot like trying to get a Yugo to perform like a Ferrari! If you installed via the default options, use native backup tools, and ignore SQL Server transaction logs, you are most likely assuming a 24-hour data loss in the event of SQL Server failure. If you aren't moving your backup media off-site, then you are assuming a total loss of data. Can your company sustain a total loss of data? 24 hours? These are some of the questions you need to answer before implementing SharePoint Server 2007, or at least before moving business-critical content into SharePoint Server 2007. First, you must define where the valuable content resides, or will reside. If SharePoint Server 2007 is simply a front-end dashboard for back-end business data, then you will be more concerned with getting SharePoint Server 2007 back online in a failure, and less concerned with the loss of SharePoint Server 2007 content. In this example, your primary recovery target would be the back-end business data. Likewise, you must design for accessing your content. If you require immediate access to your data, then solid backups to tape may not be sufficient. Instead, you may need to plan for disk-to-disk backups, or create a mirrored instance of your farm altogether. Unless you have a very simple installation, your data protection and recovery plan will require some preparation. Often, it isn't a planning process that you can do alone. It will require discussions with the data owners and stakeholders to understand the criticality of the data, and what the expected availability is. The two key concepts to keep in mind are:

Recovery Time Objective The recovery time objective (RTO) defines how long your system can be down before it is back online after a disruption. The disruption could be due to anything from a SQL Server outage to a WFE Server failure. You don't have to have the same RTO all of the time. For example, a bank might have a very short RTO from Monday through Friday, 9 A.M. until 5 P.M., but a longer RTO for all other times. The RTO should include data recovery at the server, farm, database, site, list, and item levels.

Recovery Point Objective The recovery point objective (RPO) defines your data loss threshold, measured in time. If you run daily backups only and ignore the SQL Server transaction logs, then your RPO is 23 hours, 59 minutes, and 59 seconds. Any data written to SharePoint Server 2007 after you ran the backup cannot be restored via native tools until after the next backup. Many organizations assume this risk without fully understanding the impact of losing 24 hours worth of data. Check out this blog for managing multiple SLAs within a single Web application.

There are many 3rd party backup products, like Quest, AvePoint, and Commvault, but carefully research and test these (they all work, but they each have their advantages - there's more too, I'm trying to leave anyone out intentionally). No matter what solution you choose (native SQL backups for content databases is also a good bet), you should test, test, and then test some more. I've never seen a disaster recovery plan work the first time. Don't let the first time be when you really need it! 'Pretend' to experience a disaster (not during production hours, of course!) and see if you can restore everything. Some of the trickier components to restore are the Shared Services, especially Search.

#22 - Should we migrate My Documents to My Sites? Many of you want to replace My Documents with SharePoint Server 2007 personal portals, also called My Sites. This isn't altogether a bad idea, but you need to carefully plan what content will be migrated. Remember that SharePoint Server 2007 has limitations on file upload size and file types, and drastically changing these can have negative repercussions. But My Sites are often a good starting place for an enterprise SharePoint Server 2007 deployment because of the immediate value stakeholders can see in work efficiency and collaboration. Large organizations have seen the value in Exchange Server installations, and My Sites are a natural extension to that in the minds of many executives. If your users currently store music, video, ISO, and other large file types, you should consider some type of file storage other than My Sites.

#23 - What should my farm topology be? Many administrators are concerned with the farm topology in the very beginning of their design. The truth is, your farm topology is almost always the last design consideration. You should start with the end-user's experience with the product (it is, after all, an end-user product) and design toward the farm topology. You should first decide your information architecture, Web application design, search requirements, security, governance stance, and user requirements. If you must buy hardware immediately, plan for a medium server farm topology. A medium farm topology consists of two WFE servers, one application server, and one SQL Server. Alternatively, you can continue developing on your prototype system and scale outwards as needed. Either way, your farm topology is changed with relative ease later. If you are really concerned with how you'll build your farm, start with a medium farm and edit these scripts J

#24 - Will I create custom Site Definitions? I think probably no for most. Eric Shupps says it well here. But instead of re-hashing what a bunch of SharePoint MVPs have already written and argued in pubic, check out this blog. It about says it all.

#25 - What are your security controls? Early in your design, you should decide what security authentication and authorization you will use. You essentially have two choices for authentication—Windows Authentication and Forms Based Authentication (FBA)—although other pluggable choices exist. Windows Authentication has the deepest functionality in SharePoint Server 2007, but support for FBA is rapidly gaining. If you can use Windows Authentication with SharePoint Server 2007, it is easier to install and easier to maintain. There are two types of Windows Authentication—NTLM and Kerberos. One isn't necessarily better than the other from a design perspective, but Kerberos is generally a better choice from a performance point of view, while NTLM is easier to configure and install. There are instances, however, where FBA is preferable. An example is a partner extranet where you want to authenticate users against a Line-of-Business system. Carefully test your SharePoint Server 2007 functionality before production use, when using FBA.

Ben Curry, CISSP, SharePoint Server MVP

Mindsharp

http://www.mindsharpblogs.com/ben