none
Миграция пользовательской среды в SCCM и ошибка SMSSHA_Startup returned error code 0x87d0027f на "новом" ПК RRS feed

  • Вопрос

  • Необходима помощь в понимании принципа миграции пользовательской среды  в SCCM

    Алгоритм миграции:

    0. имеется  сайт SCCM 2012 (R2), все TS назначены на коллекцию компьютеров
    1. с помощью TS SCCM выполняется захват пользовательской среды на Migration Point SCCM cо "старого" ПК "test-pc" с ОС Windows XP;
    2. "старый" ПК "test-pc"  ОС Windows XP выводится из домена.
    2.1. Выполняется команда netdom.exe reset /d:%userdomain% %computername% для обнуления учетной записи Active Directory (чтобы ее можно было использовать на новом ПК)
    3. на "новый" ПК устанавливается ОС Windows 7, устанавливается клиент SCCM 2012 R2
    4. "новый" ПК с ОС Windows 7 переименовывается в "test-pc"
    5. "новый" ПК с ОС Windows 7 вводится в домен
    6. на "новый" ПК с ОС Windows 7 производится вход под "старой" "XP-шной" доменной учетной записью.

    --------------
    7. Тут, по идее, на "новый" ПК с ОС Windows 7 должно прийти назначенное задание для восстановления данных со "старого" ПК  с ОС Windows XP, но этого не происходит:
     - сначала видно, что клиент SCCM инициализируется - присоединяется к сайту, в нем появляются дополнительные к "Цикл получения и оценки политик компьютера" и "Цикл получения и оценки политик пользователя" циклы
    - потом в центре программного обеспечения появляется задание на восстановление пользовательских данных
    - потом (!) клиент SCCM деинсталируется до начального состояния: в центре программного обеспечения  SCCM пусто, в клиенте SCCM остаются только два доступных действия "Цикл получения и оценки политик компьютера" и "Цикл получения и оценки политик пользователя"

    Ошибки: В CcmExec.log есть ошибка:
    System task 'SMSSHA_Startup' returned error code 0x87d0027f.

    Вопрос
    - как в данной ситуации правильно организовать процесс миграции пользовательской среды со "старого" ПК на "новый"?
    - сейчас в SCCM я не делаю никаких манипуляций - не удаляю учетные записи ПК, не делаю ассоциацию ПК - это правильно?
    - если "новый" ПК стаким же, как у "старого" ПК именем вводится в домен - учетную запись ПК в SCCM надо каким-либо образом переинициализировать? Как это правильно сделать? 


    • Изменено Anton V. Kotlyarenko 24 января 2014 г. 12:45 добавил пункт 2.1
    14 января 2014 г. 10:30

Ответы

  • Попробуйте пункт 3, выполнить после пункта 6 . Если у вас доменная структура то настройки сайта, MP и.т.д должны браться с AD и DNS - может конечно и не должны, но чтобы облегчить себе жизнь то лучше сделать так. Схему расширяли перед установкой SCCM? Какую версию USMT используете ?     

    • Помечено в качестве ответа Anton V. Kotlyarenko 5 февраля 2014 г. 9:27
    27 января 2014 г. 11:22
  • Когда то у себя в предприятии я наблюдал следующее:

    Создал учетную запись computer в контейнере AD куда смотрит sccm. Эта запись по сути "болванка", лежала там пару дней. Когда я производил миграцию со "старого PC" Windows XP на "старый PC" но уже с Windows 7 и ввода в домен этой машины, я заметил что после установки клиента sccm и адекватной его работы в системе, ресурс не появляется в коллекции "Все системы". Прошло около 5 часов а ситуация не изменялась. Лог adsysdis.log показал следующее:

    После того как sccm пытался в течении определенного времени (не помню сколько попыток было) получить атрибуты записи компьютер которая ещё была "пустой", он сделал очень долгую паузу. То есть в течении этой паузы, он эту запись просто игнорировал - говорил изменений не найдено. И я уже начинал думать как же в итоге заставить его увидеть эту запись компьютера которая была активна . Но спустя вот эти 5 часов, он всё таки обнаружил её и засветил её в коллекции.

    В вашем случае это и происходит. Учетная запись компьютера сброшена, в момент когда у вас выполняется миграция он про эту машину забывает. Но спустя 1-2 часа она снова появляется в системе как активная. Я считаю что это нормальная работа алгоритма по обнаружению систем в sccm.

    Вам не обязательно делать пункт 2.1

    Если вы новый компьютер разворачиваете через sccm, то соответственно он может ввести машину в домен без предварительного сброса учетной записи компьютера. То есть он это сделает за вас. 



    • Изменено Oleg1982 30 января 2014 г. 9:08 опечатка
    • Помечено в качестве ответа Anton V. Kotlyarenko 5 февраля 2014 г. 9:26
    30 января 2014 г. 9:08

