[PRT371] SharePoint Portal Server 2003: Best Practices for an Implementation
Or as the presenter called it: Ten key decision points to achieve and outstanding sharepoint deployment.
Presented by Richard (Rick) Taylor, a consultant from Mindsharp.
The session was presented as a kind of a do's and dont's mostly on a level of design desicions or project management without any look at code or coding techniques. I had kind of excepted more development related best practices such as: change templates this way, dont alter these files this way etc. There are sessions later in the week that will probably go into more detail about such things. This session however was not on that level.
The main problem with Sharepoint solutions from the experience of the speaker is that Portal/WSS concepts and differences are not clear. Portal is not for collaboration. WSS is for collaboration. Collaboration is for the sites, not for the portal.
It is important to understand that Sharepoint is NOT a document management system. Document workflow does not exist. If you bought it for that, take it back. Sharepoint is NOT a content management system. If that's what you want, get MCMS. Sharepoint IS however a document collaboration system.
Three reasons for getting Sharepoint Portal Server
1. Aggregate info.
2. Indexing and Search.
3. Personalization, My Site.
It's important to know (to stress) that the sites and workspaces are where collaboration happens. Not the portal.
Top five things you need to get user acceptance for a Sharepoint project
1.Champion (someone who speaks loudly and preferably enthusiastically on your behalf)
4.Clear project plan with milestones
5.Patience (noone likes change)
These points aren't unique to Sharepoint prcoducts though.
Roles to have on the SharePoint Planning (Project) Team
Project Manager, Project Sponsor (Who holds the funds), Stakeholder (with interest in Sharepoint like solutions), Architect (with detailed knowledge of Sharepoint), IT-staff, Developer, Testers, On-Site trainers, Help Desk Staff and Technical Writers.
1.Do not uninstall, doesn't work good, if you need to uninstall, nuke it (fdisk, format, install OS etc from the start).
2.Dont install WSS before Portal, it can get you into trouble, let Portal install WSS.
Libraries and Lists
Dont upload all documents into the portal, keep them in fileservers etc. Uploading them will make the SQL Server database unneccesary large. Leaving them on fileservers will give you some management problems though, check in/out/versioning. There are workarounds to get that to work though (which those are were not mentioned). An issue with versioning is that each version is a full document. A 1 mb document can quickly become alot of data if updated frequently.
Expose documents in lists. Dont put over 2000 items in one list though. 2000 will take 2 minutes to display. Surveys suggest that the average time that a person waits for a web application to complete before judging as slow is 6 seconds.
Dont build organization levels deep, go wide and shallow. Or you will hit the 255 URL limit. That is, have many same level organizational units. Do not thread your way into the organization in a overly granular way adding to the URL.
Be careful of what you index, it can use alot of bandwidth. Indexing is also very resource intensive. Medium to large farms require dual xeon and 4gb of ram and very large drives. Gigabit ethernet highly recommended.
Searching is probably the most problematic area in sharepoint. Hacing 50 content source probably requires a half time duty just to maintain it.
When Sharepoint is used for extranets and Active Directory is used for authentication, you will probably use two active directory forests. This will increase staffing for adminsitration. You will also need External Connector. You will also need to plan for the security of such a solution. Really think about the consequences before placing it on the extranet.
Shared Service requires even more staff. If you go to Shared Services you cant go back. It's also recommended that you have Gigabit ethernet between all servers in the farm. Many times this is not possible. You don't have to, but it you don't - you will suffer.
Only use Frontpage 2003 to edit the sharepoint site. Do NOT use Dreamverver or anything like it. You will eventuellt break it.
Do NOT develop in production. Because if you break anything, chances are you wont be able to fix it.
Sharepoint doesn't like to get broke, when it's broke, it's hard to fix it. It's more often then not time efficient to nuke it.
To deploy WSS Sites is to give control to the user. On an administration level it might be difficult to control when you have x-thousands of sites.
The concept of Audiences in Sharepoint are not for security purposes, they are for personalization. Audiences are not a way to secure information, it only stops you from navigating to them, it does not stop you from directly accessing the information.
Each Personal Portal is a site collection. Using personal portals require education. Setup policies before letting on users. Require education before using users are allowed to use the portal.
Do not underestimate the need for powerful machines for developers and it's associated cost. Developers need W2K3+IIS+WSS+SPS+SQL+VS.NET which requires a pretty powerful machine to run smoothly, especially if you run it in a VPC. 1GB of ram, or more, is highly recommended.
IT-pros handling sharepoint need to understand Code Access Security. It's very important when handling WebParts.
Test and Stage environments
Testing and staging can be made in a Virtual Server environment using the correct configurations of production. This demands a powerful machine, but still, you can get away with only one. Even load balancing and clustering works in Virtual Server.