Su quale DC si autentica un client?
Michele
Ho cercato in lungo e in largo nella rete ma non sono riuscito a trovare
una risposta alla mia domanda, forse la pongo male, non so. Sper che qua
qualcuno mi possa dare una mano.
Gestisco una rete wan al cui interno ci sono 5 DC con Windows 2003
Server Std. Il DC del centro stella ￜ quello che detiene i 5 ruoli FSMO.
Le reti sono tra loro collegate attraverso delle VPN ed il dominio per
tutti i DC ￜ unico.
Mi piacerebbe sapere se, ad esempio, tutti i client del centro stella si
collegano al DC del centro stella o se tentano (e riescono) a collegarsi
ad un altro DC localizzato altrove. C'ￜ un modo per verificare a quale
DC il client 001 si autentica nel dominio? Il collegamento dipende dalla
sottorete a cui il client appartiene o da cos'altro?
Grazie mille, ciao.
--
Michele
LC
Per sapere dove si logga un client basta fare:
set logon
da prompt dei comandi e avrai la risposta.
Comunque, per sapere se il tutto ￜ distribuito correttamente, la domanda
ￜ: "hai configurato i site di AD? se vai in AD Sites and Services vedi
la configurazione delle tue sedi?"
Ed infine: quanti Global Catalog hai? Se ne hai uno solo, considera che
tutti i client almeno una query la faranno a lui. MS consiglia di
mettere un GC in ogni sede dove c'ￜ un DC
Ciao
--
Luca
http://www.civinini.net
"Unix is simple. It just takes a genius to understand its simplicity." -
Dennis Ritchie
Peppacci - MVP -
COn questo comando vedi sul client a quale server a fatto logon. Diciamo che
non c'ￜ una verￜ e propria regola che ti fa disegnare il tuo site per
decidere su quale server fare logon, se a livello dns tutti i server hanno
lo stesso peso fara logon su quelo che ti risponde prima, ma su questo
argomento se ne potrebbe parlare a lungo. Cmq non hai descritto chiaramente
la tua struttura AD.
--
Peppacci - MVP -
Microsoft Exchange Server
http://blogs.sysadmin.it/peppacci/Default.aspx
Peppacci - MVP -
scatole se inviamo mail a destinatari sbagliati ￜ comodo inserire che
"Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione"
Insomma uno di tanti..
Michele
> Per sapere dove si logga un client basta fare:
> set logon
> da prompt dei comandi e avrai la risposta.
Perfetto, funziona alla grande! :)
> Comunque, per sapere se il tutto ￜ distribuito correttamente, la domanda
> ￜ: "hai configurato i site di AD? se vai in AD Sites and Services vedi
> la configurazione delle tue sedi?"
Vedo tutti i DC del dominio, si. Devo guardare qualcosa in particolare?
> Ed infine: quanti Global Catalog hai? Se ne hai uno solo, considera che
> tutti i client almeno una query la faranno a lui. MS consiglia di
> mettere un GC in ogni sede dove c'ￜ un DC
No, solo un DC ￜ GC e, penso non a caso, ￜ il primo che ￜ stato
installato. Il fatto ￜ che sono ancora un po' acerbo di AD e non ne so
molto. Quindi dovrei flaggare in tutti i DC il Global Catalog? Serve un
riavvio per applicare la modifica?
So che devo leggermi la KB ma in breve, perchￜ MS consiglia di mettere
un GC in ogni sede dove c'ￜ un DC?
Grazie mille per la tua risposta, gentilissimo.
Ciao.
--
Michele
Michele
> echo %logonserver%
Perfetto, funziona anche questo comando! :)
> COn questo comando vedi sul client a quale server a fatto logon. Diciamo
> che non c'ￜ una verￜ e propria regola che ti fa disegnare il tuo site
> per decidere su quale server fare logon, se a livello dns tutti i server
> hanno lo stesso peso fara logon su quelo che ti risponde prima, ma su
> questo argomento se ne potrebbe parlare a lungo. Cmq non hai descritto
> chiaramente la tua struttura AD.
Mmm, vediamo.
I DC sono in tutto 5: 2 nel centro stella, 2 nella sede remota piￜ
grande e 1 nella sede remota piￜ piccola.
Tutti i DC sono anche DNS server con il forwarder impostato verso i
server di OpenDNS.
1 DC del centro stella ￜ anche DHCP server;
1 DC nella sede remota piￜ grande ￜ anche DHCP server;
L'unico DC nella sede remota piￜ piccola ￜ anche DHCP server.
Le 3 sedi sono sotto subnet diverse l'una dall'altra.
Se ti servono altre info chiedi pure.
Grazie mille anche a te, ciao.
--
Michele
LC
> No, solo un DC ￜ GC e, penso non a caso, ￜ il primo che ￜ stato
> installato. Il fatto ￜ che sono ancora un po' acerbo di AD e non ne so
> molto. Quindi dovrei flaggare in tutti i DC il Global Catalog? Serve un
> riavvio per applicare la modifica?
> So che devo leggermi la KB ma in breve, perchￜ MS consiglia di mettere
> un GC in ogni sede dove c'ￜ un DC?
>
> Grazie mille per la tua risposta, gentilissimo.
>
> Ciao.
Senza entrare nella profonda teoria di AD ti dico alcuni elementi:
1. I site di AD "rimappano" la tua struttura fisica: se hai 5 sedi
connessi da linee "lente" (diciamo a cazzotto meno di 10 Mbps - non ￜ
preciso, ma la teoria ￜ lunga!)
2. I site sono "identificati" attraverso la subnet IP. Es.
192.168.0.0/24 - Firenze
192.168.1.0/24 - Roma
192.168.3.0/24 - Milano
10.1.5.0/24 - Napoli
...
3. Quando un PC viene acceso per la prima, chiede ad uno dei DC (uno
qualunque!) quale server usare per la validazione. Il DC risponde con
l'elenco dei server "piￜ vicini" ovvero nella stessa subnet del client
4. il client quindi contatta il DC indicato per le operazioni di logon
5. Al prossimo avvio il client "si ricorda" a quale site apparteneva e
riusa quel server (a meno che non abbia cambiato subnet, nel qual caso
viene informato dal DC di andare altrove)
6. il global catalog viene usato per tanti scopi:
- per tutte le ricerche fatte su AD (ok gli utenti non ne fanno molte !)
- se hai Exchange, le address book vengono scaricate dal DC
- se vuoi fare logon con l'upn (ovvero utente@dominio)
- il GC viene comunque interrogato al logon per vedere se l'utente fa
parte di uno o piￜ gruppi universali.
Per mettere GC un DC basta attivare il relativo flag dentro le proprietￜ
della voce "NTDS Settings" sotto il server nella console "Site and
services". Non richiede riavvio e tipicamente il processo si completa in
5 minuti (se hai un singolo dominio ￜ praticamente immediato - con piￜ
domini la cosa si fa lunga). Sull' Event viewer, nella voce Directory
Service, troverai al termine un evento che dice pressappoco "the server
is now a Global Catalog"
P.S.
Conosco piￜ di una struttura dove TUTTI i domain controller sono anche
Global Catalog
Michele
> Senza entrare nella profonda teoria di AD ti dico alcuni elementi:
>
> 1. I site di AD "rimappano" la tua struttura fisica: se hai 5 sedi
> connessi da linee "lente" (diciamo a cazzotto meno di 10 Mbps - non ￜ
> preciso, ma la teoria ￜ lunga!)
Non ho capito bene questa parte. Le mie reti sono di fatto collegate
insieme attraverso linee adsl da 7 Mbit e quindi?? Vuol dire che anche
internamente alla LAN il server "tratta" i client come se fossero
collegati con 7 Mbit invece che 100??
> 2. I site sono "identificati" attraverso la subnet IP. Es.
> 192.168.0.0/24 - Firenze
> 192.168.1.0/24 - Roma
> 192.168.3.0/24 - Milano
> 10.1.5.0/24 - Napoli
> ...
Ok, chiaro.
> 3. Quando un PC viene acceso per la prima, chiede ad uno dei DC (uno
> qualunque!) quale server usare per la validazione. Il DC risponde con
> l'elenco dei server "piￜ vicini" ovvero nella stessa subnet del client
>
> 4. il client quindi contatta il DC indicato per le operazioni di logon
>
> 5. Al prossimo avvio il client "si ricorda" a quale site apparteneva e
> riusa quel server (a meno che non abbia cambiato subnet, nel qual caso
> viene informato dal DC di andare altrove)
Sto verificando perￜ delle cose per me strane. Mi sono collegato ad un
client appartenente alla subnet del centro stella dove c'ￜ il DC GC.
Al primo logon lanciando echo %logonserver% mi compare
\\DC-CENTRO-STELLA; faccio un logout e di nuovo un login e al lancio
dello stesso comando mi compare \\DC-SEDE-REMOTA1: come ￜ possibile
tutto ciￜ? Il server \\DC-SEDE-REMOTA1 ￜ in un altra subnet ed ￜ, tra
l'altro, quello fisicamente piￜ lontano dal centro stella.
Come mai il client non si ￜ ricordato di accedere all'ultimo server?
> 6. il global catalog viene usato per tanti scopi:
> - per tutte le ricerche fatte su AD (ok gli utenti non ne fanno molte !)
> - se hai Exchange, le address book vengono scaricate dal DC
> - se vuoi fare logon con l'upn (ovvero utente@dominio)
> - il GC viene comunque interrogato al logon per vedere se l'utente fa
> parte di uno o piￜ gruppi universali.
Ok.
> Per mettere GC un DC basta attivare il relativo flag dentro le proprietￜ
> della voce "NTDS Settings" sotto il server nella console "Site and
> services". Non richiede riavvio e tipicamente il processo si completa in
> 5 minuti (se hai un singolo dominio ￜ praticamente immediato - con piￜ
> domini la cosa si fa lunga). Sull' Event viewer, nella voce Directory
> Service, troverai al termine un evento che dice pressappoco "the server
> is now a Global Catalog"
Ok.
> P.S.
> Conosco piￜ di una struttura dove TUTTI i domain controller sono anche
> Global Catalog
Ok, ciao e grazie mille, gentilissimo.
--
Michele
Peppacci - MVP -
default? I client remoti puntano come dns ai DC che hanno in locale e gli
stessi dc sono anche GC?
Michele
> I server remoti sono situati in un site specifico o sono tutti in quello di
> default?
Questa domanda non l'ho proprio capita scusami.
> I client remoti puntano come dns ai DC che hanno in locale e gli
> stessi dc sono anche GC?
La politica che ho adottato è che tutti client puntano al server DNS-
DC locale, in tutte le sedi.
Come ho avuto di spiegarti in qualche post sopra, esiste tra i 5 DC 1
solo GC che è il primo DC installato nel centro stella; nessuno degli
altri è GC.
Stamattina ho fatto altri test incuriosito dal risultato di ieri sera
e ho scoperto che 4 dei 5 client che ho testato in locale nel centro
stella hanno come logon server uno dei DC remoti: come è possibile che
un client appartenente alla rete es. 10.20.20.x vada a chiedere
l'autenticazione au un DC posto a 100 Km la cui subnet è es.
192.168.137.x?? Qual'è il criterio??
Grazie ancora, ciao.
Peppacci - MVP -
primario per i client.
Edoardo Benussi [MVP]
credo che la risposta stia da altra parte.
tu hai detto che hai un server dhcp nel centro stella
e basta quindi hai un solo dhcp che serve
gli indirizzi ip ai clients insieme alle scope options
ossia indirizzo ip del router, indirizzo ip del dns server,
indirizzo ip dell'eventuale server wins
quindi tutti i tuoi clients, in qualunque sede siano,
prendono l'ip dal medesimo dhcp server
con le stesse options mentre affinch� i clients
capiscano che si trovano nel determinato site
e che si devono autenticare al dc di quel site
devono avere
1) o un dhcp che fornisce un ambito
nella sottorete di quel sito
2) oppure l'ip statico con i parametri
di indirizzamento per la sottorete di quel sito.
ciao.
--
Edoardo Benussi - e...@mvps.org
Microsoft� MVP - Most Valuable Professional
Management Infrastructure - Systems Administration
https://mvp.support.microsoft.com/Profile/Benussi
Michele
wrote:
> Michele wrote:
>
> credo che la risposta stia da altra parte.
>
> tu hai detto che hai un server dhcp nel centro stella
> e basta quindi hai un solo dhcp che serve
> gli indirizzi ip ai clients insieme alle scope options
> ossia indirizzo ip del router, indirizzo ip del dns server,
> indirizzo ip dell'eventuale server wins
> quindi tutti i tuoi clients, in qualunque sede siano,
> prendono l'ip dal medesimo dhcp server
> con le stesse options
No scusa, non ho detto esattamente questo. Se guardi in alcuni post
rpecedenti dove ho cercato di descrivere la struttura, ho evidenziato
che ogni sede remota ha un proprio DHCP server per la propria
sottorete e con i parametri (scope, router, dns, ecc.) di quella
sottorete.
Non è che un client nella sede remota viene a prendersi un ip dal DHCP
del centro stella eh!
> mentre affinchè i clients
> capiscano che si trovano nel determinato site
> e che si devono autenticare al dc di quel site
> devono avere
> 1) o un dhcp che fornisce un ambito
> nella sottorete di quel sito
E' esattamente così: l'ambito è nella sotto rete di ogni site.
> 2) oppure l'ip statico con i parametri
> di indirizzamento per la sottorete di quel sito.
No, non credo sia come dici tu o magari c'è dell'altro. Il mio pc che
uso al lavoro ha un ip statico nella sottorete del DC locale che c'è
qua eppure anche ora ha fatto il logon sul DC della sede remota.
Grazie, ciao.
Edoardo Benussi [MVP]
[cut]
chiedo scusa perch�
non avevo capito che avevi un dhcp in ogni sito.
per�, almeno ho escluso questo caso :)
quindi ritorna determinante la domanda
che ti ha fatto Peppacci: i dc sono collocati nei Sites corretti
e le subnet sono configurate correttamente rispetto ai sites ?
Michele
wrote:
> chiedo scusa perchè
> non avevo capito che avevi un dhcp in ogni sito.
> quindi ritorna determinante la domanda
> che ti ha fatto Peppacci: i dc sono collocati nei Sites corretti
> e le subnet sono configurate correttamente rispetto ai sites ?
Niente scuse, ci mancherebbe... :)
La domanda di Peppacci non credo di averla capita bene o meglio, non
so cosa verificare per dare una risposta corretta: come vedo se i DC
sono collocati nei sites corretti e le subnet sono configurate
correttamente rispetto ai sites?
Grazie ancora, ciao.
Michele
> Niente scuse, ci mancherebbe... :)
> La domanda di Peppacci non credo di averla capita bene o meglio, non
> so cosa verificare per dare una risposta corretta: come vedo se i DC
> sono collocati nei sites corretti e le subnet sono configurate
> correttamente rispetto ai sites?
Credo di aver capito la domanda adesso, ho dato un'occhiata a AD Sites
and Services ed ho questa situazione:
- esiste un unico site denominato "Default-First-Site_name"
all'interno del quale sono collocati tutti e 5 i miei DC;
- la sezione subnets è vuota.
Immagino che Peppacci intendesse questo quando mi ha fatto la domanda.
Quindi dovrei creare un Site per ogni sede remota, giusto? All'interno
di ognuna delle sedi remota collocarci i DC di appartenenza. Poi
dovrei creare una subnet per ogni sede remota, inserirci le sottoreti
e in qualche modo "legare" le subnet ai Sites creati in precedenza.
Premetto che ho ereditato questa situazione e non ho esperienza di AD
in ambito diciamo multi-DC (anche se dello stesso dominio come nel mio
caso). Nel caso volessi "sistemare" le cose mi piacerebbe sapere quale
procedimento seguire, a cosa fare attenzione e quali sono le
controindicazioni perchè immagino che ce ne siano. Mi viene in mente
una situazione: cosa succede ai client di una determinata sede remota
(o anche nel centro stella) se una volta impostati tutti i Sites e le
Subnets uno dei DC che gestisce una sede smette di funzionare (crasha
un disco o altro malfunzionamente che ne impedisce l'avvio per
esempio)? I client di quella sede come si comporterebbero? Ci sarebbe
innanzitutto il problema del DHCP ma andrebbero a cercare altrove un
logon server? Adesso lo fanno anzi, adesso sembra preferiscano
loggarsi sempre ad un server diverso da quello locale, ma una volta
"separate" le reti sui DC che succederebbe?
Grazie tante, ciao.
Edoardo Benussi [MVP]
> On 25 Ago, 14:48, Michele <myk...@gmail.com> wrote:
>> Niente scuse, ci mancherebbe... :)
>> La domanda di Peppacci non credo di averla capita bene o meglio, non
>> so cosa verificare per dare una risposta corretta: come vedo se i DC
>> sono collocati nei sites corretti e le subnet sono configurate
>> correttamente rispetto ai sites?
>
> Credo di aver capito la domanda adesso, ho dato un'occhiata a AD Sites
> and Services ed ho questa situazione:
> - esiste un unico site denominato "Default-First-Site_name"
> all'interno del quale sono collocati tutti e 5 i miei DC;
>
> Immagino che Peppacci intendesse questo quando mi ha fatto la domanda.
> Quindi dovrei creare un Site per ogni sede remota, giusto?
esattamente!
> All'interno di ognuna delle sedi remota collocarci i DC di appartenenza.
> Poi
> dovrei creare una subnet per ogni sede remota, inserirci le sottoreti
> e in qualche modo "legare" le subnet ai Sites creati in precedenza.
esattissimamente!!!
> Premetto che ho ereditato questa situazione e non ho esperienza di AD
> in ambito diciamo multi-DC (anche se dello stesso dominio come nel mio
> caso). Nel caso volessi "sistemare" le cose mi piacerebbe sapere quale
> procedimento seguire, a cosa fare attenzione e quali sono le
> controindicazioni perch� immagino che ce ne siano.
tu hai gi� i dc messi fisicamente nelle sedi opportune
e configurati con l'ip della sottorete opportuna,
devi solo creare i siti corrispondenti alle sedi
diverse dal centro stella che rimarr� il default site,
dovrai spostare i dc che non sono nel centro stella
dal default site al sito in cui si trovano
e poi definire le sottoreti di ciascun sito.
a quel punto verranno automaticamente generati
i link di replica inter-site e nel registro eventi
andrai a verificare che anche la replica di active directory
tra siti diversi funziona regolarmente.
> Mi viene in mente
> una situazione: cosa succede ai client di una determinata sede remota
> (o anche nel centro stella) se una volta impostati tutti i Sites e le
> Subnets uno dei DC che gestisce una sede smette di funzionare (crasha
> un disco o altro malfunzionamente che ne impedisce l'avvio per
> esempio)? I client di quella sede come si comporterebbero? Ci sarebbe
> innanzitutto il problema del DHCP ma andrebbero a cercare altrove un
> logon server? Adesso lo fanno anzi, adesso sembra preferiscano
> loggarsi sempre ad un server diverso da quello locale, ma una volta
> "separate" le reti sui DC che succederebbe?
vanno a cercare un dc che non � nel loro sito.
ciao.
Michele
[cut]
> esattissimamente!!!
Quindi riassumendo: almeno uno dei DC posti nelle sedi remote deve
diventare Global Catalog.
Creo un Site per ogni sede remota, lego le subnet ad ogni Site, sposto i
DC remoti dal Default site a quelli remoti, lascio il DC del centro
stella nel Default site: tutto giusto?
Per fare tutto ciￜ ￜ necessario che nessun client sia loggato o ￜ
indifferente? Inoltre, questi cambiamenti influiranno sulla
configurazione dei DNS record?
Altro dubbio che necessita di ulteriore descrizione della mia config:
- DC centro stella collegato via VPN con DC di sede remota1 e sede remota2;
- DC sede remota1 e sede remota2 NON collegati ma le modifiche di AD
vengono propagate e replicate grazie al collegamento descritto prima.
Sta di fatto che i DC delle 2 sedi remote sanno dell'esistenza gli uni
degli altri ma di fatto non riescono a collegarsi direttamente. Questo
genera ovviamente degli errori negli event viewer che, credo a ragione,
ho sempre ignorato visto che le repliche venivano comunque effettuate.
Non ￜ che questo cambio di configurazione che di fatto separa i DC in
base alla locazione geografica e alle subnets creerￜ qualche problema
piￜ grave dei log negli event viewer?
Spero di essermi spiegato bene.
Un'ultima cosa: ￜ giusto che il primo DC installato (quello del centro
stella) sia il solo ad avere tutti i ruoli FSMO?
>> Mi viene in mente
>> una situazione: cosa succede ai client di una determinata sede remota
>> (o anche nel centro stella) se una volta impostati tutti i Sites e le
>> Subnets uno dei DC che gestisce una sede smette di funzionare (crasha
>> un disco o altro malfunzionamente che ne impedisce l'avvio per
>> esempio)? I client di quella sede come si comporterebbero? Ci sarebbe
>> innanzitutto il problema del DHCP ma andrebbero a cercare altrove un
>> logon server? Adesso lo fanno anzi, adesso sembra preferiscano
>> loggarsi sempre ad un server diverso da quello locale, ma una volta
>> "separate" le reti sui DC che succederebbe?
>
> vanno a cercare un dc che non ￜ nel loro sito.
Benissimo.
Se sarete cosￜ gentili da soddisfare anche queste mie ultime perplessitￜ
mi organizzo per mettere in pratica i cambi di configurazione.
Ancora grazie della vostra pazienza e chiarezza.
Ciao.
--
Michele
LC
> Immagino che Peppacci intendesse questo quando mi ha fatto la domanda.
> Quindi dovrei creare un Site per ogni sede remota, giusto? All'interno
> di ognuna delle sedi remota collocarci i DC di appartenenza. Poi
> dovrei creare una subnet per ogni sede remota, inserirci le sottoreti
> e in qualche modo "legare" le subnet ai Sites creati in precedenza.
>
Esattamente: crea i sites, associa le subnet ai sites e quindi sposta i
server nei relativi sites.. Aspetta un po' di tempo e vedrai che i link
di collegamento cambieranno (da tipo RPC a tipo IP).
Non avere fretta (se hai fretta si puo' fare qualche forzatura ma da
quello che dici sei un po' acerbo di AD ed � meglio evitare).
> Premetto che ho ereditato questa situazione e non ho esperienza di AD
> in ambito diciamo multi-DC (anche se dello stesso dominio come nel mio
> caso). Nel caso volessi "sistemare" le cose mi piacerebbe sapere quale
> procedimento seguire, a cosa fare attenzione e quali sono le
> controindicazioni perch� immagino che ce ne siano. Mi viene in mente
> una situazione: cosa succede ai client di una determinata sede remota
> (o anche nel centro stella) se una volta impostati tutti i Sites e le
> Subnets uno dei DC che gestisce una sede smette di funzionare (crasha
> un disco o altro malfunzionamente che ne impedisce l'avvio per
> esempio)? I client di quella sede come si comporterebbero? Ci sarebbe
> innanzitutto il problema del DHCP ma andrebbero a cercare altrove un
> logon server? Adesso lo fanno anzi, adesso sembra preferiscano
> loggarsi sempre ad un server diverso da quello locale, ma una volta
> "separate" le reti sui DC che succederebbe?
>
> Grazie tante, ciao.
Non ti preoccupare per il fault tolerance. E' assodato che se il tuo DC
non risponde viene usato quello del site "pi� vicino".
Se poi vogliamo essere pignoli dovremmo definire a modino i site link
(adesso ne avrai solo uno che si dovrebbe chiamare DEFAULTIPSITELINK).
Altrimenti potrebbe accadere che i client di SEDE-REMOTA1, se il loro
DC/GC muore, usino il DC/GC di SEDE-REMOTA2 anzich� quello centrale.
In pratica:
- i sites sono le tue sedi (per AD adesso ne hai una sola chiamata
DEfault-First-Site-Name).
- il tuo unico site � collegato ad un "tubo" chiamato DEFAULTIPSITELINK
Dopo aver fatto la suddivisione in site avrai:
- un site per ogni sede
- tutti i site collegati ad un unico "tubo" (immagina una vecchia rete
in 10Base2 con il cavo coassiale che girava per tutti i PC)
Con questa configurazione AD penser� che che tutti i site sono
ugualmente raggiungibili (ma immagino che per andare da sede-remota1 a
sede-remota2 i pacchetti debbano passare per il centro stella). Per fare
quindi le cose fatte bene dovresti fare anche tanti site-link quanti
sono i collegamenti che hai con le sedi remote, lasciando in pratica il
DEFAULTIPSITELINK vuoto. Schematicamente
SedeRemota1 <- site link 1 -> SedeCentrale
SedeRemota2 <- site link 2 -> SedeCentrale
SedeRemota3 <- site link 3 -> SedeCentrale
... e via cos�
Spero di essere stato chiaro.
![Gabriele Del Giovine [Sharepoint MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjW2MXoOr9W5NMEFVchiOuglZoKch7i4BMg7NPpuAuf5_YNedQ=s40-c)
Gabriele Del Giovine [Sharepoint MVP]
"Michele" <myk...@gmail.com> wrote in message
news:0028fe53-5354-4ec3...@v20g2000yqm.googlegroups.com...
> On 25 Ago, 09:40, "Peppacci - MVP -" <g.trafica...@sysadmin.it> wrote:
>> I server remoti sono situati in un site specifico o sono tutti in quello
>> di
>> default?
>
> Questa domanda non l'ho proprio capita scusami.
S'era capito :-)
Michele
>> Questa domanda non l'ho proprio capita scusami.
>
> S'era capito :-)
Contributo notevole, grazie. :)
Ciao.
--
Michele
LC
> Edoardo Benussi [MVP] ha scritto:
> [cut]
>> esattissimamente!!!
>
> Quindi riassumendo: almeno uno dei DC posti nelle sedi remote deve
> diventare Global Catalog.
> Creo un Site per ogni sede remota, lego le subnet ad ogni Site, sposto i
> DC remoti dal Default site a quelli remoti, lascio il DC del centro
> stella nel Default site: tutto giusto?
> Per fare tutto ciￜ ￜ necessario che nessun client sia loggato o ￜ
> indifferente? Inoltre, questi cambiamenti influiranno sulla
> configurazione dei DNS record?
Puoi farlo mentre la gente lavora. Se proprio vuoi stare tranquillo
fallo la sera tardi ed attendi che tutti i connettori si siano
riconfigurati su "IP"
>
> Altro dubbio che necessita di ulteriore descrizione della mia config:
> - DC centro stella collegato via VPN con DC di sede remota1 e sede remota2;
> - DC sede remota1 e sede remota2 NON collegati ma le modifiche di AD
> vengono propagate e replicate grazie al collegamento descritto prima.
Mi stai dicendo che sederemota1 non raggiunge sederemota2? ovvero che le
due reti vedono solo il centro stella?
Se cosￜ ￜ sei nel caso di rete "not fully routable" e quindi ￜ
necessario creare anche i site link e disattivare l'opzione "BRIDGE ALL
SITE LINKS) - la trovi nelle proprietￜ della "cartella IP" sotto la voce
"Inter site transports"
>
> Sta di fatto che i DC delle 2 sedi remote sanno dell'esistenza gli uni
> degli altri ma di fatto non riescono a collegarsi direttamente. Questo
> genera ovviamente degli errori negli event viewer che, credo a ragione,
> ho sempre ignorato visto che le repliche venivano comunque effettuate.
> Non ￜ che questo cambio di configurazione che di fatto separa i DC in
> base alla locazione geografica e alle subnets creerￜ qualche problema
> piￜ grave dei log negli event viewer?
> Spero di essermi spiegato bene.
> Un'ultima cosa: ￜ giusto che il primo DC installato (quello del centro
> stella) sia il solo ad avere tutti i ruoli FSMO?
FSMO: Flexible SINGLE MASTER Operation ovvero quei ruoli stanno su una
macchina sola. Non ￜ obbligatorio averli tutti insieme ma ad eccezione
di casi particolari non serve "splittarli" su varie macchine
Michele
> Puoi farlo mentre la gente lavora. Se proprio vuoi stare tranquillo
> fallo la sera tardi ed attendi che tutti i connettori si siano
> riconfigurati su "IP"
Perfetto!!
> Mi stai dicendo che sederemota1 non raggiunge sederemota2? ovvero che le
> due reti vedono solo il centro stella?
Esattamente.
> Se cosￜ ￜ sei nel caso di rete "not fully routable" e quindi ￜ
> necessario creare anche i site link e disattivare l'opzione "BRIDGE ALL
> SITE LINKS) - la trovi nelle proprietￜ della "cartella IP" sotto la voce
> "Inter site transports"
Ok chiarissimo ma mi sorge un altro dubbio (scusami): non ￜ che cosￜ
facendo impedisco di fatto la replica di AD tra i vari DC, vero?
A dire il vero stavo recentemente pensando di togliere le repliche
"impossibili" che di fatto mi generano solo degli errori negli event
viewers quelle cioￜ tra sederemota1 e sederemota2 che, come da te stesso
ununciato, non si vedono. Se il mio intento ￜ giusto, ￜ possibile ad
sempio far si che il DC1 della sederemota1 NON si replichi sul DC2 della
sederemota2 e viceversa? Tanto i dati vengono comunque replicati dal DC1
del centro stella su entrambe le sedi remote.
Ultima domanda: tutti i DC tranne 1 hanno l'OS in lingua inglese, 1 ￜ in
Italiano: cambia qualcosa o quest'ultimo viene comunque trattato come
gli altri?
> FSMO: Flexible SINGLE MASTER Operation ovvero quei ruoli stanno su una
> macchina sola. Non ￜ obbligatorio averli tutti insieme ma ad eccezione
> di casi particolari non serve "splittarli" su varie macchine
Chiarissimo!!
Grazie mille anche a te per la grande disponibilitￜ e pazienza.
Ciao.
--
Michele
LC
> Ok chiarissimo ma mi sorge un altro dubbio (scusami): non ￜ che cosￜ
> facendo impedisco di fatto la replica di AD tra i vari DC, vero?
> A dire il vero stavo recentemente pensando di togliere le repliche
> "impossibili" che di fatto mi generano solo degli errori negli event
> viewers quelle cioￜ tra sederemota1 e sederemota2 che, come da te stesso
> ununciato, non si vedono. Se il mio intento ￜ giusto, ￜ possibile ad
> sempio far si che il DC1 della sederemota1 NON si replichi sul DC2 della
> sederemota2 e viceversa? Tanto i dati vengono comunque replicati dal DC1
> del centro stella su entrambe le sedi remote.
Ovviamente si, ma ￜ quello che vogliamo dato che i due "estremi" non si
parlano!
Mi spiego: dato che sei in una situazione a singolo dominio tutti i DC
contengono le stesse informazioni. Quindi, se il DC di SedeRemota1
replica con DC SedeCentrale e a sua volta ques'ultimo replica con quello
di SedeRemota2 la tua struttura funziona perfettamente. Ovviamente, una
modifica fatta su un DC "remoto" impieghera' piￜ tempo ad arrivare ad un
altro DC remoto dato che deve passare dalla sede centrale.
Se avessi avuto piￜ domini allora la cosa sarebbe stata diversa (e te ne
saresti accorto molto prima!)
> Ultima domanda: tutti i DC tranne 1 hanno l'OS in lingua inglese, 1 ￜ in
> Italiano: cambia qualcosa o quest'ultimo viene comunque trattato come
> gli altri?
A parte il prurito alle mani ogni volta che devo loggarmi su un server
in italiano, non cambia nulla! Attenzione magari alle GPO: ti conviene
sempre editarle dallo stesso DC per evitare che i template "si mischino"
e come risultato avresti le descrizioni mezze in inglese e mezze in
italiano (ma a parte questo funziona tutto)
> Grazie mille anche a te per la grande disponibilitￜ e pazienza.
Di nulla
Buon lavoro