Six critical questions for any SharePoint developer

Although many organizations that use SharePoint employ internal developers to create custom solutions, every customer organization I’ve encountered in my ten years of SharePoint consulting has used external vendors for at least some development. These vendors include individual contractors, Microsoft Certified Partner firms like non-linear creations, and independent software vendors (ISVs) like Bamboo Solutions or K2.

Whether you use internal employees or third-party vendors, and whether an application is a simple web part or a complex business-process automation, you must not deploy it until you know it can be trusted. A poorly-written application can slow (or bring down) your entire SharePoint farm. It can destroy or corrupt data in your databases, or critical files on your servers. It can also circumvent your security, opening you up to all manner of attacks.

Below are six critical questions that you must ask any SharePoint developer, internal or external.

1. Is this a Sandboxed Solution?

Prior to SharePoint 2010, the only option available to the customer was to deploy every solution as a Farm Solution, where files are deployed to the file system and the code runs in the same execution space as SharePoint itself. If the solution is well written and behaves itself (for example, by NOT hogging all the server memory and crashing the SharePoint site it lives in), this is not a problem. But since the quality of custom SharePoint solutions is fully dependent on the developer/vendor, deploying a Farm Solution calls for a lot of trust on the part of the server administrator/customer

Overcoming the customer’s understandable reluctance to deploy Farm Solutions was the driving force behind the introduction, with the 2010 product release, of Sandboxed Solutions. Sandboxed Solutions are web parts, Lists or other SharePoint features that run isolated from your SharePoint sites. By default, a Sandboxed Solution cannot access or affect anything outside of the local SharePoint site; external databases, web services, and the file system are all off limits. Your server administrators can apply limits and quotas to the Solution, so that if it misbehaves by (for example) hogging server memory, SharePoint 2010 will shut it down.

Your developers/vendor may complain that Sandboxed Solutions are additional work. They may say that they are too neutered and can’t do anything useful. However, for a solution that requires access only to the local sites, lists and libraries, the latter isn’t true. And Sandboxed Solutions can be given additional permissions safely by using something called Full Trust Proxies, which let your vendor’s code request specific rights, while remaining isolated from the SharePoint execution space.

Now that we have Sandboxed Solutions, a SharePoint developer’s first question (and yours) when designing a new feature should always be, “can I write this as a Sandboxed Solution?”.

2. If it’s not Sandboxed, does it run as fully or partially trusted?

Sandboxed Solutions are still quite new, and do require extra work, so they are not yet the industry standard (this will change very soon). And there will always be some solutions that can run only as Farm Solutions. You will still have occasions, then, when it will be acceptable to deploy a Farm Solution. But if your vendor or in-house developer delivers you a Farm Solution, you must know if it partially or fully trusted.With a fully-trusted solution, your developer’s code can access the file system on your SharePoint servers, it can access the Windows Registry — it is pretty much an administrator. From a developer’s viewpoint, this is the fastest and easiest way to develop. But with the availability of Sandboxed Solutions and partially-trusted solutions, there are very few reasons for you to accept a fully-trusted solution.

A partially-trusted solution has no innate rights, and must be explicitly granted permissions (in a special configuration file called a Code Access Security policy) to do anything. The developer must provide this file, which you can inspect.

3. Does it use Elevated Privileges?

If for some reason your vendor must provide you with a fully-trusted solution, you must not deploy it until you understand everything it is going to try to do.

One of the key questions in the vetting process: does it use RunWithElevatedPrivileges? This is a SharePoint feature that is exactly what it sounds like. By default, when your vendor’s code tries to do something like access a SharePoint document, it impersonates the user browsing the page; the code can’t do anything the user can’t do. However, a fully-trusted solution (or a partially-trusted one granted the permission) can use RunWithElevatedPrivileges to temporarily impersonate an account that has Full Control of your SharePoint application. RunWithElevatedPrivileges is a powerful tool that must be used sparingly, because it can circumvent your carefully-planned SharePoint security.

