none
Не сохраняет изменения в консоли RRS feed

  • Вопрос

  • После внесения изменений в консоли, если закрыть консоль и открыть заново - все внесенные изменения, пакеты управления, представления исчезают. При этом непосредственно после введения изменений все работает. Думал на необходимую задержку для внесения изменений в базу, но в течении ночи изменения не сохранились и не появились.

    При этом перезагрузка сервера с sql сервером временно ликвидирует эту проблему, но спустя короткий промежуток времени все возобновляется опять.

    4 сентября 2013 г. 4:35

Ответы

  • Благодарю за помощь, коллеги. Проблему решили выделением нового тестового сервера с чистовой перестановкой ОС, и всех частей SCSM. Не самое изящное решение, но нужно двигаться дальше. Надеемся, что, с выходом следующих релизов, данный баг уйдет в прошлое навсегда.

    Антон, Ваша квалифицированная помощь значительно улучшит качество авиапрома :)

    26 сентября 2013 г. 10:57

Все ответы

  • Т.е. система как бы "откатывается"? Даже пакеты управления пропадают?

    Что говорят логи SCSM?


    Если сообщение оказалось полезным, пожалуйста, проголосуйте за него или пометьте в качестве ответа.

    4 сентября 2013 г. 7:03
  • Переставил сервер заново, с новой базой. Ничего не меняется. Не нашел файл лога на сервере, уточните пожалуйста путь к файлу.
    5 сентября 2013 г. 4:04
  • путь к логу

    C:\Windows\System32\winevt\Logs\Operations Manager.evtx

    у меня аналогичная проблема, все изменения после закрытия консоли не видны, но если перезапустить сервер то внесенные изменения начинают отображаться

    5 сентября 2013 г. 5:12
  • Что-то не до конца понятна суть проблемы. Т. е. вы открыли консоль, создали к примеру инцидент. Он появился? Потом закрыли консоль, открыли заново - новый инцидент пропал? Перезагрузили сервер и инцидент появился в консоли?

    1. Консоль удалённая или на сервере?

    2. Попробуйте на разных консолях параллельно проверить, на разных ПК.

    Судя по всему, данные в БД попадают, но что-то мешает консоли их получать.


    Если сообщение оказалось полезным, пожалуйста, проголосуйте за него или пометьте в качестве ответа.

    5 сентября 2013 г. 7:03
  • нет речь едет не об инцидентах и запросах на обслуживание. речь идет о создании пакетов управления,  элементах конфигурации, шаблонах, задачах.

    к примеру создаю задачу, сохраняю ее в отдельный только что созданный пакет управления, создал, смотрю все ок, задача есть, пакет управления есть. другие пользователи открывают консоль ииии, нет ничего, я закрываю консоль, открываю ииии тоже нет ничего. перезагружаю сервер, и все созданное на месте.

    5 сентября 2013 г. 7:57
  • Проверили на двух компьютерах, консоль установлена удаленно - результат аналогичный: не сохраняет созданные объекты.

    Опытным путем выяснили, что на сервере есть процесс OMSDK - System Center data access service, при перезапуске которого происходит отображение элементов в консоли. Наверно с ним чтото не так ...

    5 сентября 2013 г. 10:37
  • Создайте "Пропадающую" задачу. И посомтрите, что в этот момент происходит в SCOM-event на сервере SCSM. Если есть ошибка или предупреждение - показывайте.

    Если консоль на отдельной машине, то и проблемные сообщения с неё тоже, из SCOM-event.


    Если сообщение оказалось полезным, пожалуйста, проголосуйте за него или пометьте в качестве ответа.


    5 сентября 2013 г. 10:43
  • Создал элемент конфигурации, перезапустился - элемент пропал. На клиенте появилось два сообщения о том что удачно создано соединение с Active Directory. На сервере создалось два сообщения о том что "A client has disconnected." и "A new client has connected. ".

    Но в списке за сегодняшний день увидел три ошибки по поводу:

    Чтото с процессом System Center data access service

    6 сентября 2013 г. 0:44
  • Обычно эта ошибка возникает непосредственно после перезапуска службы, если она еще не инициализировалась а обращение к SC идет.
    6 сентября 2013 г. 4:45
  • Есть такое решение: http://vmind.ru/2012/10/31/ne-zapuskaetsya-sluzhba-microsoft-system-center-data-access-service/

    Но мне не помогло.


    • Изменено Zhenya Ieropolskiy 6 сентября 2013 г. 5:29 гиперссылка
    6 сентября 2013 г. 5:29
  • есть такое, проходили, но к нашему случаю не подходит, это в случае если служба вообще не запускается
    6 сентября 2013 г. 5:32
  • От какой У\з запускается служба? Параметры запуска?

    Что в логах System-event? Есть ли ошибки Керберос?


    Если сообщение оказалось полезным, пожалуйста, проголосуйте за него или пометьте в качестве ответа.

    6 сентября 2013 г. 6:34
  • Учетная запись администратора, параметры по умолчанию. Пробовал менять, проблема остается.




    • Изменено Zhenya Ieropolskiy 6 сентября 2013 г. 22:37 дополнить
    6 сентября 2013 г. 22:33
  • Были вот такие ошибки, но не факт что непосредственно после манипуляций с консолью, в таком случае ничего особенного не было обнаружено.

    Было несколько керберосов:


    Текст ошибки керберос:

    Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера OIT_Service. Использовалось конечное имя MSOMSdkSvc/sharepoint. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (KNAAPO.RU) отличен от домена клиента (KNAAPO.RU), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера

    7 сентября 2013 г. 2:24
  • В базе sql у oit_server все возможные права:

    7 сентября 2013 г. 2:27
  • На запрос в гугл: scsm 2012 data access service not running

    первая статья

    http://blogs.technet.com/b/servicemanager/archive/2011/10/04/system-center-data-access-service-start-up-failure-due-to-sql-configuration-change.aspx

    Тут вроде и идет речь про то что нужно выдать права учетной записи в самой базе sql, но у меня это не решило проблему.

    7 сентября 2013 г. 2:29
  • В первую очередь корректно настройте делегирование (SPN) для у\з службы OMSDK Svc.

    http://blog.scsmsolutions.com/2012/11/configure-the-kerberos-for-scsm-2012-spn-and-delegation/

    Ещё тут рассматривается что-то похожее:

    http://blog.scsmsolutions.ru/2011/08/changes-are-not-applied-on-console/


    Если сообщение оказалось полезным, пожалуйста, проголосуйте за него или пометьте в качестве ответа.



    • Изменено Dismantled 7 сентября 2013 г. 21:21
    7 сентября 2013 г. 15:03
  • На данный момент решение не найдено. Благодарю за предложенные варианты, результаты следующие:

    1. У\з не является причиной проблемы, т.к. ранее все работало без перебоев, и в актив директори у\з имеет права администратора.

    2. Кеш почистил согласно инструкции на предложенном Вами сайте. Безрезультатно.

    Если есть предложения, прошу поделиться.

    9 сентября 2013 г. 11:03
  • А SPN настроили? Ошибки Kerberos не появляются? У вас служба OMSDKSvc не может нормально авторизоваться. "ранее все работало без перебоев" - не показатель. Просто вы напрямую не сталкивались с проблемой. А теперь она всплыла и очень вероятно, что по причине некорректного SPN. Если у вас в структуре есть выделенный системный администратор домена, рекомендую обратиться к нему, показав ошибку Kerberos.

    Кстати, вопрос _CoopeR_ - а у вас есть в системе подобные ошибки Kerberos?


    Если сообщение оказалось полезным, пожалуйста, проголосуйте за него или пометьте в качестве ответа.


    • Изменено Dismantled 9 сентября 2013 г. 11:51
    9 сентября 2013 г. 11:45
  • Нет, ошибок Kerberos нет
    11 сентября 2013 г. 10:50
  • Изучил материал предложенного сайта http://blog.scsmsolutions.com/2012/11/configure-the-kerberos-for-scsm-2012-spn-and-delegation/

    Произвел следующие действия:

    1. В свойствах сервера в актив директори поставил галку "Trust this computer tor delegation to any service (Kerberos only)". В свойствах учетки oit_service в пункте Account is sensitive and cannot be delegated галки нет.

    2. После этого выполнил на сервере scsm команду:

    setspn –A  MSOMSdkSvc/sharepoint knaapo\oit_service

    перезагрузил сервер.

    При выполнении команды :

    setspn –L knaapo\oit_service

    Появляется следующий результат:



    Сервер scsm у меня называется sharepoint.

    Проблема сохранилась, причина, если я все сделал правильно, была не в настройке spn.

    11 сентября 2013 г. 23:27
  • Если вы добились полного отсутствия ошибок Kerberos (кстати, не только на SCSM-сервере), это в любом случае правильная работа, даже если это и не помогло в решении конкретно Вашей проблемы.

    Кстати, у вас Портал с Шарпоинтом установлен на одном сервере с ролью SCSM?


    Если сообщение оказалось полезным, пожалуйста, проголосуйте за него или пометьте в качестве ответа.

    12 сентября 2013 г. 6:36
  • Столкнулся с похожим случаем.

    Создал представление в AVE. Права, очереди - всё настроено. У двух человек в консоли представление отобразилось, а у двух нет.

    Проблема оказалась в кэше и, судя по всему, в кэше Data Access Service. После перезапуска этой службы на сервере, все изменения корректно отобразились у всех пользователей.

    Это всё же "костыль", как можно решить проблему оперативно. Но может быть профи подскажут, как вылечить проблему на корню? Тем более, если она выходит на хронический уровень, как, например, у автора этой темы.

    ЗЫ: Опять же, более глобальный "костыль" - настроить службу Data Access Service на периодический перезапуск по расписанию.


    Если сообщение оказалось полезным, пожалуйста, проголосуйте за него или пометьте в качестве ответа.


    • Изменено Dismantled 19 сентября 2013 г. 13:40
    19 сентября 2013 г. 13:38
  • Коллеги, предлагаю открыть кейс.

    Я такое видел всего несколько раз (2 если быть точным), но у меня не было шанса исследовать проблему, т.к. не было доступа к окружению. Причем в одном случае причина была не в сервере, а в клиентской машине - с других изменения сохранялись нормально.

    Если проблемы наблюдается на новой инсталляции её проще исследовать, так что шансы найти истинную причину высоки.

    Могу добавить, что можно попробовать включить полное логирование и исследовать и\или прислать результаты мне на почту. http://marcelzehner.ch/2011/03/24/scsm-troubleshooting/, пункт 3, Tracing. Помочь родному авиапрому - правое дело ;)


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    • Предложено в качестве ответа Dismantled 26 сентября 2013 г. 11:15
    23 сентября 2013 г. 14:34
    Модератор
  • Благодарю за помощь, коллеги. Проблему решили выделением нового тестового сервера с чистовой перестановкой ОС, и всех частей SCSM. Не самое изящное решение, но нужно двигаться дальше. Надеемся, что, с выходом следующих релизов, данный баг уйдет в прошлое навсегда.

    Антон, Ваша квалифицированная помощь значительно улучшит качество авиапрома :)

    26 сентября 2013 г. 10:57