View Full Version : Aiuto Migragione server, non si è replicato del tutto
ho un urgente bisogno di qualcuno di voi che mi aiuti ...
devo cambiare server che mi fa di DOMINIO con uno nuovo, sono stati creati account, Pc, polices e qualcos'altro ...
ho eseguito la procedura iniziando con CDPROMO, trasferimento del GC e trasferimento dei ruoli master .... tutto sembra essere andato per il meglio .. Active Dir., replicato DNS reeplicato (WINS non è attivo già sul server1) ....quando spengo il Server1 tutti gli utenti entrano ma hanno problemi di rete... es. non ci accedono +, a me comwe amministratore vnon mi fa più entrare perchè dice che non vede + il dominio... come mai?
cosa ho dimenticato?
Ho notato che sul server1 ci sono delle polices su sysvol che su Server2 non ci sono.... BOOOOOO
Grazie 10000
p.s. spreo di essermi spiegato :rolleyes:
:help: ho un urgente bisogno di qualcuno di voi che mi aiuti ...
devo cambiare server che mi fa di DOMINIO con uno nuovo, sono stati creati account, Pc, polices e qualcos'altro ...
ho eseguito la procedura iniziando con CDPROMO, trasferimento del GC e trasferimento dei ruoli master .... tutto sembra essere andato per il meglio .. Active Dir., replicato DNS reeplicato (WINS non è attivo già sul server1) ....quando spengo il Server1 tutti gli utenti entrano ma hanno problemi di rete... es. non ci accedono +, a me comwe amministratore vnon mi fa più entrare perchè dice che non vede + il dominio... come mai?
cosa ho dimenticato?
Ho notato che sul server1 ci sono delle polices su sysvol che su Server2 non ci sono.... BOOOOOO
Grazie 10000
p.s. spreo di essermi spiegato :rolleyes:
UP! :help:
vuol dire che ci sono stati problemi sulle repliche e/o il nuovo server non ha il ruolo di global catalog, cioè ha solo una copia parziale di AD.
Per problemi di questo tipo mediamente, e non ce se ne accorge subito, ci si gioca il dominio, per cui ti consiglio vivamente di rivolgerti ad una ditta o un sistemista freelance che ci dia un occhiata.
:)
vuol dire che ci sono stati problemi sulle repliche e/o il nuovo server non ha il ruolo di global catalog, cioè ha solo una copia parziale di AD.
Per problemi di questo tipo mediamente, e non ce se ne accorge subito, ci si gioca il dominio, per cui ti consiglio vivamente di rivolgerti ad una ditta o un sistemista freelance che ci dia un occhiata.
:)
:( il global catalog sul nuovo server è spuntato :rolleyes: :rolleyes:
io non posso fare nulla? dietro vostro consiglio, perchè chiamare una ditta in questo momento non è possibile ... :muro:
Squalo71
15-10-2009, 15:31
Controlla nell'event viewer se ci sono errori relativi all'Active Directory..
Comunque hai rimosso il vecchio server dall'AD? Controlla anche che sia assegnato il ruolo di Root Schema (o qualcosa di simile, non ricordo) al nuovo server.
Se hai solo spento il vecchio server, ma è ancora "vivo" nell'AD e non lo hai formattato, riaccendilo e fai il demote con DCPromo.
Controlla nell'event viewer se ci sono errori relativi all'Active Directory..
Comunque hai rimosso il vecchio server dall'AD? Controlla anche che sia assegnato il ruolo di Root Schema (o qualcosa di simile, non ricordo) al nuovo server.
Se hai solo spento il vecchio server, ma è ancora "vivo" nell'AD e non lo hai formattato, riaccendilo e fai il demote con DCPromo.
Il demote non l'ho fatto perchè quel server lo voglio ancora utilizzare, come server secondario per altri fini, a me interessa cmq che il server nuovo assuma il controllo totale e che i server vecchio sia acceso o spento non faccia alcun caso ... :rolleyes:
P.S. Dimenticavo ... cosa è questo "Root Schema" ???
Squalo71
16-10-2009, 13:02
Il demote non l'ho fatto perchè quel server lo voglio ancora utilizzare, come server secondario per altri fini, a me interessa cmq che il server nuovo assuma il controllo totale e che i server vecchio sia acceso o spento non faccia alcun caso ... :rolleyes:
P.S. Dimenticavo ... cosa è questo "Root Schema" ???
E allora se vuoi continuare a usarlo, ma non deve avere funzioni di domain controller, DEVI fare il demote con DCpromo. Una volta fatto il demote ti resta il server in AD, senza funzioni di controller, ma semplicemente come member server.
Ho sbagliato, intendevo lo Schema Master.
E allora se vuoi continuare a usarlo, ma non deve avere funzioni di domain controller, DEVI fare il demote con DCpromo. Una volta fatto il demote ti resta il server in AD, senza funzioni di controller, ma semplicemente come member server.
Ho sbagliato, intendevo lo Schema Master.
...io vorrei che avesse ancora funzioni di domain controller :rolleyes:
Squalo71
16-10-2009, 15:10
...io vorrei che avesse ancora funzioni di domain controller :rolleyes:
Allora: in AD non esiste più il concetto di Primary Domain controller e Backup Domain Controller, ma solo Domain controller, con la differenza che il primo DC prende anche il ruolo di Schema Master.
Sposta il ruolo di schema master sul nuovo server e lascia tutto così com'è.
Controlla che nell'event viewer relativo a AD non ci siano errori, ed eventualmente risolvili con una ricerchina su google o microsoft.
Ad esempio cercando su google "transfer schema master" ecco il primo risultato:
http://support.microsoft.com/kb/324801
altra cosa: ai dc Microsoft non piace molto che gli altri dc si spengano e si riaccendano cosi, perche la mancata o sporca replica per tante volte porta a molti problemi, anche sul dc che è rimasto sempre acceso.
Quindi
se vuoi continuare a usare il server come server ma non dc, fai il demote che praticamente serve solo a togliere Ad su quel server e dire agli altri dc che lui dc non lo è piu, altrimenti cercheranno sempre di replicarsi.
Allora: in AD non esiste più il concetto di Primary Domain controller e Backup Domain Controller, ma solo Domain controller, con la differenza che il primo DC prende anche il ruolo di Schema Master.
Sposta il ruolo di schema master sul nuovo server e lascia tutto così com'è.
Controlla che nell'event viewer relativo a AD non ci siano errori, ed eventualmente risolvili con una ricerchina su google o microsoft.
Ad esempio cercando su google "transfer schema master" ecco il primo risultato:
http://support.microsoft.com/kb/324801
... i 5 ruoli li avevo già trasferiti sul nuovo server...
... i 5 ruoli li avevo già trasferiti sul nuovo server...
Allora l'unica cosa rimasta da provare è, come già suggerito in precedenza, il demote del vecchio controller al ruolo di member server e poi (se vuoi che comunque continui a rivestire il ruolo controller di dominio) promuoverlo nuovamente.
... i 5 ruoli li avevo già trasferiti sul nuovo server...
Allora l'unica cosa rimasta da provare è, come già suggerito in precedenza, il demote del vecchio controller al ruolo di member server e poi (se vuoi che comunque continui a rivestire il ruolo controller di dominio) promuoverlo nuovamente.
... grazie atutti per la collaborazione, riapro la discussione perchè da allora non ho fatto più nulla ... per vari motivi
Ricapitolando, sul nuovo server ho fatto la procedura con DCPROMO, a tutti e due i server ho spuntato il GC, al nuovo server ho trasferito i 5 ruoli, non so se ho dimenticato qualcosa ...
dimenticavo una cosa, credo, molto importante: sul primo server sono rimasti condivisi la cartella SYSVOL, e NETLOGON, cosa che manca al nuovo server (in realtà dovrebbero essere 2 ma al momento lasciamo stare)... e ho notato che qualsiasi utente della rete in qualsiasi istante, l'account legge delle informazioni nella cartella SYSVOL (credo che all'interno ci siano informazioni riguardanti i GPO) .... cosa si può fare a riguardo?
Se spengo il vecchio server il DOMINIO e come se non esistesse +, il nuovo server vede sempre AD solo se lo carico io forzatamente ... e comunque si possono mettere PC sotto il Dominio .... spero di essermi spiegato ....
fare il demote mi spaventa un pò
Grazie 1000
Spero che qualcuno mi sappia dare una risposta :rolleyes:
il nuovo server vede sempre AD solo se lo carico io forzatamente
???
spero di essermi spiegato ....
Forse ti sei spiegato ma io non ho capito che cosa significa caricare forzatamente AD.
In ogni caso, per come la vedo io, le strutture dati di AD sono evidentemente corrotte. Io farei in questo modo:
1) disinstallerei AD da tutti i server tranne che sul server originale
2) usando dcdiag fareai una diagnosi dello stato di AD
3) in caso di errori riportati nel passo precedente, cercherei di correggerli
4) ripeterei i passi 2) e 3) fino a quando dcdiag non darà più errori
5) installerei AD con dcpromo sui nuovi server assicurandomi che il promote e il trasferimento dei ruoli (compreso il GC) vada a buon fine
Ciao, innanzi tutto alcuni consigli:
1) 2 DC almeno per ogni dominio della tua foresta con relativo dns.
2) tutti gli sfmo non sullo stesso server, e mai l'infrastructure master assieme al global catalog, a meno che tutti i dc del dominio siano global catalog, in quel caso diventa irrilevante dove lo piazzi, inoltre dei 5 fsmo 2 sono a livello foresta e tre di dominio, quelli a livello di foresta, ossia lo schema master e il domain naming master, possono star fuori linea anche per mesi, a patto che tu non debba aggiungere un nuovo dominio o fare modifiche allo schema.
Il global catalog non è un ruolo fsmo, per definizione fsmo significa "Flexible Single Master Operations" sono in tutto 5, due a livello di foresta e 3 a livello di dominio come detto prima, quindi devi avere un singolo pdc emulator a dominio, ma puoi avere "n" global catalog; il global catalog è una replica parziale degli attributi ti tutti gli oggetti AD (user computer gruppi etc) in ogni dominio della foresta, immaginalo come l'elenco telefonico di active directory e serve essenzialmente a velocizzare le query sul db di active directory, ma fa anche altre cose.
Venendo al tuo problema, microsoft ti mette a disposizione due tool per verificare le repliche fra dc, il primo a riga di comando è "repadmin", il secondo invece è un tool grafico che è "replmon" che puoi scaricare dal sito della microsoft.
I due dc devi tenerli sempre accesi, poichè entrambi devono sincronizzare le proprie copie del database AD fra loro, i dc dal 2000 in poi sono di tipo peer:)
Venendo al tuo problema posta gli errori di replica è poi ci si ragiona, un'ultima cosa anche i dc hanno la password computer come gli utenti e gli altri pc e server del dominio, questa viene cambiata in automatico di default ogni 21 giorni, e il sistema si autentica al dominio attraverso il servizio "netlogon", se il tuo dc è rimasto fuori linea molto tempo è probabile che la sua password sia scaduta e quindi non entri più nel dominio.
Puoi comunque resettare la password di un dc, il comando è:
netdom resetpwd /"opzioni varie"
C'è comunque la knowledge della microsoft relativa al comando che spiega tutto.
???
Forse ti sei spiegato ma io non ho capito che cosa significa caricare forzatamente AD.
In ogni caso, per come la vedo io, le strutture dati di AD sono evidentemente corrotte. Io farei in questo modo:
1) disinstallerei AD da tutti i server tranne che sul server originale
2) usando dcdiag fareai una diagnosi dello stato di AD
3) in caso di errori riportati nel passo precedente, cercherei di correggerli
4) ripeterei i passi 2) e 3) fino a quando dcdiag non darà più errori
5) installerei AD con dcpromo sui nuovi server assicurandomi che il promote e il trasferimento dei ruoli (compreso il GC) vada a buon fine
Ciao, innanzi tutto alcuni consigli:
1) 2 DC almeno per ogni dominio della tua foresta con relativo dns.
2) tutti gli sfmo non sullo stesso server, e mai l'infrastructure master assieme al global catalog, a meno che tutti i dc del dominio siano global catalog, in quel caso diventa irrilevante dove lo piazzi, inoltre dei 5 fsmo 2 sono a livello foresta e tre di dominio, quelli a livello di foresta, ossia lo schema master e il domain naming master, possono star fuori linea anche per mesi, a patto che tu non debba aggiungere un nuovo dominio o fare modifiche allo schema.
Il global catalog non è un ruolo fsmo, per definizione fsmo significa "Flexible Single Master Operations" sono in tutto 5, due a livello di foresta e 3 a livello di dominio come detto prima, quindi devi avere un singolo pdc emulator a dominio, ma puoi avere "n" global catalog; il global catalog è una replica parziale degli attributi ti tutti gli oggetti AD (user computer gruppi etc) in ogni dominio della foresta, immaginalo come l'elenco telefonico di active directory e serve essenzialmente a velocizzare le query sul db di active directory, ma fa anche altre cose.
Venendo al tuo problema, microsoft ti mette a disposizione due tool per verificare le repliche fra dc, il primo a riga di comando è "repadmin", il secondo invece è un tool grafico che è "replmon" che puoi scaricare dal sito della microsoft.
I due dc devi tenerli sempre accesi, poichè entrambi devono sincronizzare le proprie copie del database AD fra loro, i dc dal 2000 in poi sono di tipo peer:)
Venendo al tuo problema posta gli errori di replica è poi ci si ragiona, un'ultima cosa anche i dc hanno la password computer come gli utenti e gli altri pc e server del dominio, questa viene cambiata in automatico di default ogni 21 giorni, e il sistema si autentica al dominio attraverso il servizio "netlogon", se il tuo dc è rimasto fuori linea molto tempo è probabile che la sua password sia scaduta e quindi non entri più nel dominio.
Puoi comunque resettare la password di un dc, il comando è:
netdom resetpwd /"opzioni varie"
C'è comunque la knowledge della microsoft relativa al comando che spiega tutto.
Non finirò mai ringraziarvi per la vostra assistenza ...
ho fatto una cosa ....
mi sono incavolito e ho riformattato il server nuovo per poter fare passo passo e con calma tutta la migrazione...
risulatato? lo stesso di prima però questa volta ho raccolto un po di informazioni dagli EVENTI .....
ho allegato il file .....
a quanto ho capito io non replica la cartella sysvol, non capisco ...
riguardo i tools per verificare le repliche cosa devo fare esattamente?
ho provato a lanciare qualche comando, ma mi restituisce una miriade di caratteri che non comprendo ....
Aspetto vostre notizie, intanto provo a capirci qualcosa
CIAO GRAZIE
... vi farò sapere le novità
... non trovo "replmon", come faccio a scaricarlo
Direi che è un bel casino......ma un backup del systemstate del primo dc prima dell'aggiunta/rimozione dei dc lo hai? :confused:
Comunque il primo errore potrebbe esser dato da un problema di configurazione del dns, inoltre potresti avere dei residui in AD della rimozione del dc se questa non è andato a buon fine :(
per l'errore 53258 qui c'è un articolo del support microsoft
http://support.microsoft.com/kb/923977/en-us
per il primo invece potrebbe essere:un problema di configurazione del dns, il servizio di replica che non va su uno dei dc ( lo puoi vedere riavviando il servizio stesso) ed infine su "site and services" puoi forzare le repliche a mano te direttamente da un dc all'altro, inoltre vedi se per caso ci son ancora dei connettori per le repliche che puntano al dc che hai formattato.
Per l'errore 13565 a naso mi vien da pensare che è collegato al primo e relativo alle repliche che non vanno.
scarica da questo link il tool per fare la diagnostica delle repliche, dovrebbe avere anche un interfaccina grafica se sei poco avvezzo alla riga di comando.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=43CB658E-8553-4DE7-811A-562563EB5EBF
e qui un articolo (in inglese) sulle possibili soluzioni ai problemi delle repliche
http://technet.microsoft.com/en-us/library/bb727056.aspx
Infine controlla anche se l'ora dei due sistemi è uguale, poichè una differenza superiore a 5 minuti in più o in meno fra i due clock impedisce le repliche stesse.
Purtroppo la vedo ardua da un forum poter risolvere problemi del genere :(
Direi che è un bel casino......ma un backup del systemstate del primo dc prima dell'aggiunta/rimozione dei dc lo hai? :confused:
Comunque il primo errore potrebbe esser dato da un problema di configurazione del dns, inoltre potresti avere dei residui in AD della rimozione del dc se questa non è andato a buon fine :(
per l'errore 53258 qui c'è un articolo del support microsoft
http://support.microsoft.com/kb/923977/en-us
per il primo invece potrebbe essere:un problema di configurazione del dns, il servizio di replica che non va su uno dei dc ( lo puoi vedere riavviando il servizio stesso) ed infine su "site and services" puoi forzare le repliche a mano te direttamente da un dc all'altro, inoltre vedi se per caso ci son ancora dei connettori per le repliche che puntano al dc che hai formattato.
Per l'errore 13565 a naso mi vien da pensare che è collegato al primo e relativo alle repliche che non vanno.
scarica da questo link il tool per fare la diagnostica delle repliche, dovrebbe avere anche un interfaccina grafica se sei poco avvezzo alla riga di comando.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=43CB658E-8553-4DE7-811A-562563EB5EBF
e qui un articolo (in inglese) sulle possibili soluzioni ai problemi delle repliche
http://technet.microsoft.com/en-us/library/bb727056.aspx
Infine controlla anche se l'ora dei due sistemi è uguale, poichè una differenza superiore a 5 minuti in più o in meno fra i due clock impedisce le repliche stesse.
Purtroppo la vedo ardua da un forum poter risolvere problemi del genere :(
Ciao .. grazie di tutto per i tuoi consigli ....
ti riaggiorno in 2 parole la situazione attuale ....
ho portato in assistenza di 2 server e mi hanno detto che non si poteva fare nulla e quindi hanno riformattato il nuovo server e ricreato un nuovo Dominio (aimè) ... pazienza.
Ora io ho un altro Server gemello, lo devevo formattare, ed agganciarlo al Dominio in modo tale che intervenga in caso di cresh del primo server, deve avere la stessa configurazione... in parole povere una migrazione, e per non incappare nello stesso errore ti chiedo se questa procedura va bene ...
Migrare un DC ... (http://leotardi.no-ip.com/html/spostamdominio/spostamdominio.htm)
dimencicavo, mi fanno messo win2003 SP2 R2, io invece ho solo win2003 SP2.. ci sono problemi?
Ciao
Ciao .. grazie di tutto per i tuoi consigli ....
ti riaggiorno in 2 parole la situazione attuale ....
ho portato in assistenza di 2 server e mi hanno detto che non si poteva fare nulla e quindi hanno riformattato il nuovo server e ricreato un nuovo Dominio (aimè) ... pazienza.
Ora io ho un altro Server gemello, lo devevo formattare, ed agganciarlo al Dominio in modo tale che intervenga in caso di cresh del primo server, deve avere la stessa configurazione... in parole povere una migrazione, e per non incappare nello stesso errore ti chiedo se questa procedura va bene ...
Migrare un DC ... (http://leotardi.no-ip.com/html/spostamdominio/spostamdominio.htm)
dimencicavo, mi fanno messo win2003 SP2 R2, io invece ho solo win2003 SP2.. ci sono problemi?
Ciao
visto che hai un dominio nuovo una volta fatta la formattazione eleggi anche questo server a DC con il comando DCPROMO....
Ti conviene anche replicare il server dns.....
ma questa non è una migrazione, ma l'aggiunta di un dc se ho ben inteso quello che devi fare...
ma questa non è una migrazione, ma l'aggiunta di un dc se ho ben inteso quello che devi fare...
L'articolo che ha citato l'utente in effetti ha il titolo un po' fuorviante ma descrive passo passo come aggiungere un controllore di dominio e come trasferire alcuni tutti i ruoli chiave al nuovo DC.
L'articolo che ha citato l'utente in effetti ha il titolo un po' fuorviante ma descrive passo passo come aggiungere un controllore di dominio e come trasferire alcuni tutti i ruoli chiave al nuovo DC.
... quindi posso eseguire la procedura?
Ovviamente evito di passare i ruoli, in parole povere voglio avere due server che mi tengano su il Dominio e la rete anche nel caso in cui uno dei 2 server vada in crash ...
sperando di non avere lo stesso problema, come sopra .... :rolleyes:
... quindi posso eseguire la procedura?
Ovviamente evito di passare i ruoli, in parole povere voglio avere due server che mi tengano su il Dominio e la rete anche nel caso in cui uno dei 2 server vada in crash ...
sperando di non avere lo stesso problema, come sopra .... :rolleyes:
:help:
:help:
Continui a pensare ai domain controller in modo sbagliato, i domain controller dal 2000 in poi sono paritari nel dominio, non esiste il primario o il backup, sono tutti perfettamente uguali e hanno tutti copie in lettura/scrittura di AD e delle sue partizioni, i dc si mettono offline solo per manutenzioni e perchè vengono rimossi, Microsoft consiglia "caldamente" due dc per dominio con annessi dns
Unica differenza fra dc è che un domain controller detiene gli fsmo e gli altri no:) ora gli fsmo si possono trasferire: o perchè è necessario mettere il server offline per manutenzione per un prolungato periodo di tempo, o perchè da segni di cedimento, o perchè li vuoi distribuire nel tuo dominio in modo che il fail di un dc che li contiene, non li comprometta tutti e 5.
Il "seize" dei ruoli lo fai invece quando ti è scoppiato il dc che li ospita e non hai il backup, e quindi ti attacchi all'ultima spiaggia:(
Ora nel tuo caso con i due dc tu obbligatoriamente se vuoi fare sonni tranquilli la notte devi:
a) tenerli entrambe sempre online sempre 24h al giorno 7 giorni su 7
b) entrambi li devi configurare come dns, al limite pure come dhcp ( questo ovviamente con due scope diversi)o wins se necessiti di questi altri due servizi di rete ( oggi è raro che serva dato che dal 2000 in poi si va con il dns).
c) backup regolari dei systemstate di entrambi i dc e non sulle stesse macchine, ma su un dispositivo di backup in rete possibilmente in un altro ambiente che non sia la tua sala server, e comunque ogni volta che apporti modifiche importanti alla tua directory.
d) backup completo della macchina comunque ogni volta che fai modifiche importanti tipo installazione patch o sw che possano impattare notevolemente sulla macchina ( quest'ultima cosa è deprecabile perchè i dc devono fare solo i dc).
e) I dc come detto sopra solo quello devono fare: quindi no server di stampa, no applicativi che rompano le scatole tipo exchange o sql server o crm o web o quel che ti pare.
f) fare regolare manutenzione di AD.
questi altri punti dipendono dal tuo budget a disposizione e quanto puoi permetterti di stare offline con le macchine:
G) Usare per il server che detiene gli fsmo una macchina valida e ben carrozzata, con alimentatore ridondante e volumi raid sicuri tipo raid 1 o 5 o 10 con magari un disco spare.
H) tenere i sistemi in locali climatizzati a temperatura costante, e con gruppo di continuità di buona autonomia che funga anche da stabilizzatore.
Infine ricorda:
"il backup è bello, il backup è buono, il backup mi fa dormire la notte tranquillo":D
Questo come linea guida generale, che vale anche per altri sistemi che non siano dc ma che svolgano un ruolo critico nella tua struttura.
Questo come linea guida generale, che vale anche per altri sistemi che non siano dc ma che svolgano un ruolo critico nella tua struttura.
Concordo in pieno su tutti i punti, con l'unica eccezione che non vedo particolari controindicazioni nel far svolgere ai DC anche il ruolo di file server e print server.
Dato che non ho la pretesa di essere onnisciente, potresti motivare in modo un po' più esteso quali sono le controindicazioni?
Concordo in pieno su tutti i punti, con l'unica eccezione che non vedo particolari controindicazioni nel far svolgere ai DC anche il ruolo di file server e print server.
Dato che non ho la pretesa di essere onnisciente, potresti motivare in modo un po' più esteso quali sono le controindicazioni?
Banalmente minor numero di servizi e componenti che si trovano sul server e quindi minore superficie d'attacco per virus e malware e altri software dannosi, è un discorso di sicurezza, inoltre meno problemi che si possano incastrare servizi secondari che possano destabilizzare il server ( quello che non c'è non si rompe), e tempi più rapidi di installazione delle patch, (installi solo quelle relative a ciò che gira sopra al server) e questa è anche la filosofia intrapresa con l'avvento del 2008 dove microsoft punta molto alla specializzazione dei ruoli, e a seconda del ruolo che deve intraprendere il server vengono installati solo i servizi strettamente necessari a tale ruolo e nulla più, e dove sconsiglia per i dc l'installazione di servizi non strettamente connessi con tale ruolo.
C'è poi un discorso di rettività del server stesso, quanto impatta sulle sue performance avere che so un servizio che potrebbe fare un I/O disco importante, magari mentre è in corso una replica di AD, oppure durante l'autenticazione di un utente?
Senza poi contare che se sei costretto a mettere offline il server perchè devi fare manutenzione di AD (alle volte puoi pianificare alle volte invece no, immagina ti piallano per errore un OU con 100 utenti dentro e via di restore autoritativo della OU durante l'orario di ufficio.....pena quei 100 utenti non si loggano sul dominio) o se devi sostituire un componente hardware che ti obbliga a tenerlo spento, in questi casi se dovesse essere anche un file server o in print server, quanto puoi permetterti di tenere offline questi servizi che girano comunque sul DC?
Poi che ci siano in giro domain controller che oltre a fare da domain controller stesso, fanno 100 altre cose ne ho visti tanti, ma che sia una cosa buona sono piuttosto scettico:rolleyes:
Banalmente minor numero di servizi e componenti che si trovano sul server e quindi minore superficie d'attacco per virus e malware e altri software dannosi,
La mia esperienza è diversa.
Dominio AD con 180 client, tre DC due dei quali fanno anche da File e Print Server. Di virus ne abbiamo presi diversi, tutti solo sui client. I server sono UP da quasi cinque anni, senza nessun intervento di amministrazione straordinaria che abbia richiesto di metterli offline (abbiamo dovuto cambiare qualche disco, ma sono tutti in raid 5 hot swappable).
È chiaro che avere dei server specializzati è meglio, ma bisogna fare i conti con le risorse (spesso scarse) disponibili e, per la mia esperienza, far svolgere ai DC anche i ruoli di cui sopra non ha portato a grandi incrementi della rischiosità intrinseca.
La mia esperienza è diversa.
Dominio AD con 180 client, tre DC due dei quali fanno anche da File e Print Server. Di virus ne abbiamo presi diversi, tutti solo sui client. I server sono UP da quasi cinque anni, senza nessun intervento di amministrazione straordinaria che abbia richiesto di metterli offline (abbiamo dovuto cambiare qualche disco, ma sono tutti in raid 5 hot swappable).
È chiaro che avere dei server specializzati è meglio, ma bisogna fare i conti con le risorse (spesso scarse) disponibili e, per la mia esperienza, far svolgere ai DC anche i ruoli di cui sopra non ha portato a grandi incrementi della rischiosità intrinseca.
Che a voi sia sempre andata bene è un conto, che sia la cosa migliore invece è tutt'altra cosa, ed è evidente che a fronte delle indicazioni che la stessa microsoft fornisce, questa o quella azienda deroghi in base al suo budget e alla sua propensione ad assumersi dei rischi. :)
Personalmente noi preferiamo attenerci a quanto dice la microsoft e discostarci solo quando non possiamo fare altrimenti, presso dove lavoro io print server e file server sono ruoli svolti da macchine dedicate, previste espressamente in fase di progettazione dell'infrastruttura, e quindi messe debitamente a budget:)
Che a voi sia sempre andata bene è un conto, che sia la cosa migliore invece è tutt'altra cosa,
Invatti avevo sottolineato come quella fosse la mia esperienza ;)
ed è evidente che a fronte delle indicazioni che la stessa microsoft fornisce,
MS in questo caso opera in evidente conflitto di interessi :D
questa o quella azienda deroghi in base al suo budget e alla sua propensione ad assumersi dei rischi. :)
Nel nostro caso il budget ha avuto la meglio.
Personalmente noi preferiamo attenerci a quanto dice la microsoft e discostarci solo quando non possiamo fare altrimenti, presso dove lavoro io print server e file server sono ruoli svolti da macchine dedicate, previste espressamente in fase di progettazione dell'infrastruttura, e quindi messe debitamente a budget:)
Mettere a budget costa poco. Quando però il budget cala bisogna tagliare da qualche parte. Io ho preferito investire sulla "availability" di un numero ridotto di server piuttosto che sulla specializzazione dei ruoli.
Cioè, in una situazione di risorse limitate ho preferito investire sulla qualità e caratteristiche di "high availability" dei server piuttosto che su un aumento del loro numero per poter assegnare a ognuno di essi dei compiti specifici. E tale scelta è stata fatta in quanto ho considerato i costi marginali delle prime inferiori a quelle dei secondi.
Poi, ovviamente, il tutto va calato nella realtà operativa. Ho potuto "rischiare" anche perché nessuna delle attività gestite è "mission critical" e un eventuale fermo macchina avrebbe provocato tanti mugugni ma poche perdite economiche.
Invatti avevo sottolineato come quella fosse la mia esperienza ;)
magari va anche bene per molti altri, nel nostro caso no:)
MS in questo caso opera in evidente conflitto di interessi :D
Ma nemmeno tanto...almeno noi le licenze le paghiamo un tot al kilo :)
Nel nostro caso il budget ha avuto la meglio.
Nel nostro caso invece ha avuto la meglio il terrore delle penali imposte dal cliente in caso di fermo dei servizi, che nel migliore dei casi non possono andare oltre le 2 ore dalle 6 - 23 compresi sabato domenica e festivi, e dalle 23 alle 6 in caso superino le 4 ore vanno concordati con il cliente che deve esser debitamente avvisato ( alle volte mi vien da piangere )
Mettere a budget costa poco. Quando però il budget cala bisogna tagliare da qualche parte. Io ho preferito investire sulla "availability" di un numero ridotto di server piuttosto che sulla specializzazione dei ruoli.
Da voi tagliano sulle macchine (beati voi), da noi tagliano le le teste:muro:
Quanto "availability", lo stesso facciamo noi, però per assurdo 1 anno fa ci è saltata la piastra madre di un pe2800 di un cluster failover, e a quel punto pure con la garanzia mission critical 4H di Dell, abbiamo recitato il calendario, visto che poi il server secondario in standby non è salito.....:muro: :muro:
Cioè, in una situazione di risorse limitate ho preferito investire sulla qualità e caratteristiche di "high availability" dei server piuttosto che su un aumento del loro numero per poter assegnare a ognuno di essi dei compiti specifici. E tale scelta è stata fatta in quanto ho considerato i costi marginali delle prime inferiori a quelle dei secondi.
Poi, ovviamente, il tutto va calato nella realtà operativa. Ho potuto "rischiare" anche perché nessuna delle attività gestite è "mission critical" e un eventuale fermo macchina avrebbe provocato tanti mugugni ma poche perdite economiche.
Nella parte che ho evidenziato c'è la chiave di lettura del tutto, non avete una struttura "mission critical" e in quel caso un fermo di alcune ore è ok, nel mio caso lavorando in un ambiente "mission critical", anche il peto di un ape a 40 metri fa scattare la sirena di allarme.
Alla fine tutti hanno ragione e nessuno torto, nella tua realtà la scelta giusta è la tua, nella mia realtà anche 1% di rischio se può si deve eliminare anche a se richiede costi economici e amministrativi maggiori.
Magari per l'utente del topic i miei consigli poco si adattano alla sua realtà che forse è più simile alla tua. :)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.