SharePoint Configuration Management: Guidelines and Tips

SharePoint is one of those applications that grows (sprawls) at a rapid and almost uncontrollable pace, making it easy for administrators to lose control of the app. Changes are made, multiple administrators get their hands on SharePoint, and soon there's no single source of complete knowledge of the environment. Worse, changes are made without informing all administrators (stakeholders) of the changes. Typically no tools are in place for collecting data regarding configuration of the farm(s). As a result, no timely, accurate, and detailed reference documentation exists, and in many cases the ability to troubleshoot is impeded (i.e., you don't know what you have in your SharePoint environment). In a worst-case scenario, the environment cannot be rebuilt exactly to current specifications, which results in data loss or detrimental effects on performance.

The best remedy for reining in -- or better yet, preventing -- the unwanted effects of an out-of-control SharePoint environment is to devise and implement a configuration management plan that's suited to your SharePoint scenario. Here I will provide guidance that will help you determine the level of configuration management you need and some tips to help you put together a configuration management action plan and assess its effectiveness. Also see the accompanying sidebar, SharePoint Configuration Management Recommended Reading, for a list of additional resources on the topic of configuration management.

What Is Configuration Management?

Wikipedia defines configuration management as "a process for establishing and maintaining consistency of a product's performance and functional and physical attributes with its requirements, design and operational information throughout its life." More specifically, configuration management covers the following areas:

• identification of components (what do you have?)
• establishment of a standard (what is the baseline standard?)
• storage and maintenance (maintaining configuration data and tools)
• management (accounting for and tracking what you have)
• change management (control and quality)

