Comment la modification du SID Windows affecte-t-elle SQL Server?

Nos administrateurs Windows ont identifié un problème avec la façon dont ils clonent les serveurs Windows. Apparemment, certains des serveurs clonés se retrouvent avec le même SID au niveau du système d'exploitation. J'ai entendu dire que Microsoft ne prend pas en charge les serveurs qui ont des SID en double. Par conséquent, les SID sur ces serveurs doivent être modifiés.

Je suis curieux de voir comment cela affecte SQL Server. Des idées? Comment cela affecte-t-il les serveurs de bases de données en cluster?

Laissez le SID tranquille. NewSID a été retiré parce que Mark Russinovich a fait quelques recherches et a constaté que l'ensemble des "SID en double == mauvais!" ligne que nous avons tous eu percuté dans nos crânes au cours de la dernière décennie est juste une charge de non-sens.

Voir la dernière entrée de blog de Mark: Le mythe de la duplication SID de la machine .

Je recommanderais certainement de ne pas changer le SID, jusqu'à ce que vous ayez lu: Changer le SID de la machine avec NewSID brise SQL Server (et comment le corriger)

Apparemment, certains des serveurs clonés se retrouvent avec le même SID au niveau du système d'exploitation.

Je risquerais de deviner TOUS vos systèmes clonés ont le même SID. GhostWalk peut régénérer des SID pour vous. L'utilisation de sysprep sur votre image de clone initiale pourrait également vous faire économiser sur les futurs systèmes.

Si vous avez installé SQL Server, NE CHANGEZ PAS LE SID. De mauvaises choses vont arriver.

Vous pouvez utiliser sysinternals NewSID: http://technet.microsoft.com/en-us/sysinternals/bb897418.aspx

Modifiez le nom de l'ordinateur en SQL:

use master
sp_dropserver '<old computer name>'
GO
sp_addserver '<new computer name>', local
GO

sp_helpserver -- will show you the new computer name

Redémarrez ensuite le service du serveur SQL.

Si votre base de données effectue des transactions à distance à l'aide de Microsoft Distributed Transaction Coordinator, sachez que les machines clonées ont également le même ID MSDTC, qui n'est pas le SID et qui n'a pas été modifié par NewSID.

Vous le verrez dans l'Observateur d'événements:

Le MS DTC local a détecté que le MS DTC sur SERVER a la même identité unique que le MS DTC local. Cela signifie que les deux MS DTC ne pourront pas communiquer entre eux. Ce problème se produit généralement si l'un des systèmes a été cloné à l'aide d'outils de clonage non pris en charge. MS DTC nécessite que les systèmes soient clonés à l'aide des outils de clonage pris en charge tels que SYSPREP. L'exécution de 'msdtc -uninstall' puis de 'msdtc -install' à partir de l'invite de commande résoudra le problème. Remarque: L'exécution de 'msdtc -uninstall' entraînera la perte de toutes les informations de configuration MS DTC sur le système.

Je le résous comme ceci:

msdtc -uninstall

Attendez quelques minutes, puis

msdtc -install
sc config msdtc start= auto
sc start msdtc

Utilisez l'outil désormais Microsoft NewSID ou sysprep, qui est un peu comme réinstaller Windows sans copier tout le fichier.

Je ne pense pas que vous puissiez joindre deux ordinateurs au même domaine avec le même SID, donc je dirais que les serveurs SQL en cluster n'auraient aucune chance car les serveurs doivent être sur un domaine.

Le seul moyen pris en charge pour cloner un système est avec sysprep. Il existe de nombreuses raisons pour lesquelles ne pas cloner un serveur SQL:

-Il n'est pas pris en charge par Microsoft CSS.

-SQL ne fonctionnera pas correctement tant qu'il n'aura pas été "renommé".

-Si vous avez des services de signalement, il sera également arrosé.

-Les comptes de service système et réseau recevront un nouveau SID et de nouveaux mots de passe, donc si vous les avez utilisés comme comptes de service, il y aura quelques problèmes.

-Le serveur SQL crée un bon nombre de groupes locaux avec le format. SQLServer2005MSSQLUser $$ MSSQLSERVER. Il n'est pas pris en charge pour renommer ces

Afin de rectifier la situation, je voudrais-

Arrêtez le cluster, reconstruisez le système, installez SQL, créez un nouveau cluster, exécutez une sauvegarde sur le serveur qui n'a pas été reconstruit, puis arrêtez-le, restaurez cette sauvegarde vers le nouveau cluster, pointez l'application vers le nouveau cluster, reconstruisez le reste serveur et l'ajouter au nouveau cluster

- alternativement (probablement plus facile) pourquoi ne pas construire un nouveau serveur avec un nouveau nom (cela résoudra les problèmes potentiels avec SID de tout type), puis rompez l'installation du cluster SQL, joignez-le au cluster, basculez vers cette boîte puis répétez le processus, que aucun temps d'arrêt et aucun besoin de sauvegarde / restauration (bien que je suggérerais que vous le fassiez quand même). Nous utilisons zznode1, zznode2 et un nom de cluster de cette façon, créer zznode3 et le joindre au cluster est simple car le nœud n'est pas référencé lorsqu'il est dans le cluster. J'espère que cela pourra aider.