Накопительные обновления — Cumulative Updates for SharePoint 2010 — [ERROR] : Exception: Index was outside the bounds of the array. SearchAdmin Database

Ошибки, возникающие при установке накопительных обновлений на ферме шарпоинта.
Начнем-с.
Опишу одну ошибку, возникшую у нас на ферме, и как с мы ней боролись.
А началось все с того, что при «аварийном» разрыве конфигурирования накопительных обновлений этим летом, у нас на ферме вышел из строя сервер приложений (Application Server). Одной из глобальных проблем было: на нем перестали выполняться джобы.
С помощью самоотверженной поддержки сотрудников Microsoft, бОльшая часть служб была перенесена на фронт-енд (Front-End) сервер, но приложение службы поиска никак не хотело переезжать на другой сервер, поэтому пришлось работать «с костылем», пока не настроили второй сервер приложений.

После ввода в ферму второго сервера приложений и вывода первого (поломанного) сервера приложений, было создано новое приложение службы поиска на новом сервере приложений (Application server №2). Но остались на ферме следы прибывания старого приложения службы поиска. Основной работе серверов фермы это не мешало, поэтому решил пока ее не удалять полностью. Тем более, что через «WEB-морду» ее удалить не получалось (даже выполнить настройку этого приложения —Modify— не представлялось возможным), а нужно удалть только с помощью PowerShell‘а. Раздела «Search Service Application Proxy» у этого приложения службы поиска уже не было.
Конфигурирование мартовских накопительных обновлений шарпоинта за 2012 год обрывалось ошибкой:


[OWSTIMER] [SPUpgradeSession] [INFO] [10/28/2012 1:19:24 PM]: SearchAdminDatabase Name=Search_Service_Application_DB_7a6d343b0...

[OWSTIMER] [SPUpgradeSession] [ERROR] [10/28/2012 1:19:24 PM]: Upgrade [SearchAdminDatabase Name=Search_Service_Application_DB_7a6d343b0...] failed.

[OWSTIMER] [SPUpgradeSession] [INFO] [10/28/2012 1:19:24 PM]: SearchAdminDatabase Name=Search_Service_Application_DB_7a6d343b0...

[OWSTIMER] [SPUpgradeSession] [ERROR] [10/28/2012 1:19:24 PM]: Exception: Index was outside the bounds of the array.

[OWSTIMER] [SPUpgradeSession] [INFO] [10/28/2012 1:19:24 PM]: SearchAdminDatabase Name=Search_Service_Application_DB_7a6d343b0...

[OWSTIMER] [SPUpgradeSession] [ERROR] [10/28/2012 1:19:24 PM]: at Microsoft.Office.Server.Search.Upgrade.SearchAdminDatabaseSequence.InitializeTopologyBasedOn2007Settings()
at Microsoft.Office.Server.Search.Upgrade.SearchAdminDatabaseSequence.PostUpgrade()

Основной зацепкой была фраза: Exception: Index was outside the bounds of the array.
Немного погуглив, овтет был найден в одной из баз знаний микрософта (или на блоге одного из сотрудников поддержки микрософта… уже не помню 🙁 ).
Расскажу вкратце, что происходило: обновления считали, что лишнего приложения поиска, у которого даже нет своего сервера, на котором оно живет (старый сервер приложений мы вывели из фермы, так и не выполнив модификацию, и не пересли индексные файлы для поиска на другой сервер), на ферме быть не должно, и поэтому ругалось на переполнение индексов в массиве.







Команда Get-SPEnterpriseSearchServiceApplication, выполненная в PowerShell‘е выдала нам список приложений поиска.


Get-SPEnterpriseSearchServiceApplication

На ферме числилось 2 приложения поиска — одно было рабочее, которое мы настроили сразу после вывода поломанного сервера приложений из фермы, а 2-е приложение поиска — не рабочее, котороне мы не смогли удалить через WEB интерфейс после добавления нового сервера приложений на ферму.
Выбрав ID «поломанного» приложения поиска (в нашем случае ID = 7ac69fbf-67a1-4c17-834c-5f8fc5f43adb) присваиваем произвольной переменной идентификатор объекта этого приложения поиска по выбранному ID командой:


$ssa = Get-SPEnterpriseSearchServiceApplication -Identity 7ac69fbf-67a1-4c17-834c-5f8fc5f43adb

и затем, используя нашу переменную $ssa, удаляем лишнее, ненужное приложение поиска из состава фермы шарпоинта командой:


$ssa.Delete()

Вместе эти две команды по удалению приложения поиска через PowerShell выглядят так:


$ssa = Get-SPEnterpriseSearchServiceApplication -Identity 7ac69fbf-67a1-4c17-834c-5f8fc5f43adb

$ssa.Delete()

Проверить результат выполнения команд по удалению неработающего приложения поиска можно из Центра Администрирования шарпоинта:

Central Administration -> Application Management -> Manage service applications

Теперь там у нас отображается только одно приложение поиска, которое мы создавали на новом сервере приложений шарпоинта (Application Server).
Т.к. наименование нового приложения службы поиска намеренно было изменено на отичное от наименования по-умолчанию (суффиксом к названию добавлено наименование нового сервера приложений, на котором теперь «живет» приложение службы поиска), то по наименованию баз поиска в логах обновления, можно было легко догадаться об ошибке, связанной имено со старыми приложением службы поиска.

После этого повторно запуститли конфигурирование установленных накопительных обновлений (SharePoint 2010 Products Configuration Wizard), и данная ошибка уже была устранена. Правда, на этом наша эпопея с обновлениями не закончилась — обнаружены были другие ошибки, о речь которых пойдет в следующих статьях.

Cumulative Update for SharePoint...

Comments are closed.