Série de implantação do Office 365 com MEMCM - Lições aprendidas de implantação corporativa Parte 4 - Linha de base - Notificações do sistema

Nesta postagem, vou cobrir como estamos usando uma linha de base ConfigMgr para controlar a experiência do usuário. Não estou sugerindo que todos façam dessa maneira, mas, para nós, queríamos fornecer uma boa experiência do usuário, mesmo para aqueles com links lentos, e torná-la bonita, ao mesmo tempo que parecia legítima e nativa.

A linha de base Microsoft 365 é como controlamos duas coisas, o aplicativo Microsoft 365 no Centro de software e a Notificação de notificação do 365. A linha de base consiste em dois itens de configuração, um executado como sistema para determinar o estado da máquina e outro executado no contexto do usuário final para exibir uma notificação do sistema. O PreReq CI habilita ou desabilita o Toast Launch CI, então realmente queríamos que o PreReq CI fosse executado e corrigido antes do Toast Launch CI ... o que nunca foi possível fazer, mais sobre isso mais tarde.

Scripts

  • Descoberta Pré-Req [O script de descoberta também está sendo usado para fazer alterações, que normalmente seriam divididas em 2 scripts, este casal é uma postagem própria]
  • Descoberta de lançamento de brinde [Verifica a chave de registro que diz ao CI para iniciar o Toast (executar o script de correção) ou voltar a dormir]
  • Correção de lançamento de brinde [Este é o conteúdo real do brinde e provavelmente precisa de uma postagem própria]

A linha de base no console:

Originalmente, tínhamos colocado isso em um CI com duas configurações diferentes, mas queríamos tentar controlar a ordem de operação, o que simplesmente não é possível. Existe um UserVoice por aí agora que nos permite controlá-lo, mas por enquanto, não podemos. Queríamos que o Pre Req Discovery e o Remediation fossem executados antes que o Toast Notification Launch Discovery fosse executado, mas descobrimos que os Baselines executam tudo em série.

Ou seja, para todos os ICs em uma linha de base, ele passará por cada um dos scripts de descoberta na passagem 1, depois voltará na passagem 2 e executará quaisquer scripts de correção para ICs que tenham correção que foram sinalizados como não compatíveis.

Por esse motivo, combinamos a descoberta e a correção em um script e os colocamos na seção Descoberta para os pré-requisitos, para podermos executar e definir itens nos quais o script de descoberta de inicialização do Toast depende ... mas mesmo isso foi provado apenas parcialmente útil.

Vejamos primeiro o Pre-Req CI.

  • Funciona como sistema
  • Verificações
  •   Verifica o conteúdo do M365 no CCMCache
  •   Verifica se o M365 já está instalado
  •   Verifica se a implantação do canal semestral Microsoft 365 é direcionada à máquina e, se for, está visível no Centro de software
  •   Verifica se a implantação do canal semestral Microsoft 365 é direcionada à máquina e, em caso afirmativo, verifica se o prazo limite exigido

Com base nos valores retornados, ele executa ações diferentes. Atualmente, contabilizamos 15 diferentes permutações desses valores.

Vamos analisar alguns cenários: [você verá uma lista completa no script das 15 declarações de caso]

  1. Conteúdo do M365 NÃO em cache, M365 NÃO instalado: O Baseline verá que a máquina NÃO tem o conteúdo e que o M365 ainda NÃO está instalado. Isso garantirá que o aplicativo não apareça no Centro de software até que o conteúdo esteja disponível.
  2. Conteúdo do M365 em cache, M365 NÃO instalado: O Baseline verá que a máquina tem o conteúdo e que o M365 ainda não está instalado. Isso garantirá que o aplicativo (canal semestral Microsoft 365) esteja disponível no centro de software (visível), removerá o prazo e definirá uma chave de registro para habilitar a notificação do sistema.
  3. Conteúdo do M365 em cache, o M365 está instalado: O Baseline verá que o M365 já está instalado. Ele definirá uma chave de registro para desativar a notificação do sistema.

