What should I check with a Health Assessment?

When you perform a health assessment of a SharePoint farm, you need to check everything you have and compare it to patterns and practices.  In some cases you may come across limits (supported maximums) and boundaries (hard limits) for certain settings, your goal should be to ensure you are well within any limits and to have a plan in place to maintain your settings within the standards and practices as they relate to your farms.


The purpose of this blog post is to give you a guide into the physical attributes for your solution and what you need to check.  I do not talk about tools in this blog, but suggest you employ a tool for your health assessment because it provides consistent, repeatable approach to your solutions health.


I will not be too verbose in this post, but rather will concentrate on the areas one of my cohorts, Kevin Cole (follow him on twitter at SPDEVGUY), a Microsoft Certified Master of SharePoint 2010 and brilliant technical mind, and I came up with.  I have the areas broken down into 11 different sections and will briefly talk about what you need to know in each of the areas, so lets get to it.

The Check Points

As I mentioned you can check these things manually, but it will be time consuming, there are many tools available for you to perform these, we use PowerShell and it allows us to regularly and consistently create our reports for health.  I have not gone in depth into any of these, but I will add to this/modify it if you provide feedback.  This is a work in progress, but as far as I know the only check list that I have found to date that covers off the farm.

Servers

1. Determine the servers being used in the farm: Server identification is needed to understand the resources you are working with and to identify gaps in architecture
2. Determine the roles of each server in the farm: The role tells you what the server is doing and on which tier of the farm architecture the server resides.
3. Draw the logical diagram of the farm: A list of servers and their roles is difficult for the average user to understand, a graphical representation makes it easier for everyone to understand.
4. Gather the number of processors, type and if they are dedicated or shared (VM) for each server: Knowing the allocated processing power helps identify processing shortfalls that may cause performance issues.
5. Gather the RAM and whether it is dedicated or shared (VM) for each server: Knowing the allocated RAM helps identify when disk caching will occur and identify performance issues.
6. Gather the total and available storage for each server (Physical and SAN): Understanding your storage and any limitations will ensure you don't run into a situation that has you scrambling to add storage.  In addition, configuration of swap drives, etc. can affect performance.
7. Gather the type, current capacity, allocated and maximum capacity of the SAN: Knowing the SAN capacity will help with determining current capacity and planned growth. The type of SAN will help identify any RBS provider issues or determine what is needed to implement RBS, if it has not been implemented.
8. Determine the hardware lifecycle for server infrastructure: Understanding how old each server is and when it is planned to be replaced allows for a proper perspective when identifying which servers are underpowered for the current environment or for future growth.
9. Determine the patch levels of the server OS and all dependent services: Identifying any outstanding patches will identify any risks to the stability of the OS and the services SharePoint relies upon and may identify possible security exploits.
10. Determine patching schedule and outage windows for the solution: Patching Schedules and Outage windows are important to the health of the servers, allowing for proper maintenance of the servers without the risk of causing a disruption. Determine if and when patching is
    performed, when the outage window occurs and how long it lasts.
