Boyan's blog

Hiding the ribbon in SharePoint 2010 based on permissions

Boyan Tsolov — Thu, 19 May 2011 17:48:00 GMT

Have you ever noticed how in SharePoint 2010 Owners see the ribbon and can click Site Actions, and Readers see the ribbon too but there is no Site Actions to click. In some cases there is nothing else going on up there for Readers. It is wasted real estate!

Owner:

Reader:

The Reader can use all the extra space for some website goodness!

This is easy to solve.

- Open the master page, find the div tag: <div id="s4-ribbonrow"
- Put the following around it:
<Sharepoint:SPSecurityTrimmedControl runat="server" Permissions="ManageWeb">
<div id="s4-ribbonrow" …</div>
</SharePoint:SPSecurityTrimmedControl>

Et voila!

More info here:

- http://social.technet.microsoft.com/Forums/en/sharepoint2010customization/thread/9e52de43-7941-4e61-976b-d6bf2f8d926c
- http://fusionovation.com/blogs/mbell/archive/2008/09/18/security-trimmed-controls-in-sharepoint.aspx
- http://sharepoint.smayes.com/2011/02/hiding-the-sharepoint-2010-ribbon-for-readers-a-proof-of-concept/

Load testing across different domains

Boyan Tsolov — Thu, 21 Apr 2011 16:28:00 GMT

If you are having problems collecting counters from the server when running load tests, you might want to try the following:

The domain account that you are using to run the load tests must also be added to the groups “Performance Log Users” and “Performance Monitor Users” on the server the you are testing against
If the server is on another domain you need to do a little bit more work. Try this out:
1. Create a local account on the load testing server, e.g. TestUser1 / P@ssword
2. Add this user to the groups “Performance Log Users” and “Performance Monitor Users”
3. Create the exact same local account on the load testing client, i.e. TestUser1 / P@ssword
4. Log in as TestUser1 on the load testing client and run the tests as that user
In the worst case, you will have to run perfmon on the server and create Data Collector Set that you will start/stop with your load tests

"401 unauthorized access" when server-side code or browser tries to call itself with URL

Boyan Tsolov — Thu, 27 Jan 2011 21:28:00 GMT

It all started out as a problem I got in a load-balanced environment. However, this error can occur whenever you try to browse to a server's URL from that same server, but using a different host header.

In my case, I wrote server-side code that browsed to my server through the load balancer URL, instead of the server's URL. The code would run and return "401 unauthorized access", even though I was using the admin to run this code.

I have the following load balanced setup with 2 SharePoint servers in a farm:
1. Server1: url1.imason.com
2. Server2: url2.imason.com
3. Load balancer: loadURL.imason.com

The application has server-side code that tries to get a specific file from the inetpub directory: http://loadURL.imason.com/somefile.js
using
            var WebRequestObject = (HttpWebRequest)WebRequest.Create(Url);
            WebRequestObject.Credentials = CredentialCache.DefaultCredentials;
            var Response = WebRequestObject.GetResponse();

As explained before, opening the browser on one of the two servers and browsing to the same url (http://loadURL.imason.com/somefile.js) gives the same error. However, if I open the browser on any of the two servers and I browse to http://url1.imason.com/somefile.js or http://url2.imason.com/somefile.js, then I can get the file. The problem "401 unauthorized access" occurs when the server in the load balanced environment tries to call itself using a different header (loadURL.imason.com).

This actually fails on purpose. It is a security mechanism created by Microsoft and implemented in Windows XP SP2, Server 2003 SP1 onwards to prevent reflection attacks on your computer.

To fix this, I had to (basically) disable this security mechanism (called a loopback) by disabling the loopback check on both servers in the farm.
See the Method 2 solution here:
http://support.microsoft.com/kb/896861

Forms and WSP solution deployment stuck at "Installing" or "Deploying"

Boyan Tsolov — Thu, 27 Jan 2011 21:27:00 GMT

I had been tearing my hair out with his problem, and I cannot take any credit whatsoever for the solution. I fully thank Prasanjit Mandal for his excellent blog post here http://prasanjitmandal.blogspot.com/2010/06/sharepoint-timer-job-stuck-at-deploying.html on how to solve the following problem. (Please excuse the lack of pictures, I am not able to get screenshots of the problem at this point.)

I have a load balanced, two-server SharePoint farm environment. I manually deploy InfopPath forms through central admin on this farm environment. The problem that I get is that, probably due to a mis-configuration of the farm environment, the installation/deletion of forms (i.e. WSP files) stays stuck in the "Installing" or "Deleting" stage. This problem is the same as the WSP package getting stuck in the "Deploying" stage, which the blog post by Prasanjit is about.

The reason for this is that the a timer job runs at a given interval which deploys the WSP package on server 1 and then on server 2. Each server has a timer service running which runs this timer job. The blog post by Prasanjit has very good steps on how to solve such problems (stopping the service on each server, starting it, running a command line prompt command), however I found the shortest-path to solve my problem (using Prasanjit's steps).

1. In Central Admin, delete the form or install the form (do the process which gets stuck)
2. On both servers, manually run all the timer jobs, i.e. do not wait for the timer service to run the job
3. Do this by going to your SharePoint BIN directory in command prompt, most probably it is: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN
4. Run the command stsadm -o execadmsvcjobs

The command will run all the timer jobs that are scheduled for that server, which for some reason are not running and which cause "Installing" or "Deleting" or "Deploying" to be displayed perpetually in Central Admin. In my scenario, server 2 was not running its jobs, so I had to run this command only on server 2

A drawback of this "manual force" approach is that if you open the timer jobs window in Central Admin, you will see the deployment timer job for your WSP still there...waiting to be executed; even though it never will be. I manually delete that timer job since I know I have already run it.

Thanks Prasanjit!

w3wp process is greyed out in "Attach to Process" dialog

Boyan Tsolov — Fri, 15 Oct 2010 14:04:00 GMT

If you have tried to attach to the w3wp process from Visual Studio (2008 in my case) and the w3wp process is greyed out, then I might have a solution for you.

The first link that you might want to read is this one: http://social.msdn.microsoft.com/forums/en-us/csharpide/thread/10A03A88-91D2-456F-8237-66AF5410495E
The user gleason78 complains of a very similar problem - w3wp is greyed out as soon as you start the process, or as soon as you do iisreset and the process starts up again. The solution in very general terms given to him is "another IDE had already attached itself". At first you might think... but what else could have attached itself to my process on this dev machine that only I ever use? The person that originally asked the question in that forum eventually found out that there was a "debugging service" that was running.

And that is exactly where your problem might lie (maybe someone else HAS used your machine in the past?). A debugging service running in the background will immediately attach itself to the w3wp process as soon as the process starts up.

In my case, a co-worker had been debugging something on the machine I was using. He used the Debug Diagnostic Tool http://blogs.iis.net/sukesh/archive/2006/06/02/ddintro.aspx. This tool had a service running in the background at all times, which kept attaching itself to the w3wp process, preventing me from attaching another debugger (from Visual Studio). The service was "Debug Diagnostic Service (dbgsvc.exe)".

There are no instructions here for me to show - simply make sure you go to your Services console (Start > Run > "services.msc") and stop any debugging services that may be attaching themselves to w3wp.