Pourquoi l’ouverture de session par VPN traîne : profil, redirection ou fichiers hors connexion

L’ordinateur portable se connecte en une quarantaine de secondes au bureau et met des minutes à la maison, et personne n’a changé de stratégie entre-temps. Ce qui a changé, c’est le chemin réseau sous trois fonctionnalités qui se ressemblent et se comportent différemment. Un profil itinérant charge l’état du registre et les dossiers du profil, la redirection de dossiers pointe un dossier du shell vers un partage serveur, et les fichiers hors connexion conservent un cache de données réseau éligibles. Les trois peuvent ajouter du temps à une ouverture de session, et une seule en est généralement responsable.

Trois attentes avec trois responsables différents

Le profil itinérant est celui qui fait suivre les paramètres utilisateur d’une personne entre les ordinateurs participants, et le chargement a lieu tôt dans la session. La ruche de registre de l’utilisateur et les dossiers du profil sont copiés ou fusionnés à l’ouverture de session, puis réécrits à la fermeture. Ce travail est synchrone, et c’est pourquoi un chemin lent vers le partage de profils se ressent comme un bureau lent et non comme une copie de fichiers lente.

La redirection de dossiers est un autre mécanisme. Elle déplace des dossiers du shell choisis, Documents étant l’exemple courant, vers un emplacement réseau pris en charge et les y laisse. Le profil peut alors rester petit, parce que les données ne sont pas dedans, et le coût se déplace au moment où le shell ou une application touche ce dossier.

Les fichiers hors connexion ajoutent un cache local et une synchronisation pour les fichiers réseau éligibles. Ils répondent à une autre question, à savoir ce qui se passe quand le serveur est injoignable, et ils peuvent passer du temps à synchroniser à l’ouverture et à la fermeture de session quand le cache est périmé. C’est traiter les trois comme un seul réglage qui produit une stratégie lente dans un sens et inutile dans l’autre.

Mesurez laquelle attend réellement

Commencez par lire où vit le profil et s’il est chargé depuis un chemin serveur. Mesurez ensuite le temps d’une liste de répertoire sur chaque partage que la session touche, car un partage qui répond en millisecondes sur le réseau local peut prendre des secondes à travers un tunnel et un serveur de fichiers occupé.

Ces deux faits circonscrivent le problème plus vite que n’importe quel audit de stratégie, et ils ne demandent aucun changement de configuration pour être recueillis. Exécutez-les sur l’ordinateur portable affecté, pas sur un serveur qui se trouve à côté du partage.

Get-CimInstance Win32_UserProfile | Select-Object LocalPath, Loaded, SID
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*' | Select-Object ProfileImagePath
Measure-Command { Get-ChildItem '\\fs01.corp.internal\profiles\a.singh' | Out-Null }

Si le chemin du profil est local et qu’un seul dossier redirigé pointe vers un serveur, le chargement du profil n’est pas votre attente, quoi qu’en dise le ticket d’assistance. Si le chemin du profil est distant et que la liste prend des secondes, l’ouverture de session attend ce partage, et le correctif porte sur le chemin ou la taille du profil et non sur le bureau lui-même. Lisez les chiffres dans cet ordre et la discussion s’arrête généralement là.

La connexion arrive après le début de l’attente

Un tunnel utilisateur qui démarre depuis le bureau apparaît bien après le chargement du profil, il ne peut donc pas aider l’étape qui était lente. Windows remarque le chemin indisponible, revient à des informations d’identification en cache et à un profil local, et la session finit par s’ouvrir. C’est pourquoi le même ordinateur peut mettre des minutes à la première ouverture de session à la maison et des secondes à la seconde, une fois qu’un profil en cache existe. L’attente est réelle, mais la connexion dont elle a besoin n’existe pas à ce moment-là.

Corriger cela signifie avancer la connexion, pas régler le profil. Un tunnel machine ou une connexion avant ouverture de session avec authentification de l’ordinateur établit le chemin avant que l’utilisateur se connecte, et il a besoin de son propre cycle de vie de certificat et de ses propres règles de pare-feu. Les informations d’identification en cache sont l’autre moitié de la conception, et elles ne fonctionnent que pour les comptes qui se sont déjà connectés.

Testez la séquence plutôt que les composants. Fermez complètement la session, démarrez le tunnel comme le ferait un utilisateur distant, et mesurez l’ouverture de session depuis l’invite d’identification jusqu’à un bureau utilisable.

Gardez les documents hors du profil

Le partage de profils est le mauvais endroit pour de grandes collections de documents, et le guide de déploiement des profils itinérants de Microsoft garde pour cette raison le stockage des profils et les partages de dossiers redirigés séparés. Un profil qui porte un dossier Documents de plusieurs gigaoctets sera lent à chaque ouverture et fermeture de session, et la taille augmente discrètement jusqu’à ce que quelqu’un la mesure.

Redirigez les dossiers qui contiennent des données, et laissez le profil contenir les paramètres. Excluez les caches qui peuvent être reconstruits, comme les caches de navigateur et les données temporaires d’applications, car les transférer ajoute du temps et ne change rien que l’utilisateur voie. Gardez les données de boîte aux lettres et les autres magasins d’applications à l’emplacement que l’application prend en charge, et non sur un chemin itinérant.

Ne rendez pas le partage de profils disponible hors connexion. Les fichiers hors connexion appartiennent aux partages de données éligibles, et une ruche de profil en cache qui se synchronise dans les deux sens est un rapport de corruption qui attend de se produire.

Testez les quatre scénarios avant de le déclarer résolu

Une ouverture de session rapide au bureau prouve très peu. La conception doit survivre à l’accès depuis le bureau, au travail depuis la maison par le tunnel, au travail sans connexion et au retour au bureau, car c’est dans le quatrième cas que les conflits de synchronisation apparaissent. Mesurez les mêmes quatre avec un compte contrôlé et les applications réelles, et notez les chiffres.

Recueillez le journal du service de profils et l’ensemble de stratégie résultant de la session affectée, pas depuis votre station de travail d’administration.

Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 30
gpresult /r /scope:user
Measure-Command { Get-ChildItem '\\fs01.corp.internal\users\a.singh\Documents' | Out-Null }

Comparez ces temps à la référence du bureau et à la taille de ce qui est transféré. Une ouverture de session qui prend encore une minute avec un petit profil et un partage rapide n’est pas un problème de profil, et le prochain endroit à regarder est le traitement de la stratégie de groupe ou un script d’ouverture de session qui attend le réseau. Si l’écart est là, le profil n’a jamais été le problème. Vérifiez que le travail non synchronisé est conservé avant de modifier une stratégie de dossiers ou de vider un cache, car la synchronisation et une sauvegarde récupérable sont des assurances différentes.