WSUS Not Downloading Updates

During a recent WSUS upgrade from an old server to a new virtual machine running Windows Server 2008 R2, I saw an issue with the server not downloading updates correctly. The server appeared to synchronise correctly, but then no updates were downloaded.

We originally saw an issue like this when we started using Microsoft Threat Management Gateway, and the errors reported in the application event log on the new WSUS server were the same, namely:

Error 10032: The server is failing to download some updates

Error 364: Content file download failed. Reason: The server does not support the necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that the server support the Range protocol header.

Microsoft KB article 922330 provides a solution for this specific issue, in our case we’re using a pre-existing SQL Server, so went with

"%programfiles%\Update Services\Setup\ExecuteSQL.exe" -S %Computername% -d "SUSDB" -Q "update tbConfigurationC set BitsDownloadPriorityForeground=1"

However this didn’t solve the issue.

In our case, the existing instance of SQL was on another server, so the command should have been:

"%programfiles%\Update Services\Setup\ExecuteSQL.exe" -S SQLServerName\Instance -d "SUSDB" -Q "update tbConfigurationC set BitsDownloadPriorityForeground=1"

Once the revised command had been run and the WSUS server restarted, the update downloads started automatically.

CRM 2011 Update Rollup 6 (and beyond) timeout

On an instance of CRM 2011 that was being patched to Update Rollup 6 prior to patching to Update Rollup 8, the following error occurred:

System.Exception: Action Microsoft.Crm.Setup.Common.Update.DBUpdateAction failed. —> System.Data.SqlClient.SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.

The error was displayed as both a dialog on screen, and within the log file, KB2600640.log located at %APPDATA%\Microsoft\MSCRM\Logs

The solution was to raise the timeout that CRM applied for OLEDB connections from the original 30 seconds by creating two new registry keys at HKLM\SOFTWARE\Microsoft\MSCRM:

OLEDBTimeout (DWORD), value 86400 (decimal)
ExtendedTimeout (DWORD), value 1000000 (decimal)

Then restart the CRM application pool within IIS.

Once the new settings were in place, the upgrade proceeded normally.

Renaming the PerformancePoint Service Application database in SharePoint 2010

When creating the PerformancePoint Service Application, there is no way to control the name of the database that is created, not even when using PowerShell to create the Service Application. The database that gets created is in the form

<Service Application Name>_GUID

which for some reason a good many DBAs are not too keen on!

The database can however be renamed by following these steps:

  • Stop the PerformancePoint service on all SharePoint servers in the farm that are running the service using the ‘services on servers’ area of Central Administration:
    Stopping the PerformancePoint Service
  • Rename the database and log file – there are two ways of completing this; I prefer the second option of the two outlined below as it completely renames all of the references to the database, but it is a more involved process:
    1. Open SQL Server Management Studio on the SQL Server for the farm.
      Select the PerformancePoint Service Application database and then click again to allow renaming:
      Rename PerformancePoint DB in GUI
      Rename the database to match the naming convention you wish to use for farm databases. Note that this only renames the database friendly name as shown in SQL Server Management Studio and not the file names or the logical database and log file names.
    2. Alternatively:
      Open SQL Server Management Studio on the SQL Server for the farm.
      If you wish to, you can change the recovery mode of the PerformancePoint database to ‘simple’; this saves having to backup and restore a log file as well as the database file.
      Backup the PerformancePoint database created during the Service Application creation process.
      Restore the PerformancePoint database from the backup completed to a new database name which matches the naming convention you wish to use for farm databases. Note that the default naming convention for the log files on restore appends ‘_1’ to the database name to form the log file name; you may wish to change this to ‘_log’ to match the other log files that the database server hosts. The backup and restore will change the filenames used for the databases and the display name shown in SQL Server Management Studio, but not the logical database names. To change the logical database names, first find the logical names of the database and log for the database you wish to change; you can find this information either by taking note of the original database name when it was created, or from the ‘files’ section of the database properties screen within SQL Server Management Studio:
      Database Logical Names
      Execute the following two SQL queries:

      ALTER DATABASE <new PerformancePoint database name> MODIFY FILE (NAME="<original logical database name>", NEWNAME="<new PerformancePoint database name>")

      ALTER DATABASE <new PerformancePoint database name> MODIFY FILE (NAME="<original logical log file name>", NEWNAME="<new PerformancePoint database name>_log")

      If you changed the database recovery mode to ‘simple’, change it back to ‘full’.

  • On one of the SharePoint servers in the farm, open an instance of the SharePoint 2010 Management Shell, ensuring that it is run as administrator and issue the following PowerShell Commands:

    $newdatabasename = "<new PerformancePoint database name>"
    Set-SPPerformancePointServiceApplication -Identity "<name of the PerformancePoint Service Application>" -SettingsDatabase $newdatabasename

  • Restart the PerformancePoint service on the servers in the farm it was running on originally.
  • Delete the original PerformancePoint database that was created during the Service Application creation from SQL Server Management Studio.

