Обновить:
Приведенный ниже вопрос был решен с помощью принятого ниже ответа. Однако настоящая причина проблемы была в ошибке. Я добавил еще один ответ на этот вопрос ниже, который содержит сведения об этой ошибке, а также сведения о выпущенном решении для исправления.
Вопрос:
В моей организации есть лаборатория компьютеров, образ которой нужно менять каждую неделю. В настоящее время мы делаем это через SCCM 2007. На данный момент это делается путем создания нового обязательного объявления каждую неделю для рабочей последовательности задач OSD (TS). Однако я хотел бы сделать это, установив одно рекламное объявление на повторяющийся график.
Для многократного запуска TS на машине необходимо включить опцию объявления «Всегда перезапускать программу», иначе TS будет запускаться только один раз.
Проблема, с которой я сталкиваюсь, заключается в том, что при повторном создании образа машины устанавливается новый клиент и, таким образом, создается новый GUID. Это означает, что я должен предоставить некоторый автоматический способ считывания этого нового идентификатора GUID клиента в коллекцию, в которой рекламируется повторяющийся TS. Конечно, поскольку у клиента есть новый GUID, это означает, что SCCM считает, что TS еще не запущен на этой машине, и начинает переоснащение, как только оно будет считано в коллекцию, таким образом фактически помещая машину в бесконечный цикл восстановления.
Я подумал о том, чтобы просто встроить клиента в образ, чтобы он поддерживал тот же GUID через повторное изображение, но с этим подходом есть и другие проблемы.
Есть ли предложения о том, как настроить повторяющийся TS, который будет обновлять образ машины один раз в неделю?
Редактировать:
Чтобы прояснить некоторые моменты, я объясню ситуацию немного лучше:
Последовательность задач OSD, которую я пытаюсь запустить, займет около полутора часов, и это произойдет около 3 часов ночи. После завершения развертывания ОС потребуется запустить другой TS, чтобы установить последнюю программу, которая должна быть выполнена через отдельный TS из-за определенных программных ограничений.
Во-вторых, когда я говорю о GUID выше, я на самом деле имею в виду GUID SMS, который назначается вновь установленным клиентам ConfigMgr. Конечно, есть и другие причины, по которым будет создан новый SMS GUID, но в данной ситуации это не имеет значения.
Детали решения:
С предложением от newmanth ниже я сделал следующее, чтобы решить эту проблему:
Для последовательности задач OSD и связанной рекламы я установил следующие параметры:
Для коллекции, содержащей рассматриваемые компьютеры, я использовал следующие настройки:
Продолжительность окна обслуживания : 3–4:35, повторяется раз в неделю.
Я также проверяю параметр «Это расписание применяется только к последовательностям задач развертывания операционной системы». Это позволяет мне запускать мой второй TS, упомянутый выше, вне окна обслуживания, но предотвращает повторное восстановление сразу после повторного добавления клиента в коллекцию.
Окно обслуживания должно быть больше или равно максимальному времени работы TS или программы плюс продолжительность обратного отсчета агента клиента объявленных программ (у меня было установлено 5 минут). Поскольку максимальное время работы моего TS будет 90 минут, мне придется установить окно на 95 минут.
График обновления членства в коллекции : 4:45, повторяется ежедневно.
Ремонт завершен, окно технического обслуживания закрыто в 4:35. Теперь я жду 10 минут для хорошей оценки и планирую обновление членства в коллекции, чтобы повторно добавить недавно установленный клиент. Я мог бы делать это еженедельно в тот же день, что и восстановление, но я делаю это ежедневно по другим причинам.
В зависимости от того, как ваша коллекция добавляет новых клиентов, вам также может потребоваться запланировать запуск ваших методов обнаружения до того, как произойдет это обновление. Например, если ваша коллекция добавляет новых членов-клиентов на основе группы Active Directory, вам необходимо сначала запустить соответствующие методы обнаружения Active Directory, чтобы во вновь созданной записи клиента была заполнена соответствующая информация Active Directory. В противном случае в новой записи клиента не будет информации о группе AD, и она не будет добавлена в коллекцию.
С указанными выше настройками процесс восстановления должен выглядеть примерно так:
Я думаю, вы могли бы заставить это работать, установив раз в неделю окно обслуживания для рассматриваемой коллекции в сочетании с постоянным повторным запуском рекламы. Убедитесь, что окно достаточно длинное, чтобы разрешить показ рекламы один раз. Это предотвратит последующий запуск, пока снова не наступит период обслуживания. Технет: http://technet.microsoft.com/en-us/library/bb632801.aspx
Принятый ответ на этот вопрос действительно помог мне настроить рабочее решение для описанных обстоятельств, и использование указанных выше настроек в моем добавленном решении будет работать. Однако оказалось, что в этом не было необходимости, поскольку настоящая проблема, лежащая в основе моей проблемы, была связана с ошибкой SCCM 2007, которая с тех пор была исправлена.
http://support.microsoft.com/kb/977203
Не позволяйте названию этой статьи базы знаний вводить вас в заблуждение, поскольку эта конкретная ошибка затрагивает больше вещей в SCCM 2007, чем то, на что она изначально указывает.
Заметка: Хотя это исправление было заменено несколькими другими исправлениями, утилита CCMCertFix.exe, которая поставляется с этим исправлением, в частности, все еще необходима и поставляется только с этим конкретным исправлением.
Вот отрывок из KB2028442 что объясняет, что происходит:
Проблема вызвана самоподписанными сертификатами, автоматически созданными клиентом ConfigMgr 2007 в смешанном режиме. Если KB977203 Патч клиента ConfigMgr 2007 не был установлен на клиентском ПК при создании сертификатов, тогда сертификаты будут иметь встроенный символ NULL в понятном имени, как описано в KB974571.
Когда для обновления ПК используется последовательность задач экранного меню, сертификаты клиентов ConfigMgr 2007 переносятся из старой ОС Windows в новую ОС Windows. Если клиентские сертификаты ConfigMgr 2007 в исходной ОС Windows содержат встроенный символ NULL в понятное имя, как описано в KB974571, и если KB974571 устанавливается как часть эталонного образа, развертываемого последовательностью задач, затем при установке новой ОС Windows KB974571 заблокирует перенос сертификата клиента ConfigMgr 2007 со встроенным символом NULL в понятном имени. Это приведет к сбою установки клиента ConfigMgr 2007.
Теперь в моем случае клиенты устанавливались нормально, но из-за этого символа NULL сертификаты все еще не переносились должным образом, и в результате он просто создавал новые записи клиентов в SCCM с разными GUID SMS. Следовательно, каждый раз, когда я перестраивал клиентскую машину, мне приходилось запускать обновление членства в коллекции, чтобы повторно добавить клиента в коллекцию. Конечно, поскольку ConfigMgr думает, что это новый клиентский компьютер, у него нет записей о том, что он когда-либо запускал последовательность задач OSD, и поэтому немедленно запускает ее снова, эффективно помещая ее в бесконечный цикл восстановления.
После применения этого исправления к клиенту (на самом деле я использую KB977384 исправление, которое заменяет его), а затем запустив утилиту CCMCertFix перед запуском последовательности задач OSD, я больше не получу новые GUID SMS для клиентов, которые были недавно перестроены, и, следовательно, больше не нужно повторно добавлять клиента в коллекцию и OSD TS теперь увидит, что он только что успешно запустился на клиенте, и больше не будет пытаться его восстановить.
Утилиту CCMCertFix.exe необходимо запустить до запуска TS. Это означает, что он не будет работать как шаг в вашем TS. Для этого вы должны перейти в свойства TS и на вкладке «Дополнительно» есть опция «Сначала запустить другую программу». Вам также необходимо установить опцию «Всегда запускать эту программу в первую очередь».
Чтобы получить утилиту CCMCertFix.exe, необходимо установить KB977203 исправление на сервере, для которого вам будет предложено автоматически создать для него пакет. Используя созданный пакет, добавьте новую программу, просто запустив утилиту CCMCertFix.exe.
Для меня не имело значения, что я уже установил KB977384 первое, которое заменяет это исправление. Он по-прежнему успешно работал и создал для меня пакет. Мне также не нужно было развертывать это исправление на клиентах, поскольку я уже применял KB977384 исправление.