SharePoint 2010 Consultancy Project. Part 3 - How to kill SharePoint farm with the help of SharePoint Designer

Introduction

These are a few posts that came up as a result of my work in one consultancy project helping a team that worked on implementation of a SharePoint 2010 based system. My involvement into the project was not too long, only a month, and my tasks were mostly bringing break-through solutions for the most peculiar requirements or the most intricate integration points. Some of those solutions will be described in these posts.  

• SharePoint 2010 Consultancy Project. Part 1 - Business Workflows
• SharePoint 2010 Consultancy Project. Part 2 - Reports

Part 3 – How to kill SharePoint farm with the help of SharePoint Designer

In one of our SharePoint projects we had debates with customer if it is safe enough to allow business users/administrators to use SharePoint Designer in addition to SharePoint out-of-the-box web UI. On one hand SPD is a powerful tool, which could give lots of benefits even though it requires more advanced knowledge and skills. On the other hand customer’s concern was that changes made with SPD in a site may impact the whole farm in some way. My point at that time was that SPD is basically out-of-the-box tool so the biggest harm people can do with it should not extend outside of that site or in worst case web application.

Later in another project I found out that SPD can be more dangerous in terms of its impact to the whole farm performance. In fact performance of the SharePoint server can be downgraded with a custom SPD workflow; literally running that peculiar workflow kills the farm as it takes 100% of processor time and it can go on forever unless administrators take actions.
Here is a simplified workflow that I used to kill the farm. The workflow is extremely simple (see figure below). Basically this is a reusable SPD workflow consisting of a ‘Parallel Block’ and two ‘Start Approval Process’ activities in it.



The reusable workflow was assigned to a content type and then a list was created with association to this content type. Nothing bad happens yet when you just create a list item and kick off the workflow. But when user tries to do any approval action on one those two approval processes, the whole system gets busy. Processor usage goes up to 100% which never ends. Obviously no sites respond after that.
Clearly, that the process that gets all the resources is OWSTIMER. Interesting, that restarting ‘SharePoint Timer 2010’ service from Server Manager failed so I had to end OWSTIMER process directly in Task Manager. In fact this is not enough because when ‘SharePoint Timer 2010’ service recovers it continues with the workflow getting busy again. So the workflow has to be cancelled before time service is recovered.

Of course no ‘physical damage’ was caused and the problem could be resolved by restarting timer service and cancelling the workflow so no system restoration was needed. But still this example shows how easily users can bring SharePoint down using SPD (if they have proper skills and enough time of course;)