14 and 15 hives, and upgrade solution/features

 

This must not be new and I seem have done this at least once back February, because for the master page in question, I have the same file dated back in February both in the 14 and 15 hives.

But I have forgot completely what I did back then, and spent the entire morning just to update the same master page file. So this time, I write here what I learnt (again) today, so it would be clearer what to do for the next time.

The conclusion first. I need to run this cmdlet:
Install-SPSolution -Identity (the solution file name) –WebApplication (web application name) -FullTrustBinDeployment -CompatibilityLevel All –Force

We are operating a site that we have upgraded from 2010 (we started with 2007 actually). Therefore (I do not know now if it was THE way to go but), FEATUREs that we have been using from the time of 2010 including this master page that I wanted to update today, reside in the two hives.

For FEATUREs that I need to update since the upgrade to SP2013, I have specified SharePointProductVersion="15.0" in their solution manifest, and run simply stsadm –o upgradesolution (I prefer STSADM to PowerShell). They are correctly updated. We have got what we want in the effect.

Today, however, I found one shortcoming (I must have in February too), which is that the ghosted image of the master page that you see in SharePoint Designer stays as it was before i.e. not updated.

First I thought it is probably due to the cache, but at the end concluded that SPD looks into the 14 hives rather than 15. When I update the file in the 14 hive as well as 15, with the above cmdlet, you see properly the updated image in SPD.

I think this is absurd. I do not see any logic. But it appears to be the way it works...

Network share on server 2008 R2 cannot be opened from XP

 

http://panerarichang.blogspot.ch/2012/01/tip-cname-windows-server-2008-r2-x.html

I found this post very useful, after many many not useful ones which, first of all do not explain the reason and just blindly propose solutions.

Some might find my own experience useful. I found the registry key already set, but the problem was always there. XP clients cannot open the share. I removed it and put it back. Then the issue is removed.

The above post explains that that is the solution, with the reason very clearly explained. Otherwise, I would not have tried the remove/add-again solution.

WSS_KeepSessionAuthenticated

As becoming the de-fact, when asking users to authenticate, we change i.e. redirect to SSL. But then, if he/she opens another browser window and comes to us on http, to view two pages from our site simultaneously, on the second windows, he/she goes back anonymous. He/She has authenticated on the SSL i.e. https session, but not on http.

We first implemented this mechanism on SharePoint 2007. We may have wanted to redirect the second session to SSL so that the user finds himself logged-in on both windows. But due to some technical constraint not really of SharePoint, it was not that straightforward.

Anyway, this is how we started.

Then, when upgraded to 2010, we saw that the user is asked for username/password on the second session, even though the page that he is trying to open is anonymously accessible. After some research, we found out that this seems due to the WSS_KeepSessionAuthenticated cookie, that is sent. SharePoint forces the user to authenticate when it finds the cookie in the request.

To overcome, we created and hooked up a HttpModule to clear it at the beginning of the request made on http. It is an acceptable workaround for us, because we do not ask users to send their passwords as clear text.

Today, I found out that it is no longer needed with SharePoint 2013. The problem was that with SP2010, the cookie was set as non-secure. It is set when the user authenticates, and sent back to the server whether the session is secure or not. While with SP2013, it is set as secure when authenticated on https, and is sent back only when the communication is secured i.e. on SSL.

SharePoint2013 migration resetting master page references

If I am not wrong, it does, isn’t it?

Actually, it is not new. It did so when migrating to 2010 also. It changed master page reference of all sites to v4.master. I wrote a code to reset them back to our custom master. Needless to say that, before doing that, the custom master needed to be adapted. I needed the code to do this, because, even with sites where you see the master page reference is inherited from its parent, the effective master page became to v4.master.

I did not think it a big flaw at that time, but now think it is. What if for a legitimate reason, an organization employs several masters for their public facing web site, say for instance, employing different brandings for different products, champagnes etc.? Once upgraded, you do not know any more which site was on which master.

If SharePoint does not allow such an arrangement i.e. employing different master page for different sites, then OK. We would not complain. But it does allow, even encourages you, and says NO you cannot, all the sudden, when a new version comes out.

I did some googling, to find out that not so many seem concerned. Is this the sign that it has never gained enough popularity in the public facing web sites market? Where obviously branding is one of the most important aspects.

'premature end of script headers' in Apache

This is just a good-to-remember for myself.

When Apache reports this error with your CGI program, a script most of the case, you need to understand, or to know what the error message means, or what Apache complains about. Which I found many posts that I came across talking about the error do not really explain.

As you know, output of any CGI program must take the following form.

HEADERs
e.g. Content-type: text/html

A blank line

The payload. Normally a <HTML> element.

Apache complains with the message that the output fails to take the form.

Luckily, for the Perl script that I had the problem with, it was rather easy to locate and eventually remove the issue.

This was the good reference. http://www.linuxjournal.com/article/1367 It explains how to run a Perl CGI script from the command-line.

The point is that when you run it, it waits for input, for any possible POST payload. You indicate the end of the input with a control+D. Then it runs and you can see the output on your terminal. Once you get it, locating the issue should be (normally) straightforward.

In my case, the issue turned out that an external executable called from the script ends abnormally, and therefore corrupts the output.

Horizontal scroll bar does not appear

This is about an issue that we had with our public facing web site master page. That the horizontal scroll bar does not show, when it should, that is, when the page width is bigger than that of the browser window displaying it. Interestingly, it comes when you scroll down to the bottom of the page.

I did not know that SharePoint 2010 implements the scroll bars with some JavaScript so they enclose the s4-workspace div, not the body element, including the “ribbon”. And we had the above issue because I did the master page in such a way that it does not have the ribbon when the pages are viewed by the visitors.

I am sure that it is a requirement for everybody who do their public facing sites on SharePoint 2010. We need to get rid of the ribbon when the pages are consumed, while we do need it when we prepare them.

At the very early stage (with SP2007), I achieved it by denying any write on the internet zone. The Sites Action menu was not presented, if I remember well. Then soon enough, I needed to come up a different mechanism, because the site does need to be writable in certain cases such as a feedback form. I wrote a control, and with which I enclose the ribbon so that the ribbon is not rendered on the internet zone. This “not rendered” was the cause of the issue.

It appears that when SharePoint JavaScript displays the horizontal scroll bar at the bottom of the window, it positions it vertically from the ribbon. Therefore, when it does not find the ribbon, the starting point, it displays it only at the very bottom of the page, where s4-workspace div ends.

I have overcome it by hiding the ribbon i.e. style="display:none;" rather than being not rendered.

Hope it helps.

References:
- Starter Master Page: http://archive.msdn.microsoft.com/odcSP14StarterMaster
- A useful JavaScript trick: http://blog.pixelmill.com/944/sharepoint-2010-%E2%80%93-adding-a-fixed-footer-to-your-sharepoint-master-page/

variationsfixuptool

I got this error message.

The attempted operation is prohibited because it exceeds the list view threshold enforced by the administrator.

Luckily, I was able to identify the issue.

I knew the Variation uses the “Relationships List” List at the (variation or web app?) root. I looked at the list settings. It shows:

We could increase the threshold for the Web Application in Central Administration, Web Applications Management, Manage Web Applications, General Settings, Resource Throttling.

But what does the variationsfixuptool try to do with this list and reports the error due to this threshold?

With the –scan switch, after scanning the integrity of the specified subsite and reporting the result, it displays the entire “Relationships List”, which seems useless to me.

For the moment, I have not yet tried the –fix switch, thus do not know whether hitting the threshold prevents it from functioning properly when it tries to correct the integrity. Will see and write here again.