| Perhaps one of the most procrastinated tasks in the world of information technology is the creation and maintenance of the "Standard Installation and Operating Procedures," or the SIOP (or SOP, depending). Given the potential complexity of a Microsoft SharePoint Portal Server deployment, as well as the visibility such a solution garners, development of the SIOP is crucial to long- term success. The SIOP Detailed current-state documentation must be maintained and updated to ensure that a re-buildable and manageable solution is maintained . To this end, a master Standard Installation and Operating Procedures manual is mandatory, detailing the overall architecture of the solution, each component of the solution, current related configuration parameters, installation steps for each component, and "how-to's" regarding the specific configuration of each component. Keeping the SIOP Up to Date As the Microsoft SharePoint Portal Server environment evolves, the SIOP must be updated to reflect changes in the operating environment. For example, if a particular configuration change is required down the road, and is not documented, what will happen if a portion of the system landscape succumbs to fire or a natural disaster, or even something as simple as a corrupted disk? Without appropriate and current documentation, precious hours will be lost recovering the system. The next section discusses best practices in regard to maintaining system-specific documentation via the SIOP. Documentation Best Practices Every IT organization tends to have at least some rudimentary rules of thumb or best practices surrounding documentation. Many IT organizations simply take screenshots of all product installations or configurations. Others copy and paste read-me files and similar such documents into a book of procedures. Still others simply collect all printed material that came with a piece of gear or a package of software, and place it in a common folder. The following consists of generally agreed-upon best practices: -
Document why any change is ever made to the system landscape ” This is critical should the change ever be called into question. It is important to include who authorized the change as well as the problem or issue that was resolved by the change. Note this information on the page being updated, whether the page is a physical piece of paper or a soft/electronic-copy. -
Document the change ” Using the existing page (whether printed, Microsoft Word, or Web-based) of the SIOP related to the change, make both an electronic and paper copy of the existing page, and then update the page electronically and print a copy of it in preparation for the next step. -
Test the change using only the documentation as your guide ” Using a printed copy of the now-updated page in the SIOP, follow your procedure to ensure that it is accurate. Make changes as necessary, and fine-tune the processes for complete accuracy and understanding. Screenshots of the appropriate interface allow even the most difficult of configuration steps to be documented easily and clearly. -
File the pages(s) to be replaced in the SIOP in a safe place ” Never be tempted to throw away any printed pages of the SIOP for at least two years ! These can become critical documents should a change cause (or be thought to be the cause of) future issues ”at 2:00 a.m. after a catastrophic failure, it is always preferable to be able to turn to step-by-step documentation (even "old" versions of documentation), rather than an incorrectly updated procedure. At those times of what usually amounts to unplanned downtime, it is a wonderful thing to remove as much error-prone "2:00 a.m. clouded thinking" as possible. In addition, by retaining the old pages, historical changes can be tracked ”should a change ever be questioned, or should a change need to be rolled back, written documentation exists to do so in a cookie- cutter manner, thus removing any doubt that the change was indeed implemented correctly. So remember, test each change to each installation, upgrade, or how-to procedure in the SIOP, save everything, and enjoy the fruits of your clear and updated documentation! Integrating the System Landscape A SharePoint Portal Server solution does not exist in a vacuum . Rather, it operates typically as a cog in the much larger machine called Information Technology. Integrating the portal landscape into the overall IT landscape is performed at a number of levels, then, such as -
Inclusion into the systems management approach (products and practices) employed by the organization -
Domain model/Active Directory integration -
Systemwide security model -
Systemwide backup/restore model Administration Tasks Addressing product-specific tasks ”those related specifically to SharePoint Portal Server (and not systemwide operations tasks, which are covered next) ”includes the following: -
Index management, such as propagating indexes to other servers from index workspaces, or performing full, incremental, or adaptive updates -
Modifying the noise word file to exclude words like "the", "a", and "an", so as to make searches more valuable -
Modifying the thesaurus, such that searching for a particular word yields hits on words with similar meanings -
Configuring the server to crawl -
Installing Web Parts, and installing/registering iFilters when using proprietary file extensions Production Operations Tasks A number of administrative tasks fall under the category of "Production Operations," and therefore are not specific to SharePoint Portal Server as a product. That is, all enterprise applications require that a number of systems-related tasks be addressed, including Systems Managemen t All servers and resources within the SharePoint Portal Server landscape must be "added" to the toolset or utility responsible for managing the servers. Such utilities might include HP Openview, Microsoft SMS, Compaq Insight Manager, CA Unicenter, and so on. Systems Maintenanc e All servers must be monitored from a performance perspective, leveraging the systems management tools as well as utilities like Performance Monitor, or PerfMon. PerfMon may also be used for basic capacity planning and frontline problem troubleshooting. Backup/Restor e All servers must be backed up regularly, and these backups need to be tested to ensure that a restore is actually possible. Note that the amount of traffic on your network resulting from the backup and restore process may be reduced substantially by backing up to and restoring from compressed drives . Managing by Exceptio n The Operations team should be taught how to manage events that occur across the system landscape. For example, issues with Production should be addressed in one manner, while issues with a Technical Sandbox should be addressed in a different manner. As the portal solution matures, fewer and fewer issues should require the attention of Operations ”rather, as issues and conditions are identified and sorted out over time, automatic methods of dealing with them should be implemented. In the end, only severe issues should have the attention of the Operations staff. Escalating Issue s Once issues have been raised to the attention of the Operations staff, appropriate escalation procedures must be leveraged in all cases. Even cases where the issue is "known" merit escalation ”it is not appropriate to see a "severe" error message, for example, and do nothing. Additionally, escalation processes normally reflect time-of-day or other similar time-critical properties, where escalation actions might differ for a particular issue if it occurs at 3 a.m. Saturday morning or 2 p.m. Thursday afternoon during month-end closing week. Continuous Improvement/Feedbac k The Operations team should continuously feed a knowledge base of issues and problems and their resolutions . In this way, less time is ultimately spent troubleshooting and more time is spent proactively managing the SPS landscape. Disaster Recovery In this section, we address disaster recovery of the Microsoft SharePoint Portal Server Production system. It should be noted, however, that disaster recovery, or DR, may be important to system environments other than just Production. A multi-portal enterprise-wide Development system, for example, may be nearly as important to safeguard, especially just before go-live . An exercise in ROI (return on investment) ”the cost of safeguarding the system versus the cost of recovering your system without benefit of a DR system ”must be performed. Only then does the benefit of maintaining a DR system ”whether for a Production system, Development system, or other component of the system landscape ”become apparent. Disaster recovery is much more than simply having backup and restore capabilities. Rather, DR seeks to provide production-level coverage in the absence of the production system landscape. This could mean many things, depending upon the configuration of the system. Generally, though, DR assumes that the entire system is unavailable, or that a critical single component, such as a dedicated search server, is down. Central to good DR is duplicating the server(s) running SharePoint Portal Server. Duplication is a special term for Microsoft SharePoint Portal Server ”while a typical backup/restore process allows recovery of a server, Microsoft's server duplication process leverages SharePoint Portal Server's unique script-based backup and restore procedures. The restore script, for instance, allows for a copy of a master dashboard site to be created on multiple computers, even to the point of creating the master dashboard over multiple computers distributed across a network. To provide this level of disaster tolerance, the SharePoint Portal Server backup and restore process is used to create multiple copies of the master server. This is performed by remotely restoring backup images of a server to other servers in the same domain. A server can also be duplicated by leveraging the backup/restore process in the following manner: NOTE These scripts can easily be automated, such that jobs may be created and scheduled to create a backup image of the master server for duplication. You may also set up a scheduled duplication process to perform the restore on the remote drive.
For ABC Company, a Disaster Recovery Plan will only initially address the productive system, including the portal and dedicated search server resources. As mentioned previously, the ABC technical support organization selected a three-system landscape partly for reasons of disaster recovery. The Development Portal environment was established at a location miles away from the Production and Technical Sandbox systems, and a duplication backup/restore process was scripted to allow for recovery of the Production system on the Development system. Eventually, as the portal grows to encompass additional business groups and functionality, ABC will again need to address the scope and breadth of DR protection required. For the first six months after go-live, however, this approach will more than adequately serve their needs for disaster tolerance. |
