Advies: 2e DC toevoegen of 1e in nieuw domein/site?

[fabstar81]

Goedemorgen GoTters,

situatie:
sub.domein.com domain op adres a
1 win2k3 dc, ad, exch, iis, ftp, print, dfs
mixed clients (xp, 7)

wens:
uiteindelijk overgaan naar sub.domein.org domain (gelijknamig subdomein)
bovendien wil ik het domain verspreiden over 2 sites (adres a en b).
kunnen inloggen op beide adressen

problemen:
verandering van domeinnaam op 1 server niet te doen

vraag:
welke situatie is het beste:
1: een tweede dc erbij zetten op adres b en de .com -> .org laten voor wat het is
2: een eerste dc oprichten in .org domein maar in zelfde forest voor adres b, VPN regelen tussen de 2 adressen, trusts maken, en inloggen maar
3: een eerste dc oprichten in .org domein in nieuwe forest voor adres b, VPN regelen tussen de 2 adressen, trusts maken, en inloggen maar
4: een tweede dc erbij zetten op adres b, en een nieuwe "site" aanmaken zodat clients op de goede server inloggen afhankelijk van locatie

Het gaat me op dit moment nog maar om het nadenken over de infrastructuur. het is zo dat de nieuwe dc op adres b wel meer files zal moeten transferren, dus het handigst is misschien om de profielen e.d. op adres b te zullen opslaan. feit is wel dat de eerste server op adres a moet blijven staan.

Wat ik al heb geprobeerd:
ik heb een gelijknamige subdomein aangemaakt eindigend op .org op de nieuwe 2008 dc. echter bij het toevoegen van dit domein in de forest zegt ie dat hij dat de netbios dezelfde naam heeft. logisch, het is ook hetzelfde , heb dat nu aangepast. nog niet alle gebruikers kunnen op beide dc's inloggen, maar dat komt ws door rechten. administrator account lukt wel, dus iig is de communicatie tussen de 2 servers goed. ik krijg nog niet alle bestanden (desktops zijn gedeeld) te zien dus met de rechten van de files is ook nog iets mis.

einddoel:
uiteindelijk met beide servers over te zijn op het .org subdomein en op beide adressen in te kunnen loggen.

wat is dus nu de beste werkwijze? of structuur?

[Razwer]

wat is de grote nood van .com naar .org veranderen? erg arbeids intensief en redelijk nutteloos.
optie 1 zou ik voor gaan. simpelste oplossing en werkt het beste.
als je DNS entries nodig hebt voor extern resolven op .org is het simpel genoeg om een 2e zone te maken.
het is toch niet echt gewenst je interne DNS op internet te laten resolven als deze dus ook zou gebruiken voor externe adressen. Mits je dat van plan was, maar lijkt me de enige "logische beredenering".

[Rolfie]

1: een tweede dc erbij zetten op adres b en de .com -> .org laten voor wat het is

Mooi doen en zo laten, alleen nog een site er bij aanmaken (ofwel zie 4).

2: een eerste dc oprichten in .org domein maar in zelfde forest voor adres b, VPN regelen tussen de 2 adressen, trusts maken, en inloggen maar

3: een eerste dc oprichten in .org domein in nieuwe forest voor adres b, VPN regelen tussen de 2 adressen, trusts maken, en inloggen maar

Volgens mij is zo dat als je ze in het zelfde forest installeerd, er al meteen een trust is.
Je weet wel, dat bij een uitval van de VPN tunnel je niet meer kan inloggen?
Je weet ook al all je authenticatie verkeer altijd over de VPN tunnel moet, icm alle GPO's, login scripts, roaming profiles enz enz.

4: een tweede dc erbij zetten op adres b, en een nieuwe "site" aanmaken zodat clients op de goede server inloggen afhankelijk van locatie

Ik zou voor deze gaan, of je moet om werk verlegen zitten.

Bedenk je goed waarom zou je het ongelooflijk moeilijk maken? Wat is de redenen om de .com aan te passen naar de .org. Je gebruikers merken er toch niets van.

[fabstar81]

