Envieu un perfil VPN des d’un recurs compartit de domini i tot funciona, fins al portàtil que no pot arribar al domini. En aquell moment el lliurament depèn justament de la connexió que el perfil existeix per crear. La persona que té aquell portàtil és en un lloc que el servei d’ajuda no veu. Tracteu la primera instal·lació i l’actualització habitual com dos camins separats dins d’un mateix paquet, perquè fallen de maneres que no tenen res en comú.

La primera instal·lació és un problema diferent

Hi ha dos esdeveniments que compten, i només un passa mentre la xarxa col·labora. La taula els separa segons què hi ha disponible, què desencadena la feina i com sol anar malament.

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 artefacte revisat pot servir tots dos camins; la suposició sobre la connectivitat no es pot compartir. Un script d’inici amaga aquesta suposició mentre s’executa en un escriptori de la xarxa corporativa, i la deixa al descobert al camp. L’script no és defectuós, només se li demana que s’executi on ningú no l’ha dissenyat.

Què ha de contenir el paquet

Decidiu cinc coses abans d’empaquetar: quin mecanisme de perfil de Windows és compatible, si l’abast és per usuari o per dispositiu, quins certificats o components de client són prerequisits, què diu la definició del perfil i quina acció l’aplica. ProfileXML és la manera compatible d’expressar la configuració de VPN, lliurada mitjançant el CSP VPNv2, i la guia d’opcions de perfil de Microsoft enumera què pot contenir. Tot el que quedi fora d’aquesta llista és una decisió que preneu sobre la marxa.

Els paràmetres d’un script auxiliar pertanyen a aquell script. Noms com xmlFilePath o AllUserConnection són eleccions d’un autor i no un estàndard que respecti cada instal·lador; copiar-los en un altre script dona una ordre que sembla correcta i no fa res.

Manteniu l’script i la definició sota una sola versió, i auditeu d’on vénen tots dos juntament amb els seus permisos. Un script d’inici privilegiat que resulta llegible des de SYSVOL encara no s’ha revisat, i distribuir per política no és una revisió.

Aconseguir la primera connexió

La primera instal·lació passa mentre el dispositiu encara es pot assolir d’una altra manera: una xarxa aprovada, un canal de gestió existent o un flux d’inscripció dissenyat per a això. Els certificats i els requisits de confiança del mètode d’autenticació triat pertanyen a aquell mateix paquet, ja que res no es pot baixar per un túnel que encara no existeix. Pregunteu quin d’aquests tres canals és real per a aquest usuari abans que algú prometi una data. Un canal que només existeix sobre el paper es converteix en una trucada des del camp.

Escriviu què fa realment el tècnic o l’usuari en aquell moment. Si la resposta és que TI es connecta remotament per ajudar, llavors el camí de la primera instal·lació depèn en silenci d’una segona eina d’accés remot que algú també ha de proporcionar i mantenir.

Les actualitzacions necessiten un estat conegut

Quan la màquina arriba al domini, el procés habitual de domini o de gestió de dispositius pot agafar el relleu. És en l’abast on s’hi colen els errors, perquè un script d’inici s’executa en context de màquina, mentre que una acció d’inici de sessió d’usuari i una acció de gestió de dispositius poden diferir tant en abast com en permisos.

Una entrada de connexió per a tots els usuaris no és un túnel de dispositiu previ a l’inici de sessió, diguin el que diguin els noms. Els túnels de dispositiu tenen els seus propis requisits de plataforma, protocol i credencials, i llegir aquests requisits és l’única manera de saber si aquí és possible un túnel previ a l’inici de sessió. Un túnel d’usuari que comença en iniciar sessió ofereix una garantia diferent.

Feu repetible el camí d’actualització: trobeu el perfil que ja està gestionat, conserveu les preferències d’usuari previstes, apliqueu una definició compatible i informeu un resultat clar. Crear un perfil nou a cada actualització de política és com una màquina acaba amb cinc entrades i un usuari que tria la incorrecta.

El registre que ho manté suportable

Tres respostes pertanyen al traspàs: com obté la primera connexió un dispositiu acabat d’emetre, qui pot canviar el paquet i com un administrador se’n surt d’un canvi incompatible. Amb això escrit, el desplegament ja no depèn d’algú que ja té l’accés que cal aprovisionar.

Guardeu aquest registre al costat de la versió del paquet i actualitzeu tots dos en el mateix canvi. Si no, la persona següent reconstrueix el camí de bootstrap a partir d’un tiquet tancat fa un any.

Articles relacionats