11. Determine the SQL Server version and patch level: Knowing your SQL Server version and patch level will help you identify issues with performance and may identify security holes.  In addition, the SQL Server version affects some feature availability and limitations, depending on your farm.
12. RBS SQL Server Configuration: Storing BLOBs in the database can consume large amounts of file space and expensive server resources. RBS efficiently transfers the BLOBs to a dedicated storage solution of your choosing, and stores references to them in the database. This frees server storage for structured data, and frees server resources for database operations.
13. RBS BLOB Threshold: Setting the right size threshold will ensure a balance between processing needed to offload large files and your content database size.
14. SAN Configuration: A misconfigured SAN can cause increased latency and other issues to RBS, SharePoint and SQL Server.
15. Storage Provider Configuration: Using the correct storage provider (and correct version) for your SAN will improve performance. 
16. SAN Capacity: Ensure your future storage needs do not exceed the current capacity, check for the current utilization and available storage as well as the ability to expand storage hardware if needed.
17. SharePoint RBS Configuration: Ensure your farm is configured correctly for RBS.
18. BLOB caching setup: Disk-based caching is extremely fast and eliminates the need for database round trips if it is configured properly.
19. RAM Utilization: Ensure your farm servers are not over utilized.
20. CPU Utilization: Ensure your farm servers are not over utilized.
21. User Profile import filters:  Are service accounts and disabled accounts filtered out?
22. User profile synchronization schedule: Find the right balance for the sync. 
23. Portal super reader and super user accounts setup: Verify they are set properly and that the membership is correct. 
24. Office web apps cache: It is recommended to isolate the content database used for the Office Web Apps cache, so that cached files do not contribute to size of the "main" content database(s) for the Web application.
25. OWA service apps: Ensure the Apps are running on correct server roles.
26. Web apps: Ensure Web apps are not running in ASP.NET debug mode in production.
27. Farms: Record the number of Farms and purpose of each.
28. Web Apps: Ensure Web apps are configured correctly.
29. Content Databases: Ensure proper content database sizes and configuration.
30. Site Collections: Ensure properly sized and organized site collections.
31. Custom Features: Review and record the Custom Features, where they are used, their intended purpose and proper installation and activation.
32. Custom Apps: Review and record all custom apps installed on the farm, their intended use and where they are being used.
33. Custom Web Parts: Review and record where any custom web parts are being used and that they are working properly.
34. Environments: Record and ensure the environments are synchronized and consistent with each other and that they are being used for their intended purpose.
35. Environment Patching: Check environments for consistent patching (build numbers) between all environments
36. SQL Naming: Ensure SQL Servers are using SQL Aliases, not computer names or CNAMES
37. DNS: Ensure host records defined for the SQL Aliases
     

Platform

1. Page File on a separate drive from the OS, SharePoint and Logs
2. Does Storage meet the farms needs (current vs. projected)
3. Are there large files being stored in document repositories
4. Record number and size of files
5. Is there a change management process involved?

Logs

1. Check Application log for errors
2. Check System log for errors
3. Check ULS log for errors/ critical / warnings
4. Check IIS logs for 503 error pages
5. Check IIS logs for slow (>200ms) loading pages
6. Check IIS logs for Active Directory Latency (304 not modified with excessive load times)
7. Check IIS logs for dead links (404 errors)
8. Check Requests per second count from IIS logs
9. Check log locations (SharePoint/IIS should be on a secondary drive)
10. Check for unrestricted growth
11. Check log drive capacity/utilization

Solution Integrity

1. Old SSP Site removed (for in place upgrades)
2. Check Supported Limits for Managed path counts
3. Check Supported Limits for Content DB sizes
4. Check Supported Limits for List item counts
5. Check for deleted pages in navigation
6. Check for unused content sources in the search crawl
7. Check Health Analyzer rules
8. Check patch levels for all content databases
9. Check for orphaned site collections
10. Check for broken site collections
11. Check for broken my sites
12. Check for missing web part references (Error web part detected)
13. Any Sites running in UI Compatibility Mode (2007 or 2010)
14. Check code quality process for stress testing
15. Check code quality process for load testing
16. Check code quality process for security testing (each role)

Continuity

1. Is backup being performed? 
2. Review backup process
   http://technet.microsoft.com/en-us/library/cc298801.aspx#sectoin1b 
3. Is the disaster recovery plan tested and reviewed annually? 
4. Ensure Central Admin is redundant.
5. Is disaster recovery farm on another site? 
6. Virtual machines distributed properly across physical hosts for disaster protection?
7.  Check for role redundancy for Web front ends
8.  Check for role redundancy for Application Servers
9.  Check for role redundancy for Database
10.  Check for Service redundancy 

Security 