de reden is dat ik de .com niet meer bezit. dus ik dacht, overstappen op de .org zodat ik niet telkens mn remote desktopadressen aan moet passen van .com naar .org. outlook anywhere zou dan ook gewoon altijd werken.

maar lees ik nu dat dat dus op te lossen is middels DNS?
al de laptops die buiten komen zijn dus aangemeld bij het domein .com, maar als ik remote desktop wil terwijl ik niet op het netwerk zit, moet ik dus altijd aanpassen naar .org. dat is eigenlijk de enige reden. de mailadressen zijn in exchange al naar de .org geconfigt, en daarmee is de communicatie iig ook afgevangen.

ik doe dus het beste eraan om een 2e dc erbij te plaatsen in de bestaande domain .com. Nu staat deze week nog de 2e DC op dezelfde locatie als de 1e. Is het makkelijk te configgen als de 2 dc's op de 2 verschillende adressen staan? VPN volstaat dan? of is het aan te raden om het nu te doen.

hoe zit het verder met rootshares enzo? roaming profiles? het handigste is dat de servers die beiden bezitten en wellicht snachts of real time syncen?

[Rolfie]

de reden is dat ik de .com niet meer bezit. dus ik dacht, overstappen op de .org zodat ik niet telkens mn remote desktopadressen aan moet passen van .com naar .org. outlook anywhere zou dan ook gewoon altijd werken.

al de laptops die buiten komen zijn dus aangemeld bij het domein .com, maar als ik remote desktop wil terwijl ik niet op het netwerk zit, moet ik dus altijd aanpassen naar .org. dat is eigenlijk de enige reden.

ik doe dus het beste eraan om een 2e dc erbij te plaatsen in de bestaande domain .com. Nu staat deze week nog de 2e DC op dezelfde locatie als de 1e. Is het makkelijk te configgen als de 2 dc's op de 2 verschillende adressen staan? VPN volstaat dan? of is het aan te raden om het nu te doen.

Misschien een boekje lezen? Bij microsoft eens wat artikelen lezen? Daarin wordt dit allemaal prima uitgelegd.

hoe zit het verder met rootshares enzo? roaming profiles? het handigste is dat de servers die beiden bezitten en wellicht snachts of real time syncen?

Misschien een boekje lezen? en kijken naar DFS werkt eventueel icm DFS-R?
Maar roaming profiles .

[fabstar81]

de roaming profiles die bestaan natuurlijk al. het hele domein bestaat al. alles werkt naar behoren, alleen moet ik dus op een tweede locatie een 2e dc neerzetten zodat ik ook op die locatie kan inloggen. DFS bestaat ook al, er wordt gebruik gemaakt van rootshares waaronder alle shares c.q. roaming profiles/app data/my docs etc hangen.

vraag nu is; ik moet dus gaan proberen om de rootshare te replicerren over de DC's (VPN) zodat het laden niet eindeloos lang duurt wil je op locatie a inloggen terwijl je profile op b staat, en vice versa.

[alt-92]

Wat zegt je eigen common sense DLL ?
Ik kan me voorstellen dat je de initiële sync op dezelfde lokatie wil doen om de replicatietijd op lokatie B terug te dringen, dat wel.

Al snap ik nog steeds niet wat je nu wil met je TLD wijziging, tenzij je zowel intern als extern dezelfde namespace gebruikt.

[fabstar81]

nou ja, dat veranderen van de TLD is puur cosmetisch eigenlijk. door de arbeidsintensiviteit heb ik dat maar laten schieten. ik wacht wel totdat de .com weer beschikbaar komt. enige reden is dus dat de laptops die buiten het domein komen, bijvoorbeeld het serveradres moeten aanpassen als ze buiten de router verbinding willen maken. maar ja, aparte favorieten van bijvoorbeeld exchange webmail zijn zo aangemaakt.

ik heb gister de 2e DC toegevoegd in de oorspronkelijke .com domain. moest nog ff domainprep draaien en het domain native maken (dacht dat ik dat al jaren gedaan had ) en klaar is het. en wat ben ik dom, ben ik vergeten eerst de computernaam te veranderen. fucked up dus.

