I've been a little quiet on the blogging front of late, due to a birth - the birth of the WEA (World Education Alliance) - http://worldeducationalliance.com. Further details below as originally published by Bill English of Mindsharp.
The World Education Alliance is a global education alliance, incorporating Mindsharp (USA), Combined Knowledge Ltd, (UK and EMEA) and Combined Knowledge Asia Pacific, (Australia and New Zealand). Each of the companies within the WEA specializes in the development and delivery of Information Technology Training classes. The Exclusive portfolio of courses that are available from the World Education Alliance enables organizations to have Global Training Solutions that meet the needs of any role involved in an environment from Administrators, Developers, Designers and End Users to Executives.
The courses are written and delivered by Expert Information Technology trainers and consultants who have the knowledge and skills required to deliver quality training courses either on a public scheduled basis or as private courses to various organizations. Our Trainers and Consultants boast industry leading accreditations and references including the prestigious Microsoft MVP Accreditation.
The World Education Alliance, enables you to organize your Information Technology Training requirements for Administrators, Developers, Designers and End Users over multiple locations in one easy step, you can maintain the same local contact that will help you to plan and organize your training program across multiple office locations. This process enables you to maintain the quality of IT training that you require across all regions ensuring that all people involved in an implementation are receiving the same training wherever they are based.
Benefits of using the WEA
The WEA provides clients with a 'One Stop Shop' for their IT Training Requirements. Through the WEA, a world-wide company can train everyone in their organization on SharePoint and Unified Communications and experience the following benefits:
- One-Stop-Shop for all of their SharePoint education needs
- Seamless booking for trainers, travel and materials for world-wide engagements
- Consistent courseware and customer experience
- Assurance that the instructors are well-trained and fully prepared to teach their classes
- Consistent pricing and invoicing processes
- Unique, but flexible bundling of solutions for customers, including trainer selection, course selection and delivery mechanisms
Benefits of working with Combined Knowledge, Mindsharp and the World Education Alliance
For those who train and work with us, there are several benefits of associating with Combined Knowledge and Mindsharp:
- Work with recognized, respected industry leaders
- Live anywhere in the world and train with us
- World-wide training opportunities
- Participate in internal education on new technologies
- Technical support for trainers for both the technology and the course
- Mentoring for professional development, including writing and training
Education Courses
The breadth of the education options within the WEA is substantial. Consider the following number of training classes, sorted by audiences for SharePoint Products and Technologies:
Core Technologies in SharePoint Server 2007
Configure and Administer Windows SharePoint Services 3.0
Upgrade SharePoint Portal Server 2003 to SharePoint Server 2007
Customize SharePoint sites without writing code using SharePoint Designer 2007
Implement Business Intelligence Solutions using Excel Services
Implement, Customize and Manage SharePoint Server 2007 and Search Server 2008
Developer's guide to Windows SharePoint Services 3.0
Create Branded Solutions using SharePoint's Web Content Management
Customize SharePoint sites without writing code using SharePoint Designer 2007
SharePoint InfoPath 2007 for Developers
Office SharePoint 2007 Power End User
Site Collection Administrator for the Power End User
Site Owner
Site Member
Key Topics for SharePoint End Users Online
- Executives, Architects and IT Managers
SharePoint Server 2007 Governance and Taxonomy Workshops
SharePoint Server 2007 Design and Architecture Workshops
1 day Management overview
- For Unified Communications, we offer the following course:
Core Technologies in Microsoft Office Communications Server 2007
Delivery Methods
Both Mindsharp and Combined Knowledge offer our courses via a number of different delivery methods. These methods can be combined within a larger bundled solution to meet your exact needs. Utilizing over 50 authorized trainers world-wide, the World Education Alliance allows you to have our training delivered using the following methods:
- Instructor-Led
- CBT
- Train-the-Trainer (end-user courseware only)
- Remote Training to your desktop (Live Meeting plus Audio)
- Public classes
- Private classes
- Customized classes and workshops
Delivery Locations
The World Education Alliance can deliver education in most areas of the world. We have offices in London, Sydney and Minneapolis. We can offer training in the following locations and can bring education to your company privately anywhere in the world:
- Nearly any city in the United States
- Ottawa and Montreal, Canada
- UK Midlands – Public Classes
- UK London – Public classes
- UK Wide – Private classes
- Cologne, Germany – Public classes
- Amsterdam, Holland – Public classes
- Luxemburg –Public classes
- EMEA wide for private classes
- Sydney – Public classes
- Melbourne – Public classes
- Brisbane – Public classes
- Auckland NZ – Public classes
- Wellington NZ – Public classes
- Asia Pacific wide for private classes
Facts about WEA Trainers
There are over 50 authorized trainers in the World Education Alliance. Of these, twelve are MVPs and two are former MVPs. We also offer training in English, French, German, Spanish, Dutch and Finnish. Between 2007 and 2008, our corp of trainers more than doubled.
Please let us know how we can help you today. You'll find that this alliance between Combined Knowledge and Mindsharp will bring you benefits and advantages for SharePoint and Unified Communications education that few others can offer.
If you need education world-wide or in your own town, village or city, we can assist you today. If you live in North America, South America or Africa, please contact David Hoffeld at dhoffeld@mindsharp.com. If you live in the UK, Europe and the Middle East please contact Zoe Watson at zoe@combined-knowledge.com. For Asia Pacific and Australia please contact kerriann@combined-knowledge.com.au We pledge to you that we'll do everything we can to ensure you're delighted with our education services.
Bill English, MVP
First of all, thanks to all of the attendees, speakers, sponsors, and exhibitors for their support of the SharePoint community, and the 2008 Best Practices SharePoint Conference. It's hard to believe, but we're already planning the 2009 Best Practices SharePoint Conference! We have moved the conference to the beginning of the year, February 2-4. We decided to host it earlier in the year as we had many requests from those of you on the West coast who couldn't make it to Washington D.C., and from many who were on the waiting list that didn't get in. This time, we are hosting it at the Torrey Pines Hilton in La Jolla, California. For those of you who are golf fans, that's where Tiger Woods holds his annual tournament. We had a lot of positive feedback from the first conference and really appreciate the honest feedback regarding session content. Most importantly, you told us what you would like to see at the next one and how to improve the technical content (more Real World Best Practices and we heard you loud and clear!). It is absolutely true that we rarely get to implement the technically correct best practice. Usually, it's a compromise of politics, finances, functionality, and technical skills. So while some of the sessions will be similar to the last conference, most of the sessions will be brand new, and none of the sessions will be exact repeats. We find the best practice for conferences is to always have new, updated content :-) You can see more about the location and conference at http://www.sharepointbestpractices.com.
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
Come see us at the 2009 Best Practices SharePoint Conference in La Jolla, CA Feb 2-4!
http://www.sharepointbestpractices.com