Cannot remove folder “SharePoint site name”

I recently ran into this issue while trying to move a series of sub-sites to site collections on a SharePoint farm. In order to achieve part of the process, I’d scripted the deletion of the sub-site tree using the stsadm –o deleteweb command once I’d exported it as there were quite a number of sub-sites and I wanted to try and save a little time.

I’d see the error message ‘cannot remove folder “sub-site name”’ for a couple of the sub-sites at a particular level, then the next couple might well be removed correctly, then more ‘cannot remove…’ errors.

To diagnose the issue a little more, I tried using the alternate options for the deleteweb stsadm command, namely

stsadm –o deleteweb –webid <sub-site ID> –databasename <content web application DB name> –databaseserver <DB server> -force

Note: To find a list of the sub-site IDs, run the following command:
stsadm –o enumallwebs –databasename <content web application DB name>
This will produce a list of all of the sub-sites including their URL and ID

Using the alternate options for the deleteweb stsadm command provided me with a lot more information on what the issue was that was stopping me from deleting some of the sub-sites.  In may case, the error shown was ‘The transaction log for database <DB name> is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases’.

Checking the autogrowth options for the log file for the content database in question did indeed show that the file size was limited to quite a small value. Increasing the autogrowth limit on the transaction log to a more reasonable size immediately got me up and running again.

Manually removing a SQL Reporting Services instance from a scale out deployment

If you need to remove an instance of SQL Reporting Services from a scale out deployment, but for some reason cannot contact the instance you wish to remove (e.g. the computer has failed or been rebuilt without removing it from the scale out deployment first) you can do this manually from one of the other computers in the scale out deployment by following these steps:

  • To list the announced report servers currently in the database:
    RSKeyMgmt –l
  • This will provide you with a list in the format
    MachineName\Instance – <GUID of the instance>
    Note the GUID of the instance you wish to remove
  • To remove the instance of SQL Reporting Services:
    RSKeyMgmt –r <GUID of the instance noted above>
  • You will be asked to confirm that you wish delete the key you have entered.

Note that RSKeyMgmt.exe is located in C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\ on a 64-bit SQL 2008 Reporting Services instance.

“Access is Denied” when crawling content on MOSS 2007 hosted on Windows Server 2008

One of the SharePoint farms we’ve built recently runs on Windows Server 2008  and SQL Server 2008.  As usual, the installation is a least privileged account setup, with individual accounts running the various services and app pools. The farm is also patched to the latest level.

We’ve experienced one or two issues with this setup, but the most persistent one has been to do with crawling.  When crawls run, they would consistently fail with the following error in the Event viewer:

“The start address <https://site.domain.com> cannot be crawled.

Context: Application ‘SharedServices1’, Catalog ‘Portal_Content’

Details:
    Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content.   (0x80041205)”

In addition, the following error appeared in the SharePoint logs:

***** Couldn’t retrieve server https://site.domain.com policy, hr = 80041205 – File:d:\office\source\search\search\gather\protocols\sts3\sts3util.cxx Line:548

And the crawl logs showed only errors, each having the following description:

“Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify the account you are using has “Full Read” permissions on the SharePoint Web Application being crawled.(The item was deleted because it was either not found or the crawler was denied access to it.)”

We’d checked all of the usual suspects including web application permissions for the account used by search, database permissions etc with no success.

The solution was to disable the loopback check on the servers hosting SharePoint. Adding the hostnames served to the BackConnectionHostNames list in the registry on the SharePoint servers wasn’t enough, the loopback check had to be completely disabled.

As an aside, another issue we’d experienced with an InfoPath form with code behind failing to load correctly on these servers was also solved disabling the loopback check on these servers.

For instructions on disabling the loopback check, see KB896861.