het is compleet in het beginstadium van het bijplaatsen, maar kan ik nu beter de dc zo hernoemen of kan ik hem beter uit het domein halen, nieuwe naam geven, weer in het domein plaatsen?

ik zag trouwens tijdens het repliceren dat er nog resten van de bijgeplaatste .org domain in het forest waren. dacht dat ik die compleet had verwijderd dmv adsiedit en ntdsutil.

vandaag hopelijk nieuwe site toevoegen, RAS en VPN opzetten en dan de server verhuizen naar lokatie A. de rest kan k wel via VPN doen.

[fabstar81]

potverdorie!
nu heb ik al voor de 2e keer dat die nieuwe DC zegt, NA het toevoegen in het domain, na een paar keer rebooten en hardware changes dat "your computer is currently not connected to any networks".

iemand die weet wat dat is? op google blijkt dat het vaker voorkomt op vista computers, maar geen resultaten i.c.m. windows 2008. heb al meerdere NIC's geprobeerd en rebooten en dat soort zaken helpt ook niet.

de eerste keer heb ik een reinstall gedaan, maar ja...dan zzit je weer met een vervuild domain omdat de DC niet netjes is afgemeld.

grrrrrrrrr

[Verwijderd]

Je hebt een reinstall van je nieuwe DC gedaan, maar geen demote kunnen uitvoeren omdat je geen verbinding kreeg kort samengevat?? Is het een virtual dat je over hardware changes praat?

[fabstar81]

ja klopt. kreeg geen verbinding (ineens was de NIC gewoon verdwenen uit apparaatbeheer en kreeg met geen mogelijk hem terug) en kon dus geen demote doen.

het is een hardware server. heb hem voor de wedstrijd helemaal leeggetrokken kwa hardware met alleen die NIC erin en toen herkende ie hem weer. misschien had het te maken met een wireless kaart die er ook in zit. helaasch...die zal dus ff moeten wachten totdat ik die aan de praat krijg.

anyways....nu werkt alles weer naar behoren.
ik ga nu eerst VPN opzetten op de nieuwe DC, shares opzetten op de nieuwe DC, shares syncen, sites aanmaken en dan hopelijk deze week nog de eerste DC naar adres a.

is dat een beetje de goede volgorde?

[fabstar81]

replication van de data (installbestanden) is gelukt. nu nog de roaming profiles configgen zodat user inloggen op site b ook de profiles van server op site b pakken.

lees gemengde verhalen om 2008's DFSR hiervoor te gebruiken. Is niet opgezet hiervoor, maar kan wel goed hiervoor gebruikt worden. iemand ervaring mee?

[fabstar81]

sites, subnets, links zijn toegevoegd. 2e dc is gemoved naar de nieuwe site. dus nu is het tijd om de 1e dc los te koppelen en naar adres a te zetten.

nu kom ik erachter dat we geen R2 van 2003 hebben. Doet replication het dus niet tussen 2003 en 2008.
iemand nog een tip?

[Jazzy]

fabstar81 schreef op dinsdag 13 juli 2010 @ 09:45:
nu kom ik erachter dat we geen R2 van 2003 hebben. Doet replication het dus niet tussen 2003 en 2008.
iemand nog een tip?

Wat wil je precies bereiken?

[fabstar81]

het enige wat nog gerepliceerd moet worden zijn de profielen van de users. op internet heb ik gelezen dat de meesten dat oplossen dmv het nieuwe DFS replication van 2008. Ondanks dat het daarvoor (icm profielen) niet echt voor ontworpen is.

Ik wil dus de profielen share (is een domeinshare) gaan repliceren over de 2008 en 2003 server.

[Henkje.doc]

DFS-R is een functie die alleen werkt als het domain functional level op windows 2008 staat.

Bij een domain func. level op windows 2003 gebruikt hij FRS.

Algemene DFS info
Link

Info rondom SYVOL replication
Link

[Jazzy]

Henkje.doc schreef op woensdag 14 juli 2010 @ 06:36:
DFS-R is een functie die alleen werkt als het domain functional level op windows 2008 staat.

Bij een domain func. level op windows 2003 gebruikt hij FRS.

Dan heb je het over de replicatie van Sysvol, dat heeft hier niets mee te maken. DFS-R kun je al gebruiken vanaf Windows Server 2003 R2.

