Neil,1) If you start setting firewall rules then I am pretty sure you will break things as you will block urgent replication. What happens if some one changes their password and then goes to the home site? What about group membership changes? Do you really want to wait two days before you update these?.2) I don't think that "normal admins" can trigger unscheduled replication changes. Certainly I am a Domain Admin and I can't trigger replication changes on our infrastructure, but it is Windows/20003) IMHO you would be better worrying about getting things to replicate when they are supposed to rather than things replicating when they shouldn'tDave
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Ulf B. Simon-WeidnerSent: 30 May 2006 11:32
To: [email protected]
Subject: RE: [ActiveDir] AD lag sites and replication
Hi Neil,I'd still go for a firewall with scheduled rules. IMHO there's no such thing as "locked down replication schedules" - as soon as someone is hitting a switch to force replication across sites. And the firewall will help you to assure no client is hitting a lag sites DC.Gruesse - Sincerely,
Ulf B. Simon-Weidner
Profile & Publications: http://mvp.support.microsoft.com/profile="">
Weblog: http://msmvps.org/UlfBSimonWeidner
Website: http://www.windowsserverfaq.org
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, May 30, 2006 10:33 AM
To: [email protected]
Subject: RE: [ActiveDir] AD lag sites and replication
Thanks Ulf.I was hoping to avoid NIC disabling and such like. I was looking for a solution which would enforce the replication schedule between sites, such that an admin could not 'over ride' it.I'd rather handle the situation with procedures and policies than use scripts to disable NICs (or connection objects) at scheduled times :)neil
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Ulf B. Simon-Weidner
Sent: 30 May 2006 09:01
To: [email protected]
Subject: RE: [ActiveDir] AD lag sites and replication
You are able to disable the network interfaces, pretty easy with VMWare or Virtual Server since you are able to do it from the host via scripting, bit more painfull if you have to do it from the DC itself since you don't have any remote access when the nic is disabled (you could use a scheduled task which runs netsh to activate / deactivate the interface).Also putting a firewall with scheduled rules in between would work very well, especially since you can block everything but RDP at the no-sync times.As long as you don't exceed the tombstone-lifetime I don't see any reasons why this should not be supported since we are just talking about lag-sites without any memberservers / clients / users who log onto those DCs.Gruesse - Sincerely,
Ulf B. Simon-Weidner
Profile & Publications: http://mvp.support.microsoft.com/profile="">
Weblog: http://msmvps.org/UlfBSimonWeidner
Website: http://www.windowsserverfaq.org
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, May 30, 2006 9:49 AM
To: [email protected]
Subject: [ActiveDir] AD lag sites and replication
I'm looking to implement one or more lag sites, with staggered replication schedules. (i.e. NYC lag replicates tues and thurs, 2-4 am; LON lag replicates mon, wed and fri 2-4 am).
We're concerned that admins can still force replication outside of these hours using repadmin or replmon etc.
Is there a (supported) way to ensure that replication can ONLY occur within the hours described above?
Thanks,
neilPLEASE READ: The information contained in this email is confidential andintended for the named recipient(s) only. If you are not an intendedrecipient of this email please notify the sender immediately and delete yourcopy from your system. You must not copy, distribute or take any furtheraction in reliance on it. Email is not a secure method of communication andNomura International plc ('NIplc') will not, to the extent permitted by law,accept responsibility or liability for (a) the accuracy or completeness of,or (b) the presence of any virus, worm or similar malicious or disablingcode in, this message or any attachment(s) to it. If verification of thisemail is sought then please request a hard copy. Unless otherwise statedthis email: (1) is not, and should not be treated or relied upon as,investment research; (2) contains views or opinions that are solely those ofthe author and do not necessarily represent those of NIplc; (3) is intendedfor informational purposes only and is not a recommendation, solicitation oroffer to buy or sell securities or related financial instruments. NIplcdoes not provide investment services to private customers. Authorised andregulated by the Financial Services Authority. Registered in Englandno. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,London, EC1A 4NP. A member of the Nomura group of companies.PLEASE READ: The information contained in this email is confidential andintended for the named recipient(s) only. If you are not an intendedrecipient of this email please notify the sender immediately and delete yourcopy from your system. You must not copy, distribute or take any furtheraction in reliance on it. Email is not a secure method of communication andNomura International plc ('NIplc') will not, to the extent permitted by law,accept responsibility or liability for (a) the accuracy or completeness of,or (b) the presence of any virus, worm or similar malicious or disablingcode in, this message or any attachment(s) to it. If verification of thisemail is sought then please request a hard copy. Unless otherwise statedthis email: (1) is not, and should not be treated or relied upon as,investment research; (2) contains views or opinions that are solely those ofthe author and do not necessarily represent those of NIplc; (3) is intendedfor informational purposes only and is not a recommendation, solicitation oroffer to buy or sell securities or related financial instruments. NIplcdoes not provide investment services to private customers. Authorised andregulated by the Financial Services Authority. Registered in Englandno. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,London, EC1A 4NP. A member of the Nomura group of companies.
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. As a public body, the Council may be required to disclose this email, or any response to it, under the Freedom of Information Act 2000, unless the information in it is covered by one of the exemptions in the Act.
If you receive this email in error please notify Stockport e-Services via [EMAIL PROTECTED] and then permanently remove it from your system.
Thank you.
http://www.stockport.gov.uk
**********************************************************************
I think that's point, isn't it? To be able to have a site that lags the rest of them for replication changes? :)
FWIW, there is no way that I'm aware of to prevent an admin from triggering replication in the sense that an admin could override any changes you make to be able that would otherwise allow them to trigger the replication. While you may counter that you're just trying to prevent the admin from doing something easily
i.e. make them work to override the change, I read into this that you want to absolutely prevent them from triggering replication. For that, you need to look outside the system they have rights on else change them from DA to OU admin. The other alternative is to trust them not to make that change without knowing what they're doing. An easy argument that anyone with DA should be able to be that trusted, but reality often differs from desire.
Admins, by design have rights to the system. As such, they have rights to make those changes that allow them to, well, make changes.
Al
On 5/30/06, Dave Wade <[EMAIL PROTECTED]> wrote:
- Re: [ActiveDir] AD lag sites and replication Al Mulnick
- RE: [ActiveDir] AD lag sites and replication Dave Wade
- Re: [ActiveDir] AD lag sites and replication Mark Parris
- RE: [ActiveDir] AD lag sites and replication Coleman, Hunter
- RE: [ActiveDir] AD lag sites and replication Molkentin, Steve
- Re: [ActiveDir] AD lag sites and replication Mark Parris
- RE: [ActiveDir] AD lag sites and replica... Ulf B. Simon-Weidner
- Re: [ActiveDir] AD lag sites and rep... Al Mulnick
- Re: [ActiveDir] AD lag sites an... Mark Parris
- RE: [ActiveDir][OT] AD lag sites and rep... joe
- RE: [ActiveDir] AD lag sites and replication Mark Parris
