Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem

SharePoint 2010: Send to -> Email a link does not work

After performing a successfully (though heavy) migration from SharePoint 2007 to 2010, end users started reporting that clicking on the action from the contextual menu linked to document/items Email a link did actually nothing.

This issue occurs because the master page that was originally designed for SharePoint 2007 did not includes the necessary control to enable this function. Simply adding the control <SharePoint:SPPageManager runat=”server” /> inside the tag <head></head> of the master page will do the trick.

Non-accidential developpers (unlike me) are certainly aware of that thanks to the following resources:

Happy migration!


Unable to Attach the Process when Debugging Server Applications in Visual Studio

Recently I was debugging custom SharePoint-based application and timer jobs. Unfortunately and although my account was member of the local administrator’s group on my development server, Visual Studio refused to attach to the process I wanted to debug throwing out the error Unable to Attach the Process. Visual Studio has insufficient privileges to debug the process. To debug this process, Visual Studio must run as an administrator to my face.

The root cause is fairly simple to find: in environments where Windows (Server) high security is a concern, the privilege Debug Programs (SeDebugPrivilege), granted by default to the Administrators built-in group, is removed in order to prevent admins from getting their hands on passwords from other users (as well as other data stored in memory) or service accounts using tools similar to LSADUMP to name juste one.

Unfortunately, the consequence of this is the inability for an administrator to attach to a program in order to debug it live. The problem is not typical to VS but to any debugging program willing to attach to a live process.

3 possible solutions/workarounds:

  • Get your security administrator to restore that privilege. This it can be done on a per computer-basis, it should not be too harmful on a dev computer
  • Run your server application with your own user account (the one you log on with). Obviously against best practices and not always possible in highly secure environment since other privileges might not be granted (log on as service, log on as batch…)
  • Try running Visual Studio through the PSEXEC tool with parameters –s –I and –a. really tricky, has some limitation and, like the workaround above, not always possible in highly secured environments…

To list the privileges your account has been granted, just use the command whoami /priv.

Additional Information’s

Happy debugging!