In che modo la modifica del SID di Windows influisce su SQL Server?

I nostri amministratori di Windows hanno identificato un problema con il modo in cui clonano i server Windows. Apparentemente alcuni dei server clonati finiscono con lo stesso SID a livello di sistema operativo. Ho sentito che Microsoft non supporta server con SID duplicati. Pertanto, i SID su questi server devono essere modificati.

Sono curioso di sapere come ciò influisca su SQL Server. Qualche idea? In che modo influisce sui server di database in cluster?

Lasciare il SID da solo. NewSID è stato ritirato perché Mark Russinovich ha scavato e scoperto che l'intero "duplicati SID == cattivo!" la linea che tutti noi abbiamo suonato nei nostri teschi nell'ultimo decennio o giù di lì è solo un carico di sciocchezze.

Vedi l'ultimo post del blog di Mark: The Machine SID Duplication Myth .

Consiglio vivamente di non modificare il SID, fino a dopo aver letto: La modifica del SID della macchina con NewSID interrompe SQL Server (e come risolverlo)

Apparentemente, alcuni dei server clonati finiscono con lo stesso SID a livello di sistema operativo.

Vorrei rischiare di indovinare TUTTI i sistemi clonati hanno lo stesso SID. GhostWalk può rigenerare i SID per te. L'uso di sysprep sull'immagine del clone iniziale potrebbe salvarti anche su sistemi futuri.

Se hai installato SQL Server NON MODIFICARE IL SID. Accadranno cose brutte.

È possibile utilizzare sysinternals NewSID: http://technet.microsoft.com/en-us/sysinternals/bb897418.aspx

Cambia il nome del computer in 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

Quindi riavviare il servizio SQL Server.

Se il database esegue transazioni remote utilizzando Microsoft Distributed Transaction Coordinator, tenere presente che anche le macchine clonate hanno lo stesso ID MSDTC, che non è il SID e non modificato da NewSID.

Lo vedrai nel Visualizzatore eventi:

MS DTC locale ha rilevato che MS DTC su SERVER ha la stessa identità univoca di MS DTC locale. Ciò significa che i due MS DTC non saranno in grado di comunicare tra loro. Questo problema si verifica in genere se uno dei sistemi è stato clonato utilizzando strumenti di clonazione non supportati. MS DTC richiede che i sistemi vengano clonati utilizzando strumenti di clonazione supportati come SYSPREP. L'esecuzione di "msdtc -uninstall" e quindi di "msdtc -install" dal prompt dei comandi risolverà il problema. Nota: l'esecuzione di "msdtc -uninstall" comporterà la perdita di tutte le informazioni di configurazione di MS DTC dal sistema.

Lo risolvo così:

msdtc -uninstall

Aspetta un paio di minuti, quindi

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

Usa lo strumento NewSID o sysprep ora di proprietà di Microsoft , che è un po 'come reinstallare Windows senza copiare tutti i file.

Non penso che tu possa unire due computer allo stesso dominio con lo stesso SID, quindi direi che i server SQL in cluster non avrebbero possibilità poiché i server devono trovarsi su un dominio.

L'unico modo supportato per clonare un sistema è con sysprep. Ci sono molte ragioni per non clonare un server sql:

-Non è supportato da Microsoft CSS.

-SQL non funzionerà correttamente fino a quando non viene "rinominato".

-Se disponi di servizi di segnalazione, anche questo verrà cancellato.

-Gli account del sistema e del servizio di rete riceveranno nuovi SID e password, quindi se li hai usati come account di servizio ci sarà qualche problema.

-SQL Server crea alcuni buoni gruppi locali con il formato. SQLServer2005MSSQLUser $$ MSSQLSERVER. Non è supportato per rinominarli

Al fine di correggere la situazione, vorrei-

Rompere il cluster, ricostruire il sistema, installare SQL, creare un nuovo cluster, eseguire un backup sul server che non è stato ricostruito- quindi arrestarlo, ripristinare quel backup sul nuovo cluster, puntare l'applicazione sul nuovo cluster, ricostruire il rimanente server e aggiungerlo al nuovo cluster

- in alternativa (probabilmente più semplice) perché non creare un nuovo server con un nuovo nome (questo risolverà potenziali problemi con SID di qualsiasi tipo) quindi rompere il cluster installare SQL unirlo al cluster, eseguire il failover in quella casella quindi ripetere il processo, che nessun downtime e nessuna necessità di backup / ripristino (anche se suggerirei comunque di averlo fatto). Usiamo zznode1, zznode2 e un nome di cluster in questo modo creare zznode3 e unirlo al cluster è semplice poiché al nodo non si fa riferimento quando si trova nel cluster. Spero possa aiutare.