SharePoint 2013 Login as a different user

Exciting days with the release of SharePoint 2013 beta. First thing i noticed on a setup on one of my servers, is that you do no longer see the option to sign in as a different user. Apparently the link is either missing or has willingly been removed from the UI. A little comparison with a SP2010 environment shows that the actual link for signing in as a different user is /_layouts/closeConnection.aspx?loginasanotheruser=true.

Fortunately the link still works in SP2013, which might make me believe that the link has just been forgotten adn will probably be back in the RTM release. If not, I guess the very first customization a lot of customers will ask for is to have the button back in the User menu.

How to change the language of a site in SP2010

Notice: the information in this post is not supported by Microsoft. The use of the method described below will revoke your support status for your environment. Use at your own risk

This question came up today and I remembered being able to change this for MOSS by changing the content database so I wondered if it would still work in SP2010.

Well, actually it does ….

The article I used as a source for MOSS can be found at http://sharepointlearn.blogspot.com/2008/12/changing-language-of-existing.html

the only change to the original article is that the Table name has changed in SP2010. Here is the updated information:

The language of the site is stored at SP Web level. It is stored in database in the AllWebs table. So you need to change the language in database whatever language you want. To change the language in database you need to fire following Query:

For changing the language of all sites in to ‘Dutch’ language:
UPDATE dbo.AllWebs SET Language = 1043

Changing the language of one site collection: (Dutch language)
UPDATE dbo.AllWebs SET Language = 1043 WHERE SiteId = [[SiteCollectionId]]

Changing the language of a single web or subsite: (Dutch language)
UPDATE dbo.AllWebs SET Language = 1043 WHERE Id = [[WebId]]

Note:
Before applying the new language, you need to verify that the language pack for the language that you want to apply is installed on your machine or not.

Cumulative updates packaging changed for SharePoint 2010

while browsing the updates page on Technet I found:

The packaging of cumulative updates changed as of August 31, 2011. The following packages are provided for cumulative updates:
• SharePoint Foundation 2010
• SharePoint Foundation 2010 + SharePoint Server 2010
• SharePoint Foundation 2010 + SharePoint Server 2010 + Project Server 2010
As a result of the new packaging, it is no longer necessary to install the SharePoint Foundation cumulative update and then install the SharePoint Server cumulative update.

Source: http://technet.microsoft.com/en-us/sharepoint/ff800847

Remove HTTP Response Headers for internet facing SharePoint sites

if you are serious about to publish an internet facing SharePoint site you have to consider security. One of the first things a possible hacker will inspect are the HTTP Response Headers. I usually use the Firefox Developper toolbar to check the HTTP Response Headers of my SharePoint sites. (Information Menu -> View Response Headers)

Without cleaning the reponse headers you will see something like:

Connection: Keep-Alive
Expires: Mon, 23 May 2011 13:56:12 GMT
Date: Tue, 07 Jun 2011 13:56:13 GMT
Content-Type: text/html; charset=utf-8
<strong>Server: Microsoft-IIS/7.5</strong>
Cache-Control: private, max-age=0
Last-Modified: Tue, 07 Jun 2011 13:56:12 GMT
<strong>SPRequestGuid: 2ba6c04a-f3ca-40be-a543-7fb2448bd92e
X-SharePointHealthScore: 0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 14.0.0.5130</strong>
Transfer-Encoding: chunked
Content-Encoding: gzip
Vary: Accept-Encoding

200 OK

