Print | posted on Friday, March 13, 2009 7:38 PM
If you have been in any of my SharePoint admin classes or worked with me on deployments you will be familiar with one of my favorite topics, the ‘hidden cost’ of SharePoint. I’m not talking about scary topics like ‘governance’, ‘best practices’, culture change, end user training, or Enterprise CALs, but rather all the other things you absolutely must have when operating SharePoint in the enterprise. It’s long overdue that I post a summary here for all those who want the key takeaway information.
This is not a criticism of the SharePoint stack. None of these things are really a ‘hidden cost’. Any SharePoint practitioner worth her salt should be communicating the requirement for these additional tools right from the get go on engagements. Indeed this is also true in most cases for other enterprise server products, such as Exchange and SQL Server, from Microsoft.
The problem is that these things are generally not budgeted for as part of the project to deploy SharePoint. Usually an ‘architect’ or ‘expert’ isn’t hired in until after the project is budgeted and approved. Therefore, you are a ways into the project before the requirement for these additional tools become apparent to the team. At that point it’s usually difficult to fund the acquisition, skills and deployment. Factor in the common requirement to perform a evaluation for each area of different vendors and the whole thing becomes a time suck away from the core focus of the delivery.
This is one of many aspects of SharePoint that make the traditional IT project model unsuitable. SharePoint is a journey not a finite delivery, and you never know where that journey will take you.
What usually ends up happening is that the people who call the shots, afraid to ask for more money to do the job properly, will make statements like, “we’ll review that 6 months post deployment” or “we’ll do that later”. This is extremely dangerous as each of the items below are just as critical to your capacity, performance and security planning as are the SharePoint server roles themselves. Besides when someone says “we’ll do that later” you can pretty much put money down on the table that it will never happen!
These are the the essential additional infrastructure capabilities you absolutely must deploy alongside SharePoint in the enterprise. I am not going to dive deep into each area in this post, but simply summarize why you need these tools and throw out some options (not recommendations). If you are a vendor and I don’t mention your product, too bad, this is my blog :) But seriously don’t be offended, I am not making product recommendations here. At the end I will attempt to articulate the other fringe considerations when evaluating products in this space.
1. SharePoint Backup and Restore
Out of the box doesn’t cut it. SLAs, Site Deletion etc. If you deploy Exchange in the enterprise chances are you are not using the ‘OOTB’ exchange backup and recovery tools, but rather a robust and more adequate SLA meeting toolset.
Don’t believe the hype from imaging companies that sell “snap restore” technologies, don’t believe the hype from SAN vendors. Even if you have a nice SAN replication story implemented you will still need a off disk backup and recovery toolset.
There are a bunch of options here. AvePoint is the market leader simply because they had the solution in this space for previous versions and it is proven. Other options include Quest Recovery Manager and Microsoft’s Data Protection Manager, which offers a new approach to backup and restore of massive data sets.
Ensure that you match the product to your SLA requirements and also think about time to backup and how that affects your content database design. Also consider the file format of the backups, and how flexible they are with respect to off disk storage. Oh and don’t forget to actually test a restore every so often.
2. SharePoint Anti-Virus
Yes, you need it. The host anti-virus installed on your SharePoint servers is not adequate, it will *not* scan incoming (uploaded) files as those files never touch the file system on the boxes, they go straight into a blob in the database. Some vendors sell A/V which works on the ‘edge’ scanning HTTP but most of them have known issues with SharePoint. Don’t fall into the trap of thinking that just because all your clients have host AV your SharePoint will be protected. Can you *guarantee* all your hosts have AV turned on and their definitions up to date? No, I didn’t think so!
You need a product that integrates with the SharePoint Anti Virus API. I’ve used all of them that claim to do this. Many are terrible and simply don’t work properly with .NET applications (they lock web.config for example). Once you have it installed you tell SharePoint when/how to scan content using Central Administration. The A/V itself goes on the WFEs.
Microsoft Forefront Security for SharePoint (formerly Antigen), Bit Defender and Trend Portal Protect are all options in this space. Forefront has a decent management UI and multiple scan engines. It’s licensed on a per user basis or as part of your existing Enterprise Agreement.
You can scan on upload and/or download. For new farm, upload only is a good option as you know you have an empty farm to start with. Be aware however of the performance impact here and ensure you have enough WFEs to accommodate the hit.
Also remember to exclude SharePoint stuff from host based AV as detailed in KB952167.
3. Systems Management
If you are deploying a farm of any reasonable size you need a systems management toolset that can monitor operations, correlate logs and events for diagnostic and performance analysis/trending. This tool might wake people up with an SMS when things go horribly wrong. Ideally you would also have the ability to perform operations in event of say a single server failing do something sensible like take it offline.
It’s common for enterprises to wish to use their existing toolset here, and whilst that is a reasonable goal, it’s not so practical as most tools don’t have SharePoint agents or management packs. If you are OK with implementing those yourself then Tivoli and NetIQ are good options.
Microsoft System Center Operations Manager is another great option here as this has pre-defined management packs for SharePoint (and the rest of the stack) which you can easily tweak for your deployment.
Whichever one you go for here you will have to implement your own scripting and automation as well. Don’t forget there will be other elements to your deployment such as a load balancer, and the ideal world is to have the systems management toolset act in a holistic nature based on the service availability of your farm(s). Aside from the tooling, learn Powershell!
4. Usage Analysis (end user and IT)
Spent a couple mil implementing SharePoint and have no idea how it’s being used, which bits are popular, which bits aren't, how much storage is being used? That’s not good. It simply doesn’t matter how much you think you know about your user population or the technology, it won’t play out the way you expect with SharePoint. There is no one who can predict usage patterns. How can you tweak, change and remodel things like Information Architecture, physical roles, topology, storage and search if you have no metrics on how it’s being used. With a magic eight ball!
Therefore you need a usage analysis and reporting engine. SharePoint is only ever successful if those who are operating it understand how it’s being used and engage with the user population to continually improve it. OOTB stats are reasonable for very small deployments but simply don’t cut the mustard elsewhere except in the realm of search usage.
It’s imperative that you have both sides of the coin covered here. Just as you can’t predict usage patterns neither is it likely your farm topology will be suitable in the long haul. Things have to evolve as your user population adopts SharePoint.
Nintex and Quest both have good tools in this space, as do some of the usual suspects such as WebTrends. Be wary of “legacy” vendors that say they “support SharePoint”. If that means putting some javascript in a page that writes a row to a database that’s a bad sign. And don’t even think of storing your usage analysis warehouse on the same SQL instances which are hosting your content databases.
This area is often combined with Systems Management as there is significant overlap.
The multiple vendor problem
Great, so we need a bunch of extra stuff. This is a problem, as you could end up with four vendors. Do those tools all play nice together? Four different licensing models, four difference release cycles, four wildly different support experiences. There is a lot to think about here. In an ideal world, you would get all of them from the same vendor, and that vendor would be Microsoft. However in reality it’s likely the company will have agreements in place with certain vendors before SharePoint enters the picture. Tread carefully. And remember the golden rule of the SharePoint ISV gold rush:
Don’t believe the hype, if a SharePoint ISV tells you they have all the tools you need, or that “they know more about SharePoint than Microsoft”, laugh in their face and ask to speak to someone with some credibility.
There is no single SharePoint ISV that has your IT Pro needs covered. Not yet at least.
Conclusion
There you have it, four things you need alongside SharePoint in the enterprise. There are of course other things that for a given deployment are necessary (e.g. replication or rights management), but these four are the absolute must haves.
It is absolutely imperative that these things are not treated as bolt on elements, but are factored into your holistic solution wide farm planning, design and testing.
I urge all SharePoint practitioners to communicate these requirements before your customers start buying boxes and hiring developers.