Все ответы

  • Привет,

    Посмотрите ссылки внизу:

    Migrate Windows XP to Windows 7 Using USMT (User State Migration Tool) [Upgrade XP or Vista] Step By Step

    How to migrate user data from Windows XP to Windows 8.1 with System Center 2012 R2 Configuration Manager


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий. Не забывайте помечать сообщения как ответы и полезные, если они Вам помогли.


    15 января 2014 г. 9:48
    Модератор
  • Спасибо, но, к сожалению, в указанных руководствах не смог найти, как обойти вышеозначенную проблему. Проблема продолжает возникать как миграции так и при обновлении ПК Windows XP => Windows 7.

    24 января 2014 г. 12:02
  • Проверьте границы клиентов.

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

    24 января 2014 г. 18:29
    Отвечающий
  • С границами тоже вроде все ок.

    В дальнейшем ситуация с клиентом SCCM на Windows 7 выглядит так:
    8. Клиент SCCM "восстанавливается" до нормального состояния примерно через сутки после установки ОС/введения ПК в домен.

    27 января 2014 г. 7:29
  • Попробуйте пункт 3, выполнить после пункта 6 . Если у вас доменная структура то настройки сайта, MP и.т.д должны браться с AD и DNS - может конечно и не должны, но чтобы облегчить себе жизнь то лучше сделать так. Схему расширяли перед установкой SCCM? Какую версию USMT используете ?     

    • Помечено в качестве ответа Anton V. Kotlyarenko 5 февраля 2014 г. 9:27
    27 января 2014 г. 11:22
  • Попробовал п.3 после п.6 - так работает, но долго происходит обнаружение новых систем и установка клиента: через 1-2 часа, мне же по проекту миграции необходимо в течении - 5-10 мин (в тестовой среде так и работало)
    - стоит обнаружение систем Active Directory - раз в день полное, обнаружение изменений - раз в 5 мин. Запуск полного обнаружения вручную - не помогает - установка клиента не начинается.
    - также стоит установка клиента SCCM c обновлениями ОС Windows  - но не работает в филиалах почему-то: ошибка 80072EE2 центра обновлений. Интеграция WSUS-SCCM  настроена.
    В общем пока не ставлю вручную установку клиента на коллекцию ПК филиалов, клиент на новых ПК с ОС Windows 7 сразу не ставится.

    Схема Active Directory расширена.
    USMT сначала использовал 4.0, сейчас перешел на 5.0 для захвата, 6.3 - для восстановления.

    28 января 2014 г. 7:26
  • Не совсем вас понимаю. Что значит обнаружение новых систем и установка клиента ? Вы же устанавливаете клиент в пункте 3. Если у вас стоит автоматическая установка клиента, на новые обнаруженные системы (то есть системы о которых SCCM до этого не знал то есть отсутствующие в базе), то установка клиента не обязательно должна начаться мгновенно. Если вы в процессе миграции через последовательность задач(или вручную) устанавливаете клиента sccm, то после обнаружения системы, об установки клиента не может идти и речи.   

    По поводу обнаружения, контейнеры AD добавлены в "обнаружение систем Active Directory" ? 

    на вашем сервере "Primary Site" есть лог "adsysdis.log" откройте его в cmtrace.exe и посмотрите процесс обнаружения . Есть ли какие нибудь ошибки в этом логе ?

    Откройте консоль вкладку "Мониторинг" состояние компонента "SMS_AD_SYSTEM_DISCOVERY_AGENT" и посмотрите по нему сообщения .

    30 января 2014 г. 3:14
  • В этом, собственно и проблема - 
    необходимо добиться, чтобы на установленной ОС Windows 7 максимально быстро был установлен клиент SCCM для выполнения TS по возврату пользовательских данных, но:
    - если в TS по разворачиванию Windows 7 НЕ устанавливать клиент, клиент SCCM устанавливается через недопустимо долгое время - 1-2 часа
    - если в TS по разворачиванию Windows 7 устанавливать клиент - то возникает проблема описанная в первом посте (и в этом случае клиент становится работоспособным примерно через сутки).

    - контейнеры/субконтейнеры AD добавлены в "обнаружение систем Active Directory" 

    SMS_AD_SYSTEM_DISCOVERY_AGENT:
    Критичных сообщений вообще нет, периодически есть warnings:
    --------
    "Число объектов, об ошибках которых сообщил агент обнаружения системы Active Directory: 1. Число объектов, у которых обнаружены ошибки при чтении некритических свойств и для которых созданы записи данных обнаружения: 0. Число объектов, у которых обнаружены ошибки при чтении критических свойств и для которых не созданы записи данных обнаружения: 1.
    Возможная причина: у сервера сайта, возможно, нет доступа к некоторым свойствам данного объекта. У указанного контейнера, возможно, отсутствуют доступные свойства.
    Решение: проверьте схему Active Directory касательно свойств, которые не являются скопированными или заблокированными. Дополнительные сведения см. в журнале обнаружения"
    -------
    Я так понимаю, это учетные записи ПК в Active Directory, которые еще не используются, т.к - 

    adsysdis.log:
    затерты данные за проблемные дни (10-22/01/14), сейчас есть ошибки только такого вида:
    ERROR: System <pcname> is a unsupported operating system, unsupported version, or malformed AD entry. Reported system type is:  ().
    (это учетные записи ПК в Active Directory, которые еще не используются)
    30 января 2014 г. 7:45
  • Когда то у себя в предприятии я наблюдал следующее:

    Создал учетную запись computer в контейнере AD куда смотрит sccm. Эта запись по сути "болванка", лежала там пару дней. Когда я производил миграцию со "старого PC" Windows XP на "старый PC" но уже с Windows 7 и ввода в домен этой машины, я заметил что после установки клиента sccm и адекватной его работы в системе, ресурс не появляется в коллекции "Все системы". Прошло около 5 часов а ситуация не изменялась. Лог adsysdis.log показал следующее:

    После того как sccm пытался в течении определенного времени (не помню сколько попыток было) получить атрибуты записи компьютер которая ещё была "пустой", он сделал очень долгую паузу. То есть в течении этой паузы, он эту запись просто игнорировал - говорил изменений не найдено. И я уже начинал думать как же в итоге заставить его увидеть эту запись компьютера которая была активна . Но спустя вот эти 5 часов, он всё таки обнаружил её и засветил её в коллекции.

    В вашем случае это и происходит. Учетная запись компьютера сброшена, в момент когда у вас выполняется миграция он про эту машину забывает. Но спустя 1-2 часа она снова появляется в системе как активная. Я считаю что это нормальная работа алгоритма по обнаружению систем в sccm.

    Вам не обязательно делать пункт 2.1

    Если вы новый компьютер разворачиваете через sccm, то соответственно он может ввести машину в домен без предварительного сброса учетной записи компьютера. То есть он это сделает за вас. 



    • Изменено Oleg1982 30 января 2014 г. 9:08 опечатка
    • Помечено в качестве ответа Anton V. Kotlyarenko 5 февраля 2014 г. 9:26
    30 января 2014 г. 9:08
  • Данная ошибка с SMSSHA_Startup нерелевантная.

    Дело в том, что независимо от имен машин - если HWID машин разные, то это будут разные машины с точки зрения SCCM (если не принимать меры). Поэтому странно, что при перезаливке новой машины на W7 вы вообще видите задание на Capture user setting в списке.

    Правильный путь в сценарии переезда с одной физической машины на другую - 2 TS для Capture и Restore + связка в Computer Associations

    2 февраля 2014 г. 8:48
  • По правильному пути, к сожалению, делать не получается, т.к:
    - не известен mac-адрес "нового" ПК (т.к. он буквально достается из коробки в момент мирграции)
    - на "новом" ПК необходимо использовать тоже имя учетной записи ПК Active Directory, что и на "старом" ПК.
     (использование "промежуточного" имени ПК замедлит процесс миграции, что в моей ситуации недопустимо)

    Задание на восстановление на "новом" ПК я вижу нормально только через сутки - вот в этом-то и проблема.
    (причем, после п.6 в SCCM видно, что изменился, как минимум, IP-адрес на IP "нового" ПК, т.е. SCCM нормально "принял" "новый" ПК - никаких задвоений и т.д.)
    Скорее всего, это происходит из-за п.2.1., как это было отмечено выше.

    3 февраля 2014 г. 8:16