Maar de simpeltste oplossing is om de profielen van de gebruikers op de 2e lokatie gewoon op een fileserver op die lokatie te zetten.

[ Voor 15% gewijzigd door Jazzy op 14-07-2010 08:02 ]

[fabstar81]

maar dan nog moeten ze up to date zijn met de profielen die op de andere lokatie staan.
gebruikers loggen nl in op beide lokaties.

[Jazzy]

fabstar81 schreef op woensdag 14 juli 2010 @ 09:03:
maar dan nog moeten ze up to date zijn met de profielen die op de andere lokatie staan.
gebruikers loggen nl in op beide lokaties.

Ik weet niet of replicatie de beste oplossing is. Er kunnen vrij eenvoudig problemen ontstaan omdat de bestanden benaderd kunnen worden van beide locaties, er is namelijk geen file lock met DFS-R.

[fabstar81]

maar dan ben je er toch ook niet met een fileserver? op enig moment moet die toch ook de juiste gegevens bevatten.

vanmiddag verplaats ik trouwens de server. Ben benieuwd of het sites and services verhaal gaat werken. er waren nog wat kinkjes in de kabel vwb DNS.

[Jazzy]

fabstar81 schreef op woensdag 14 juli 2010 @ 13:36:
maar dan ben je er toch ook niet met een fileserver? op enig moment moet die toch ook de juiste gegevens bevatten.

Normaal gesproken zou je dan de profielen van de medewerkers op de andere lokatie verplaatsen naar die fileserver. Die enkele keer dat iemand dan op de 'verkeerde' lokatie werkt duurt het gewoon wat langer voor zijn profiel geladen is.

Hoeveel tijd heb je nog om alles uit te denken voor het in productie gaat? Als je denkt dat DFS-R het antwoord is dan zou ik je bestaande fileserver gewoon upgraden naar Server 2003 R2 of hoger. Jullie zitten sinds gisteren toch al in Extended Support voor Windows Server 2003.

[fabstar81]

ik heb nog wel ff voordat het in productie gaat. upgraden naar R2 was al een logische stap.
tot die tijd ook een test ernaast leggen hoe lang het profiel laden duurt als het remote opgehaald moet worden.

denk dat het wel meevalt. het is een 1 mbit lijn. medewerkers hebben vroeger altijd gewerkt met een VPN inlog NA aanmelden waardoor hun documenten wel beschikbaar waren maar hun profiel op de laptop stond al. dat werkte prima. qua snelheid dan

[fabstar81]

zo, de sites zijn opgetuigd. vpn werkt tussen beide DC's, DNS is gesynchroniseerd, alles lijkt te zijn gerepliceerd. gebruikers kunnen inloggen op site b en beschikken over alle shares en profielen en documenten. zelfs exchange werkt. maar nu....clients en de server op site b (server b is VPN server, server a op site a zet VPN naar b op) hebben geen internet!

ik denk dat er iets mis is met de router, of DNS. gister heb ik de router gereset en alles opnieuw geconfigd, en toen leek alles het te doen. maar nu krijg ik dus met geen mogelijkheid internet aan de gang. zie ik iets over het hoofd of moet ik weer de router reconfiggen om te zien of het daaraan ligt?

opzet is als volgt:
site a: 192.168.1.0
subnet 255.255.255.0
server a (1e dc in domein) windows2003
192.168.1.88
exchange
profile server
fileserver
GC, DC
1e DNS: 192.168.1.88
2e DNS: 192.168.2.66
standaard gateway: 192.168.1.1 (router)
router op site a verzorgt DHCP

bovenstaande instellingen gelden ook voor de clients

site b: 192.168.2.0
subnet 255.255.255.0
server b windows2008
192.168.2.66
fileserver
GC, DC, DHCP voor clients op site b
1e DNS: 192.168.2.66
2e DNS: 192.168.1.88
standaard gateway: 192.168.2.1 (router)

bovenstaande instellingen gelden ook voor de clients

eigen dns in site is dus ingesteld als primary, secondary is de dns van de andere site.

