Introduction to SharePoint Administration
- by Joel Oleson
Welcome to the SharePoint Administration community area. This site was designed to be a resource for pointing you to the most critical resources. You don't have to talk to many administrators to know that many of the best resources are found in blogs. The design of this site is really to help you find the information you're looking for without having to scour the Web yourself.
If you're new to SharePoint Administration, you'll quickly realize that the built-in help resources are not for administrators. Those help resources are intended for end users, were designed in the early betas, and haven't really been updated. Many of the resources for SharePoint administrators are on TechNet, but the community has really continued to share prescriptive guidance. One thing we hope you'll find is the sincere efforts of Bamboo to help you better manage and administer your SharePoint farms.
SharePoint administration can quickly be broken down into the following categories: Support, Operations, Engineering (including planning and optimizing physical architecture), and Architects (Solutions and Information Architecture).
The Tier 1 Support Team
Many companies overlook this critical role. This team often makes the difference between success or failure. Support ends up being the face of your SharePoint service. Are users being educated, receiving answers, or being turned away mad? Are there service level agreements in place, and a means of communication when support is aware of an issue? Often this team understands the health of the service better than those that are hands-on with the servers, because they have the pulse.
At Bamboo, one of the first products designed was the Knowledge Base Solution Accelerator. The Knowledge Base was designed around the idea that common questions and answers should be captured and shared. The concept of the knowledge base allows the support desk to scale. Scale and service health should be the focus of this team. Establishing metrics to measure the health to achieve scale should be ultimate goal. Service owners need to make sure the support team's voice is heard. These metrics need to be tracked and they need to matter. Here are some examples: (ticket = support incident/support call)
- Average Time To Resolution
- # of Tickets open
- # of Tickets closed
- % of Tickets closed within SLA (72 hrs service level agreement for example)
- # of Tickets opened beyond SLA
- % of Tickets closed - User Response Dissatisfied
- % of Tickets closed - Satisfied
- % of Tickets closed - Highly Satisfied
- Tickets flagged to be reviewed/escalated
As it relates to SharePoint, this team commonly:
- Takes all requests
- Creates and manages the FAQ/end user knowledge base
- Maintains and supports end user training materials
- Is aware and often involved in any planned downtime activities
- Meets with the Tier 2 team to ask questions and share knowledge
- Facilitates site creation
- Resolves site lockout
- Access and permissions related troubleshooting
- Extranet User management/Small companies User management (See User Management Suite)
- Password resets (#1 support desk call; check out the Bamboo Password Reset Web Part)
They may as well increase the Quotas, and change ownership where necessary. They can be given read access across the environment through Web application policies or even special rights through the Web application policies. I'd recommend slowly rolling out any rights, starting out with read, and working with leads that you trust with read/write access only to the Web UI. I'd recommend no access to central administration for Tier 1 in most medium to large environments. Their goal would be to focus on user issues, not changing settings in the Web applications, antivirus, blocked file types, etc... These should be left to the Server Administrators, AKA the ops team. The help desk should understand the site settings interface and list settings really well. These areas are where users can get stuck and will need help. Having access to these interfaces as support becomes more experienced will quickly result in faster resolution to support calls.
The Operations Team (Tier 2)
This team really needs to understand the common administration tasks of:
- Maintenance: hotfixes, service packs
- Backup/restore - they will often have to work with another team to manage the TAPES or other devices
- Disaster recovery solutions - may be another farm or virtual solution
- Optional - Cluster and Load Balancing Support
- Security and Authorization (DC support/Firewalls)
- SQL Support and Maintenance (This may be outsourced to SQL team)
o DBCC - Database Consistency Checks
o Database Backups
o Database Index Maintenance
o Whitespace and Growth management
- Disk Management
- Virtualization Support (may be outsourced to another team)
- Dev environment support
- Test environment support
- Staging or Pre-Production
- Deployment of solutions and features (hint: require .WSP)
In the three-tiered administration UI, there are site settings for managing sites and site collections, the Shared Services Provider (SSP) for managing the common services similar to the concepts of SOA. Search, Profiles, Business Data Catalog, My Site Host, and Excel Services all have service configuration settings. Only in the largest enterprises do I see dedicated people setup to manage things like search and keywords. Profiles and their settings can often be setup once. Same with most of the services. Search is really the one that has maintenance tasks associated with it. It requires some care and feeding to ensure optimized relevancy. It's not exactly true that it can be setup once and walked away from. New content sources and troubleshooting will require someone to handle these requests unless the strategy is to let it just run.
The third tier is the Central Administration. This is where the Operations team spends their time. Bamboo has built a few tools such as System Log Manager which can help address the arduous task of handling troubleshooting across a ton of repositories. I wrote a blog about the difficulty associated with the largest number of logs and places to look than any other Microsoft app (with the exception of anything built on SharePoint).
These guys keep the trains running and are involved in the monitoring and performance of the farms.
Dev and Test Teams
While these teams may be part of IT or in a business unit, they should be considered a part of the process and involved in many of the change control boards at a minimum on the initiation side, but also to defend their requests and to understand what changes are being introduced into the environment.
This team would benefit by being a part of online SharePoint communities such as this one. They can both contribute and learn from the activities in the forums and share best practices and lessons learned.
The Engineering Team (Tier 3)
The engineering team is responsible for:
- Planning for high availability
- Upgrade validation and steps
- Storage management
- Performance management over time
- Risk management
- Overviewing some of the change management
- ITIL and MOF implementation with the PMO (Project Management Office) team
- Database management plans and optimization techniques
- Operations best practices
- Cluster solutions
- Virtualization and imaging solutions and testing (may be outsourced)
- Reviewing usage reports and making recommendations for scale up / scale out
- Firewall and security management reviews
- Optimization plans and techniques
- Meeting with the dev teams to ensure best practices
- Investigating list scale, database scale, and site and site collection scale issues, and providing guidance and best practices
This team is about helping the ops team become more proactive. They should make sure that the ops team is not randomized by performance issues by designing systems that are optimized and scalable.
This team should be pulled in when the ops team is getting behind or is unable to resolve a persistent issue. They should be more project based than incident based and knowledge sharing and expertise is important in both teams.
In some enterprises, this team will be responsible not just for SharePoint, but Exchange, SQL, AD, and/or other Line of Business solutions. In deployments where SharePoint is a line of business solution, the upper tiers are often sacrificed or it becomes all in one. In centralized deployments, where companies are more likely to achieve economies of scale, it is more common to build this type of expertise.
This team should be involved in the SharePoint community and subscribed to the top blogs to stay on top of recommendations such as when to upgrade to the next service pack or whether or not a hotfix should be deployed. They should also be aware of solutions which can help the ops team become more efficient. They should also work with the Business stakeholders to make them aware of the direction of the platform and share technical requirements and provide feedback on business requirements as they relate to the platform.
Architects - Information Architects (Futures and Development Best Practices)
While the developers themselves don't get too involved in architecture, an often missed role in SharePoint deployments is around the information architecture. The Ops team doesn't care too much as long as it doesn't impact their databases or their backup SLAs. The engineers start to care, but they aren't interested in discussing the taxonomy.
The business doesn't care whether it's a site or a site collection. So who does care? Someone needs to. SharePoint scales when the site vs. site collection question comes front and center. Lists scale when planned, tested, and are managed. Where some of these things are ignored in the beginning, a couple of years down the road these same objects that worked just fine, now are slow. The slow later turns to unresponsive and "hangy."
The physical architecture should be managed by the engineering team, but the information architecture itself needs to be planned through the help of external consultants, or truly experienced SharePoint Architects who understand the scale of SharePoint and can map business requirements to SharePoint solutions. Many of the answers to these planning questions are in blogs or are simply learned through experience.
There are resources available, and should be understood in planning information architectures.
List and Database Scale and performance resources:
The Architect, whether a consultant or an experienced lead engineer, needs to help institute best practices on solutions coming from the dev team. They also need to understand the business and be able to recommend off the shelf solutions vs. build, especially when it comes to building solutions which are large in scope.
- Joel Oleson AKA SharePoint Joel
Editor's note: In addition to the content available in the "SharePoint Joel's Picks" feature, we've also collected Joel's guest blogs on the topic of SharePoint administration here for your convenience: