Migrer l’accès à distance vers Windows Server 2012

S'applique à: Windows Server 2012

Le service Routage et accès distant (RRAS) est une fonctionnalité des systèmes d’exploitation Windows Server antérieurs à Windows Server 2012 qui vous permettait d’utiliser un ordinateur en tant que routeur IPv4 ou IPv6, en tant que routeur de traduction d’adresses réseau (NAT) IPv4 ou en tant que serveur d’accès à distance qui hébergeait des connexions à distance ou de réseau privé virtuel (VPN) à partir de clients distants. Cette fonctionnalité a maintenant été combinée avec DirectAccess pour composer le rôle serveur Accès à distance dans Windows Server 2012. Ce guide explique comment migrer un serveur qui héberge le service Routage et accès distant (dans Windows Server 2008 R2 et d’autres versions de bas niveau) vers un ordinateur qui exécute Windows Server 2012.

À propos de ce guide

La documentation et les outils de migration facilitent la migration des paramètres et des données des rôles serveur d’un serveur existant vers un serveur de destination qui exécute Windows Server 2012. En utilisant les outils décrits dans ce guide, vous pouvez simplifier le processus de migration, réduire la durée de la migration, accroître la précision du processus de migration et favoriser l’élimination des conflits qui, sans le recours à ces outils, pourraient se produire pendant le processus de migration. Pour plus d’informations sur l’installation et l’utilisation des outils de migration sur les serveurs source et de destination, consultez le guide Installation, accès et suppression des Outils de migration de Windows Server (https://go.microsoft.com/fwlink/?LinkId=247607).

Public visé

Ce document s’adresse aux administrateurs informatiques, professionnels de l’informatique et autres travailleurs du savoir chargés de l’exploitation et du déploiement des serveurs d’accès à distance dans un environnement géré. La réalisation de certaines étapes de migration décrites dans ce guide nécessite une certaine connaissance des scripts.

Ce que ce guide ne contient pas

Ce guide ne décrit pas l’architecture ni les fonctionnalités détaillées du rôle Accès à distance. Les scénarios suivants ne sont pas pris en charge dans ce guide de migration :

• tout processus pour une mise à niveau sur place, où le nouveau système d’exploitation est installé sur le matériel serveur existant à l’aide de l’option Upgrade pendant l’installation ;

• scénarios de clustering et multisite ;

• Migration de plusieurs rôles serveur

  Si votre serveur exécute plusieurs rôles, il est recommandé de concevoir une procédure de migration personnalisée propre à votre environnement de serveur et basée sur les informations fournies dans ce guide et dans d’autres guides de migration des rôles.

Scénarios de migration pris en charge

Ce guide fournit des instructions pour la migration d’un serveur existant vers un serveur exécutant Windows Server 2012.

Systèmes d'exploitation pris en charge

Ce guide fournit des instructions visant à migrer les données et paramètres d’un serveur existant qui est remplacé par un nouveau serveur 64 bits physique ou virtuel avec une nouvelle installation du système d’exploitation, comme décrit dans le tableau suivant.

• Les versions des systèmes d’exploitation présentées dans le tableau précédent correspondent aux premières combinaisons de systèmes d’exploitation et de Service Packs prises en charge. Les Service Packs plus récents sont pris en charge.

• La migration avec DirectAccess déjà configuré sur le serveur de destination n’est pas prise en charge.

• Les éditions Foundation, Standard, Enterprise et Datacenter du système d’exploitation Windows Server sont prises en charge en tant que serveurs source ou de destination. Cette prise en charge inclut la migration entre différentes éditions. Par exemple, vous pouvez effectuer la migration d’un serveur exécutant Windows Server 2003 Standard vers un serveur exécutant Windows Server 2012.

• Les migrations entre systèmes d’exploitation physiques et systèmes d’exploitation virtuels sont prises en charge.

• La migration depuis un serveur source vers un serveur de destination qui exécute un système d’exploitation dans une autre langue d’interface utilisateur système (c’est-à-dire, la langue installée) que celle du serveur source n’est pas prise en charge. Par exemple, vous ne pouvez pas utiliser les Outils de migration de Windows Server pour effectuer la migration des rôles, paramètres de système d’exploitation, données ou ressources partagées à partir d’un ordinateur qui exécute Windows Server 2008 R2 en français vers un ordinateur qui exécute Windows Server 2012 en allemand.

  Notes

  La langue d’interface utilisateur système est la langue du package d’installation localisé qui a été utilisé pour installer le système d’exploitation Windows.

• Les migrations de systèmes x86 et x64 sont toutes prises en charge pour Windows Server 2003 et Windows Server 2008. Toutes les éditions de Windows Server 2008 R2 et de Windows Server 2012sont compatibles avec des processeurs x64.

Configurations de rôles prises en charge

La liste générale ci-dessous recense les scénarios de migration pris en charge pour l’accès à distance. Tous les paramètres couverts par ces scénarios sont migrés.

• DirectAccess (pris en charge dans la migration de Windows Server 2012 vers Windows Server 2012 uniquement)

• Serveur VPN

• Serveur d’accès distant

• Traduction d'adresses réseau (NAT)

• Routage, avec les composants facultatifs suivants :

  • Agent de relais DHCP

  • Protocole RIP (Routing Information Protocol)

  • Protocole IGMP (Internet Group Management Protocol)

En plus des scénarios mentionnés ci-dessus, la migration ajuste aussi automatiquement la configuration du serveur de destination de façon à tenir compte des fonctionnalités qui ne sont plus prises en charge et à prendre en charge les fonctionnalités introduites avec Windows Server 2012 et non prises en charge dans les versions antérieures de Windows.

Dépendances de migration

Si un serveur NPS local ou distant utilisé pour l’authentification, la gestion des comptes ou la gestion des stratégies doit également être migré, procédez à sa migration avant de procéder à celle de l’accès à distance. Pour plus d'informations, voir Migrer un serveur NPS (Network Policy Server) vers Windows Server 2012.

Si vous effectuez une mise à niveau de Windows 2008 R2 DirectAccess vers Windows Server 2012, assurez-vous que tous les paramètres de configuration DirectAccess ont été appliqués sur le serveur Windows 2008 R2. Il est possible d’enregistrer les paramètres par le biais de la console, mais de ne pas les appliquer. Avant d’effectuer la mise à niveau, vérifiez que les paramètres enregistrés ont également été appliqués.

Composants de migration pris en charge dans aucune version du système d’exploitation

Les composants Accès à distance suivants ne sont pris en charge par tous les systèmes d’exploitation :

Composants de migration qui ne sont pas migrés automatiquement

Les éléments et paramètres d’accès à distance suivants ne sont pas migrés par les applets de commande Windows PowerShell fournies avec les Outils de migration de Windows Server. Vous devez donc configurer manuellement l’élément ou le paramètre en question sur le nouveau serveur RRAS, comme l’explique la section Réalisation des étapes de migration manuelles obligatoires de ce guide.

• Liaisons de certificat SSL. Les paramètres de liaison de certificat SSL et de liaison de chiffrement pour SSTP sont migrés comme suit :

  1. L’Assistant Migration recherche un certificat source sur l’ordinateur de destination. S’il en trouve un, SSTP utilise ce certificat.

  2. Si aucun certificat source n’est trouvé, l’Assistant Migration recherche un certificat valide ayant la même racine de confiance que le certificat source.

  3. Si un certificat n’est toujours pas trouvé, la configuration SSTP sur l’ordinateur de destination est « Par défaut ».

  4. Si les certificats auto-signés sont utilisés (valides pour Windows Server 2012), ils sont créés automatiquement sur l’ordinateur de destination.

• Comptes d’utilisateurs sur le serveur RRAS local. Si vous utilisez des comptes d’utilisateurs et de groupes basés sur un domaine, et que l’ancien et le nouveau serveur RRAS font tous deux partie du même domaine, aucune migration des comptes n’est requise. Des comptes d’utilisateurs locaux peuvent être utilisés si l’Authentification Windows est configurée sur le serveur RRAS source.

• Seulement le routage/VPN/DirectAccess lorsqu’ils sont tous installés. Si la configuration de votre serveur d’accès à distance inclut tous les services disponibles, tous les services doivent être migrés ensemble. La migration d’un seul de ces services vers le serveur de destination n’est pas prise en charge.

• Un serveur local ou distant exécutant le serveur NPS (Network Policy Server) qui fournit l’authentification, ainsi que la gestion des comptes et des stratégies. Ce guide ne présente pas les étapes requises pour migrer un serveur qui exécute NPS. Pour migrer un serveur qui exécute NPS, utilisez Migrer un serveur NPS (Network Policy Server) vers Windows Server 2012. La migration du serveur NPS doit être exécutée lorsque cela est approprié, conformément aux indications ultérieures de ce guide.

  Notes

  Si vous n’utilisez pas de serveur qui exécute NPS, les stratégies d’accès à distance et paramètres de gestion des comptes par défaut qui sont créés automatiquement lors de la configuration du service RRAS ne sont pas migrés.

• Connexions d’accès à distance à la demande. Le serveur de destination peut avoir des modems différents, et de nombreux paramètres de connexion à la demande sont spécifiques au modem ou au périphérique RNIS sélectionné.

• Certificats utilisés pour l’authentification de connexions IKEv2, SSTP et L2TP/IPsec.

• Liaison de certificat SSL pour SSTP lorsque la case à cocher Utiliser HTTP n’est pas activée.

• Connexions VPN IKEv2 qui utilisent des cartes réseau IPv6. IKEv2 est pris en charge sur les serveurs RRAS qui exécutent Windows Server 2008 R2 uniquement. Vous pouvez, dans la console MMC (Microsoft Management Console) RRAS de Windows Server 2008 R2, spécifier l’interface réseau utilisée pour acquérir des adresses DHCP et DNS IPV6 à l’usage des clients VPN IKEv2. Si vous effectuez une migration du service RRAS de Windows Server 2008 R2 vers un autre serveur qui exécute Windows Server 2008 R2, le paramètre est migré. Toutefois, si vous effectuez la migration à partir d’une version antérieure de Windows, il n’y a aucun paramètre à migrer, et la valeur par défaut Autoriser le RAS à sélectionner la carte est utilisée.

• Chiffrement faible. Dans Windows Server 2003, le chiffrement faible est activé, mais il est désactivé par défaut dans les versions ultérieures de Windows. Vous ne pouvez activer le chiffrement faible qu’en modifiant le Registre. Lors d’une migration à partir de Windows Server 2003, le processus de migration ne crée pas les paramètres de Registre requis sur le nouveau serveur ; ils doivent être configurés manuellement. Pour les versions ultérieures de Windows, si ces paramètres de Registre sont présents, ils sont migrés.

• DLL d’administration et de sécurité et clés de Registre correspondantes. Ces DLL sont disponibles à la fois dans les versions 32 bits et 64 bits, et ne fonctionnent pas dans une migration d’un système 32 bits vers un système 64 bits.

• DLL personnalisées utilisées pour établir une connexion à la demande. Ces DLL sont disponibles à la fois dans les versions 32 bits et 64 bits, et ne fonctionnent pas dans une migration d’un système 32 bits vers un système 64 bits. Les paramètres de Registre correspondants ne sont pas migrés non plus.

• Profils du Gestionnaire des connexions. Le Kit d’administration du Gestionnaire des connexions Microsoft est utilisé pour créer des profils VPN et d’accès à distance. Les profils créés sont stockés dans des dossiers spécifiques sur le serveur RRAS. Les profils créés dans une version 32 bits de Windows ne fonctionnent pas sur les ordinateurs qui exécutent une version 64 bits de Windows, et vice versa. Pour plus d’informations sur les profils de connexion, voir Kit d’administration du Gestionnaire des connexions (https://go.microsoft.com/fwlink/?linkid=55986).

• Paramètre Fragments transmis en groupe sur NAT. Ce paramètre est activé si le serveur RRAS est déployé derrière un routeur NAT qui fonctionne sur le système d’exploitation Windows. Il est obligatoire pour que les connexions L2TP/IPsec qui utilisent l’authentification par certificat d’ordinateur réussissent. Nous vous recommandons d’activer cette valeur afin de contourner un problème connu du RRAS.

• Paramètre Enregistrer les informations d’Accès à distance et routage supplémentaires (utilisées pour le débogage) de la boîte de dialogue Propriétés de Routage et accès distant sous l’onglet Journalisation.

Vue d’ensemble du processus de migration du service Routage et accès distant

Le processus de prémigration implique la collecte manuelle de données, suivie de l’exécution de différentes procédures sur les serveurs source et de destination. Le processus de migration comprend des procédures à réaliser sur les serveurs source et de destination, procédures qui utilisent les applets de commande Export et Import pour collecter, stocker et migrer automatiquement des paramètres de rôle serveur. Les procédures de post-migration incluent une phase visant à vérifier que le serveur de destination a correctement remplacé le serveur source, puis une phase de retrait ou de réaffectation du serveur source. Si la procédure de vérification indique que la migration a échoué, le dépannage commence. Si le dépannage échoue, des instructions de restauration sont fournies pour faire revenir le réseau à l’utilisation du serveur source d’origine.

Impact de la migration

Au cours de la migration, le serveur d’accès à distance n’est pas disponible pour accepter des connexions entrantes ou acheminer le trafic.

• Il n’est pas possible pour les nouveaux clients distants de se connecter au serveur au moyen de connexions d’accès à distance, VPN ou DirectAccess. Les connexions existantes sur le serveur sont déconnectées. Si vous avez plusieurs serveurs d’accès à distance, l’indisponibilité de ce serveur réduit la capacité jusqu’à ce que le nouveau serveur redevienne opérationnel. Pour les connexions à la demande, vous devez fournir une connectivité alternative entre les bureaux ou reconfigurer les connexions de sorte qu’elles pointent vers un autre serveur.

• Les fonctionnalités de routage et NAT ne sont pas disponibles. Si ces fonctionnalités sont requises pendant la migration, un autre routeur peut être déployé jusqu’à ce que le nouveau serveur de destination soit disponible.

Les impacts de la post-migration sont les suivants :

• Si vous projetez de réutiliser le nom du serveur source comme nom du serveur de destination, le nom peut être configuré sur le serveur de destination une fois le serveur source déconnecté du réseau. Sinon, un conflit de noms peut affecter la disponibilité. Si vous projetez d’utiliser les deux serveurs, un nom unique doit être attribué au serveur de destination.

• Un serveur VPN peut être connecté directement à Internet ou être placé sur un réseau de périmètre situé derrière un pare-feu ou un routeur NAT. Si l’adresse IP ou le nom DNS du serveur de destination change dans le cadre de la migration, ou une fois la migration effectuée, les mappages du pare-feu ou du périphérique NAT doivent être reconfigurés de façon à pointer vers l’adresse ou le nom appropriés. Vous devez également mettre à jour tout serveur DNS intranet ou Internet avec le nouveau nom et la nouvelle adresse IP. Pensez aussi à informer les utilisateurs des modifications intervenues au niveau du nom ou de l’adresse IP des serveurs afin qu’ils puissent se connecter au serveur approprié. Si vous utilisez des profils de connexion créés à l’aide du Kit d’administration du Gestionnaire des connexions Microsoft, déployez un nouveau profil avec les informations d’adresse de serveur mises à jour.

Nous vous recommandons d’annoncer la date et la durée prévues de la migration afin que les utilisateurs puissent prendre leurs dispositions.

Autorisations requises pour effectuer la migration

Les autorisations suivantes sont requises sur le serveur source et les serveurs d’accès à distance de destination :

• Des droits d’utilisateur de domaine sont requis pour joindre le nouveau serveur au domaine.

• Des droits administratifs locaux sont requis pour installer et gérer le rôle Accès à distance.

• Des autorisations d’administrateur pour les objets de stratégie de groupe DirectAccess équivalentes à celles configurées sur l’ordinateur source sont requises.

• Des autorisations en écriture sont requises sur l’emplacement du magasin de migration. Pour plus d’informations, voir Accès à distance : préparer la migration dans ce guide.

Durée estimée

La migration peut prendre deux à trois heures, test inclus.

Voir aussi

Accès à distance : préparer la migration
Accès à distance : migrer l’accès à distance
Accès à distance : vérifier la migration
Accès à distance : tâches de post-migration