Distribuya un perfil VPN desde un recurso compartido de dominio y todo funciona, hasta el portátil que no puede llegar al dominio. En ese momento la entrega depende de la propia conexión que el perfil existe para crear. Quien sostiene ese portátil está en algún lugar que el servicio de ayuda no ve. Trate la primera instalación y la actualización habitual como dos rutas separadas dentro de un mismo paquete, porque ambas fallan de formas que no tienen nada en común.

La primera instalación es un problema distinto

Importan dos sucesos, y solo uno ocurre mientras la red colabora. La tabla los separa por lo que hay disponible, lo que desencadena el trabajo y cómo suele salir mal.

First installRoutine update
Network reachableSomething other than the VPN being installedThe domain or a management channel
TriggerEnrollment, imaging, or a prepared packageA policy refresh or a management push
Usual failureNo route to the package at allDuplicate profiles, or a change that silently does nothing

Un artefacto revisado puede servir a ambas rutas; la suposición sobre la conectividad no se puede compartir. Un script de inicio oculta esa suposición mientras se ejecuta en un escritorio de la red corporativa, y la deja al descubierto en campo. El script no es defectuoso, simplemente se le pide ejecutarse donde nadie lo diseñó para ejecutarse.

Lo que debe contener el paquete

Decida cinco cosas antes de empaquetar: qué mecanismo de perfil de Windows está admitido, si el ámbito es por usuario o por dispositivo, qué certificados o componentes de cliente son requisitos previos, qué dice la definición del perfil y qué acción la aplica. ProfileXML es la forma admitida de expresar la configuración de VPN, entregada mediante el CSP VPNv2, y la guía de opciones de perfil de Microsoft enumera lo que puede contener. Todo lo que quede fuera de esa lista es una decisión que usted toma sobre la marcha.

Los parámetros de un script auxiliar pertenecen a ese script. Nombres como xmlFilePath o AllUserConnection son elecciones de un autor y no un estándar que todo instalador respete; copiarlos en otro script produce un comando que parece correcto y no hace nada.

Mantenga el script y la definición en una misma versión, y audite de dónde vienen ambos junto con sus permisos. Un script de inicio privilegiado que resulta legible desde SYSVOL sigue sin haber sido revisado, y distribuir por directiva no es revisar.

Conseguir la primera conexión

La primera instalación ocurre mientras el dispositivo aún puede alcanzarse de otra forma: una red aprobada, un canal de gestión existente o un flujo de inscripción diseñado para ello. Los certificados y los requisitos de confianza del método de autenticación elegido pertenecen a ese mismo paquete, ya que nada puede descargarse por un túnel que todavía no existe. Pregunte cuál de esos tres canales es real para este usuario antes de que alguien prometa una fecha. Un canal que solo existe en el papel se convierte en una llamada desde el campo.

Anote lo que el técnico o el usuario hace realmente en ese momento. Si la respuesta es que TI se conecta en remoto para ayudar, entonces la ruta de primera instalación depende en silencio de una segunda herramienta de acceso remoto que alguien también debe aprovisionar y mantener.

Las actualizaciones necesitan un estado conocido

Cuando la máquina llega al dominio, puede tomar el relevo el proceso habitual de dominio o de gestión de dispositivos. Los errores se cuelan en el ámbito, porque un script de inicio se ejecuta en contexto de máquina, mientras que una acción de inicio de sesión de usuario y una acción de gestión de dispositivos pueden diferir tanto en ámbito como en permisos.

Una entrada de conexión para todos los usuarios no es un túnel de dispositivo previo al inicio de sesión, digan lo que digan los nombres. Los túneles de dispositivo tienen sus propios requisitos de plataforma, protocolo y credenciales, y leer esos requisitos es la única forma de saber si aquí es posible un túnel previo al inicio de sesión. Un túnel de usuario que arranca al iniciar sesión ofrece una garantía distinta.

Haga repetible la ruta de actualización: encuentre el perfil que ya está gestionado, conserve las preferencias de usuario previstas, aplique una definición compatible e informe un resultado claro. Crear un perfil nuevo en cada actualización de directiva es como una máquina acaba con cinco entradas y un usuario que elige la equivocada.

El registro que lo mantiene soportable

Tres respuestas pertenecen al traspaso: cómo obtiene su primera conexión un dispositivo recién emitido, quién puede cambiar el paquete y cómo revierte un administrador un cambio incompatible. Con eso escrito, el despliegue deja de depender de alguien que ya tiene el acceso que se aprovisiona.

Guarde ese registro junto a la versión del paquete y actualice ambos en el mismo cambio. De lo contrario, la siguiente persona reconstruye la ruta de bootstrap a partir de un ticket cerrado hace un año.

Artículos relacionados