server b zegt in het netwerkcentrum bij de analyse van lan-verbinding dat er zowel lokaal als internetverkeer is. op de clients in site b zegt die analyse dat er alleen lokaal verkeer is en geen internet.
maar zowel op server als op clients in site b is er geen internet.

[ Voor 10% gewijzigd door fabstar81 op 17-07-2010 11:09 ]

[Razwer]

zal wel dns zijn. knikker eens de dns servers van je isp in je dns server van site b bij de forwarders.

[fabstar81]

Ok, dat ga ik nog proberen.
Merkte trouwens dat zodra server a inbelt bij b, a ook geen internet verkeer naar binnen meer heeft. Rdp en mail valt dan uit.

Heeft het misschien iets te maken met dat er maar 1 nic in elke server zit?

[fabstar81]

ok, DNS forwarder heeft gewerkt. op site b is er nu internet. er kan connectie gemaakt worden met servers op site a en de profielen zijn beschikbaar.

enige is nu dat zodra server a is ingebeld bij server b, server a dus geen verbindingen van buitenaf toelaat. mail komt nu dus niet binnen en webmail is ook niet beschikbaar via internet.

[Razwer]

pfoe, rras te lang geleden mee geprutst. Kan volgens mij aan meerdere dingen liggen.
Volgens mij is het ergens een vinkje over wel of niet remote default gateway gebruiken (niet doen dus) en moet je ook tcp/ip filter uit zetten als die aan schiet.
als dat niet werkt heb je idd een aparte wan adaptor nodig voor je wan connections.

er zijn hier vast jongens die meer van RRAS weten dan ik die je beter kunnen helpen.

wrom doe je demand dial btw? wrom niet gewoon een lt2p tunnel met preshared key? betaal je voor dataverkeer of is het een security ding?

[ Voor 8% gewijzigd door Razwer op 17-07-2010 16:30 ]

[fabstar81]

Het idee was om een vpn tunnel tussen de routers op te zetten maar de routers blijken niet geschikt. Dus voorlopig on demand...maar doel is idd een permanente tunnel

Stap voor stap. Ga je aanbevelingen even remote uittesten

[alt-92]

Dat doe je in ieder geval nooit op je DC's, zet daar liever een dedicated router/PC voor neer

[fabstar81]

Helaas, maar de dc's zijn op het moment het enige wat we hebben.

[fabstar81]

ok, in de VPN verbinding aangegeven dat hij niet gebruik mag maken van de default gateway op de site waarop ie inbelt.

dan is inderdaad mail gewoon beschikbaar als hij is ingebeld. probleem is dan echter weer dat het netwerk dan weer niet bereikbaar is.

correctie: de servers hebben wel netwerk met elkaar. de clients op site b kunnen server a niet bereiken.

[ Voor 17% gewijzigd door fabstar81 op 18-07-2010 22:23 ]

[Razwer]

static routes maken op je router (die nu de default gateway is van je netwerk wat waarschijnlijk je internet verbinding is).
dus op de def gateway router van site A route add voor subnet B met default gateway je RRAS bak (DC in jouw geval) en zelfde op site B voor site A doen.

[ Voor 8% gewijzigd door Razwer op 19-07-2010 00:19 ]

[fabstar81]

de router op site A is een modem met router functionaliteit. ik moet even de specs nakijken of het mogelijk is om daar static routes in toe te voegen. Het gaat om de DV2010. zo te zien in de digitale handleiding http://www.davolink.com/i...SER&detSeq=850&pIndex=122 niet.

[Razwer]

dan heb je een probleem
investeer 100 euro in een nieuwe router en stop die er tussen, en doe daar je static route op.

edit: kan wel volgens mij
advanced setup-->routing.

[ Voor 82% gewijzigd door Razwer op 19-07-2010 13:13 ]

[fabstar81]

uuuuh, als ik die dingen remote aanpas in de router, kom ik er dan nog wel remote op?

edit: helaas; onder advanced is alleen NAT en LAN te zien

[ Voor 31% gewijzigd door fabstar81 op 19-07-2010 13:43 ]

[Razwer]

