My organization suffers from the single resource as the SharePoint administrator. Take a deep breath, look in the mirror, and repeat after me: "This is a problem that I have helped create." Wipe the shock and denial away and say it again. Yes, SharePoint, while not perfect, has given at least a few levels of control that allow us all to relieve some of this overhead burden. Figuring out who should be farm administrators, site collection administrators, SSP administration and site administrators is a good place to start. If you lay out the process and have taken the time to create a framework that is well-designed you can let go of the reins and regain some of your life.

Sites are randomly created and lead to a number of layouts, design and content that seems to have no owner. This is where the planning process comes into play. An organization can use content management, business process, or even a change control process to manage who and when sites, site collections, and content types are created. Use what is built into SharePoint to maintain both a primary and secondary contact for each site. Defining your design often leads to a natural progression and direction about who would be a natural owner for each of these areas. The goal is that the SharePoint administrator or SharePoint architect can then be relied on as advisors and not the owners of this content.

For most organizations, SharePoint administration starts out the same way as SharePoint. A pilot or point solution grows when fed content and attention. The type of growth and level of focus on your job is related to whether SharePoint has grown in the light and been fed and pruned or left to its own devices and taken on a life of its own. The part-time assignment to the full-time job can be addressed by an appropriate level of reporting and pushback for requests. Take time to learn what information SharePoint can report about usage and growth. Beg, borrow, and buy as necessary the tools to extend this reporting, filling in where necessary the time spent on user and system issues. And, if all else fails, find an advocate who understands the importance of the SharePoint administrator and the burden administrators face.

I am trying to control growth by enabling quotas. This is exactly what quotas should be used for. However, we constantly see that SharePoint quotas are being increased as the exception becomes the rule and eventually they are just turned off. This again all comes back to the planning and deployment of SharePoint. Think about how to break up the various groups, especially those who would be heavy users from the beginning and define as necessary site collections, applying a different level of quotas. As new projects, phases, or content migrations are brought online, refine your specifications and quotas to support these options.

My Sites is one of my favorite features in SharePoint. What better way to get users excited then to give them a level of interaction that they don't normally get from any other application they use. This feature should also come with a "buyer beware" warning that both growth and support are going to increase at an exponential level. Take time and think through the backup, restore, quota, growth, and file type limitations. The most successful implementations I see are when My Sites is phased in later rather than sooner. This allows for lessons and support boundaries to be defined.

Backup and recovery seem to go hand in hand. Do you know what level of backup you are creating? Are you able to define what the pros and cons are for each option that is being used? When is it appropriate to use Central Admin, STSADM, or SQL for backups? To what level are you recovering for end users? When using the recycle bin what can and cannot be recovered in the timeframe? Overall these topics seem to create more questions than answers. Take time to learn all of the options and a natural selection will follow. The key is to understand and to ensure that you can recover in case of a disaster and when one of those "Resume Generating Events" occurs.

How many times have we been called in to solve a problem with SharePoint only to discover that all of the accounts from search to farm administration are running on the same user account? And maybe that is also the account the SharePoint administrator uses to log into e-mail? The key here is to understand which services, components, and features require an account. Rule number one in any application deployment and management is that the "Service Account" should not be used by an end user. There are several points-of-view on this issue from a different account for everything to a few accounts for most and then reuse for each feature that is brought on. The balance is that one is too few and 50 are too many. The other thought is name those accounts something that correlates to what they are used for.

Consider that SharePoint is growing by leaps and bounds and the skill set for being a SharePoint administrator crosses from AD to SQL. While the load of the SharePoint administrator is heavy, the keys to offloading are in these same hands. We will still keep looking for the right cloning formula, but until then take the time to rein in your SharePoint environment.