Если сразу после установки xorg клавиатура и мышь не работает, а в логах xorg можно увидеть сообщение “сannot locate a core keyboard device”, то надо добавить в /etc/rc.conf строчку
hald_enable=”YES”
При следующей перезагрузке или после ручного старта hald клавиатура и мышь в xorg должны заработать.
Місяць: Лютий 2011
Создание Менеджмент пака
В предыдущей заметке я рассказал как включать логирование информационных событий о печати в операционных системах семейства Windows. Теперь я расскажу что же с этими событиями можно делать. Ответ очень прост – их надо собирать и на основе их создавать отчеты. Собирать можно разными способами, один из них это использование для данной цели SCOM 2007. Конфигурация SCOM описывается в менеджмент-паках, и процесс создания менеджмент-пака для сбора статистики использования принтеров показан в нижеприведенном видео.
Скачать Менеджмент-пак
Включение логирования событий от диспетчера печати
Для простейшего анализа кто что печатает можно включить логирование информационных событий печати. И тогда в журнале событий будут появляться события с данными о принтере, количесве напечатанных листов, названиями документов. Выглядит такое событие так:
Как оказалось включение логирования данного события принципиально отличается в в редакциях Windows 7/2008 R2 и более ранних. На картинке показано событие из Windows Server 2008 R2.
Отличия следующие: �
1. Номер события был 10, стал 307;
2. Журнал был System, стал Microsoft-Windows-PrintService/Operational;
3. Включаось логирование события в свойствах диспетчера печати, теперь в свойствах соответствующего журнала.
Для включения логирования данного события в Windows Server 2008 R2 необходимо сделать следующее:
Server Manager->Diagnostics->Event Viever->Applications and services Logs->Microsoft->Windows->Microsoft-Windows-PrintService/Operational и нажать Enable Log
Либо установить ключ реестра:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \Windows\CurrentVersion\WINEVT\Channels \Microsoft-Windows-PrintService/Operational-Enabled равным 1.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \Windows\CurrentVersion\WINEVT\Channels \Microsoft-Windows-PrintService/Operational-Enabled равным 1.
Для включения логирования данного события в Windows Server 2003 необходимо сделать следующее:
Start-Settings->Control Panel->Printers and Faxes File->Server Properties->Advanced и установить флаг “Log spooler information events
Либо установить ключ реестра: HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Control \Print\Providers -> EventLog
равным 7.
Алерт – 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