As it appears IIS 7 blocks access to urls where /bin/ is present in the Url.

The solution to this problem is to rename the site collection or remove the exception in the web.config of your web application as suggested by Russ.

I prefer the web.config approach on the web application level by adding the following section:

<?xml version="1.0"?>
<configuration>
 <system.webServer>
   <security>
    <requestFiltering>
     <hiddenSegments>
      <remove segment="bin" />
     </hiddenSegments>
    </requestFiltering>
   </security>
  </system.webServer>
 </configuration>

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.

just wanted to point out a very good article that sums up all you need to know about Host Named site collectiosn in SharePoint 2010.

Find the original article by Kirk Evans at

http://blogs.msdn.com/b/kaevans/archive/2012/03/27/what-every-sharepoint-admin-needs-to-know-about-host-named-site-collections.aspx

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

According to the Technet article I needed to execute the following Powershell scripts:

$site = Get-SPSite "<VariationURL>"
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Add("DisableAutomaticPropagation", $true)
$folder.Update()
$site.Close()

Unfortunately it didn’t work. for some reason the $folder variable was null
error message was:
You cannot call a method on a null-valued expression.
At line:1 char:23
+ $folder.Properties.Add <<<< ("DisableAutomaticPropagation", $true)
+ CategoryInfo : InvalidOperation: (Add:String) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull

after a little bit of looking around in powershell I did come up with a workaround by loading the Relationships list in a separate variable, changing the script as follows:

$site = Get-SPSite "<VariationURL>"
$list = $site.RootWeb.GetList("Relationships List")
$folder = $list.RootFolder
$folder.Properties.Add("DisableAutomaticPropagation", $true)
$folder.Update()
$site.Close()

Hope this helps someone out

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.

just a quick post with a simple command. I needed to update all the Default Time zone settings for all the web applications in a SharePoint 2010 farm.

Here’s how to do it in a single command:
Get-SPWebApplication |Foreach-Object { $_.DefaultTimeZone = 3 ; $_.Update() }

The value 3 stands for the time zone (UTC +01:00) Brussels, Copenhagen, Madrid, Paris

Sven Häfker’s post:
Fix: Unable to activate worker process proxy object within the worker process
Issue:
We have encountered an issue that the Sandbox Worker Process (SPUCHostService.exe) of SharePoint 2010 wasn’t able to initialize itself on several servers. As a result Sandboxed Solutions couldn’t be used. We’ve found the following entries in the SharePoint ULS:

- Unable to activate worker process proxy object within the worker process: ipc://1787a8e0-45c3-48dc-9b3c-a60e8b4d6199:7000

- Error activating the worker process manager instance within the worker process.- Inner Exception: System.InvalidOperationException: Unable to activate worker processproxy object within the worker process: ipc://1787a8e0-45c3-48dc-9b3c-a60e8b4d6199:7000 at Microsoft.SharePoint.UserCode.SPUserCodeWorkerProcess.CreateWorkerProcessProxies() – Process creation/initialization threw an exception. Stopping this process.
“ipc://aec755bf-3ac8-4c2e-b5a4-9198b1bf027e:7000″ – Stopping shim process. Shim process name: “SPUCWorkerProcess” Shim PID: “0×1868″
Shim service url: “ipc://aec755bf-3ac8-4c2e-b5a4-9198b1bf027e:7000″ – Stopping proxy process. Proxy process name: “SPUCWorkerProcessProxy” Proxy PID:
“0x0AB0″ Proxy service url: “ipc://1787a8e0-45c3-48dc-9b3c-a60e8b4d6199:7000″ – Error activating the worker process manager instance within the worker process.

- Starting worker process threw – Inner Exception: System.InvalidOperationException: Unable to activate worker process proxy object within the worker process: ipc://1787a8e0-45c3-48dc-9b3c-a60e8b4d6199:7000 at Microsoft.SharePoint.UserCode.SPUserCodeWorkerProcess.CreateWorkerProcessProxies() – CreateSandBoxedProcessWorker() is called
- Created desktop: Service-0×0-2bea3589$\Microsoft Office Isolated Environment

Fix:
After trying to fix the issue for several hours, we tried to disable the “Check for publisher’s certificate revocation”-setting for the Service Account of the Sandbox and this solved the issue. You can do this by changing the following key in the registry:

HKEY_USERS\[SID OF THE SERVICE ACCOUNT]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing
The value of “State” needs to be set to “0x00023e00″.

You can get the SID of the Service Account with PowerShell:

$(Get-SPManagedAccount -Identity “THE SERVICE ACCOUNT”).Sid.Value

I found the solution to this issue on the SharePoint forum here

This happens when you have the Usage and Health Data Collection Service Application installed. This service application creates a database just for logging. Apparently the Search Service was trying to make entries in that database and couldn’t.

The solution to this issue is to enable the Usage Data Collection, which is not enabled by default when you create the Usage and Health Data Collection Service Application .

To enable the Usage Data Collection navigate to Central Admin\Application Management\Service Applications\Manage service applications. Once there highlight the WSS_UsageApplication (or whatever name you gave the service application)and select manage from the ribbon. Under Usage Data Collection check the box. Under Health Data Collection check the Enable health data collection box. Hit OK and the errors will be gone.

One of those errors in there is the following:

Title Missing server side dependencies.
Severity 1 – Error
Category Configuration
Explanation [MissingWebPart] WebPart class [8d6034c4-a416-e535-281a-6b714894e1aa] is referenced [2] times in the database [SP2010_ContentDB_CentralAdmin], but is not installed on the current farm. Please install any feature/solution which contains this web part. One or more web parts are referenced in the database [SP2010_ContentDB_CentralAdmin], but are not installed on the current farm. Please install any feature or solution which contains these web parts.

To get rid of this error you simply need to configure the SharePoint Foundation Search service though the Central Admin – Services on Server page on one of the servers in the farm.

Once this is configured, the error will go away.

UPDATE: on one of my other farms I noticed this error and configured the SharePoint Foundation Search service (which oddly enough once configured, changes its name to SharePoint Foundation Help Search)

a little more research and some Google results later I found an answer to this problem posted on the technet forums by John D Palm stating:
“This error will appear on a cleanly installed system in the Health Analyzer Reports until you visit the following pages:

Browse to them and the error will no longer appear in the Health Analyzer Report.”

I followed John’s advise and indeed the error went away just after having visited both these pages and hitting the Reanalyze now button on the alert.

So there you go