Now, what I needed removing was all the SharePoint stuff, the ASP.NET stuff and the server information (marked in bold). Luckily I was not the first guy out there to do so and I used Stefan Goßner’s post (http://blogs.technet.com/b/stefan_gossner/archive/2008/03/12/iis-7-how-to-send-a-custom-server-http-header.aspx) as a lead to achieve what I wanted.

I ended up creating a custom HttpModule for removing the excess information in combination with adding a section to the web.config for the custom Headers added by SharePoint as they were not removed by the HttpModule after my initial testing.

Actions performed:
1. Create a folder named App_Code in the IIS folder of the SharePoint site where the headers need to be removed
2. Create a file with notepad named CustomHttpModule.cs
3. Edit with notepad:

using System;
using System.Text;
using System.Web; 

namespace Custom.ServerModules
{
  public class CustomHttpHeaderModule : IHttpModule
  {
    public void Init(HttpApplication context)
    {
      context.PreSendRequestHeaders += OnPreSendRequestHeaders;
    }
    public void Dispose()
    {
    }
    void OnPreSendRequestHeaders(object sender, EventArgs e)
    {
      HttpContext.Current.Response.Headers.Remove("Server");
      HttpContext.Current.Response.Headers.Remove("X-AspNet-Version");
      HttpContext.Current.Response.Headers.Remove("X-SharePointHealthScore");
      HttpContext.Current.Response.Headers.Remove("SPRequestGuid");
    }
 }
}

4. Save the file
5. Edit the web.config file of the SharePoint web application
- Add the custom module to the section system.webserver
- have the custom headers removed

<system.webServer>
  <modules runAllManagedModulesForAllRequests="true">
    ...
    <add name="CustomHttpModule" type="Custom.ServerModules.CustomHttpHeaderModule" />
  </modules>
  ...
  <httpProtocol>
    <customHeaders>
      <remove name="MicrosoftSharePointTeamServices" />
      <remove name="X-Powered-By" />
    </customHeaders>
  </httpProtocol>
</system.webserver>

One remark though if you implement this. Removing the header MicrosoftSharePointTeamServices may break your search crawling. In my case I usually dedicate a web front end for crawling or have the Web application role activated on the crawler. Evidently this web front end does not get the custom httpmodule.

Where is the RSS Viewer web part in SP 2010?

Like everything in SharePoint why make things simple if you can make it hard :)

Turns out that if you want the RSS Viewer webpart, you need to activate the “SharePoint Server Standard Site Collection features” feature in your site collection first.

Took me about 10 minutes of snooping around in the Web part gallery and trying ta add a new one, before I figured that one out.

Thanks to Craig Lussier for answering this exact question on the Technet Forum.

Rename SharePoint 2010 Central Admin database

I had a post on this for SharePoint 2007 and needed to do the same thing for SharePoint 2010, but wanted to do this the powershell way instead of the stsadm way I used for MOSS. Not sure if that would even work…

turns out I didn’t need to reinvent the weel as Todd Klindt has already blogged about this here

The trick to all this is that for moving all site collections in a content database you would execute Get-SPSite with -contentdatabase parameter to get all the site collections for that content database and then pipe that to a Move-SpSite command. With the Central Admin content database the only way to get the site collections is to specify the GUID of the contentdatabase instead of the database name

In short, here are the commands:


#Create a new Content Database
New-SPContentDatabase -Name SharePoint_CentralAdmin -WebApplication http://sp2010:1000
#Get the Database GUIDs
get-spcontentdatabase -webapplication http://sp2010:1000
Id: d3d04cb1-b919-4262-b2d7-46733ef2c5df
Name : SharePoint_AdminContent_81476219-04f5-46b8-807f-31aa4afb4056
WebApplication : SPAdministrationWebApplication
Server : SP2010-DB
CurrentSiteCount : 2

Id : d8647aed-ef42-4052-814b-670b36fb8c1e
Name : SharePoint_CentralAdmin
WebApplication : SPAdministrationWebApplication
Server : SP2010-DB
CurrentSiteCount : 0

#Move the site collections
Get-SPSite -ContentDatabase d3d04cb1-b919-4262-b2d7-46733ef2c5df | Move-SPSite -DestinationDatabase d8647aed-ef42-4052-814b-670b36fb8c1e

Now do an IISRESET and check that the Central Admin site renders properly. If it does you can safely remove the content database with the GUID in it. Since I check the Central Admin site, I just delete the content database with the GUID from within the Central Admin Site

SharePoint 2010 gradual upgrade approach using ISA server

Now first a little remark about this post: This post will not handle the actual upgrade from MOSS 2007 to SP2010. It will only provide a possible method to use when you are considering to gradually upgrade specific web applications, meaning that you actually want to have the same web application with the same hostheader available on MOSS 2007 and SP2010 and redirect your users to the correct farm depending on the site collection they target.

