Installation Failure: Windows failed to install the following update with error 0x80070643: Windows Server 2008 R2 Service Pack 1 x64 Edition (KB976932). Другие обновления также могут не устанавливаться.

Для диагностики и исправление проблем с обновлениями на Windows 7 и Windows 2008 (R2) замечательно подходит утилита System Update Readiness Tool. При запуске утилита однократно сканирует систему и помещает лог в %windir%\logs\cbs. Из лога можно понять, какие файлы были повреждены, какие исправлены и какие исправить не получилось. В последнем случае можно легко перетащить поврежденные файлы с другого компьютера.

Источник: http://social.technet.microsoft.com/Forums/en-US/winserverwsus/thread/3a1a9428-e004-424e-bd1f-849146939de7/

Миграция отчетов в SSRS (Migrate SSRS reports)

Совершенно замечательное приложение, чтобы мигрировать репорты с одного сервера на другой, выгрузить/загрузить их кучей и т.д. - RSScripter:

http://www.sqldbatips.com/showarticle.asp?ID=62

Jasper Smith, thank you!

SQL Server Integration Services (SSIS) запускает SQLDUMPER.EXE и виснет во время выполнения пакета.

Эта проблема возникла у меня почему-то только на Windows7 (на XP все работало нормально). Во время отладки SSIS package на мгновение появлялось DOS-окошко с SQLDUMPER, после чего задачи в Business Intelligence Development Studio оставались желтенькими, но никогда не завершались. Решение этой проблемы такое же странное, как и она сама - надо выключить службу SQL Server VSS Writer.

Источник: http://discussions.virtualdr.com/showthread.php?t=220983

ADODB.Recordset error '800a0e78' Operation is not allowed when the object is closed.

У меня это случилось при миграции старого веб-приложения (ASP) на новый веб и сиквел сервер. Были изменены параметры подключения (с ODBC на OLE DB). Приложение подключалось к базе данных, SQL Profiler показывал, что команды исполняются, однако часть кода

set objDBConnection = Server.CreateObject("ADODB.Connection")
Set objRs = Server.CreateObject( "ADODB.RecordSet")
objDbConnection.Open(ConnectionString)
objRs.Execute("EXEC someStoredProcedure")

возвращало закрытый объект objRs и ошибку ADODB.Recordset error '800a0e78' , чего не случалось до миграции.
Немножко поковырявшись и погуглив, нашел следующее: вызовы stored procedures, сделанные через ODBC не возвращают "(x) rows affected", а OLE DB - возвращают. Соответственно, встретив эту строчку в ответе, OLE DB неверно интерпретирует ее как отсутствие данных и закрывает объект. Починить это можно двумя способами - поставив SET NOCOUNT ON вначале кода stored procedure (более правильный способ) или включив no count глобально на уровне сервера (на уровне базы данных, к сожалению, этого не сделать).
В связи с этим приходит следующая мысль: обязательное использование SET NOCOUNT ON в начале кода stored procedure - это хороший тон.

Источник: http://tutorials.aspfaq.com/8000xxxxx-errors/why-do-i-get-800a0cc1-errors.html

SQL Server Management Studio at x64 platform ('System.OutOfMemoryException', memory leaks, etc.)

Не успел я порадоваться на свой новый лэптоп (Elitebook 8540w, 8GB RAM), как заметил, что SSMS ведет там себя очень странно - зависает, работает ощутимо медленнее, чем на моем старом лэптопе и периодически отъедает 1-2GB RAM на очень простых запросах.
Дня два копал интернет, пока не нашел следующее:
"...You may experience slow performance when you run 32-bit SQL Server tools on 64-bit operating systems..."

"...To improve performance, run these 32-bit tools on a computer that is running a 32-bit operating system. Then, connect to a 64-bit server that is running SQL Server..."
В результате получается, что мой новый лэптоп несовместим с моим основным рабочим инструментом.
Не понимаю я Microsoft - почему, несмотря на то, что все новые версии ОС объявлены x64, инструменты разработчика даже для SQL 2008 R2 все еще x32?
Источник: http://support.microsoft.com/?id=906892

An attempt to start/stop instance of service Windows SharePoint Services Web Application on server did not succeed.Re-run the action via UI or command line on the specified server. Additional information is below.

'<' is an unexpected token. The expected token is '='. Line 54, position 7.

или

'<', hexadecimal value 0x3C, is an invalid attribute character. Line 81, position 7.

Блоги и форумы стыдливо молчат по поводу этой ошибки, хотя о ней спрашивают.
Причина проста - некоторые программы повреждают XML-файлы при открытии. В данном случае поврежден файл web.config, находящийся по C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\CONFIG

Server Extension 2002 corrupts MS WORD documents during downloading (Server Extension 2002 повреждает файлы MS WORD при скачивании)

Симптомы волшебные, как всегда. Присутствует plain-html static веб-сайт, проще некуда, куда пользователь закачивает документы в формате Microsoft Word и редактирует странички при помощи Microsoft Frontpage. Если скачивать эти документы из папки напрямую, то все ОК. Если пробовать их скачать через ссылку на веб-сайте - файл оказывается поврежденным и короче на 1 байт.
Сравнив работающий и неработающий файл, я выяснил, что в файле присутствует hyperlink, содержащий строчку "https://". В неработающем файле эта строчка была заменена на "http://", что нарушило CRC.
Я не могу сказать точно, что повреждает файл, но на других серверах без Server Extension мы никогда не имели такой проблемы. Так что решим, что это виноват он.
Проблему решили заменой "https://" на "http://" в документах.