jammer de bammer, nieuwe router kopen en er tussen proppen. verander het subnet dat je tele2 ding geeft en geef je nieuwe router je huidige subnet.
als je portforwards doet moet je ze op je tele2 router doorsturen naar je nieuwe, en op je nieuwe router naar de server sturen.
stel subnet A is nu 192.168.1.0 dan geef je je tele2 modem nu ip in de range 10.1.1.0 ofzo (of 192.168.99.0 etc etc) en je nieuwe router 192.168.1.0.
op je nieuwe router voeg je die static route toe.

[fabstar81]

eigenlijk wilde ik voor site b toch al een nieuwe router kopen. dan gaat de oude van site b maar naar site a en config ik het zoals je nu schetst.

deze configuratie gaat er trouwens van uit (denk ik) dat op beide sites de dc's altijd live zijn. wat als er 1 uitvalt of tijdelijk de vpn tunnel (demand of niet) uitgeschakeld wordt? dan blijft de route in de router nog altijd staan naar de 2e site, die op dat moment dan niet beschikbaar is.

heeft dat nog gevolgen voor de sites? (die dan dus "apart" zijn)

[fabstar81]

ik heb overigens net een password gewijzigd op site b om te zien hoe snel en óf die gerepliceerd wordt. Gevolg: user kan niet meer inloggen op site a.

Ook heb ik in de dhcp van de RRAS server een range toegewezen en server a van site a opnieuw laten inbellen zodat ie een nieuw ip kreeg. Gevolg: FQDN resolven gaat ineens niet meer. komt dit omdat DNS dan nog niet goed gerepliceerd is?

ik heb de replication in sites and services op 15 minuten gezet.

repadmin /showrepl toont op dc b in site b dat de laatste om 14:09 successful was.
repadmin /showrepl toont op dc a in site a dat de laatste om 11:56 successful was.

replication stond default op 180 minuten. ik heb ook handmatig laten repliceren. ervan uitgaande dat site a nog niet is gerepliceerd en dus wacht op de schedule, moet ik nog 20 minuten wachten om te zien of ie die dan wel pakt.

en dan maar hopen dat ie de wijzigingen meeneemt?

de reden dat het snel moet repliceren is omdat users op site b bijvoorbeeld wijzigingen van password doen. op server a draait de exchange server waarop ook de blackberrys staan.

edit: dumb ass die ik ben...moet ik wel handmatig de goede kant op REPLICATE NOW doen...

[ Voor 51% gewijzigd door fabstar81 op 19-07-2010 14:54 ]

[fabstar81]

Maakt volgende situatie nog iets uit?
Clients van site a hoeven praktisch nooit iets van de servers van site b hebben.
Andersom is wel noodzakelijk. Alleen profielen moeten gelijk zijn, en die staan nu op a.

[Razwer]

dat is aan jou. practisch nooit is niet nooit. zolang die clients met je DC kunnen praten is het genoeg in principe.

[fabstar81]

Maar moet ik dan ook met static routes aan de gang?
Met praktisch nooit bedoel ik dat ik niet hoef te voorzien in de optimale oplossing.
Op site b staan alleen wat files. Die kan ik ook op andere manieren aanbieden. Die shares hoeven niet per se altijd via AD/netwerk beschikbaar te zijn.

Ik probeer nog eens de situatie te schetsen.
Server/site a:
Clients hebben geen noodzaak om op netwerk van site b te komen. Wél site a ivm profielen
Clients loggen in op server a
profielen komen van server a
er moet replicatie zijn tussen de servers

Server/site b:
Clients hebben wél noodzaak om op netwerk/shares te komen van zowel site a als b
clients loggen in op server b
profielen komen van server a, zolang dfs-r nog niet goed is opgetuigd en de profielen gesynct worden
alle app data, desktop redirect en my docs komen ook van server a

Middels vpn heb ik volgende situaties gehad:
gebruikmakend van default gateway op remote lokatie (in dit geval maakt server a gebruik van def gateway van site b):
netwerk werkt perfect...alle clients hebben toegang tot alle shares over de sites heen
server a accepteert geen verbindingen meer van buitenaf

