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.