Maksym Krasovskyy blog

Для простейшего анализа кто что печатает можно включить логирование информационных событий печати. И тогда в журнале событий будут появляться события с данными о принтере, количесве напечатанных листов, названиями документов. Выглядит такое событие так:

Как оказалось включение логирования данного события принципиально отличается в в редакциях Windows 7/2008 R2 и более ранних. На картинке показано событие из Windows Server 2008 R2.
Отличия следующие: �
1. Номер события был 10, стал 307;
2. Журнал был System, стал Microsoft-Windows-PrintService/Operational;
3. Включаось логирование события в свойствах диспетчера печати, теперь в свойствах соответствующего журнала.

Для включения логирования данного события в Windows Server 2008 R2 необходимо сделать следующее:

Появлялся у меня с завидной периодиностью алерт 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

Для переименования компьютера, если идти к нему не хочется, достаточно дать ледующую команду:
NETDOM RENAMECOMPUTER currentname /NewName:newname /UserD:useranme /PasswordD:* /REBoot:1
Чтоб принудительно компьютер не перегружать /REBoot:1 убираем.

Если после установки клиента, он не появляется в консоли SCCM как установленые, на самом клиенте отсуствует список программ для установки и другая видимая активность клиента, то возможно клиент просто не может подключиться к сайту.
В моем случае в логах клиента практически не было лог файлов (что и понятно, ведь клиент толком работать не начал), единственным логом, в котором была какая-то активность, был ClientIDManagerStartup.log.
В нем периодически появлялись события типа:
Error initializing client registration (0×80040222)
RegTask: Failed to refresh MP. Error: 0×80004005.
В моем случае помогла просто переустановка клиента, в другом аналогичном случае помог вывод-ввод компьютера из домена. (на необходимость повторного ввода компьютера в домен указывало netbios имя компьютера, которое отличалось от полного доменного имени компьютера).