Geen gebruikmakend van default gateway op remote lokatie (in dit geval maakt server a gebruik van de def gateway van site a):
netwerk werkt op site a perfect, op site b kunnen clients geen netwerk connectie maken met server a. Exchange werkt wel gewoon.
server a accepteert wel verbindingen van buitenaf.

Schiet mij maar lek...

Stel ik maak een static route aan en ik neem eerstgenoemde eisen mee. (Clients van a hoeven niet per se bij b) waar moet ik die dan plaatsen en hoe gaat die eruit zien?

[Razwer]

fabstar81 schreef op dinsdag 20 juli 2010 @ 09:58:
Geen gebruikmakend van default gateway op remote lokatie (in dit geval maakt server a gebruik van de def gateway van site a):
netwerk werkt op site a perfect, op site b kunnen clients geen netwerk connectie maken met server a. Exchange werkt wel gewoon.
server a accepteert wel verbindingen van buitenaf.

Schiet mij maar lek...

Stel ik maak een static route aan en ik neem eerstgenoemde eisen mee. (Clients van a hoeven niet per se bij b) waar moet ik die dan plaatsen en hoe gaat die eruit zien?

static route maken op de router van site B naar subnet A met default gateway je RRAS IP op site B.

mocht dit niet genoeg zijn, wel een routing protocol op je RRAS bak zetten of ook daar een static route maken en IP forwarding aanzetten.

[ Voor 8% gewijzigd door Razwer op 20-07-2010 18:09 ]

[alt-92]

fabstar81 schreef op maandag 19 juli 2010 @ 14:03:
eigenlijk wilde ik voor site b toch al een nieuwe router kopen. dan gaat de oude van site b maar naar site a en config ik het zoals je nu schetst.

Doe het dan gelijk goed, doe jezelf en de klant een plezier en haal twee routers die een ipsec tunnel kunnen opbouwen en laat daar je site2site VPN op draaien.
Dan heb je een bak minder ellende.

[fabstar81]

na een paar dagen draaien lijkt het erop dat alles toch werkt. het lijkt er dus op dat de routing tables dynamisch al zijn gevuld.

clients van site b kunnen op shares van zowel server b als server a komen.
clients van site a kunnen op shares van zowel server a als server b komen.

en nu is ook eindelijk die hele riedel gerepliceerd van 100 gb! dat was niet leuk over een 1 mb lijntje. heeft een kleine week gerepliceerd, maar hij doet het

enig probleem is dat users toch ernstige vertraging ervaren bij het aanmelden in het domein. Op site b inloggen kost als de servers middels VPN zijn verbonden een klein half uur, waarna een lokaal profiel wordt gekozen. en dit terwijl de userfolders op beide servers/sites zijn gerepliceerd. logonserver is ook altijd de server op eigen site, dus schiet mij maar in een kerstboom.

[fabstar81]

na aanmelding kan je in de eigenschappen van de mydocs folder ook zien welke mappen hij kiest ivm DFS. Daar kiest hij ook altijd de goeie folder. waarom duurt het inloggen dan zolang?

[Parzival]

dat kan verschillende oorzaken hebben.. heb je group policies? heb je roaming profiles.. etc etc.. zet die pc eens in een OU met daarin block all policies.. start opnieuw op en log aan met een user zonder roaming profile of startup/logonscripts.. en kijk dan of het snel is..

[mbaltus]

Moeilijk te zeggen, dat hangt er vanaf wat voor VPN oplossing je gebruikt.
In principe zet je hiervoor een site2site VPN op en dan zou je dit soort problemen niet moeten hebben.

[fabstar81]

de VPN oplossing is vooralsnog dat DC a van site a inbelt op DC b van site b. Alle roaming profiles e.d. zijn gerepliceerd tussen de verschillende sites, dus in feite zou hij niets van site a nodig moeten hebben. blijkbaar heeft ie dat ook niet, want logonserver is ook de goede van de site waar ie is en de redirected mydocs folders etc. pakt ie ook van de goede site af.

hoe kan ik terugzien welk profile hij neemt? ook met set? daar staat telkens het domain based namespace, dus wordt ik ook niet wijzer van.

ik zal nog eens proberen om de pc in een ou met blocked policies te gooien en dan te zien.