none
Ошибки 33350, 5300, 5304 RRS feed

  • Вопрос

  •     Добрый день. Проблема такая: существовал 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) com

    4 сентября 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
    Отвечающий