Déplacement de SQL Server vers un domaine différent
Quelles sont les meilleures pratiques/étapes importantes lorsque la machine Windows Server hébergeant SQL Server 2008 R2 est déplacée vers un autre domaine? Quelles étapes doivent/doivent être effectuées pour SQL Server avant et après le nouveau domaine est joint?
De quoi devez-vous tenir compte lors de la migration de SQL Server vers un autre domaine?
Les étapes ci-dessous supposent:
- L'adresse IP changera également
- SQL Server n'est PAS en cluster
Pas:
Une sauvegarde:
- AVANT: sauvegarder les bases de données hors machine
B. Services:
- AVANT: selon la nature du changement/déplacement, vous souhaiterez peut-être définir le démarrage du service sur Manuel pour tous les services SQL
- APRÈS: Une fois que les choses ou fonctionnent correctement, ramenez le service à son réglage d'origine
C. SA:
- AVANT: si tous les comptes d'administrateur sont des comptes de domaine ou des groupes, activez temporairement le compte "sa" avec un mot de passe fort
- APRÈS le déplacement: une fois que les comptes basés sur le domaine sont configurés dans le nouveau domaine, "sa" peut être à nouveau désactivé
D. Service de compte Windows:
- AVANT de déplacer: pour chaque service Windows lié à SQL-Server, modifiez le service pour utiliser un compte Windows LOCAL ou l'un des comptes intégrés
- APRÈS le déménagement: accordez les privilèges nécessaires aux nouveaux comptes de domaine du service. Lorsque des autorisations spéciales ne sont pas nécessaires, le Gestionnaire de configuration de service SQL peut être utilisé pour modifier le compte de service
E. Comptes de domaine Windows utilisés pour se connecter à SQL Server
- Recréez les comptes nécessaires ou utilisez les comptes correspondants dans le nouveau domaine.
- AVANT de déplacer, scriptez les autorisations pour les anciens comptes de domaine, y compris les autorisations SQL, les autorisations sur les dossiers et fichiers Windows, les autorisations Windows, etc.
- APRÈS avoir déménagé, appliquez ces scripts aux nouveaux comptes de domaine correspondants afin qu'ils aient les mêmes autorisations
F. Adresse IP: SQL Server (sauf en cluster) utilisera la nouvelle adresse IP
- APRÈS: Les applications client qui référencent le service par adresse IP devront être configurées avec la nouvelle adresse IP.
Pare-feu:
- APRÈS: les anciennes ouvertures de pare-feu qui ne sont plus utilisées devront être fermées, de nouvelles ouvertures de pare-feu devront peut-être être créées pour SQL Server, OLAP, SSRS entre les serveurs et les clients)
H. Entrées DNS:
- APRÈS: vérifier que DNS a correctement mis à jour
- APRÈS: Les clients et les services qui font référence par nom DNS peuvent devoir être redémarrés ET/OU leurs systèmes hôtes peuvent avoir besoin de vider leur cache DNS. Pour les postes de travail Windows, cela peut être fait avec "ipconfig/flushdns"
I. Noms de principe de service (SPN). Certaines instances autonomes (et toutes en cluster) utilisent des SPN.
- APRÈS: L'ANCIEN SPN doit être supprimé et un NOUVEAU SPN doit être créé. Bien qu'il ne soit pas recommandé d'utiliser un compte de service SQL Server pour gérer ses propres SPN, si tel est le cas, le nouveau compte de service de domaine devra se voir accorder le privilège WriteServicePrincipalName "
J. Alias de l'utilitaire réseau client.
- APRÈS: mettre à jour les clients qui les utilisent devront mettre à jour
K. Configuration de l'application client et de la connexion de service:
- APRÈS: les noms de source de données (DSN), les chaînes de connexion, les fichiers de configuration, les noms Oracle TNS pour les connexions - devront être mis à jour et les applications et services devront peut-être être redémarrés
L. Nom de la machine interne.
APRÈS: si le nom de la machine change également, l'entrée du nom de la machine interne de SQL Server devra peut-être être mise à jour
sp_dropserver 'MyOldMachineName' aller sp_addserver 'MyNewMachineName', 'local' aller
M. Réplication de fusion - Si la réplication de fusion est en cours d'utilisation, elle devra également être reconfigurée.
- AVANT: assurez-vous que toutes les répliques sont à jour
- APRÈS: reconfigurer la réplication de fusion
Attributions - quelques informations ajoutées à partir de ces sources:
Les identifiants et autorisations sont les premiers qui me viennent à l'esprit. Vous devrez également corriger la façon dont les applications atteignent la base de données. Cela pourrait être assez gênant. Jetez un oeil à cet article sur le MSDN, pourrait être utile.
Un autre problème que j'ai vu est le nom est sys.servers. Fait une
SELECT * à partir de sys.servers
J'ai vu des fois où la colonne de nom ne change pas ou n'est pas le nom de domaine complet du nouveau serveur.