Implementación de Office 365 con MEMCM: lecciones aprendidas, parte 4

En esta publicación, cubriré cómo estamos usando una línea de base ConfigMgr para controlar la experiencia del usuario. No estoy sugiriendo que todos lo hagan de esta manera, pero para nosotros, queríamos brindar una buena experiencia de usuario, incluso para aquellos en enlaces lentos, y hacer que se vea bonito sin dejar de parecer legítimo y nativo.

La línea de base Microsoft 365 es cómo controlamos dos cosas, la aplicación Microsoft 365 en el centro de software y la notificación de 365 Toast. La línea base consta de dos elementos de configuración, uno que se ejecuta como un sistema para determinar el estado de la máquina y otro que se ejecuta en el contexto del usuario final para mostrar una notificación del sistema. PreReq CI habilita o deshabilita Toast Launch CI, por lo que realmente queríamos que PreReq CI se ejecutara y remediara antes que Toast Launch CI... lo cual nunca pudimos hacer, más sobre eso más adelante.

Guiones

La línea de base en la consola:

Originalmente los habíamos puesto en un CI con dos configuraciones diferentes, pero queríamos intentar controlar el orden de operación, lo cual simplemente no es posible. Hay una UserVoice ahora que nos permite controlarla, pero por ahora, no podemos. Queríamos que el descubrimiento de requisitos previos y la corrección se ejecutaran antes de que se ejecutara el descubrimiento de lanzamiento de notificaciones de Toast, pero descubrimos que las líneas de base ejecutan todo en serie.

Es decir, para todos los CI en una línea de base, pasará por cada uno de los scripts de descubrimiento en el Paso 1, luego regresará en el Paso 2 y ejecutará cualquier script de remediación para los CI que tengan una remediación marcada como No conforme.

Por esta razón, combinamos Discovery y Remediation en un solo script y lo colocamos en la sección Discovery para los Pre-Reqs, para poder ejecutar y establecer elementos en los que se basa Toast Launch Discovery Script... pero incluso esto ha demostrado ser solo parcialmente. útil.

Veamos primero el prerrequisito de CI.

  • Funciona como sistema
  • Cheques
  •   Comprobaciones del contenido de M365 en CCMCache
  •   Comprueba si M365 ya está instalado
  •   Comprueba si la implementación del canal semianual Microsoft 365 está dirigida a la máquina y, de ser así, si está visible en el Centro de software
  •   Comprueba si la implementación del canal semestral Microsoft 365 está dirigida a la máquina y, de ser así, comprueba si tiene una fecha límite requerida

En función de los valores devueltos, realiza diferentes acciones. Actualmente, contamos con 15 permutaciones diferentes de esos valores.

Tomemos algunos escenarios: [verá una lista completa en el guión de las 15 declaraciones de casos]

  1. Contenido de M365 NO almacenado en caché, M365 NO instalado: Baseline verá que la máquina NO tiene el contenido y que M365 NO está instalado. Se asegurará de que la aplicación no aparezca en el Centro de software hasta que el contenido esté disponible.
  2. Contenido de M365 almacenado en caché, M365 NO instalado: La línea de base verá que la máquina tiene el contenido y que M365 aún no está instalado. Se asegurará de que la aplicación (Canal semianual Microsoft 365) esté disponible en el centro de software (visible), eliminará la fecha límite y establecerá una clave de registro para habilitar la notificación del brindis.
  3. Contenido de M365 en caché, M365 está instalado: La línea de base verá que M365 ya está instalado. Establecerá una clave de registro para deshabilitar la notificación del brindis.

Si bien hay otras opciones, esas son las más importantes.

Acciones que tomará la IC

  • Alternar la política de implementación de aplicaciones en WMI ("ROOT\ccm\Policy\(USER GUID\ActualConfig class name = "CCM_ApplicationCIAssignment")
  •   Alterna UserUIExperience de False a True (Esto lo hará visible en el centro de software)
  •   Elimina la propiedad EnforcementDeadline (esto cambiará el formulario de solicitud requerido con una fecha límite a "disponible" en el Centro de software)
  • Alterna la clave de registro personalizada [HKLM \ SOFTWARE \ SWD \ O365 - Propiedad: Enable_0365_Toast - Valor: Verdadero o Falso]

Cliente: Verá la línea de base de notificación de autoservicio Microsoft 365.

Registro del lado del cliente:

Cuando la máquina obtiene la política por primera vez pero aún no ha descargado el contenido.

Después de que se descargue el Contenido, verá un poco más de acción aquí: (Tenga en cuenta que nuestro Descubrimiento y Remediación están en el mismo script, y el script está en el Script de "Descubrimiento" en el CI. NO estamos usando el Remediation Guión en el CI.

En esta imagen, está viendo que CI Detecta que el contenido de MS Office se ha almacenado en caché en CCM Cache y que M365 aún no está instalado. También ve que la aplicación aún no está visible en el centro de software, y el Registro no se ha configurado para habilitar el Toast
Luego ejecuta Remediation, para habilitar la aplicación en el centro de software, eliminar la fecha límite y configurar la clave de registro para habilitar el brindis.
En esta ejecución de Baseline, parece que todo ya está bien y no se necesitan cambios.

Esos son registros del elemento de configuración "PreReq", que se registra en c: \ windows \ temp \ o365_baseline.log

Ahora al Launch Toast CI
  • Se ejecuta en el contexto del usuario (por lo que el Toast se mostrará en su contexto y el usuario final lo verá)
  • Comprueba el valor del registro HKLM \ Software \ SWD \ O365 - Enable_0365_Toast

Valor de registro:

Aquí el valor se establece en falso porque la máquina desde la que lo capturé ya tiene M365 instalado. Baseline vio que M365 estaba instalado y cambió esta configuración de Verdadero a Falso para que Toast ya no se iniciara. ¡No tiene sentido lanzar un Toast para que la gente lo instale si ya instalaron M365!

El registro de Launch-Toast se ejecuta como el usuario final, por lo que los registros van a la carpeta temporal del usuario final (c: \ users \ %username% \ appdata \ local \ temp \ o365_baseline.log)

El CI tiene dos Scripts
  • Guión de descubrimiento
  •  Si la clave de registro = Verdadero… Informe que no cumple con CM, lo que activará la corrección
  •  Si la clave de registro = Falso… Informe conforme a CM y no ejecute Remediación.
  • Guión de corrección

Veamos los registros que podrían ayudar a explicar más.

Aquí puede ver si el CI se ejecuta y la clave de registro está configurada como falsa, no hace nada y vuelve a dormir. Si la clave del registro se establece en True, activa la notificación de brindis:

La imagen de Toast: (El guión de corrección de Launch Toast)

Eso explica cómo funciona el brindis ... Baseline funciona.
Todos los scripts están en GitHub y he intentado agregar muchos comentarios, pero si crees que se merecen blogs, házmelo saber -Gary

Consulte las otras publicaciones de esta serie:

Lecciones aprendidas de implementación empresarial, parte 1: contenido

Lecciones aprendidas de implementación empresarial Parte 2: Cambio de canales

Lecciones aprendidas sobre implementación empresarial Parte 3: Implementaciones

Vea cómo Right Click Tools está cambiando la forma en que se administran los sistemas.

Aumente la productividad de inmediato con nuestra versión limitada y gratuita de la edición Community.

Comience con Right Click Tools hoy:

Ayuda

  • Este campo es para fines de validación y no debe modificarse.

Contacto

  • Este campo es para fines de validación y no debe modificarse.

Al enviar este formulario, comprende que Recast Software puede procesar sus datos como se describe en el Recast Software Política de privacidad.

es_MXSpanish