SQL Server 2012 Sempre su AG - Blocco account di servizio Dbengine

Question

Sto avendo uno strano problema e spero che tu possa essere in grado di aiutare!

Problema: ho un cluster di gruppo di disponibilità a 2 nodi SQL Server 2012 che utilizza un FSW. Entrambi i nodi utilizzano lo stesso account di servizio DBEngine (come è normale in queste configurazioni).

Ci sono attualmente 3 gruppi di disponibilità su questo cluster, e funziona bene per un bel po 'di tempo.

Oggi ho riavviato il conto del nodo passivo DBEngine (come stavo aggiungendo un certificato SSL per una nuova applicazione, nuovo gruppo di disponibilità). Quando il nodo è tornato il backup, non è più sincronizzato con il nodo 1. Lo stato della replica è stato disconnesso, e ho potuto vedere molti errori di accesso sui registri SQL del nodo 1 (nodo attivo).

Ho trovato che il conto del servizio DBEngine aveva bloccato. L'ho sbloccato, ma presto bloccava di nuovo.

Ho rimosso il certificato SSL e riavviato nuovamente il nodo passivo (quindi è stato nello stesso stato con cui ho iniziato) e ha iniziato bene, ma entro un minuto, l'account di servizio si è bloccato di nuovo.

Passaggi ho provato:

.

• ha creato un nuovo account di servizio per escludere l'account utilizzato altrove, ha avviato entrambi i nodi sotto il nuovo account .... Account bloccato quando il nodo 2 è iniziato

• sbloccato l'account, nodo interrotto 2. Nodo riavviato 1. Account fine ... attese .. Account ancora bene. Iniziato il nodo 2 servizio ... Account bloccato.

• Ricreati gli endpoint di mirroring su entrambi i nodi e le autorizzazioni di collegamento riapplicato al conto di servizio DBEngine. - Questo non lo aggiusta.

• riavviati sia di VM

• rimosso il nodo 2 replica dal gruppo di disponibilità, ha rimosso tutti i database (dal nodo 2) e ha lasciato cadere il mirroring Endpoint sul nodo 2. Servizio di nodo 2 riavviato. - A questo punto entrambi i nodi erano felici con lo stesso account di servizio.

• ha provato nuovamente il nodo 2 come replica utilizzando la procedura guidata. Lo ha aggiunto, ha eseguito il backup del database, ripristinato al nodo 2 e ha ottenuto l'ultimo passaggio dove lo collega e la password bloccata di nuovo!

Qualcuno ha qualche idea? Qualsiasi input sarebbe stato notevolmente ricevuto!

sam

Answer 1

Quindi, nel caso in cui qualcuno vuole sapere cosa ha causato questo, è stata una politica di gruppo!

Qualche tempo fa, non bisognavo a me, i controller di dominio per il dominio in questione sono stati aggiornati a Server 2012. Insieme a questo è arrivato un sacco di politiche del Gruppo Windows Server 2012. Le politiche aggiuntive erano state aggiunte a uno dei server genitore OU con un filtro applicato.

Sfortunatamente il filtro aveva un errore di battitura, e quindi è stato applicato a tutti i miei server di database su questo dominio.

Avevo quasi escluso che è un problema GP, come sembravo avere tutte le autorizzazioni di cui avevo bisogno, e ho potuto vedere le connessioni che entrano nelle porte corrette tra ogni nodo. I server erano felici come nodi singoli!

Ho chiesto al team del server di spostare i server (solo per vedere) al "Computers", e dopo un Gpupdate forzato, Bingo!

Sfortunatamente, non sono sicuro esattamente quale politica ha causato il problema perché c'erano molto! C'era un numero a che fare con l'utilizzo e l'autenticazione NTLM, e sono convinto che il problema fosse legato a questo. A qualche punto avrò configurato un laboratorio di prova per provare e replicare il problema.

Quindi eccoti! Controlla sempre le politiche del gruppo, anche se credi (come ho fatto) che nulla era cambiato!