I have been doing some brainstorming with regards to an upcoming SharePoint 2007 to SharePoint 2010 migration for one of my customers. I have had my fair deal of upgrading from SharePoint 2003 to MOSS 2007 using the gradual upgrade approach that was built-in into MOSS 2007.  

In that scenario you were able to use the URL redirection feature of MOSS. In short you could alter your DNS settings for your web application to point to your MOSS farm and then MOSS would determine if the specific site collection the user was targeting had already been upgraded and if not MOSS would redirect the user to the old SharePoint 2003 site using an alternative URL. This scenario causes a lot of confusion with your users that are accessing sites that have not been upgraded because they would start seeing your alternative url. For example: your original url was teamsites.contoso.com. Once you activated the gradual upgrade of a that specific web application, all your users would start targeting the MOSS farm and then be redirected to the alternative url which could be something like old-teamsites.contoso.com or teamsites.contoso.com:8080

In SharePoint 2010 there is still a way to use this alterantive url redirection as described in the “Using AAM URL redirection as part of the upgrade process (SharePoint Server 2010) white paper”

Now my customer asked me for a way to do it without an alternative url and simply use the same url and depending on the targeted site collection be redirected to either MOSS 2007 or SP2010. This got me thinking that it would certainly not be feasible using only DNS. The alternative url redirection feature was not an option, so I needed something that can handle such logic. This brought me to my good friend ISA server (more specifically ISA 2006)

Let me explain using a small scenario:

MOSS 2007 Farm
- Web application: teamsites.contoso.com
- site collection: /sites/siteA

SP2010 Farm
- Web application: teamsites.contoso.com
- site collection: /sites/siteB

Now there is no way that you can have your users access teamsites.contoso.com/sites/siteA and teamsites.contoso.com/sites/siteB if you are just going to use a DNS entry. To which farm would you have it pointed? The user would only be able to access one of these two sites.

What if you have the DNS entry pointed to an ISA server? Could you configure ISA to analaze the incoming request and redirect the users to the correct farm? The answer is Yes !

In ISA 2006 you can create a publishing rule for publishing a SharePoint site. With a publishing rule you can accept incoming hostnames and redirect that to a specific computer or IP address. Now in addition to that you can specify the paths that a rule should respond to.

So for this solution to work you would create 2 Publishing rules :

- 1 publishing rule publishing the web application teamsites.contoso.com towards the SP2010 farm using the IP address of the SP2010 WFE or using load balancer Virtual IP address of the WFE Servers. On the Paths tab for the rule, remove the /* path and add the path /sites/siteB/* path

- 1 publishing rule publishing the web application teamsites.contoso.com towards the MOSS 2007 farm  using the IP address of the MOSS 2007 WFE or using load balancer Virtual IP address of the WFE Servers. On the Paths tab for the rule, remove the /* path and add the path /sites/siteA/* path

Apply the new rules and that should do it.

With this in place you can easily plan the upgrade of all the individual site collection one by one if you want and let your users work transparently throughout your migration period with the same url they are used too.

Now I have tested this scneario and it actually does work. I also must admit that I have not tested this scenario very thoughly yet and that there mey be some catches, but hey it’s the idea that I want to pass you on

 

Document your SP2010 Farm configuration

I was passed a link today by Thomas Vochten, that leads to a Technet Article containing a pretty neat Powershell script for documenting a SharePoint 2010 farm configuration.

The script will output several XML files containing specifi farm configuration settings. Ideally you could have a single XML file created on a daily basis and windiff the files to check for any changes in the farm.

Find the original article on http://technet.microsoft.com/en-us/library/ff645391(office.14).aspx

 

SharePoint 2010 Knowledgde articles

So you took the step of installing your first SharePoint 2010 server or farm. You install the server, but not everything goes smoothly or doesn’t work as expected. What’s next? Well, a good place to start is to use the knowledge base that Microsoft tools use, such as the System Center Operations Center (SCOM) Knowledge articles. These are the articles that typically show up in SCOM, provided that you have installed the SharePoint 2010 Management pack,  if it has encountered an error on your SharePoint installation or farm.

The knowledge articles can be found at http://technet.microsoft.com/en-us/library/ee513133(office.14).aspx

Thanks to Neil Hodgkinson (@Nellymo) for providing this tip and link on Twitter