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

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.

The fix that Tristan Watkins describes on his blog here fixes just that.

Commands:

#Run Get-SPServiceApplicationProxy to enumerate the IDs of all the Service Application Proxies in your farm.
DisplayName          TypeName             Id
-----------          --------             --
State Service App... State Service Proxy  e51696f1-3523-4e20-9b75-578485024b37
Managed Metadata ... Managed Metadata ... 830bafcf-f0d3-4254-91e4-8cfe11840e27
Search Service Ap... Search Service Ap... a988d821-8247-4294-ba11-961b22e51f8b
Application Disco... Application Disco... af617d69-7332-49f3-a61c-0eef3f7470cf
Excel Services Ap... Excel Services Ap... b6c5b951-7b4d-4837-83f3-c916c1ef6c7d
WSS_UsageApplication Usage and Health ... 83301455-c854-4596-af5c-0bc6ee963b6d

#Copy the ID for the WSS_UsageApplication.
$UP = Get-SPServiceApplicationProxy | where {$_.ID -eq "PASTE ID HERE"}
$UP.Provision()


If you refresh the Manage Service Application page the proxy should be started now.

Anyway, here is the script I created based on the AutoSPInstaller for configuring the Search Service Application using custom database names:


$SSADB = "SharePoint_ServiceDB_SearchAdmin"
$SSAName = "Search Service Application"
$SVCAcct = "CONTOSO\the_search_service_account"
$SSI = get-spenterprisesearchserviceinstance -local

# 5.Provision Search Admin Component.
set-SPenterprisesearchadministrationcomponent -searchapplication $SearchApp -searchserviceinstance $SSI


This will just create your required databases. From this point on you can configure the required crawl / query topologies using Central Admin.