wshom.ocx error (EventID 1000 in Application log)

На некоторых домен-контроллерах в журнале приложений постоянно возникала ошибка 1000 со следующими описаниями:

Faulting application cscript.exe, version 5.7.0.18005, time stamp 0x49e01e5f, faulting module ntdll.dll, version 6.0.6002.18005, time stamp 0x49e03821, exception code 0xc00000fd, fault offset 0x0004a4d2, process id 0x87d0, application start time 0x01cc114200749b48.

Faulting application cscript.exe, version 5.7.0.18005, time stamp 0x49e01e5f, faulting module wshom.ocx, version 5.7.0.18005, time stamp 0x49e03856, exception code 0xc00000fd, fault offset 0x0000df97, process id 0x84e8, application start time 0x01cc1142b346a8f3.

 

Содержимое ключа состояло в огромном количестве записей вида:

Failed to create object 'McActiveDir.ActiveDirectory'.This is an unexpected error.
The error returned was 'ActiveX component can't create object' (0x1AD)
Failed to create object 'McActiveDir.ActiveDirectory'.This is an unexpected error.
The error returned was 'ActiveX component can't create object' (0x1AD)
Failed to create object 'McActiveDir.ActiveDirectory'.This is an unexpected error.
The error returned was 'ActiveX component can't create object' (0x1AD)
Failed to create object 'McActiveDir.ActiveDirectory'.This is an unexpected error.
The error returned was 'ActiveX component can't create object' (0x1AD) 

Очистка данного ключа устраняет ошибку и как результат, возникающее событые с номером 1000.

 

Создание Менеджмент пака

В предыдущей заметке я рассказал как включать логирование информационных событий о печати в операционных системах семейства Windows. Теперь я расскажу что же с этими событиями можно делать.  Ответ очень прост – их надо собирать и на основе их создавать отчеты. Собирать можно разными способами, один из них это использование для данной цели SCOM 2007.  Конфигурация SCOM описывается в менеджмент-паках, и процесс создания менеджмент-пака для сбора статистики использования принтеров показан в нижеприведенном видео.

 

Скачать Менеджмент-пак

Алерт – Root Management Server Unavailable

Появлялся у меня с завидной периодиностью алерт Root Management Server Unavailable, хотя вроде все работает. Для избавления от него было проледано слеюующее:

1. Regedt32
2. Locate HKEY_LOCAL_MACHINE -> SOFTWARE -> MICROSOFT -> MICROSOFT OPERATIONS MANANGER -> 3.0 -> SDK SERVICE
3. Right click – New Key
4. Enter “RHS Watcher”
5. Right click “RHS Watcher” -> New -> DWORD
6. Enter “MinutesToWaitBeforeAlerting”
7. Double-click on “MinutesToWaitBeforeAlerting” and enter value of 5
8. Close regdt32 and open Services.msc
9. Restart OpsMgr Config Service, OpsMgr Health Service, and OpsMgr Health Service

Идея не моя, взято отсюда – http://it.peterspowerblog.com/2008/09/04/root-management-server-unavailable.aspx

Однако данные действия не помогли мне избавиться от ошибки. Далее было найдено решение зачем-то удалить сетевые устройства, у меня одно такое было, которое не мониторилось – удалил, не помогло. После чего была найдена статья http://blogs.technet.com/b/kevinholman/archive/2009/11/10/29106-event-on-rms-index-was-out-of-range-wait-what.aspx Действительно в логе был Event с ID=29106, после удаления 2-х агентов проблема не решилась. В итоге проблема решилась проверкой времени на RMS и SQL серверах. На SQL сервере время отличалось от доменного на 2 минуты. Поле принудительной синхронизации времени командой net time /domain:domain /set проблема исчезла.

Поиск элементов менеджмент-пака

Понадобилось мне на одном из серверов отключить Discovery, потому что компьютер был не доменный, а для дискавери необходим был доменный аккаунт. Да и не было на конкретном сервере никаких файловых сервисов. В эвенте был идентификатор discovery, а вот в Operation Console было его нормальное имя. Поиск нормального имени был осуществлен при помощи вот такой строки на powershell:
get-managementpack | foreach-object{$_.GetDiscoveries()} | where {$_.Name -eq "Microsoft.Windows.FileServer.DFSR.2008R2.DFSRServerDiscovery2008R2"} | select DisplayName
Условивие можно задать в виде $_.Name.Contains(“DFS”) -eq $true

Принудительная очистка базы аудита в SCOM 2007

К сожалению место на дисках имеет свойство заканчиваться. Сервер аудита (Audit Collection Server) хранит все в базе данные, неправильный прогноз размера базы данных приводит к тому, что в один прекрасный день место на диске заканчивается и сервер аудита фактически прекращает работать. Количество дней, за которые хранятся записи в базе аудита, настраивается очень просто, при помощи такого запроса:

USE OperationsManagerAC
UPDATE dtConfig
SET Value = <number of days to retain data + 1>
WHERE Id = 6

Но сделать такие настройки мало, необходимо еще и удалить ненужные данные. Можно конечно дождаться пока данные будут удалены автоматически, но лучше это сделать сразу для возобновления нормальной работы. Для этого необходимо открыть SQL запрос, находящийся в папке \\ACS\%SystemRoot%\System32\Security\AdtServer\DbDeletePartition.sql и заменить строку “!g!” на id раздела, который необходимо удалить. id раздела можно получить, выполнив такой запрос:

SELECT *
FROM dtPartition
ORDER BY PartitionCloseTime

Выбираем самый старый раздел и используем его ID для удаления.