1. Check for Extra ISA Firewall rules.
2. Check SSL Use // IPSEC
3. Are MySites hosted on a dedicated web application?
4. Is the farm admin able to manage the service accounts?
5. Ensure farm account is not be used for other services.
6. Farm account should not be in local administrators group unless doing install or patch.
7. Ensure external access uses SSL?
8. Kerberos Configuration (SPN's configured properly)
   SP 2007 http://blogs.msdn.com/b/martinkearn/archive/2007/04/23/configuring-kerberos-for-sharepoint-2007-part-1-base-configuration-for-sharepoint.aspx 
   SP 2010 http://www.microsoft.com/en-us/download/details.aspx?id=23176 
   SP 2013 http://technet.microsoft.com/en-us/library/ee806870.aspx
9. Ensure the proper number of service accounts:
   SP 2007: 3
   SP 2010: 5
   SP 2013: up to 16 service and 3 server.
10. Ensure My Sites are configured with secondary site collection owners.
11. Ensure farm admin and service accounts are not be permitted interactive logon.
12. Ensure the proper service accounts are used for the proper services:
    http://technet.microsoft.com/en-us/library/ee662513.aspx

Database

1. Check content databases within limits.
2. Check transaction log sizes.
3. Check for excessive free space. // shrink db
4. Trim audit logs to reduce content db size.
5. Check for maximum degree of parallelism.
6. Ensure database auto growth sizes set properly.

Information Architecture

1. Verify: universal site taxonomy.
2. Check maximum site depth.
3. Check maximum site width
4. Check for a high number of role assignments on individual items.
5. Check for a high number of unique permissions.
6. Check content growth projections.
7. Check for a high number of sites sharing a content database.

Branding

1. Are there any custom master pages?
2. Are the custom master pages or page layouts working properly?
3. Are all images / styles / etc checked in and published?

Customization

1. What WSP Solutions are deployed?
2. Are any InfoPath forms deployed?
3. Check for Invalid / missing Feature counts.
4. Ensure assemblies are compiled in release mode not debug mode.
5. Which solutions are 3rd party?
6. Which solutions are in house?
7. Check solution utilization (Where, activation locations, actual usage)

Search

1. Check crawl logs for any errors or warnings.
2. Check crawl schedules.
3. Check crawl running time versus crawl interval.
4. Check for successful crawls and crawl failures.
5. Check search service account configuration.

I realize there may be some repetition above, but the purpose of this is to help you ensure a healthy environment.  If you have any questions, additions or modifications, please comment and I will make updates.  Please follow me on twitter @DavidRMcMillan and @DevFactoPortals.  I look forward to making this a resource any admin can use.

ECM Governance - Post 5

I think it is official, I suck at blogs, but I promise to try to post more (not saying I will), but one thing you can be sure of is a tweet when I do.  I seem to be getting worse at this, rather than better, blog posts always end up being low on my priority list and the time between seems to increase, not decrease.  Today I wanted to finish off the definitions of the different principles and then we can move on from there, hopefully in a more timely manner.

Collaboration Principles

Collaboration principles are principles that describe the way in which we plan on using the Team, Project and other collaboration site capabilities of the solution. It should include things like the site design, which lists and libraries are standard, the security roles used in collaboration, Content Types for templates and anything else you want to control in the collaboration portion of your solution.

Collaboration principles are about the control of who can do what, where and when. They provide a foundation for collaborative interaction and as such are always used in your solution in some way. As an example of a Collaboration principle, I have included "Collaboration sites will inherit the top menu navigation from the parent site", which encompasses the fact that collaboration sites are more loosely controlled than portal sites and control revolves more around the user experience.  Later when we examine the application of policies, we will see that as we move down the hierarchy from portals to collaboration sites and then to my sites, we change from highly structured and restrictive control to a looser user enabled control, but more about that later.

Collaboration sites will inherit the top menu navigation from the parent site
Principle
Collaboration sites will inherit the top menu navigation from the parent site.

Implication
To maintain a consistent user experience, the same top menu is used throughout all collaboration sites, Site Administrators will have no control over navigation.

Business Process Principles

Business Process Management is a core function that every ECM needs and SharePoint is no exception.  The one caveat I have to say is that SharePoint sucks for creating workflows and forms, thank goodness they deprecated InfoPath, Nintex does a far better job in the forms area and makes it possible for power users (with training and mentorship) to create some complex workflows.  The developer will never disappear for the complex workflows, but his work is minimized, providing a better return for the organization.  Come to think of it, the ROI of a tool like Nintex seems like a good topic for another blog post, stay tuned for that too, lol.

Anyway, regardless of the tools used, BPM needs some structure around how workflows, integrations and forms are created, where they are stored, how they are executed and anything else you think will need a boundary around.  In this example I have created a principle for the management of alerts and notifications, which fall under business process management.  The principle is intended to reduce the overhead of managing alerts and notifications, but ensuring users are responsible for managing their own alerts and notifications.  Coupled with this principle are other principles around training for users and principles for notification and alert creation.

Each user is responsible for the management of alerts and e-mail notifications
Principle
Each user is responsible for the management of their own alerts and e-mail notifications.
Implication
While anyone can assign alerts to others, each user is responsible for the maintenance of their own alerts and notifications. Each user needs to ensure they receive the notifications they need.

Esthetic/Site Design Principles

Now I changed the name of this, many ECM governance practitioners will call this user experience, but for me, it is more than just the user experience and encompasses the brand, navigation, search style guides, master pages, XSL transformations and anything else that affects the look and feel of the solution, including site and page templates.  These rules are often the most important because they directly affect the user experience and adoption; no one like an ugly site. 

I remember a developer that once worked for me, he had recently come from China and I asked him if he could brand our product SharePoint site.  He said "yes" and with a slight head bow, immediately set to work.  He ended up spending the evening at home working on it, so when I came in the next morning, he proudly presented me with a SharePoint team site branded in bright red and gold, or as his cohorts called it the ketchup and mustard brand, very much like the 1980's McDonald's I grew up loving... but alas there was no Hamburglar anywhere on the site.

That little story illustrates why this is so important, every user has a different idea when it comes to look and feel and if I had simple used a governance principle that said his brand had to align with the corporate style guide, there would never have been an issue; well maybe.  I have included a couple examples in this case, one that identifies the importance of user experience, the other ensures no one thinks they can make up their own brand.

Prefer Findability over Authoring Convenience
Principle
Ensure that “findability” governs design decisions – optimize metadata and site configuration to provide the best value for the end-users, not just the content contributor.
Implication
In situations where design trade-offs must be considered (more metadata versus less, information above or below “the fold”, duplicating links in multiple places), decisions should be made to make it easier for end users rather than content contributors. “Findability” means designing sites so that important information is easily visible and that navigational cues are used to help users easily find key information. It also means using metadata to improve accuracy of search results. Both the “browse” and “search” experience for users will guide design decisions in initial site development and modification over time.

All publishing and collaboration sites will be consistently branded
Principle
All publishing and collaboration sites will be consistently branded.
Implication
In order to maintain consistency in the look and feel of the intranet, standardized brands will be used for collaborative and publishing sites and will not be modifiable by the site owners.

Content Principles

Where the Esthetic principles are the most important principles for user experience and adoption, content principles are about making the solution fit for purpose, after all this is an ECM we are taking about (emphasis on the "C"). In reality, my experience has proven that the content principles will out number all the other principles combined, why, we can every content type will need principles to define it. Whether we are talking about a metadata field, a vocabulary, taxonomy, document, list, image, template page or alert, it is all content and that means that principles that affect any part of the system will probably affect the content principles.

Because content principles are such a vast area, I have included several examples to help you get started, but understand even in the beginning this category is the main part of a governance document. Some of these you have already seen, which reinforces my point of overlap, yet I am sure you can see how they apply to more than one category.

All content is owned
Principle
All content must have a clearly identified “owner”.
Implication
Users need to know who to contact if content on a site is out-of-date or inaccurate. The content owner is accountable for all the content in a site and for ensuring it is up-to-date. Each site should have a clearly defined owner that is visible on the main page of each site.

Maintain a single source of truth
Principle
All content exists in only one location.
Implication
This means that the official version of a document is posted once by the content owner. For the reader’s convenience, users may create a link to the official copy of a document from any site, but should not post a “convenience copy”. Users should not post copies of documents to their personal hard drives or My Site web sites if they are already on a site.

In situations where some documents or records need to be available offline due to a very slow or inconsistent connection to the SharePoint sites, SharePoint Workspace can be used to make these records available offline.

Use built-in versioning
Principle
Edit documents in place. Do not download or make copies for editing, if possible.
Implication
Version control will be enabled in document libraries where prior versions need to be retained during document creation or editing. If prior versions need to be retained permanently for legal purposes, “old” versions of documents should be stored as records. Documents should be edited in place rather than deleted and added again, so that document links created by other users will not break.

Sponsors/Owners are Accountable
Principle
Site Sponsors/Owners are accountable, but everyone owns the responsibility for content management.
Implication
All content that is posted to a site and shared by more than a small team will be governed by a content management process that ensures content is accurate, relevant, and current. Site Sponsors/Owners are responsible and accountable for content quality and currency and archiving old content on a timely basis but site users are responsible for making Site Sponsors/Owners aware of content that needs updating.

Business Intelligence Principles

Business Intelligence principles encompass the use and presentation of BI data, reports, dashboards,  charts, graphs and KPIs.  They are intended as with any other principle to provide both consistency and ease of management, with the later being very important.

In this example, we define a principle that ensures we are controlling access to the BI tools, which require an enterprise license in SharePoint.

The Business Intelligence Centre can only be accessed by the BI User role
Principle
Only the BI User Role will have access to the BI Centre
Implication
To control the Enterprise license in SharePoint the BI Centre exists in it's own web application and can only be accessed by users who have the proper licensing.  The BI User role has been configured to ensure compliance with the Microsoft licensing model.

So anyway, this one took a long time, so I made up for it with more content, but I am trying to get my MVP, so I may need to blog a lot more, it doesn't do a lot of good knowing a bunch of stuff if I am not going to share it with the world.  Got to change the IT world, one client or reader at a time.

ps.  follow me on twitter, @DavidRMcMillan, I will post articles and where I will be speaking there.

ECM Governance - Post 4

Guiding Principles continued

Hi Everyone,

Last post I had a pretty short entry and it took a long time for me to get it out, unfortunately work sometimes gets in the way of my sharing of information as you can see I haven't posted in some time due to client constraints, anyway, this post I want to continue the descriptions of the different categories of guiding principles I have outlined for a SharePoint implementation (realize these are not the only categories, some may need to be added or some may not be needed, depending on the purpose of the solution being provided).

Last post we reviewed the General and Security principle categories, this post we will look at the following categories:

Document Management Principles

Publishing Principles

So let's get to it...

Document Management Principles

Document Management principles are principles that have to do with the way in which our solution should manage and control the creation and modification of documents in the system.  The reason it is not referred to here as records or information management is really a matter of scope. Document Management principles need to encompass records and information management (RIM), but it should also encompass content that is not part of the document or information strategy.  We are not going to rewrite the RIM (if one exists), but rather we will try to capture the principles behind why the architecture and strategy were implemented.  In addition, we will define principles for content that has not be defined in the RIM (like SharePoint lists) and configuration specific items, like the version control, check-in and check out and draft version rules.

The Document Management Principles are not meant to replace the RIM, but are meant to tie the RIM strategy and governance into the governance of the ECM solution (remember keep it simple and understandable).  In reality, the document management principles are probably one of the most numerous rules you will have in you ECM governance plan, as most of ECM is about the management of documents and content.  As an example of a document management principle, I have my number one rule for all governance (your governance plan will fail without it), "All Content is Owned." as it is outlined below.  Notice it is a principle that encompasses more than just records or documents, addressing all types of content; yet it still applies as a document management process because it affects the way people will work with documents and records.

All Content is Owned
Principle
All content must have a clearly identified “owner”. 

Implication
Users need to know who to contact if content on a site is out of date or inaccurate. The content owner is responsible for all the content in a site and for ensuring it is up to date. Each site should have a clearly defined owner that is visible on the main page of each site.

Publishing Principles

Publishing principles are principles that describe the way in which we plan on using the intranet and published site capabilities of the solution.  It should encompass plans for language variations, the way we are reviewing and publishing content and any other principles that may affect the configuration of the publishing and audience components of the solution.

Publishing principles are about the control of who sees what and when, they provide a foundation for portals and as such are only used when a portal solution is required.  As an example of a publishing principle, I have included "All portal and department site content is reviewed and approved prior to being published", which encompasses the fact that portal and department sites are highly controlled and all changes are reviewed and approved prior to being made available to users.

         All portal and department site content is reviewed and approved prior to being published
           Principle
           All content changes for publishing sites must be reviewed and approved before the changes can be published.
         Implication
         Content owners are responsible for updates, while site approvers are accountable for the correctness
           and appropriateness of the content being published.

Next post we will complete the definitions of the categories for principles and from there will move on to other important governance, like who does what in governance implementation and how we can make principles work within an organization.

ECM Governance - Post 3

Guiding Principles continued

Hi Everyone (or me, myself and I, not sure if anyone reads this...) sorry for the delay in this next post, I having been busy doing and not spending enough time writing about it.  In my post 2, we examined the idea of guiding principles and how they are used to set a foundation for our ECM.  We identified several categories or "Areas of Impact" that these principles could be separated into and this week I would like to start by detailing the intent of each of those categories.

General Principles

The general principles are principles that do not fall into any other category, they are usually the least specific (or most general) and often refer to governance rules and policies and how you intend to use them.  A good example of a general rule is the scope of the governance plan or how we intend to apply principles as a general rule.

For example, we want consistent governance across the entire solution and exceptions need to be recorded whenever a site or site collection does not follow the set of policies defined.  In that case, we can create a general principle to define that need:

Governance Scope
Principle
All governance principles, policies, standards and training are tied to the scope and intended purpose of the entire solution. Governance applies equally to all sites and all site areas.

Implication
While some policies will be enforced across the entire organization, others may be determined by each site owner. The Governance document is not intended to define the site specific policies, but is intended to provide the foundation for all sites. Deviation from the governance policies is by exception only and should be recorded and approved by the steering committee prior to implementation.

Security Principles

Security Principles deal with the need for security and how we plan on using security in our solution.  We address things like the security architecture, the use of roles, external access and permission management as security principles.  It is important that we keep security principles as general as possible, to allow for better granularity at the policy and configuration level of the solution to meet the organizations security needs.

As an example we can look at a principle that is common to any governance plan, the use of roles to manage permissions within the solution.  Again the principle is defined and then the implications to the way the solution will be used are outlined.

Role-based Security Model
Principle
Use of a Role-based security model will govern access control and permissions to the SharePoint Portal.

Implication
Users may have different permissions on different sites or areas of the site, which has an implication for both governance and training. This permission is based off the roles that are assigned at any given level. Direct permissions should not be used; if it is found that direct access is being provided, the roles should be reviewed to determine if a GAP exists in the role structure. If a GAP exists, a new role should be defined to prevent the future need for direct security permissions.

In my next post, I will go over the remaining principles Document Management Principles, Publishing Principles, Collaboration Principles, Business Process Principles and Esthetic Principles. Also if you want to learn more in person, I will be presenting on governance at the SharePoint Summit Vancouver 2013, October 28 & 29, I hope I see you there!

Some helpful Links for MOSS Administrators

Administrator Guides
· MOSS 2007 - Administrator Guide
· WSS 3.0 - SDK
· WSS 3.0 - Technical Library
· MOSS 2007 - Newly published content
· WSS 3.0 - Newly published content
· WSS 3.0 - SharePoint Server 2007 Developer Portal
· WSS 3.0/MOSS 2007 - Office SharePoint Server 2007 Administrator's Companion
· Complete reference of all PSCONFIG operations


Best Practices
· Before You Begin with SharePoint Server 2007
· Best Practices Analyzer for WSS 3.0 and MOSS2007
· Writing SQL Syntax Queries for Relevant Results in MOSS2007
· Backing Up and Restoring Web Sites w/ Stsadm
· MOSS 2007 - Planning and Architecture for Office SharePoint Server 2007


Search
· Configure the Office SharePoint Server Search service
· Configure Office SharePoint Server Search to crawl Lotus Notes
· Security considerations for search
· Overview: Plan search
· White paper: Evaluation guide for search in Office SharePoint Server
· Plan to deploy index and query servers

STSADM Commands
· Jose Barreto's Blog Complete reference of all STSADM operations (with parameters) in MOSS 2007 SP1