Something else that can circumvent your security is Feature Event Receivers.

4. Does it use Feature Feature Receivers?

A Farm (non-Sandboxed) Solution can include small bits of code that run when your server administrator installs or uninstalls a custom solution. For example, the solution may depend on the existence of an external database; a Feature Event Receiver can confirm that the database exists, and create it if necessary.

Feature Event Receivers enjoy full administrative privileges on your server farm, so it is very important that you fully understand what they are programmed to do.

5. Where does it store configuration settings?

Many applications need a place to store configuration settings (e.g., database connection strings, or a email address for alerts). If your vendor’s solution uses the main configuration file (web.config) for this purpose, you increase your risk because this file may be shared by hundreds of SharePoint sites on your farm, and the slightest typo can bring them all down.

In general, an experienced SharePoint developer will not provide you a solution that requires manual entries to web.config. Instead, a Sandboxed Solution will keep its settings in a local SharePoint list, and a Farm Solution will do the same or include a Feature (or Feature Event Receiver) that adds settings to the web.config file automagically on installation (and removes them on uninstallation).

6. Where does it log messages?

Finally, an experienced vendor will develop a solution with extensive logging. Even if the code has been developed defensively and tested thoroughly (two other things you need to ask about), even the best software goes wrong occasionally. When that happens in a production environment, you need to know exactly what happened so it can be diagnosed and remedied.

An application can log messages to the Windows event log, a database table, the SharePoint Unified Logging Service, or a SharePoint List. Before you deploy the solution, you need to know which of these places it logs to, what kinds of messages it logs (is logging too verbose? Too sparse?), and whether the logging can be configured (is logging off by default? Are there different modes — Errors Only, Verbose, etc.?). If there is no way for you to get enough information when something goes wrong to at least understand what happened, without involving the vendor, this is a sign of a poorly-designed solution.

These questions are only a sampling of the kind of due diligence required of you as the owner of a SharePoint environment. As in any business relationship, the key ingredient is trust.

– See more at:

Five Reasons Why SharePoint Online is Great for Small and Medium-sized Business

The Grid is full of Office 365 experts that are brimming with great information. The Grid User Post blog series will expose some of The Grid’s best content to the entire Office 365 Community. The Grid User Posts are written by third party contributors and are not necessarily the opinions of Microsoft. Are you interested in contributing to The Grid? Click here to apply.

Our latest Grid User Post was written by Jethro Seghers. 

Recently over the last months I have been trying to persuade Small Medium-sized Businesses (SMBs) to try out SharePoint Online, and upon using it they all loved it. It intrigues me that a solution that has been noted as an Enterprise Solution, became so popular in the SMB market. But Why?

In this post I’m going to try to give 5 different reasons why I think SMB is a Grow Market for SharePoint Online.

1. SMBs have structured data they need to store somehow and somewhere.

It doesn’t matter how SMBs are structuring their data now, they have a structure. The structure that they use is based upon the systems that they have running. If you take the physical folders, the storage room, etc, a well trained professional will find his or her documents in their own classification system. The problem is that everybody knows their way in their own little box, but not in the big world outside.

The way that they structure their documents is not different from how we do it in SharePoint Online, it’s just not digital. But they have folders, meta data, content types and even security. In some organization they tried to translate their physical structure to folders on a File Server, with varying degrees of success. They understand and realize that entering the digital world is necessary. But the system they chose to translate their structure upon has to be able to cope with the same requirements as their offline system and SharePoint Online is able to do that.

2. Small and Medium-sized Businesses have Line of Business Applications

SMBs have line of business applications, maybe not in the traditional way as we see them, but without a doubt they have them. It’s not because SMBs are small that they are under educated or not technologically advanced. On one of my recent visits to a small business, I saw a line of business application that took in an order and based on the different order lines it created kitchen doors from a raw piece of wood to a magnificent detailed kitchen door. The machine operators did every check digitally, every settings was recorded in a detailed follow-up system. At the end of the day the system knows exactly how many kitchen doors were made, how long it took, what it cost for the company. When I showed them SharePoint they were enthusiastic but they have one very important question, “Can it be integrated with what we are using today?” That’s another big advantage of SharePoint Online, because Yes it can. Integration possibilities are (almost) endless.

