Лучший отвечающий
Ошибки 33350, 5300, 5304

Вопрос
-
Добрый день. Проблема такая: существовал Operations Manager 2007 R2 в односерверной конфигурации (RMS + все DBs + Reporting). После переезда баз данных на другой сервер в журнале RMS регистрируются события 33350 DataAccesLayer (Database connectivity has been lost - Login failed for user 'NT AUTHORITY\ANONIMOUS LOGON'), затем через некоторое время 5300, 5304 (Health service - Local health service is not healthy), ну и алерты не идут в консоль. На SQL сервере событие 18456 (Login failed for user 'NT AUTHORITY\ANONIMOUS LOGON' [Client:<ip-адрес RMS>]). По иерархии AD - RMS в родительском домене, SQL в дочернем. Все SPN-ы проверены, права учетных записей на SQL тоже. НА RMS службы запускаются из-под: System Center Data Access - domain SDK user, System Center Management - Local System, System Center Management Configuration - domain SDK user. Статья http://thoughtsonopsmgr.blogspot.com/2010/05/eventid-5300-and-eventid-5304-in-opsmgr.html прочитана, в принципе, такой выход устраивает, но хотелось бы понять, где собака зарыта, из-за чего все-таки возникают ошибки.
- Изменено Mike Kulikov 3 сентября 2012 г. 5:07
3 сентября 2012 г. 4:21
Ответы
-
Дак вроде SQL и не должен читать SPN для RMS или MS...
Тащемта все заработало после того, как поменял Action account для SCOMовских серверов управления с Local System на доменного пользователя. Нда...
- Помечено в качестве ответа Mike Kulikov 6 сентября 2012 г. 9:59
6 сентября 2012 г. 9:59
Все ответы
-
Судя по AUTHORITY\ANONIMOUS LOGON' - проблемы с Kerberos. Ну а что проверять - тут вариантов очень мног.
SCSMSolutions
email: freemanru (at) gmail (dot) com4 сентября 2012 г. 12:01Отвечающий -
А вы при переезде все сделали, как в инструкции?4 сентября 2012 г. 15:04Отвечающий
-
Угу, делал даже по нескольким инструкциям - Microsoft + Kevin Holman + Daniel Grandini.
Сейчас поменял местами RMS и MS, удалил SCOM с MS (и MS из консоли), удалил все логины по старому MS из SQL, пересоедил к домену, снова сделал его вторым MS - после этого в логах SQL снова пошли события 18456, ну и через некоторое время событие 5300 на MS. На данный момент все агенты работают через RMS, соответственно алерты и оповещения идут без проблем.
Еще уточнение: сейчас RMS и SQL - Windows Server 2008 R2, проблемный MS - Windows Server 2003 R2 SP2 x64. Как я уже говорил, RMS и MS - в родительском домене, SQL 2008 R2 SP1 - в дочернем. Может, конечно, дело в named pipes или в других настройках на SQL (судя по этой статье http://thoughtsonopsmgr.blogspot.com/2011/03/eventid-31552-failed-to-store-data-in.html ). Буду экспериментировать дальше...
- Изменено Mike Kulikov 10 сентября 2012 г. 7:06
5 сентября 2012 г. 5:30 -
Угу, делал даже по нескольким инструкциям - Microsoft + Kevin Hollman + Daniel Grandini.
Сейчас поменял местами RMS и MS, удалил SCOM с MS (и MS из консоли), удалил все логины по старому MS из SQL, пересоедил к домену, снова сделал его вторым MS - после этого в логах SQL снова пошли события 18456, ну и через некоторое время событие 5300 на MS. На данный момент все агенты работают через RMS, соответственно алерты и оповещения идут без проблем.
Еще уточнение: сейчас RMS и SQL - Windows Server 2008 R2, проблемный MS - Windows Server 2003 R2 SP2 x64. Как я уже говорил, RMS и MS - в родительском домене, SQL 2008 R2 SP1 - в дочернем. Может, конечно, дело в named pipes или в других настройках на SQL (судя по этой статье http://thoughtsonopsmgr.blogspot.com/2011/03/eventid-31552-failed-to-store-data-in.html ). Буду экспериментировать дальше...
На самом деле не знаю, как у OpsMgr, думаю, что всё должно работать, но у того же ConfigMgr такая конфигурация не поддерживается, т.е. SQL, SQL Reports и SMS Provider должны быть в одном домене. Вы SPN записи прописали для всех служб? Вполне возможно, что сервис SQL не имеет прав на чтение пользователей с другого домена.6 сентября 2012 г. 7:20Отвечающий -
Дак вроде SQL и не должен читать SPN для RMS или MS...
Тащемта все заработало после того, как поменял Action account для SCOMовских серверов управления с Local System на доменного пользователя. Нда...
- Помечено в качестве ответа Mike Kulikov 6 сентября 2012 г. 9:59
6 сентября 2012 г. 9:59 -
Воооо! С этого и надо было начинать :)6 сентября 2012 г. 10:45Отвечающий