У нас есть много тонких клиентов под управлением Windows Embedded Standard 7 и сервера SCCM 2012 R2 для управления ими. На тонких клиентах включены фильтры записи (FBWF), поэтому изменения машины не являются постоянными. В тех редких случаях, когда нам нужно что-то на них обновить, мы просто развертываем это через SCCM, и он автоматически отключает и снова включает фильтры записи для фиксации изменений.
Вот что должен случиться:
Клиент SCCM уведомляет пользователя и делает 30-минутный обратный отсчет, чтобы сохранить его работу и выйти из системы. Затем тонкий клиент перезагружается и отключает фильтр записи. На экране входа в систему отображается замок и уведомление о том, что устройство обслуживается, и не позволит обычным (не администраторам) пользователям входить в систему, пока SCCM делает это. Когда SCCM завершен, он повторно включает фильтр записи, перезагружается, а затем пользователи могут снова войти в систему.
У меня проблема в том, что мы используем считыватели проксимити карт для входа в систему. Сотрудники не вводят пароли. Они просто нажимают свой значок. Эта система хороша, но программное обеспечение, которое ее запускает, нарушает автоматизацию фильтра записи с Windows Embedded.
Вот что фактически бывает:
Клиент SCCM выдает обычное уведомление за 15 минут перед перезагрузкой с отключенным фильтром записи. Когда он перезагружается, нормальный отображается экран входа в систему. Пользователи могут войти в систему и использовать ее, пока SCCM устанавливает программное обеспечение. И поскольку сеанс пользователя активен, он снова дает еще 30-минутное уведомление перед перезагрузкой с снова включенным фильтром записи.
В этом сценарии он не только добавляет дополнительные 30 минут ко времени развертывания, но также дает обычным пользователям 30-60 минут незащищенного времени на тонких клиентах, при этом любые изменения, которые они вносят, навсегда сохраняются в образе, когда фильтр записи снова включается.
Проблема возникает из-за того, что Windows Embedded 7 использует другой поставщик учетных данных (он же GINA), чем обычный Windows 7, но продукт SSO должен заменять поставщик учетных данных Windows для работы. Я связался с поставщиком по этому поводу, но он просто сказал, что это известная проблема и для нее нет исправления или обходного пути.
Итак, вот мой вопрос:
Как я могу имитировать желаемое поведение другим способом? Я знаю, что есть параметр групповой политики, в котором вы можете запретить локальный вход в систему для определенных групп пользователей. Я думал, что могу изменить соответствующий параметр реестра до и после установки, но я открыт для других идей.
Я не выше установки сценариев, если нужно. Я свободно владею сценариями, PowerShell, VBScript и т. Д. Мне просто интересно, есть ли у кого-нибудь какие-нибудь блестящие идеи, как решить эту проблему.
Обновить:
Я забыл упомянуть, что эти устройства используются в больницах, чтобы персонал составлял диаграммы своих пациентов. Они должны быть доступны 24 часа в сутки, поэтому мы не можем ограничивать часы входа в систему или настраивать окна обслуживания. Мы контролируем время простоя, заранее уведомляя начальников смен, но все, что занимает более часа, становится проблемой соблюдения правовых норм и требует введения в действие официальных процедур простоя.
Кажется, никто не коснулся возможности использования последовательности задач для решения этой проблемы, поэтому позвольте мне перечислить преимущества (при условии, что вы не совсем знакомы с ними в целом, но, пожалуйста, прочтите, даже если вы знакомы):
Если все, что вы устанавливаете и настраиваете, обрабатывается с помощью SCCM, вы сможете использовать для этого последовательность задач. В первую очередь для OSD использование TS не только для OSD и может обеспечить следующие преимущества:
Нет входа на рабочую станцию
TS выполняется до запуска winlogon.exe, поэтому нет возможности непреднамеренного входа пользователя в систему, поскольку нет окна входа в систему. Это подводит меня ко второму пункту:
Пользовательский фоновый экран
Вы можете предоставить экран-заставку, который говорит, что выполняется техническое обслуживание, или что угодно, что вы действительно хотите.
TS - это на самом деле просто прославленный сценарий, но он имеет много функций и собран таким образом, чтобы сократить время разработки, и я нашел варианты использования за пределами OSD.
Похоже, у вас уже есть сценарий для выполнения того, что вам нужно, поэтому вы должны иметь возможность поместить его в TS с минимальной отладкой и приступить к работе.
Прежде чем мы начнем, я хочу высказать педантичное замечание, скорее в пользу широких читателей, чем вас самих.
мы просто отправляем его через SCCM
SCCM - это технология на основе вытягивания. Я знаю, что вы имели в виду, но я считаю, что с моими специалистами уровня 1 каждая возможность, которую я получаю, чтобы подчеркнуть, что SCCM не является технологией на основе push, помогает им быстрее понять это.
Я связался с поставщиком по этому поводу, но он просто сказал, что это известная проблема, и для нее нет исправления или обходного пути.
Это очень плохо, так как похоже, что причиной этой проблемы является встроенная программа аутентификации карты. Оставайтесь на стороне поставщика, может быть, они действительно исправят свое программное обеспечение.
Перейдем к настоящему ответу - я вижу для вас несколько возможных решений, но ни одно из них не является особенно хорошим.
Set/Get-Privileges командлеты, которые позволят вам управлять назначениями прав пользователейВы не указали, использует ли программное обеспечение SSO учетные данные Active Directory, поэтому решением может быть использование функции Active Directory «Часы входа в систему». Это на уровне пользователя, но может быть легко написано в Powershell (этот являясь примером). По сути, установите часы входа в систему таким образом, чтобы «запретить» вход в систему в окне обновления SCCM, и пользователи не смогут входить в клиенты, пока SCCM делает свое дело. Вам понадобится первая принудительная перезагрузка, которая выведет их из системы (функция часов входа в систему не работает для зарегистрированных пользователей), но в противном случае ее было бы безболезненно реализовать.
Возможно, захотите проверить это и посмотреть, работает ли это:
Сценарий в начале действия SCCM для выполнения следующих действий:
В конце:
Добавьте участников безопасности, которые вы удалили, обратно в локальную группу пользователей.
Фактические группы, которые вы добавляете / удаляете, могут зависеть от того, как в настоящее время настроены ваши компьютеры.
Что-то более запутанное, начало активности SCCM могло бы скопировать ярлык для logoff.exe в папку All Users Start Menu \ Startup (обычно C: \ ProgramData \ Microsoft \ Windows \ Start Menu \ Programs \ StartUp). Это приведет к выходу из сеанса сразу после входа в систему. На всякий случай вам может понадобиться сценарий запуска / выключения для удаления этого ярлыка. (Я считаю, что ярлыки запуска можно обойти, удерживая клавишу Shift во время входа в систему).