3. Digital Collaboration Efficiency is at the tips of their hands

Digital Collaboration is finally possible for SMB. They don’t have to mail every document to each other, they can use version control and they can simultaneous work on the document. SharePoint Online provides multiple tools to increase your business efficiency including ease of finding documents which takes care of the issue of reproducing documents. Easy communication through SharePoint makes sure that people know the company’s regulations, policies and guidelines. This helps decreases the number of accidents and increases the knowledge of Business Logic.

And these are just the basic features of a SharePoint Online. If you broaden our view to Office 365, we can introduce Lync, Yammer and Office 2013 as an additional collaboration source.

4. Inter-SMB Relationships

SharePoint Online (and Office 365) makes it easier to collaborate with suppliers and customers, which increases the ease of communication between businesses. This results in more business and more business results in growth. If multiple SMBs have that same growth, that will result in an increase of the economy. SharePoint Online makes it possible for these businesses to focus on the company and not  IT.

5. SharePoint Online is affordable

When we look at the resources an On Premises Environment needs to be active, it’s massive. This results in a high cost in hardware, software and licenses. At that point we’re not even operational yet. We still need to setup our SharePoint environment suited for the business that we want to support, which results in additional costs. Our setup has to be operational for the maximum number of accounts that we are going to support, again, more money. When you make the sum of all these costs, it’s just too expensive for some businesses. The licensing model of Office 365 and SharePoint Online, allows SMBs to just pay a fixed price per month for the number of users that are working on their SharePoint Online environment. If they are fortunate and grow in employees, then they can just purchase more user licenses against a fixed price per month. Do you need more storage, a fixed price per month per GB. So at the end, the price if very low for the use of an ENTERPRISE platform.

The bottom line is that Office 365 lets Small and Medium Businesses have access to an Enterprise Platform at SMB Pricing.

Access Denied When Editing SP Designer Workflow even Fullcontrol

Recently I saw an access denied error when a user tried to edit a SharePoint Designer workflow task. The error did not occur if the user was a site collection administrator, but did occur even if they had full control to the site, list, and task list.

Running through the Request Access pages, it appeared that SharePoint did not think the user had rights to the task list, even though they did after thoroughly checking permissions.

I figured that it was having trouble with permissions to the ASPX pages from the Designer-generated tasks forms, so I solved it by doing the following, by admin account:
– Open the site in SharePoint designer
– Locate the “Workflows” node in the tree view.
– Right-click “Workflows” and select Properties.
– Click the Security tab.
– Choose the option to manage permissions from the browser.

It turns out that this “Workflows” node is actually a SharePoint folder object, and it turned out that this folder did not inherit permissions from the parent. The web page for managing permissions that came up showed me this, and enabled me to reinherit permissions and fix the problem.

Login Failed For User ‘NT AUTHORITY\SYSTEM’. [CLIENT: ]


You receive hundreds if not thousands of NT Authority\SYSTEM “Login failed for user ‘NT AUTHORITY\SYSTEM’. [CLIENT: <local machine>]” error messages


Errors often occur every minute



You’ve probably deleted your Shared Service Provider or created a new one. Unfortunately, some scheduled jobs will remain on your SQL server that reference the now defunct database.


  • Launch SQL Server Management Studio and connect to the server that houses your Shared Service Provider
  • Within SSMS expand the SQL Server Agent and select jobs.
  • Locate the jobs that have names that end in “_DeleteExpiredSessions”
  • clip_image003

  • You in the “Steps” tab double click on the first step and check to see if there’s a database, if there’s no database selected you’ve probably deleted said database so you can safely disable the job.
  • clip_image004

  • If you don’t understand these instructions or are confused then STOP! Disabling SQL jobs is dangerous business and can cause undesired outcomes.