none
sdk service is either not running or not yet initialized SCOM 2012 RRS feed

  • Вопрос

  • Добрый день! 

    Дано: 

    - 2 сервера Windows Server 2008 r2

    - SQL server 2008 r2

    - SCOM 2012

    - Файерволлы отключены

    - в едином домене

    - сеть одна

    Выполнил : http://blogs.technet.com/b/kevinholman/archive/2011/08/08/opsmgr-2012-what-should-the-spn-s-look-like.aspx и то что указано на серевере управления

    Setspn.exe -A MSOMSdkSvc/SCOM01 s-OM-DA-Svc

    Setspn.exe -A MSOMSdkSvc/SCOM01.holding.com s-OM-DA-Svc.

    После этого выходит ошибка при подключении (служба SDK включена на сервере управления):

    Статьи читал эту и эту

     

    C уважением к Вам, Я

    24 января 2013 г. 14:08

Все ответы

  • Привет,

    Setspn.exe -A MSOMSdkSvc/ServerFQDN ServerNetBiosName
    Setspn.exe -A MSOMSdkSvc/ServerNetBiosName ServerNetBiosName
     
    Setspn.exe -U -A MSOMSdkSvc/ServerFQDN sdkAccount
    Setspn.exe -U -A MSOMSdkSvc/ServerNetBiosName sdkAccount

    А вообще если запутались с spn то лучше поставить последний патч для scom 2012 или SP1..дать sdkAccount временно права доменного админа или права 

    Read/Write servicePrincipalName для данной учетки и рестартовать сервис Data Access Service. Все зарегистрируется корректно само собой. В последних обновлениях нет бага когда после рестарта Data Access Service scom пытался каждый раз регистрировать spn и если у учетки отбирали нужные права то алерт снова появлялся в консоли scom.
    25 января 2013 г. 22:05
  • Добрый день! 

    Setspn.exe -A MSOMSdkSvc/ServerFQDN ServerNetBiosName
    Setspn.exe -A MSOMSdkSvc/ServerNetBiosName ServerNetBiosName
     
    Setspn.exe -U -A MSOMSdkSvc/ServerFQDN sdkAccount
    Setspn.exe -U -A MSOMSdkSvc/ServerNetBiosName sdkAccount

    Выполнить?

    В первых двух командах что необходимо вставить вместо "ServerFQDN ServerNetBiosName" и "ServerNetBiosName ServerNetBiosName"?

    Вторая группа команд тоже самое, только с аккаунтами? 

    выполнять на сервере управления или на сервере БД?


    C уважением к Вам, Я

    28 января 2013 г. 6:55
  • Привет,

    1. в вашем случае ServerFQDN - SCOM01.holding.com, ServerNetBiosName -SCOM01

    2. Да

    3. Не важно где выполнять, главное иметь права доменного админа или иметь разрешения на изменение свойства servicePrincipalName для учетной записи. В вся информация хранится в AD для данных учеток а не конкретно на сервере.

    28 января 2013 г. 7:30
  • Добрый день!

    Прошу прощения за долгий ответ.

    Ещё одно уточнение ServerFQDN - указать же имя сервера управления SCOM или имя сервера базы данных?

    Setspn.exe -A MSOMSdkSvc/SCOM01 s-OM-DA-Svc

    Setspn.exe -A MSOMSdkSvc/SCOM01.holding.com s-OM-DA-Svс - здесь указан сервер БД

    Заранее благодарен!


    C уважением к Вам, Я

    4 февраля 2013 г. 11:14
  • Имя сервера управления SCOM, если их несколько то надо регистрировать для каждого
    4 февраля 2013 г. 11:20
  • А MSOMSdkSvc - это имя экземпляра SQL?...

    C уважением к Вам, Я

    4 февраля 2013 г. 11:40
  • Нет это serviceclass 

    http://social.technet.microsoft.com/wiki/contents/articles/717.service-principal-names-spns-setspn-syntax-setspn-exe.aspx

    4 февраля 2013 г. 11:45
  • Получается необходимо выполнить:

    Setspn.exe -A MSOMSdkSvc/ServerFQDN ServerNetBiosName

    где указать MSOMSdkSvc (этот класс одинаков для всех)? (и соответвенно имя сервера SCOM)

    Спасибо


    C уважением к Вам, Я

    4 февраля 2013 г. 12:03
  • Правильно
    4 февраля 2013 г. 12:11
  • Спасибо! Проверю дам знать!


    C уважением к Вам, Я

    4 февраля 2013 г. 12:31
  • Получается необходимо выполнить:

    Setspn.exe -A MSOMSdkSvc/ServerFQDN ServerNetBiosName

    где указать MSOMSdkSvc (этот класс одинаков для всех)? (и соответвенно имя сервера SCOM)

    Спасибо


    C уважением к Вам, Я


    Насколько я помню, то в самом алерте написано решение проблемы.

    Vladimir Zelenov | http://systemcenter4all.wordpress.com

    7 февраля 2013 г. 7:32
    Отвечающий
  • Получается необходимо выполнить:

    Setspn.exe -A MSOMSdkSvc/ServerFQDN ServerNetBiosName

    где указать MSOMSdkSvc (этот класс одинаков для всех)? (и соответвенно имя сервера SCOM)

    Спасибо


    C уважением к Вам, Я


    Насколько я помню, то в самом алерте написано решение проблемы.

    Vladimir Zelenov | http://systemcenter4all.wordpress.com


    Написано. Только служба запущена.

    C уважением к Вам, Я

    11 февраля 2013 г. 9:58
  • Добрый день!

    команды отработали - где прописано полное доменное имя сервака. SRV-SCOM-MS01 - менеджмент сервер. Где у сервака указано коротко имя, то выходит ошибка:

    Microsoft Windows [Version 6.1.7601]

    Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

     

    C:\Windows\system32>Setspn.exe -A MSOMSdkSvc/SRV-SCOM-MS01.domain.ru SRV-SCOM-MS01

    Registering ServicePrincipalNames for CN=srv-scom-ms01,OU=??????????,DC=domain,DC=ru

            MSOMSdkSvc/SRV-SCOM-MS01.domain.ru

    Updated object

     

    C:\Windows\system32>Setspn.exe -A MSOMSdkSvc/ SRV-SCOM-MS01 SRV-SCOM-MS01

    Unknown parameter SRV-SCOM-MS01.  Please check your usage.

     

    Usage: Setspn.exe [modifiers switch] [accountname]

      Where "accountname" can be the name or domain\name

      of the target computer or user account

     

      Edit Mode Switches:

       -R = reset HOST ServicePrincipalName

        Usage:   setspn -R accountname

       -A = add arbitrary SPN

        Usage:   setspn -A SPN accountname

       -S = add arbitrary SPN after verifying no duplicates exist

        Usage:   setspn -S SPN accountname

       -D = delete arbitrary SPN

        Usage:   setspn -D SPN accountname

       -L = list SPNs registered to target account

        Usage:   setspn [-L] accountname

     

      Edit Mode Modifiers:

       -C = specify that accountname is a computer account

       -U = specify that accountname is a user account

     

        Note: -C and -U are exclusive.  If neither is specified, the tool

         will interpret accountname as a computer name if such a computer

         exists, and a user name if it does not.

     

      Query Mode Switches:

       -Q = query for existence of SPN

        Usage:   setspn -Q SPN

       -X = search for duplicate SPNs

        Usage:   setspn -X

     

        Note: searching for duplicates, especially forestwide, can take

         a long period of time and a large amount of memory.  -Q will execute

         on each target domain/forest.  -X will return duplicates that exist

         across all targets. SPNs are not required to be unique across forests,

         but duplicates can cause authentication issues when authenticating

         cross-forest.

     

      Query Mode Modifiers:

       -P = suppresses progress to the console and can be used when redirecting

        output to a file or when used in an unattended script.  There will be no

        output until the command is complete.

       -F = perform queries at the forest, rather than domain level

       -T = perform query on the speicified domain or forest (when -F is also used)

        Usage:   setspn -T domain (switches and other parameters)

         "" or * can be used to indicate the current domain or forest.

     

        Note: these modifiers can be used with the -S switch in order to specify

         where the check for duplicates should be performed before adding the SPN.

        Note: -T can be specified multiple times.

     

    Examples:

    setspn -R daserver1

       It will register SPN "HOST/daserver1" and "HOST/{DNS of daserver1}"

    setspn -A http/daserver daserver1

       It will register SPN "http/daserver" for computer "daserver1"

    setspn -D http/daserver daserver1

       It will delete SPN "http/daserver" for computer "daserver1"

    setspn -F -S http/daserver daserver1

       It will register SPN "http/daserver" for computer "daserver1"

        if no such SPN exists in the forest

    setspn -U -A http/daserver dauser

       It will register SPN "http/daserver" for user account "dauser"

    setspn -T * -T foo -X

       It will report all duplicate registration of SPNs in this domain and foo

    setspn -T foo -F -Q */daserver

       It will find all SPNs of the form */daserver registered in the forest to

        which foo belongs

     

    C:\Windows\system32>Setspn.exe -A MSOMSdkSvc/SRV-SCOM-MS01 SRV-SCOM-MS01

    Registering ServicePrincipalNames for CN=srv-scom-ms01,OU=??????????,DC=domain, DC=ru

            MSOMSdkSvc/SRV-SCOM-MS01

    Updated object

     

    C:\Windows\system32>Setspn.exe -U -A MSOMSdkSvc/SRV-SCOM-MS01.domain.ru domain\SCOMDASvc

    Registering ServicePrincipalNames for CN=SCOMDASvc,OU=????????? ??????? ??????,O

    U=????????????,DC=domain,DC=ru

            MSOMSdkSvc/SRV-SCOM-MS01.e-lab.icl.kazan.ru

    Updated object

     

    C:\Windows\system32>Setspn.exe -U -A MSOMSdkSvc/ SRV-SCOM-MS01 domain\SCOMDASvc

    Unknown parameter domain\SCOMDASvc.  Please check your usage.

     

    Usage: Setspn.exe [modifiers switch] [accountname]

      Where "accountname" can be the name or domain\name

      of the target computer or user account

     

      Edit Mode Switches:

       -R = reset HOST ServicePrincipalName

        Usage:   setspn -R accountname

       -A = add arbitrary SPN

        Usage:   setspn -A SPN accountname

       -S = add arbitrary SPN after verifying no duplicates exist

        Usage:   setspn -S SPN accountname

       -D = delete arbitrary SPN

        Usage:   setspn -D SPN accountname

       -L = list SPNs registered to target account

       Usage:   setspn [-L] accountname

     

      Edit Mode Modifiers:

       -C = specify that accountname is a computer account

       -U = specify that accountname is a user account

     

        Note: -C and -U are exclusive.  If neither is specified, the tool

         will interpret accountname as a computer name if such a computer

         exists, and a user name if it does not.

     

      Query Mode Switches:

       -Q = query for existence of SPN

        Usage:   setspn -Q SPN

       -X = search for duplicate SPNs

        Usage:   setspn -X

     

        Note: searching for duplicates, especially forestwide, can take

         a long period of time and a large amount of memory.  -Q will execute

         on each target domain/forest.  -X will return duplicates that exist

         across all targets. SPNs are not required to be unique across forests,

         but duplicates can cause authentication issues when authenticating

         cross-forest.

     

      Query Mode Modifiers:

       -P = suppresses progress to the console and can be used when redirecting

        output to a file or when used in an unattended script.  There will be no

        output until the command is complete.

       -F = perform queries at the forest, rather than domain level

       -T = perform query on the speicified domain or forest (when -F is also used)

        Usage:   setspn -T domain (switches and other parameters)

         "" or * can be used to indicate the current domain or forest.

     

        Note: these modifiers can be used with the -S switch in order to specify

         where the check for duplicates should be performed before adding the SPN.

        Note: -T can be specified multiple times.

     

    Examples:

    setspn -R daserver1

       It will register SPN "HOST/daserver1" and "HOST/{DNS of daserver1}"

    setspn -A http/daserver daserver1

       It will register SPN "http/daserver" for computer "daserver1"

    setspn -D http/daserver daserver1

       It will delete SPN "http/daserver" for computer "daserver1"

    setspn -F -S http/daserver daserver1

       It will register SPN "http/daserver" for computer "daserver1"

        if no such SPN exists in the forest

    setspn -U -A http/daserver dauser

       It will register SPN "http/daserver" for user account "dauser"

    setspn -T * -T foo -X

       It will report all duplicate registration of SPNs in this domain and foo

    setspn -T foo -F -Q */daserver

       It will find all SPNs of the form */daserver registered in the forest to

        which foo belongs

     

    C:\Windows\system32>Setspn.exe -U -A MSOMSdkSvc/SRV-SCOM-MS01 domain\SCOMDASvc

    Registering ServicePrincipalNames for CN=SCOMDASvc,OU=????????? ??????? ??????,O

    U=????????????,DC=domain,DC=ru

            MSOMSdkSvc/SRV-SCOM-MS01

    Updated object

     

    C:\Windows\system32>


    C уважением к Вам, Я

    11 февраля 2013 г. 10:04
  • Каким образом записана учетная запись в свойствах сервиса - DOMAIN\user или user@FQDN ?

    12 февраля 2013 г. 9:07
  • DOMAIN\use

    C уважением к Вам, Я

    26 февраля 2013 г. 12:49
  • C:\Windows\system32>Setspn.exe -A MSOMSdkSvc/ SRV-SCOM-MS01 SRV-SCOM-MS01


    Пробел лишний "MSOMSdkSvc/ SRV-SCOM-MS01"
    1 марта 2013 г. 7:44
  • А вообще если запутались с spn то лучше поставить последний патч для scom 2012 или SP1..дать sdkAccount временно права доменного админа или права 

    Read/Write servicePrincipalName для данной учетки и рестартовать сервис Data Access Service. Все зарегистрируется корректно само собой. В последних обновлениях нет бага когда после рестарта Data Access Service scom пытался каждый раз регистрировать spn и если у учетки отбирали нужные права то алерт снова появлялся в консоли scom.

    А есть подтверждение вот этого? Потому что основной баг был не в том, что алерт лишний появляется, а в том, что служба пыталась зарегистрировать неверный SPN - на сервер вместо УЗ службы.

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

    13 марта 2013 г. 0:22
    Отвечающий
  • Убрал.

    Выполнились команды удачно. Всё равно ошибка...


    C уважением к Вам, Я

    13 марта 2013 г. 5:54
  • "А есть подтверждение вот этого? Потому что основной баг был не в том, что алерт лишний появляется, а в том, что служба пыталась зарегистрировать неверный SPN - на сервер вместо УЗ службы."

    Я маленько о другой проблеме говорил, когда после рестарта DAS, в модуле было прописано каждый раз регистрировать SPN даже если он корректно прописан. И при отсутствии прав на модификацию SPN всегда происходила ошибка. Сейчас из модуля это совсем убрали но остался баг в при рестарте службы HealthService кода действительно каждый раз регистрируется spn на учетку сервера с правами учетки для SDK. Соответственно отсюда следующее поведение:

    1. Если используется Local System для System Center Data Access service то он сам регистрируется корректно.

    2. Если используется Domain User для System Center Data Access service то при рестарте HealthService SCOM пытается зарегистрировать SPN для учетки сервера (что неверно), соответственно у Domain User нет прав на изменение SPN и генерируется след. событие в eventlog Operations Manager

    Source: OpsMgr SDK Service

    EventID: 26371

    В SCOM соответственно появляется алерт с ложным требованием зарегистрировать SPN на учетку сервера. (Это именно то о чем вы говорите и это не поправили)

    3. Если у доменной учетки есть права на изменение SPN то при рестарте HealthService SCOM просто регистрирует SPN (при его отсутствии) на учетку сервера. Соответственно если данный SPN был зарегистрирован то при отсутствии прав на изменение SPN никаких ошибок в eventlog не генерируется.

    В общем раньше spn для доменной учетки сам регистрировался а сейчас только в ручную (ну или возможно при установке SCOM что то может регистрироваться при наличии прав, но не проверял)


    13 марта 2013 г. 9:53
  • To MeLo4

    Если все как по этой статье зарегистрировано то волноваться не о чем. (http://blogs.technet.com/b/kevinholman/archive/2011/08/08/opsmgr-2012-what-should-the-spn-s-look-like.aspx). Также если используется NLB то его имя также надо зарегистрировать след. образом setspn –a MSOMSdkSvc/<load balanced name> <DAS account domain>\<DAS account name>

    В каком случае может происходить ошибка я описал выше.

    13 марта 2013 г. 9:57
  • To Alexis Yakovlev

    Спасибо...

    Но я то подключится не могу.. :) И не волнуюсь :)


    C уважением к Вам, Я

    13 марта 2013 г. 10:35
  • Проблема не решена.

    C уважением к Вам, Я

    28 марта 2013 г. 9:51