[Win2k] Group Policy op Slow Link Connections

[Verwijderd]

Er is besloten de huidige lokatie uit te breiden naar een 2e lokatie middels VPN.
Op de 2e lokatie komt enkel een fileserver (op termijn misschien DFS). Een DC komt er niet. Het gaat om een 128 kbit ADSL verbinding (1024/256 en 512/128 MxStream lijntjes).

Windows 2000 ziet dit als een zogenaamde Slow Link met als gevolg dat Group Policies niet naar de clients op de 2e lokatie worden doorgevoerd. Inloggen op het domain gaat overigens prima en DNS werkt perfect.

In de Group Policy heb ik Slow Link Detection uitgeschakeld (door de Slow Link value van 500 op 0 te zetten). Echter de clients op lokatie 2 willen nog steeds niet de Group Policies overnemen. Tevens wordt het logonscript in de NETLOGON niet uitgevoerd vanaf lokatie 2.

De "Default User" profile in de NETLOGON share op de DC wordt overigens wel gekopieerd. Op de clients op lokatie 1 wordt het logonscript wel uitgevoerd en worden de Group Policies wel doorgevoerd. Dit omdat het daar geen Slow Link naar de DC toe is.

Google kon mij niet helpen, Technet ook niet. Ik heb alleen een vermoeden. Namelijk dat je in de Group Policy wel kunt vermelden dat Slow Link Detection uit moet, maar dat dat niet wordt doorgevoerd omdat het een Slow Link is. Deze policy zal dus eenmalig handmatig op de clients van lokatie 2 moeten worden ingevoerd zodat voortaan alle policies worden doorgevoerd.

Wie kan mij aan een oplossing helpen? Het eenmalig een registry instelling doorvoeren op alle PC's vind ik niet erg (het zijn er toch maar 5). Maar welke instelling?

[Verwijderd]

Het handmatig kopieren van de "Policies registry keys" van een bak op lokatie 1 naar een bak op lokatie 2 mocht ook niet baten.

Er moet toch een oplossing zijn waardoor de Slow Link Detection gewoon wordt uitgeschakeld?

[mutsje]

het lijkt me raadzaam als je een slowlink connection hebt een domain controller op locatie te plaatsen en deze ook Global Catalog server te maken. Anders wordt telkens jou slowlink aangesproken opzoek naar objects in jou organisatie. Plaatse je geen GC in jou 2e site dan krijg je enorm verkeer over die lijn.

[Verwijderd]

Het plaatsen van een extra domeincontroller is te overwegen, het is echter een kostbare zaak.

De bedoeling is dat er 1 server komt te staan die zowel als fileserver als Exchange server dient om de mailboxes op lokatie te draaien. Een Exchange server en DC mogen sowieso niet samen ivm security dus dan zal er een 2e server moeten komen. Aangezien het om slechts 5 users tegelijkertijd gaat kan de lokale DC best een 1 Ghz machine met IDE schijven zijn.

Wat denken jullie?

[Verwijderd]

Het wordt geen 2e domain controller. Hier is simpelweg het geld niet voor. Weet iemand hoe ik alsnog GPO's via een Slow Link kan deployen?

[Verwijderd]

* schopje *

[mutsje]

Group policies over een small link leverd niet zoveel data op. Echter wel dat bij elke querie naar een machine de GC geraadpleegt gaat worden. Hier zul je bij implementatie van je netwerk wel degelijk rekening mee moeten gaan houden.

vraag:
Wat houd je eigenlijk tegen om Exchange200X toch op een DC te plaatsen?

[Verwijderd]

mutsje schreef op 08 September 2003 @ 09:02:
Group policies over een small link leverd niet zoveel data op. Echter wel dat bij elke querie naar een machine de GC geraadpleegt gaat worden. Hier zul je bij implementatie van je netwerk wel degelijk rekening mee moeten gaan houden.

vraag:
Wat houd je eigenlijk tegen om Exchange200X toch op een DC te plaatsen?

Tot nu toe valt het dataverkeer opzich wel mee. We hebben ook geen datalimiet, dus een beetje extra dataverkeer maakt ook niet uit. De users hebben wel opgemerkt dat het internet soms een kleine vertraging lijkt te hebben, maar internet is geen belangrijk onderdeel van hun werk.

En het antwoord op je vraag:
Officieel hoor je een Exchange server niet op een DC te draaien. Ook niet in een Front-End/Back-End situatie. Dit bemoeilijkt het hacken van je netwerk (ook van binnenuit), aangezien je je IIS dan ook niet op de DC hebt draaien. De DC moet gewoon puur AD hosten, meer niet.

Het lijkt echt net alsof er gewoon geen oplossing voor is. Heel Technet is al geraadpleegd, Google is honderden searches rijker... misschien wordt het tijd om bekend te maken dat de kosten toch veel hoger uitvallen dan gepland...

[mutsje]

Als je geen Exchange en Domain Controller wil maken is een investering inderdaad noodzakelijk. Je kunt dan op de 2e DC een secondary DNS maken en die AD integrated maken zodat de nieuwe updates van je DNS server alleen met AD replicatie geschiet. Ook zou ik AD replicatie in offline business hours definieren zodat de gebruikers er geen hinder van ondervinden.. nieuwe accounts en dergelijke changes worden toch gelijk gesynchroniseerd.

[Verwijderd]

Verwijderd schreef op 04 September 2003 @ 21:12:
Het plaatsen van een extra domeincontroller is te overwegen, het is echter een kostbare zaak.