Embora existam outras opções, essas são as grandes.

Ações que o CI realizará

  • Alterne a política de implantação de aplicativos no WMI (“ROOT \ ccm \ Policy \ (USER GUID \ ActualConfig classname =“ CCM_ApplicationCIAssignment ”)
  •   Alterna UserUIExperience de False para True (isso o tornará visível no centro de software)
  •   Exclui a propriedade EnforcementDeadline (isso mudará o aplicativo de obrigatório com um prazo para "disponível" no Centro de Software)
  • Alterna a chave de registro personalizada [HKLM \ SOFTWARE \ SWD \ O365 - Propriedade: Enable_0365_Toast - Valor: Verdadeiro ou Falso]

Cliente: você verá a linha de base de notificação de autoatendimento Microsoft 365.

Registro do lado do cliente:

Quando a máquina obtém a política pela primeira vez, mas ainda não baixou o conteúdo.

Depois que o conteúdo for baixado, você verá um pouco mais de ação aqui: (Observe que nossa descoberta e correção estão no mesmo script, e o script está no script de "descoberta" no CI. NÃO estamos usando o script de correção no CI.

Nesta imagem, você está vendo que o CI detecta que o conteúdo do MS Office foi armazenado em cache no cache do CCM e que o M365 ainda não foi instalado. Ele também vê que o aplicativo ainda não está visível no centro de software, e o registro não foi configurado para habilitar o Toast
Em seguida, ele executa a Correção para habilitar o aplicativo na central de software, remover o prazo e definir a chave de registro para habilitar o brinde
Nesta execução do Baseline, ele vê que tudo já está bom e nenhuma alteração é necessária.

Esses são os registros do item de configuração “PreReq”, que registra toc: \ windows \ temp \ o365_baseline.log

Agora para o lançamento do Toast CI
  • É executado no contexto do usuário (portanto, o Toast será exibido em seu contexto e visto pelo usuário final)
  • Verifica o valor do registro HKLM \ Software \ SWD \ O365 - Enable_0365_Toast

Valor de registro:

Aqui, o valor é definido como falso, porque a máquina de onde o capturei já tem o M365 instalado. A linha de base viu que o M365 foi instalado e alternou essa configuração de True para False para que o Toast não fosse mais iniciado. Não adianta lançar um Toast para as pessoas instalarem se já instalaram o M365!

O Launch-Toast Log é executado como o usuário final, portanto, os registros vão para a pasta temporária do usuário final (c: \ users \ 1TP1Nomedeusuário% \ appdata \ local \ temp \ o365_baseline.log)

O CI tem dois Scripts
  • Script de descoberta
  •  Se a chave de registro = True ... Relatório de não conformidade ao CM, que ativará a correção
  •  If Registry Key = False… Report Compliant ao CM e não executa a correção.
  • Script de Remediação

Vamos dar uma olhada nos logs que podem ajudar a explicar mais.

Aqui você pode ver se o CI é executado e a chave do registro está definida como falsa, ele não faz nada e volta a hibernar. Se a chave do Registro estiver definida como True, ele dispara a notificação do sistema:

The Toast Image: (The Launch Toast Remediation Script)

Isso explica como funciona o brinde ... A linha de base funciona.
Os scripts estão todos no GitHub e tentei adicionar muitos comentários, mas se você acha que eles merecem blogs, me avise -Gary

Confira as outras postagens desta série:

Lições aprendidas de implantação empresarial - Parte 1 - Conteúdo

Lições aprendidas de implantação corporativa - Parte 2 - Mudando de canal

Lições aprendidas de implantação corporativa, parte 3 - implantações

Veja como Right Click Tools está mudando a forma como os sistemas são gerenciados.

Aumente imediatamente a produtividade com o nosso limitado e gratuito, Community Edition.

Comece com Right Click Tools hoje:

Compartilhar isso:

Suporte

  • Este campo é para fins de validação e não deve ser alterado.

Contato

  • Este campo é para fins de validação e não deve ser alterado.
pt_BRPortuguese