Although an in-depth exploration of change management is beyond the scope of this article (we'll look at it briefly, though), I cannot overstate how important change management is in facilitating the success of configuration management. Specifically, change management is the gatekeeper of changes to the production configurations. To sum it up, configuration management is a discipline consisting of people, processes, policies, and tools that come together to manage your SharePoint environment effectively.

What Level of Configuration Management Do I Require?

In the process of creating a SharePoint configuration management plan, the first question you'll need to answer is this: How much process rigor and tools do you really require? To answer this question, first consider how many farms you have. How many administrators do you have? Have many users do you have? If you're a single small farm with a few hundred users and one administrator, you probably won't require extensive process rigor. If you have several farms (with a farm located on each major continent), multiple admins, and thousands of users, you will most likely require extensive process rigor and tools to successfully implement your configuration management plan.

A Configuration Management Action Plan

To implement and sustain configuration management, I advise you to follow the guidance that I'll provide in this section. You should also measure your success on an ongoing basis according to the outcomes of these actions.

Assemble a plan. In this step, you will determine how you'll tackle implementing and sustaining configuration management. (This step is more oriented toward large organizations with large SharePoint environments.) Assembling the plan will help you think through what resources your organization requires to implement and sustain configuration management. The plan should contain at minimum these basic elements:

• scope of work
• communication plan
• risk plan
• team contact list
• schedule
• budget

A SharePoint Team Site is well suited to support the plan by providing a calendar, contact list, document library, announcements, discussion area, and task list. If you're a large company, your project management office will assist you with this and will most likely assign a project manager. Also in large organizations, an executive sponsor is a key success factor to help allocate project funding and maneuver through departmental politics.

Identify components. This step is crucial to identifying what programs and files your SharePoint environment contains. As a first pass, you should limit this survey to your SharePoint environment -- especially in a large enterprise. But for smaller organizations where one or two people are responsible for the entire environment, you should also document your dependencies, such as your domain controllers and backup systems.

If you have a limited budget, the free SharePoint Documentation Generator tool does a pretty good job of documenting the basics of the farm. The tool is an executable that you run from the Web Front-end (WFE). To install the tool, refer to its documentation. Also, to obtain Windows-specific information, download Windows Sysinternals and run PSInfo on all your servers. If you have a SAN, I suggest that you document it as well, by using the manufacturer-provided tools.

If your organization has thousands of sites and you are dealing with a multinational environment, I recommend you invest in third-party documentation tools. These tools will enable you to not only document and report on sites but also to conduct bulk administration tasks (e.g., apply settings to sites) quickly and efficiently. Here are some third-party tools I've worked with:

• AvePoint: focuses on products for SharePoint and offers a full suite of management tools.
• Axceler: offers an administration tool called ControlPoint.
• Dell (formerly Quest Software): provides a suite of tools for managing Windows environments and also has SharePoint-specific tools.

If you have Microsoft System Center Operations Manager, it makes sense to download the SharePoint Management Pack. This will enable you to monitor and report on your SharePoint farm. Once you've installed the aforementioned tools, you will have documentation for your SharePoint farm, Windows servers, and SAN.

Establish a baseline standard. Now that you have documented your farm, you should establish a standard for its configuration. For smaller organizations that have only one farm, this step might not be as crucial as it is for large multi-farm and multi-national environments. Your document should describe a standard server configuration for your WFE, SQL Server, and application servers. This description would include, at minimum, equipment manufacturer(s), model(s), and options such as CPU, RAM, disk, and NIC.

 

 

 

Additionally, you should establish a standard for how the network and SAN are to be configured. For example, you should document the Virtual LAN (VLAN) that the WFEs plug into to service clients and document the VLAN used for farm traffic. I've run into situations where environments didn't isolate traffic, and then during spikes the farm died because of congestion on overloaded switches.

You'll also want to document the SAN, including the disk channels, RAID level, and number of drives. This documentation is essential for maintenance, capacity expansions, and troubleshooting. For example, I've run into situations where the SAN was saturated, which caused SQL Server disk I/O buffers to fill, in turn leading to disconnects from the farm. I/O issues usually occur as a result of improperly configured disk channels (e.g., not enough spindles or operational job overlap -- such as during an antivirus scan or backup).

For large organizations, I suggest you reach out to key stakeholders (e.g., architects, administrators, third-party software or service providers) to obtain their feedback in regard to standards. I suggest using Microsoft Word to document your standards, keeping the document under 25 pages. Where possible, reference external links to keep the document short and readable. Also, I suggest using automation to help build and rebuild your farm quickly and consistently. For large organizations, this automation is crucial because it will help IT to meet SLAs and restore service as quickly as possible. Small organizations might also benefit from automation for the same reasons.

I suggest you automate the following administrative tasks:

• Script the installation of SharePoint. You can do so using either Windows PowerShell or AutoSPInstaller.
• Script the installation of Windows -- for example, by using Microsoft System Center Configuration Manager (SCCM).
• Script the installation of SQL Server. You should use a command-line installation to do this.
• Package all customizations. All customizations should be packaged as SharePoint installer files (.wsp) to automate installation. (For more information, see "How to: Create a SharePoint Solution Package in Visual Studio.")

Store and maintain configuration data and tools. Here is where most organizations fall off the rails in implementing their SharePoint configuration management plan: They don't maintain the documentation, or they relied too heavily on manual documentation processes. You must run the tools used in the "identify components" step on a regular basis and make reports available to those who require the information as part of their job function.

Additionally, you should run updates as part of the change-control process. For example, when you expand disk capacity or add an application and site collection, you must update the documentation at the same time you make the change. For small organizations, this is a simple task: Run the documentation tools and update your Word document. For large organizations, change control is even more important and poses a greater challenge because of the scale and complexity of large enterprises. For large organizations, I suggest taking the following approach to maintaining and updating your SharePoint documentation:

• Establish a SharePoint Team Site to contain all the documentation for the farms.
• Identify all stakeholders involved with the documentation, such as architects, administrators, and third-party service providers. Invite them to the site and hold a meeting to advise them of its purpose.
• Use a discussion area and task list within the Team Site to open up communication among the stakeholders regarding feedback and suggestions. For example, the documentation might have gaps, or users have suggestions about server standards and how the standard was defined.
• Use a Help desk management tool (e.g., BMC Remedy Service Desk) to help automate change control and task assignment workflows and track completion of tasks.
• Establish quarterly meetings with stakeholders to review standards and documentation. This is an opportunity for the stakeholders to participate in the standards process. In the case of outsourced environments, there are generally constraints regarding standards such as the available server models (e.g., because of third-party data center racking availability -- servers and racks designed together). Stakeholders must be educated about the constraints so that their expectations are realistic.

Track your configuration. You should track the configuration by using previously mentioned tools (e.g., SCCM, ControlPoint) to ensure that the SharePoint farm information (i.e., assets) is accurate and up to date. Do not confuse this step, which is focused on asset tracking and reporting, with the "store and maintain" step, which is focused on maintaining information about the assets (e.g., documentation, automated reports). At minimum, your configuration-tracking report should provide serial number, model number, options, location, and value for each asset.

Implement change management. This is the SharePoint configuration management step that most organizations get wrong because they don't maintain their documentation (hard copy and online), so that it becomes less accurate and therefore less useful over time. The only way to prevent this problem is to implement a change management plan. Such a plan creates visibility around ownership of documentation, automating processes, triggering the processes automatically using change management tools, and tracking progress with workflow.

Here's a basic outline of a SharePoint documentation change management approach:

• Assign ownership of documentation to specific staff.
• Use a Help desk management tool (such as BMC Remedy Service Desk, mentioned earlier) to help automate change control and task assignment workflows and track completion of tasks.
• Set up workflows within the Help desk management tool that trigger when changes to the SharePoint farm are scheduled.
  • Workflows initiate documentation updates.
  • Contact owners.
  • Track completion of tasks.

Change management is a complex topic, and a comprehensive change management plan takes time to implement. Large organizations will most likely have a program in place, whereas smaller organizations can probably get by using a simplified process.

 

 

 

How Do You Know When You Get It Right?

There are a few indicators that can help you gauge the success of your SharePoint configuration management plan and determine where to focus should you miss the mark:

• A healthier service and less time fussing. With your configuration under control, you should spend less time trying to figure out what you have and what's wrong and worrying about rebuild/recovery. You should be confident about the state of your farm(s).
• Reference for day-to-day administration. You should be able to easily look up the configuration of SQL Server and SharePoint settings and/or job status. For example, did profile sync run properly? What are default settings for the services? Site collections? Lists and libraries?
• Assessing impact of change requests -- the ability to access risk. For example, is a user requesting something that might impact capacity and performance? Will a change recommended by a support engineer conflict on an existing setting required to fix a past problem?
• Planning for capacity and performance -- the ability to proactively project capacity changes before limits are reached. For example, do I have lists reaching their maximum limit that require cleanup or migration to another platform? Do I have content databases reaching capacity? Note the connection with the related disciplines of performance and capacity management.
• Building and rebuilding -- the ability to account for components and settings. For example, how easily and quickly can you rebuild a server in the farm (e.g., a WFE)? Or rebuild the farm from scratch? Note the linkage to fault management -- a related discipline.
• Troubleshooting -- the ability to view the configuration in detail to facilitate the troubleshooting/support process. For example, how is SQL Server configured? Why is it configured this way? Did something change from baseline that should not have changed?

Where the aforementioned indicators become of greater importance is in heavily outsourced environments where multiple parties are involved in day-to-day management and support. In this case, it's very easy for a support person in company A to make changes or conduct administrative or project work that could impact SharePoint. It could take days, if not weeks, to uncover such changes.

Configuration Management Is a Discipline

SharePoint configuration management is a discipline that requires commitment from an organization to get right. A successful configuration management plan requires tools, trained and qualified staff, clear lines of ownership, and process and policy controls that are continually enforced.

Where SharePoint configuration management typically goes wrong is because of inadequate change management. Specifically, tools are not used to document new installations and settings fully -- SharePoint, SQL Server, network OS, servers, network, and storage. Process rigor isn't mature (i.e., documented, well known, and repeatable consistently).

Think of it this way: Your farm has been in operation for two years. Do you have everything you need to rebuild it? If a new admin started, do you have information about all the settings? History of the changes made and why? Finally, remember that process improvement is ongoing. Be sure to test your configuration management plan by conducting tests that validate the accuracy of the documentation, your ability to rebuild farms, and how well you can troubleshoot and support change management. Regularly testing your SharePoint configuration management plan will help ensure that your organization reaps the plan's full benefits.