De bedoeling is dat er 1 server komt te staan die zowel als fileserver als Exchange server dient om de mailboxes op lokatie te draaien. Een Exchange server en DC mogen sowieso niet samen ivm security dus dan zal er een 2e server moeten komen. Aangezien het om slechts 5 users tegelijkertijd gaat kan de lokale DC best een 1 Ghz machine met IDE schijven zijn.

Wat denken jullie?

als je die exchange server alleen een connector heeft naar een mailserver op lokatie 1 zie ik het probleem niet zo...

Ook niet in een Front-End/Back-End situatie. Dit bemoeilijkt het hacken van je netwerk (ook van binnenuit), aangezien je je IIS dan ook niet op de DC hebt draaien

ummm iis moet ook niet te bereiken zijn tenzij je owa gebruikt en dat kan je ook alleen regelen over https. als je ook echt een front/back end situatie hebt (enterprise version) hoeft de exchange server op de 2de lokatie totaal geen directe connectie naar inet te hebben.

edit: je hebt verder natuurlijk wel gelijk dat je beter een member kan gebruiken, maar de risico's ook niet gaan overdrijven.

[ Voor 35% gewijzigd door Verwijderd op 08-09-2003 11:50 ]

[Verwijderd]

Verwijderd schreef op 08 September 2003 @ 11:08:
[...]


als je die exchange server alleen een connector heeft naar een mailserver op lokatie 1 zie ik het probleem niet zo...


[...]

ummm iis moet ook niet te bereiken zijn tenzij je owa gebruikt en dat kan je ook alleen regelen over https. als je ook echt een front/back end situatie hebt (enterprise version) hoeft de exchange server op de 2de lokatie totaal geen directe connectie naar inet te hebben.

edit: je hebt verder natuurlijk wel gelijk dat je beter een member kan gebruiken, maar de risico's ook niet gaan overdrijven.

OWA zal door sommigen sporadisch worden gebruikt. De service moet dus wel aanwezig zijn. Vandaar dat de Exchange server geen DC mag zijn, hij hangt namelijk direct aan het internet.

Er wordt overigens overwogen om OWA niet direct aan het internet te hangen maar om OWA achter een VPN beschikbaar te maken. De gebruikers kunnen op aanvraag een laptop in bruikleen krijgen, en daarop zijn alle VPN instellingen al in opgeslagen.

De situatie wordt, mocht er inderdaad een 2e DC komen:

Lokatie 1: NLDC -> Domain Controller, RADIUS server (voor VPN router), DNS
Lokatie 1: NLASV01 -> Exchange Server, Fileserver (DFS), OWA via HTTPS, DNS*
Lokatie 2: NLDC01 -> Domain Controller, RADIUS server (voor VPN router), DNS
Lokatie 2: NLAMS01 -> Exchange Server, Fileserver (DFS), OWA via HTTPS, DNS*
(* = Secondary Zone)

Gelukkig zijn er op beide machines aparte harddisks voor de Exchange Server en de Gedeelde mappen (Fileserver). Eigenlijk had ik hier (ook ivm security) ook aparte servers voor gewild.

Is dit een beetje een realistische situatie? Of kan ik het beter helemaal anders aanpakken?

Ik ben het overigens wel eens met je nickname, iis5_rulez
IIS vind ik na de juiste configuratie vele malen beter dan Apache

mutsje schreef op 08 September 2003 @ 10:55:
Als je geen Exchange en Domain Controller wil maken is een investering inderdaad noodzakelijk. Je kunt dan op de 2e DC een secondary DNS maken en die AD integrated maken zodat de nieuwe updates van je DNS server alleen met AD replicatie geschiet. Ook zou ik AD replicatie in offline business hours definieren zodat de gebruikers er geen hinder van ondervinden.. nieuwe accounts en dergelijke changes worden toch gelijk gesynchroniseerd.

In het begin zal ik het repliceren denk ik gewoon elk uur laten geschieden. Het internet zelf is toch niet van belang voor de medewerkers.

Prive internet is voor de medewerkers best toegestaan, en dat gebeurt dan ook gewoon, maar het repliceren krijgt natuurlijk voorrang. De huidige server op lokatie is al een DNS Server (Secondary Zone Transfer DNS).

Nog een bijkomend vraagje over DFS.
Hoe bepaalt een client naar welke van de 2 servers hij een share connect? Als je een mapping aanmaakt naar \\domain\share dan pakt de client volgens mij een willekeurige server, met als gevolg dat de share van de andere lokatie wordt gepakt. Ik zat te denken aan een Kixtart loginscript die een mapping aanmaakt afhankelijk van je logonserver (ik neem aan dat je logonserver altijd de server is met de laagste pingtijd?)

[mutsje]

Je logon server is welke de GC vind dat deze het dichts bij staat en niet je pingtijd. Meestal bepaalt een GC bij mijn weten waar je heen gaat dus niet de snelheid.

[Verwijderd]

Lokatie 1: NLDC -> Domain Controller, RADIUS server (voor VPN router), DNS
Lokatie 1: NLASV01 -> Exchange Server, Fileserver (DFS), OWA via HTTPS, DNS*
Lokatie 2: NLDC01 -> Domain Controller, RADIUS server (voor VPN router), DNS
Lokatie 2: NLAMS01 -> Exchange Server, Fileserver (DFS), OWA via HTTPS, DNS*
(* = Secondary Zone)

Zijn die dubbele inbel en OWA faciliteiten niet overbodig? Als iemand dan toch over het web moet, of in- moet bellen, maakt het voor de rest weinig uit waar ze dat doen.