Temos muitos thin clients executando o Windows Embedded Standard 7 e um servidor SCCM 2012 R2 para gerenciá-los. Os thin clients têm seus filtros de gravação ativados (FBWF) para que as alterações na máquina não sejam persistentes. Nas raras ocasiões em que precisamos atualizar algo sobre eles, apenas o implantamos via SCCM e ele automaticamente se encarrega de desativar e ativar os filtros de gravação para confirmar as alterações.
Eis o que deve acontecer: o
cliente SCCM avisa o usuário e uma contagem regressiva de 30 minutos para salvar seu trabalho e sair do sistema. O thin client então reinicia e desativa o filtro de gravação. A tela de logon exibe um cadeado e percebe que a unidade está sendo reparada, e não permitirá que usuários normais (não administradores) façam logon enquanto o SCCM estiver fazendo isso. Quando o SCCM é concluído, ele reativa o filtro de gravação, reinicia e os usuários podem efetuar login novamente.
O problema que estou tendo é que usamos leitores de cartão de proximidade para fazer login no sistema. Os funcionários não digitam senhas. Eles apenas tocam em seu crachá. Esse sistema é bom, mas o software que o executa interrompe a automação do filtro de gravação com o Windows Embedded.
Aqui está o que realmente acontece: o
cliente SCCM emite o aviso habitual de 15 minutos antes de reiniciar com o filtro de gravação desativado. Quando ele é reiniciado, a tela de login normal é exibida. Os usuários podem efetuar login no sistema e usá-lo enquanto o SCCM está instalando o software. E como uma sessão do usuário está ativa, ela novamente avisa 30 minutos antes de reiniciar com o filtro de gravação novamente.
Nesse cenário, ele não apenas adiciona 30 minutos extras ao tempo de implantação, mas também oferece aos usuários comuns 30-60 minutos sólidos de tempo desprotegido nos thin clients com as alterações que eles fizerem, ficando permanentemente inseridas na imagem quando o o filtro de gravação é ativado novamente.
O problema decorre do fato de o Windows Embedded 7 usar um provedor de credenciais diferente (também conhecido como GINA) do que o Windows 7 comum, mas o produto SSO deve substituir o provedor de credenciais do Windows para funcionar. Entrei em contato com o fornecedor, mas eles dizem que é um problema conhecido e que não há solução ou solução alternativa para ele.
Então, aqui está minha pergunta:
como posso simular o comportamento desejado de outra maneira? Eu sei que existe uma configuração de diretiva de grupo em que você pode negar o logon local para grupos de usuários específicos. Eu estava pensando em mudar a configuração de registro correspondente antes e depois da instalação, mas estou aberto a outras idéias.
Não estou acima das instalações de script, se necessário. Sou fluente em scripts, PowerShell, VBScript, etc. Gostaria de saber se alguém tem alguma idéia brilhante sobre como resolver isso.
Atualização:
Eu esqueci de mencionar que esses dispositivos estão sendo usados em um ambiente hospitalar para que a equipe registre seus pacientes. Eles devem estar disponíveis 24 horas por dia, portanto, não podemos restringir o horário de logon ou configurar as janelas de manutenção. Gerenciamos o tempo de inatividade, mediante aviso prévio aos supervisores de turno, mas qualquer coisa que leve mais de uma hora se torna um problema de conformidade legal e exige que os procedimentos oficiais de tempo de inatividade sejam implementados.
Respostas:
Antes de começarmos, quero fazer uma observação pedante, mais para o benefício do público em geral do que para você.
O SCCM é uma tecnologia baseada em pull. Eu sei o que você quis dizer, mas acho que, com meus funcionários de nível 1, todas as oportunidades que tenho para enfatizar que o SCCM não é uma tecnologia baseada em push os ajudam a entendê-lo mais rapidamente.
Isso é muito ruim, pois parece que a causa desse problema é o programa de autenticação de cartão incorporado. Continue com o fornecedor, talvez eles consertem seu software.
Para uma resposta real - vejo algumas soluções possíveis para você, nenhuma delas particularmente boa.
Set/Get-Privilegescmdlets que permitirão manipular as Atribuições de Direitos do Usuáriofonte
secedit.exeatravés de um script. Não estou falando sobre o uso da Diretiva de Grupo do Active Directory, pois o tempo de pesquisa aleatória não funcionará para sua janela de manutenção.Parece que ninguém tocou na possibilidade de usar uma sequência de tarefas para lidar com isso, então permita-me listar os benefícios (supondo que você não esteja realmente familiarizado com eles em geral, mas leia mesmo se estiver):
Se tudo o que você instalar e configurar for tratado com SCCM, você poderá usar uma sequência de tarefas para fazer isso. Principalmente para OSD, o uso de um TS não é apenas para OSD e pode fornecer os seguintes benefícios:
Um TS é executado antes da execução do winlogon.exe; portanto, não há possibilidade de um usuário fazer logon inadvertidamente, pois não há uma janela de logon. O que me leva ao meu segundo ponto:
Você pode fornecer uma tela inicial informando que a manutenção está sendo executada ou o que você deseja que realmente diga.
Um TS é realmente apenas um script glorificado, mas tem muitas funcionalidades e é organizado de maneira a diminuir o tempo de desenvolvimento, e eu encontrei casos de uso além do OSD.
Parece que você já possui um script para fazer o que precisa, portanto, você poderá colocá-lo em um TS com o mínimo de depuração e continuar.
fonte
Você não especificou se o software SSO usa credenciais do Active Directory; portanto, uma solução seria usar a função "Horas de logon" do Active Directory. É no nível por usuário, mas pode ser facilmente script no Powershell ( este é um exemplo). Basicamente, defina as horas de logon para "negar" o logon na janela de atualização do SCCM e os usuários não conseguirão efetuar logon nos clientes enquanto o SCCM faz suas tarefas. Você precisará ter a primeira reinicialização forçada que fará logoff (a função de horas de logon não funciona em usuários logados), mas, caso contrário, seria indolor de implementar.
fonte
Pode querer testar isso e ver se funciona:
Um script no início da atividade do SCCM para fazer o seguinte:
No fim:
Adicione as entidades de segurança que você removeu de volta ao grupo local Usuários
Os grupos reais que você adiciona / remove podem depender de como os computadores estão configurados no momento.
Algo um pouco mais estacionário, o início da atividade do SCCM pode copiar um atalho para logoff.exe na pasta Todos os Usuários Iniciar Menu \ Inicialização (normalmente C: \ ProgramData \ Microsoft \ Windows \ Menu Iniciar \ Programas \ StartUp). Isso teria o efeito de fazer logoff de uma sessão assim que eles fizerem logon. Para ser seguro, convém ter um script de inicialização / desligamento para excluir esse atalho. (Acredito que os atalhos de inicialização podem ser ignorados mantendo a tecla Shift pressionada durante o logon).
fonte