Create a role to EXECUTE Stored Procedures in SQL

CREATE ROLE proc_executor
GRANT EXECUTE TO proc_executor

And then you can add users to that role.

Disable the recognition of mobile browsers

It can be done by adding the following snippet in thesystem.web section of the web.config of your Web Application:
    <result type="System.Web.Mobile.MobileCapabilities, System.Web.Mobile, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

CCS to hide borders around active web-parts.

.s4-wpActive .s4-wpTopTable {

SharePoint 2010: System.Security.Cryptography.CryptographicException – ERROR

SharePoint 2010 has a new feature which recycles the OWSTIMER.EXE process every night – similar to the application pool functionality in IIS – to avoid memory problems inside the timer service.

The recycling is controlled by a new timer job which has been added in SharePoint 2010: the “Timer Service Recycle” job which per default runs once a day at 6 AM.

While performing the recycling and shutting down the timer service the timer service runs into a problem in .NET which Tess Ferrandez has explained here.

The problem here is that the encryption key was created on a specific thread which was impersonated under a specific users account. When the .NET Finalizer processes the encryption key while the timer service shuts down it executed on a different thread which is not impersonated – so the key does not exist and you get an exception like “keyset does not exist”.

As this exception occurs in the final stages of the shutdown of the process it does not cause any harm – beside adding an event to the event log when it happens:


Eventlog Error

An unhandled exception occurred and the process was terminated.
Application ID: DefaultDomain
Process ID: 4213
Exception: System.Security.Cryptography.CryptographicException

Message: Keyset does not exist

StackTrace:    at System.Security.Cryptography.CryptographicException.ThrowCryptogaphicException(Int32 hr)
at System.Security.Cryptography.SafeProvHandle._FreeCSP(IntPtr pProvCtx)
at System.Security.Cryptography.SafeProvHandle.ReleaseHandle()
at System.Runtime.InteropServices.SafeHandle.InternalFinalize()
at System.Runtime.InteropServices.SafeHandle.Dispose(Boolean disposing)
at System.Runtime.InteropServices.SafeHandle.Finalize()

A more visible problem for a customer will occur when Visual Studio or a another JIT Debugger is installed on the affected box. In this case the following dialog will show up on the Console when the problem occurs:

Uninstalling Visual Studio will not resolve this issue as the registry settings which present this dialog are still active.

To configure the server to no longer show a dialog when an unhandled exception occurs, use the registry editor to delete the following registry keys:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger

On a 64-bit operating system also delete the following registry keys:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger

More details are at:

Pop Up in Modal SP Dialog

<a href=”javascript:OpenPopUpPage(‘/SitePages/yourpage.aspx’);”>What s NEW ?</a>

Browser Back Button History Not Working with SharePoint Managed Metadata links

Browser Back Button History Not Working with SharePoint Managed Metadata links.

A client reported user grief in that when users clicked from static hyperlinks they had put on their SharePoint team site page Content Editor Web Part, which pointed to specific nodes on a Managed Metadata treeview menu, subsequent clicks of the browsers back button would not have the normal effect of returning to them from whence they came. In fact the back button in the browser really does nothing at all.

The reason is there is a # symbol at the tail end of the URL. The # symbol is traditionally used to denote anchor tags in HTML. In modern web applications it’s commonly used in AJAX techniques .

In the particular case of links to the nodes in the left-hand managed metadata menu, those links include a tag#serverfilter  with a bunch of parameters after that that tell the web browser to go to the specific node in the menu. Unfortunately, as the client discovered, Internet Explorer and some other browsers do not handle browser history normally when navigating via the # tag. Even though you are apparently loading new page content, the browser disagrees, because you are not actually loading an entire new web page – just a dynamic portion of Javascript that is displaying new content.

An example of such a URL is below – the offending #serverfilter and the variables it delivers are bolded.


One of the biggest problems when using AJAX in web development has always been maintaining application state. In a Javascript heavy site (like SharePoint) one might want to do all sorts of things that alter the state of the user experience. For example, opening up modal dialogs (popups) over the page to request input from the user, etc. Because these state changes are occurring only with Javascript the browser is technically unaware of what is going on. If the user decides to hit the back button thinking they are just going back to before they opened a popup, they’ll be surprised when it takes them several steps backward to the last point where their browser actually made a full request. Similar issues occur when they refresh the page. The dynamic state is totally blown away and a new page request is made.

Since the basics of web navigation have always implied that a “new page” is what forms a single unit of web history, you’re not getting the back action as expected when direct linking to items in the Managed Metadata menu tree.  Unfortunately this is not a SharePoint-specific problem, it is endemic with lot’s of newer web applications online today from various vendors.

While I personally have coded workarounds for this type of problem in the past, it was for very specific, simple application scenarios (not like the huge complexity of SharePoint). In the case of out-of-the-box (mis)behavior like this I would advise simply that this unexpected back button behavior is the way it is and that users will have to adapt to selective back button history response (as they probably have on other online web applications).


Written by Keith Tuomi on. Posted in Internet ExplorerManaged MetadataSharePoint 2010



Open a new document from a word template for a SharePoint Document Library

Open a new document from a word template for a SharePoint Document Library, instead of opening the dotx file itself – as SP would normally do.
<script type="text/javascript" src="/_layouts/jquery.min.js"></script>
<script type="text/javascript">
$( function () {
$("a[href$='.dot'], a[href$='.dotx'], a[href$='.xlt'], a[href$='.xltx']").attr("onclick", "").click( function () {
saveLocation = $(this).attr("href").split("/").slice(0, -2).join("/")
createNewDocumentWithProgID(window.location.protocol + '//' + + $(this).attr("href"), window.location.protocol + '//' + + saveLocation, 'SharePoint.OpenDocuments', false)
return false
As always when we are working with jQuery you have to make sure that you reference the location of that .js-file
I got it from
 <script src="//"></script>