| Author | Messages | |
listmail
Posts:178
 | | 05/08/2008 2:40 PM |
| LOL... ;o)
I sometimes remember weird things... But that value would stick out to me...
If it is a number for a computer limit/boundary of some sort and it isn't a
multiple of some base-2 value it always sticks out to me. If it had been
50176 or 51200 it wouldn't have stuck out.
Thanks for the link, that is actually the document I was thinking of. Very
informative doc. 
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Coleman, Hunter
Sent: Thursday, May 08, 2008 2:13 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Triggers for Change Notification Between Sites
Maybe the carbon monoxide was actually *helping* your memory?
Once the size of the data that has to be replicated exceeds 50,000 bytes,
compression kicks in and reduces the amount of data considerably.
http://technet.microsoft.com/en-us/library/bb742457.aspx
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Thursday, May 08, 2008 11:13 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Triggers for Change Notification Between Sites
Dean brings up a good point that I forgot to mention... hitting the minimum
threshold for compression to kick in... If I recall that is around 49-50k or
so - maybe 50,000 bytes on the nose??? I just recall it being somewhere
around 10 new user creations or something like that... Dean will likely
remember the actual value as he backs up his carbon memory with silicon and
magnetic substances.
So if your churn is small but consistent, you may not hit the data levels
necessary for compression and could eat up more bandwidth that way as well.
There is a technet article out there somewhere as well that discusses this
stuff if you don't have the old Notes From the Field book. I recall it still
being about W2K so its out of date but it gave the methodology and perf
counters to look at for testing this kind of thing if someone is truly
interested.
But again, it all comes back to how important is the "more quickly
converged" state to you... I generally recommend hub datacenters all be
connected with change notification, WAN spokes... maybe... maybe not.
Depends on the criticality to get the data out there. I would hazard to
guess that most WAN Sites do not need to be that well converged but it would
depend on the company and what they do in the WAN sites. For example if you
have reconfigured your outlook clients to use a local GC instead of the GC
near the Exchange servers I would be more likely to enable change
notification.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Thursday, May 08, 2008 11:49 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Triggers for Change Notification Between Sites
RE: the benefit of notify vs. scheduling my first thought falls in-line
with Dmitris; if theres high-churn then notification is likely your enemy
across slower, low-bandwidth pipes (unless having consistency as close to
real-time as AD can muster is a requirement) because we end up replicating
values whose lifetime within the directory may well be so fleeting that
theyre overwritten prior to the scheduled replication window and would,
therefore, never have made it across the WAN in the first place. Stated
another way, AD doesnt maintain a value-history, it merely replicates the
current value(s) of changed properties as determined by the metadata
exchanged between the replicating DCs; update the phone number of an object
5 times, 1) with notify à youll generate 5 times the roundtrip replication
traffic, 2) with scheduled intersite replication à youll replicate only the
current value.
In the case of low or almost no-churn, the question is potentially rendered
moot (kinda depends on your definition of low I spose.) and we must also
take into consideration the absence of compression if the message size falls
below the trigger.
RE: the is compression enabled question, Im gonna be specific here to
eliminate any confusion: the question I see is this does a
change-notification-enabled connection object that crosses a site boundary
still cause the DCs to compress the replication messages? -- thats
probably best answered by taking a look at the resulting connect objects
Options attribute .. so if we mod. a site link as follows -
#define NTDSSITELINK_OPT_USE_NOTIFY ( 1 << 0 ) // Use notification on this
link à 1
a few mins. later the resulting connection objects look something like
this
CN=622896af-4374-4818-b9bc-8092998f7d60,CN=NTDS
Settings,CN=LIGHT,CN=Servers,CN=Office,CN=Sites,CN=Configuration,DC=mset,DC=
local
fromServer: CN=NTDS
Settings,CN=FALCON,CN=Servers,CN=Other,CN=Sites,CN=Configuration,DC=mset,DC=
local
options: 13
13 breaks down to
bit 0 = 1: KCC-owned
#define NTDSCONN_OPT_IS_GENERATED
bit 2 = 4: Override notify defaults #define
NTDSCONN_OPT_OVERRIDE_NOTIFY_DEFAULT
· otherwise defined as use compression
bit 3 = 8: Change notification #define
NTDSCONN_OPT_USE_NOTIFY
this indicates to me that compression is indeed used (a conclusion that
matches my initial hip-shot.)
In addition, note that bit 4 (16: Disable intersite compression) is not
raised. The remaining bits arent pertinent to this discussion.
--
Dean Wells
MSEtechnology
* Email: dwells@msetechnology.com
http://msetechnology.com <http://msetechnology.com/>
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Jack Parkin
Sent: Thursday, May 08, 2008 9:12 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Triggers for Change Notification Between Sites
I just wanted to second Dan's sorta question about compression. I've always
wondered if compression was still used if Change Notification was enabled.
I had assumed it would be, but I'd love definite confirmation of that. If
compression is still used, I would definitely have to agree with Dan that in
normal operation change notification would seem to make better use of
bandwidth.
Thanks all, I've enjoyed reading this thread.
-Jack
"Dan Holme" <dan.holme@intelliem.com>
Sent by: ActiveDir-owner@mail.activedir.org
05/07/2008 09:41 PM
Please respond to
ActiveDir@mail.activedir.org
To
<ActiveDir@mail.activedir.org>
cc
Subject
RE: [ActiveDir] Triggers for Change Notification Between Sites
Yes, they are at Windows Server 2003 FFL.
But remember
the same number of bytes are going to go from Bridgehead in
Site A to Bridgehead in Site B no matter what
. Its just a matter of when.
Id argue youre actually making better use of your bandwidth by using
Change Notification than not, because then you dont have a big bunch of
bytes going between sites every 15 minutes (or whatever), but rather are
trickling them. OK, theres a VERY small amount of overhead with the
change notification process itself, but the same number of bytes are going
over the link and
(JOE PLEASE CORRECT ME)
I believe that, even with Change Notification, the intersite replication
will continue to use compression
So, bottom line, regardless of your FFL, if 30 kbytes need to replicate it
MIGHT be better to let 6x5 kb (six changes numbers are just examples)
trickle over every 2.5 minutes versus all 30KB at the fifteen minute mark.
BTW: you might also argue that if youre NOT at WS2003FFL, Change
Notification is more crucial because you DECREASE the risk of potentially
conflicting changes to group membership during a replication window!!! So
from a security standpoint, Im probably more interested in convergence when
a non-converged state might lead to human/business/security problems.
Food for thought.
Dan
(combining branched threads)
FROM ERIC:
Dan
Are they at the W2K3 FFL? I can see that it may be a problem without LVR
going.
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Wednesday, May 07, 2008 2:51 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Triggers for Change Notification Between Sites
Wow, I hate to say it, but I live for joe's posts hahah.. yes, I'm a
suckup. LOL. Seriously though, thank you for your overflow of AD knowledge
(everyone else too!)
It's good to know at least I was on the right track on how the whole enable
change notify process worked. I needed much clarification on what to expect
since I didnt get my expected result initially.
joe <listmail@joeware.net> wrote:
Possibly...
Assuming change notification was enabled properly, it works. However the
replication is still pushed through the bridgehead server for the given
site. You don't get a ring topology across the sites like you have within a
single site. It is a ring within the site and the standard spanning tree for
intersite. That means convergence isn't coming from two different
directions... you have a SPoF or more accurately SPoL(atency). So say you
have enough DCs in a site to get a full 3 hop ring then change notification
to another site could still realistically be over a minute with default
holdback timing, etc and not even considering the time to process the churn
involved. It could take considerably over a minute if the bridgehead is busy
(either dealing with lots of work or it has a poor connection to a site and
RPC is being troublesome over that pipe). I have seen bridgeheads that have
gotten tied up for long periods of time (hours under W2K, tens of minutes
under 2K3) when a single site was having network issues and it was causing
slowness of all replication going through that bridgehead.
More info... DCs only have single inbound pull replication thread and the
replication is pull based. So while DC-A can service many DCs asking for
updates, it can only pull from one DC at a time. So if you have a bridgehead
that is tied up pulling from say DC-C and DC-B has changes for it, DC-B will
send the change notification to the bridgehead but it will have to finish
with DC-C first before it gets to DC-B to get the changes to be pulled by
DCs in sites that that bridgehead services. Confused yet?
There is also some implication in the thread about urgent replication...
Urgent replication is different than change notification though it is
related. Urgent replication just means you don't go through the holdback
period but nothing is truly urgently replicated, it is just urgently queued.
I.E. It hits the queue right away but has the normal priorities of the other
stuff queued so it isn't like it goes to the head of the pack or anything.
This stuff was discussed in Dean and my presentation at DEC back in 2006,
pop out to Jadonex for the powerpoint about it and the info on the queuing
priorities, etc.
If you want to watch what is happening, go pick up ADQueueLoop, AdFind (with
-sc replqueue or -sc ncrepl switches), or repadmin (with /queue switch) to
see what is currently going through the queue or to show the current queue
in its entirely and play with those, you will see the replication requests
being queued up and processed. If you have two sites (Site A and Site B) and
two DCs (SA-DC1 and SB-DC1) and you watch the Repl Queue on SB-DC1 and
change notification is enabled between them and then make a change directly
on SA-DC1 then you should see a repl request for SA-DC1 pop into the queue
in a time dependent on the number of DCs that are change notify enabled with
SB-DC1. So if that is the only DC with a change notification connection
(i.e. no DCs in the site with SA-DC1 and only the one change notification
site) you would normally expect to see something within 15 seconds.
joe
--
O'Reilly Active Directory Third Edition -
<http://www.joeware.net/win/ad3e.htm> http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: Wednesday, May 07, 2008 5:25 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Triggers for Change Notification Between Sites
I'm guessing you needed to sit out the replication interval for the site
link change.
As Dean said on k3 you should be seeing replication between these sites
converging in a matter of seconds now.
--brian
On Wed, May 7, 2008 at 4:38 PM, Rand Salazar <rmscheck@yahoo.com> wrote:
Hmm is it just those three items?
Is a better definition, only changes deemed under Urgent Replication are
triggered under Site Link Change Notification?
I'm just trying to understand it more as now our test environment is
confusing me! Now it is replicating changes rather quickly.. changes such
as Exchange mailbox moves, descriptions, renames, etc... These werent
happening earlier.. Currently the rep interval is set to 30 minutes.
Earlier this morning the test environment was replicating these changes
after 30 mins. Now its happening within a minute or so. Strange. Is this
expected behavior or am I barking up the wrong tree?
"Gustafson, Eric (Oldcastle Materials)" <
<mailto:eric.gustafson@oldcastlematerials.com>
eric.gustafson@oldcastlematerials.com> wrote:
An article from the ActiveDir.org site;
<http://www.activedir.org/Articles/tabid/54/articleType/ArticleView/articleI
d/40/Default.aspx>
http://www.activedir.org/Articles/tabid/54/articleType/ArticleView/articleId
/40/Default.aspx
From: <mailto:ActiveDir-owner@mail.activedir.org>
ActiveDir-owner@mail.activedir.org [mailto:
<mailto:ActiveDir-owner@mail.activedir.org>
ActiveDir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Wednesday, May 07, 2008 11:14 AM
To: Active Dir
Subject: [ActiveDir] Triggers for Change Notification Between Sites
Folks,
What sort of event will trigger change between sites if we enable site link
notifications? In our test environment with it enabled, we performed a user
rename on one site and nothing happened in the second site for close to the
actual site links replication interval.
As far as I can tell, replication is occurring normally between sites as
eventually the change will replicate, but I would like for it to be quicker
or at least bypass the set interval.
Just for clarification, the options attribute in our test environment was
"Not Set" so I entered a 1 to enable.
Thanks.
_____
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
now.
<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8H
DtDypao8Wcj9tAcJ%20>
_____
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
now.
<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8H
DtDypao8Wcj9tAcJ>
--
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
_____
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8H
DtDypao8Wcj9tAcJ%20> it now.
| | | |
| rmscheck
Posts:19
| | 05/18/2008 1:38 PM |
| <table cellspacing='0' cellpadding='0' border='0' ><tr><td style='font: inherit;'><P>Ok, so I've been playing with ADQueueLoop and its pretty awesome. I have a few questions on its output if you dont mind..</P>
<P> </P>
<P>I've been trying to search for what these options are, NEVERNOTIFY, ASYNC, SCHEDULED, REQUESTED, etc.. can anyone shed some light on these? I'm curious now, as the site in which I have change enabled I see NEVERNOTIFY listed in queue items.</P>
<P> </P>
<P>Thanks!<BR><BR>--- On <B>Wed, 5/7/08, joe <I><listmail@joeware.net></I></B> wrote:<BR></P>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(16,16,255) 2px solid">From: joe <listmail@joeware.net><BR>Subject: RE: [ActiveDir] Triggers for Change Notification Between Sites<BR>To: ActiveDir@mail.activedir.org<BR>Date: Wednesday, May 7, 2008, 10:15 PM<BR><BR>
<DIV id=yiv1199742466>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2>Possibly...</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2>Assuming change notification was enabled properly, it works. However the replication is still pushed through the bridgehead server for the given site. You don't get a ring topology across the sites like you have within a single site. It is a ring within the site and the standard spanning tree for intersite. That means convergence isn't coming from two different directions... you have a SPoF or more accurately SPoL(atency). So say you have enough DCs in a site to get a full 3 hop ring then change notification to another site could still realistically be over a minute with default holdback timing, etc and not even considering the time to process the churn involved. It could take considerably over a minute if the bridgehead is busy (either dealing with lots of work or it has a poor connection to a site and RPC is being troublesome over that
pipe). I have seen bridgeheads that have gotten tied up for long periods of time (hours under W2K, tens of minutes under 2K3) when a single site was having network issues and it was causing slowness of all replication going through that bridgehead.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2>More info... DCs only have single inbound pull replication thread and the replication is pull based. So while DC-A can service many DCs asking for updates, it can only pull from one DC at a time. So if you have a bridgehead that is tied up pulling from say DC-C and DC-B has changes for it, DC-B will send the change notification to the bridgehead but it will have to finish with DC-C first before it gets to DC-B to get the changes to be pulled by DCs in sites that that bridgehead services. Confused yet?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2>There is also some implication in the thread about urgent replication... Urgent replication is different than change notification though it is related. Urgent replication just means you don't go through the holdback period but nothing is truly urgently replicated, it is just urgently queued. I.E. It hits the queue right away but has the normal priorities of the other stuff queued so it isn't like it goes to the head of the pack or anything. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2>This stuff was discussed in Dean and my presentation at DEC back in 2006, pop out to Jadonex for the powerpoint about it and the info on the queuing priorities, etc. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2>If you want to watch what is happening, go pick up ADQueueLoop, AdFind (with -sc replqueue or -sc ncrepl switches), or repadmin (with /queue switch) to see what is currently going through the queue or to show the current queue in its entirely and play with those, you will see the replication requests being queued up and processed. If you have two sites (Site A and Site B) and two DCs (SA-DC1 and SB-DC1) and you watch the Repl Queue on SB-DC1 and change notification is enabled between them and then make a change directly on SA-DC1 then you should see a repl request for SA-DC1 pop into the queue in a time dependent on the number of DCs that are change notify enabled with SB-DC1. So if that is the only DC with a change notification connection (i.e. no DCs in the site with SA-DC1 and only the one change notification site) you would normally expect to see
something within 15 seconds. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2> joe</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=574225521-07052008></SPAN><SPAN class=574225521-07052008></SPAN><SPAN class=574225521-07052008></SPAN><SPAN class=574225521-07052008></SPAN><SPAN class=574225521-07052008></SPAN><SPAN class=574225521-07052008><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV align=left>
<DIV align=left>
<DIV dir=ltr align=left><SPAN class=625444604-27012006><FONT face=Arial color=#0000ff size=2>--</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=625444604-27012006><FONT face=Arial color=#0000ff size=2>O'Reilly Active Directory Third Edition - <A title=blocked::http://www.joeware.net/win/ad3e.htm href="http://www.joeware.net/win/ad3e.htm" target=_blank rel=nofollow>http://www.joeware.net/win/ad3e.htm</A> </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=625444604-27012006><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV></DIV></DIV>
<DIV> </DIV></DIV></BLOCKQUOTE></td></tr></table>
<hr size=1>Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. <a href="http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ "> Try it now.</a>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
| | | |
| paulseaden
Posts:4
| | 05/18/2008 1:40 PM |
| That is really interesting- I'll remember that for the future. Thanks
Dean. MS states that using the Windows 2003 (Xpress) algorithm reduces
computational overhead by 40% over the Windows 2000 default algorithm
(MSzip) during replication, which as you state is a significant increase
in performance.
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: 08 May 2008 18:43
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Triggers for Change Notification Between Sites
I'll re-emphasize that computational hit; it's a significant hit on the
32 bit boxes I've tested! There's a little more below for those
interested in tweaking this stuff. The first reg. tweak provides the
ability to adjust compression on a per domain controller basis by
setting the registry value:
HKLM\CCS\Services\NTDS\Parameters - REG_DWORD: Replicator compression
algorithm
0 - Disable Compression
1 - <unused>
2 - Force MSzip algorithm
3 - Default, use Xpress algorithm
Note though that the new compression algorithm can also be adjusted to
provide more compression at the cost of computational load vs. less
compression and lower load on the bridgeheads. The adjustment is again
a per DC reg. tweak -
HKLM\CCS\Services\NTDS\Parameters - REG_DWORD: Replicator compression
level
Values: 0 through 9 (Default=3)
0=faster, 9=more compression (values beyond 3 don't appear to provide
much in the way of a compression gain)
... and for the sake of completeness, don't forget we can also adjust
compression in a more distributed manner or with even more precise
control by editing the Site Links or Connection objects respectively.
--
Dean Wells
MSEtechnology
* Email: dwells@msetechnology.com
http://msetechnology.com <http://msetechnology.com/>
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
paul.seaden@uk.nomura.com
Sent: Thursday, May 08, 2008 1:11 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Triggers for Change Notification Between Sites
Interestingly, the compression ratio from Windows 2000 is higher than
Windows 2003 for the same load of data- MS state that the Windows 2000
algorithm gives a further 20% or so on top of the Windows 2003 one,
which is about right from what I have seen in testing. The reduction in
compression that you get from the Windows 2003 algorithm equals a big
jump in performance computation time for replication though.
I have worked in environments that had sites in emerging countries that
had reduced infrastructure whereby we reverted the compression algorithm
back to Windows 2000 because the compression ratio was more important
than the computation time for the replication, as it meant less data
over the wire. This obviously needs to be used in conjunction with an
effective replication schedule too.
This can be done by changing the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Rep
licator compression algorithm
Changing it from 3 -> 2 reverts back to the Windows 2000 algorithm.
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: 08 May 2008 16:05
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Triggers for Change Notification Between Sites
I am not positive but I also believe compression is still in place when
you enable change notification across sites. However... You will have
less data going across which will possibly impact the compession ratios
(i.e. the more data to compress, in general the better the ratios), this
was true with Windows 2000 AD x-site compress as evidenced by the tables
from "Windows 2000 Active Directory Notes from the Field" from MSPress
but I am not sure if I have seen anything with that level of detail
regarding the newer compression mechanisms MSFT is using. I would
certainly be curious to see that.
You will also have more overhead bytes overall for the replication
process itself... More TCP/IP handshaking packets, more RPC handshaking
packets, etc. so while the pure AD type data that you need to converge
could be identical or close or who knows (depending on how the
compression is impacted), you will definitely have more state
maintenance data going across. Whether that is worth worrying about or
not is probably academic because I doubt it would be enough to overcome
the desire to get to a *more* converged state *more* quickly.
Likely if you are really super concerned about data transfer size over a
specific wire, you are likely going to be specifying some sort of
schedule for replication anyway because the pipe will be used for more
than AD. I am thinking about satellite connections, wireless connections
(whether standard wireless or things like VLF/ELF), dialup, super bad
telcom lines, etc here.
You also have the point that Dmitri made concerning the versions of the
changes. I also agree with Dmitri that that likely isn't a real normal
case for most places, likely if you replicate every 15 minutes you are
already getting every version of an attribute update but if you do have
a replicated attribute that is getting popped every 10-15-60 seconds you
will be replicating more data from that. Active Directory according to
what I recall was designed to be primarily read and that is how most
people truly use it. If you need a bunch of updates constantly to the
same attributes you likely want to be looking at some sort of SQL
solution anyway not that I haven't seen occurences of people who
constantly push changes into AD on a very frequent basis. Its just
unusual in my experience.
In one design where I enabled change notification I set up sort of two
rings between the three regional datacenters (standard americas, emea,
asiapac layout). Three hub datacenters, each had 2 sites, an Exchange
site and the NOS site. The NOS sites were connected together in 3
sitelinks with change notification enabled. The Exchange sites were
connected together in 3 sitelinks with change notification enabled. The
Exchange and NOS sites in each location were connected with a site link
with change notification enabled. All WAN sites that spoked off from the
NOS sites were not change notification enabled. All told around 400 DCs
globally, can't recall the number in the hub sites but likely around 60.
Any change made on any DC in any of the hub sites (whether Exchange or
NOS) was converged very quickly across the globe hub sites (minutes tops
even if WAN sites were causing issues with *some* of the bridgeheads*
because there were multiple paths). Anyone who works with multiple RUS
instances in a very large distributed deployment can likely appreciate
the quick convergence this allowed. The WAN sites got pretty much any
change made in any datacenter site within 20 minutes but again that was
dependent on how busy the bridgehead DCs were. With K3 and the load
balancing of intersite connections that got even better.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dan Holme
Sent: Wednesday, May 07, 2008 9:39 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Triggers for Change Notification Between Sites
Yes, they are at Windows Server 2003 FFL.
But remember... the same number of bytes are going to go from Bridgehead
in Site A to Bridgehead in Site B no matter what.... It's just a matter
of when. I'd argue you're actually making better use of your bandwidth
by using Change Notification than not, because then you don't have a
"big bunch" of bytes going between sites every 15 minutes (or whatever),
but rather are "trickling" them. OK, there's a VERY small amount of
overhead with the "change notification" process itself, but the same
number of bytes are going over the link and
(JOE PLEASE CORRECT ME)
I believe that, even with Change Notification, the intersite replication
will continue to use compression
So, bottom line, regardless of your FFL, if 30 kbytes need to replicate
it MIGHT be better to let 6x5 kb (six changes - numbers are just
examples) trickle over every 2.5 minutes versus all 30KB at the "fifteen
minute" mark.
BTW: you might also argue that if you're NOT at WS2003FFL, Change
Notification is more crucial because you DECREASE the risk of
potentially conflicting changes to group membership during a replication
window!!! So from a security standpoint, I'm probably more interested
in convergence when a "non-converged" state might lead to
"human/business/security" problems.
Food for thought.
Dan
(combining branched threads)
FROM ERIC:
Dan -
Are they at the W2K3 FFL? I can see that it may be a problem without LVR
going.
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Wednesday, May 07, 2008 2:51 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Triggers for Change Notification Between Sites
Wow, I hate to say it, but I live for joe's posts hahah.. yes, I'm a
suckup. LOL. Seriously though, thank you for your overflow of AD
knowledge (everyone else too!)
It's good to know at least I was on the right track on how the whole
enable change notify process worked. I needed much clarification on
what to expect since I didnt get my expected result initially.
joe <listmail@joeware.net> wrote:
Possibly...
Assuming change notification was enabled properly, it works.
However the replication is still pushed through the bridgehead server
for the given site. You don't get a ring topology across the sites like
you have within a single site. It is a ring within the site and the
standard spanning tree for intersite. That means convergence isn't
coming from two different directions... you have a SPoF or more
accurately SPoL(atency). So say you have enough DCs in a site to get a
full 3 hop ring then change notification to another site could still
realistically be over a minute with default holdback timing, etc and not
even considering the time to process the churn involved. It could take
considerably over a minute if the bridgehead is busy (either dealing
with lots of work or it has a poor connection to a site and RPC is being
troublesome over that pipe). I have seen bridgeheads that have gotten
tied up for long periods of time (hours under W2K, tens of minutes under
2K3) when a single site was having network issues and it was causing
slowness of all replication going through that bridgehead.
More info... DCs only have single inbound pull replication
thread and the replication is pull based. So while DC-A can service many
DCs asking for updates, it can only pull from one DC at a time. So if
you have a bridgehead that is tied up pulling from say DC-C and DC-B has
changes for it, DC-B will send the change notification to the bridgehead
but it will have to finish with DC-C first before it gets to DC-B to get
the changes to be pulled by DCs in sites that that bridgehead services.
Confused yet?
There is also some implication in the thread about urgent
replication... Urgent replication is different than change notification
though it is related. Urgent replication just means you don't go through
the holdback period but nothing is truly urgently replicated, it is just
urgently queued. I.E. It hits the queue right away but has the normal
priorities of the other stuff queued so it isn't like it goes to the
head of the pack or anything.
This stuff was discussed in Dean and my presentation at DEC back
in 2006, pop out to Jadonex for the powerpoint about it and the info on
the queuing priorities, etc.
If you want to watch what is happening, go pick up ADQueueLoop,
AdFind (with -sc replqueue or -sc ncrepl switches), or repadmin (with
/queue switch) to see what is currently going through the queue or to
show the current queue in its entirely and play with those, you will see
the replication requests being queued up and processed. If you have two
sites (Site A and Site B) and two DCs (SA-DC1 and SB-DC1) and you watch
the Repl Queue on SB-DC1 and change notification is enabled between them
and then make a change directly on SA-DC1 then you should see a repl
request for SA-DC1 pop into the queue in a time dependent on the number
of DCs that are change notify enabled with SB-DC1. So if that is the
only DC with a change notification connection (i.e. no DCs in the site
with SA-DC1 and only the one change notification site) you would
normally expect to see something within 15 seconds.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: Wednesday, May 07, 2008 5:25 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Triggers for Change Notification
Between Sites
I'm guessing you needed to sit out the replication interval for
the site link change.
As Dean said on k3 you should be seeing replication between
these sites converging in a matter of seconds now.
--brian
On Wed, May 7, 2008 at 4:38 PM, Rand Salazar
<rmscheck@yahoo.com> wrote:
Hmm is it just those three items?
Is a better definition, only changes deemed under Urgent
Replication are triggered under Site Link Change Notification?
I'm just trying to understand it more as now our test
environment is confusing me! Now it is replicating changes rather
quickly.. changes such as Exchange mailbox moves, descriptions,
renames, etc... These werent happening earlier.. Currently the rep
interval is set to 30 minutes. Earlier this morning the test
environment was replicating these changes after 30 mins. Now its
happening within a minute or so. Strange. Is this expected behavior or
am I barking up the wrong tree?
"Gustafson, Eric (Oldcastle Materials)"
<eric.gustafson@oldcastlematerials.com> wrote:
An article from the ActiveDir.org site;
http://www.activedir.org/Articles/tabid/54/articleType/ArticleView/artic
leId/40/Default.aspx
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Wednesday, May 07, 2008 11:14 AM
To: Active Dir
Subject: [ActiveDir] Triggers for Change Notification Between
Sites
Folks,
What sort of event will trigger change between sites if we
enable site link notifications? In our test environment with it
enabled, we performed a user rename on one site and nothing happened in
the second site for close to the actual site links replication interval.
As far as I can tell, replication is occurring normally between
sites as eventually the change will replicate, but I would like for it
to be quicker or at least bypass the set interval.
Just for clarification, the options attribute in our test
environment was "Not Set" so I entered a 1 to enable.
Thanks.
________________________________
Be a better friend, newshound, and know-it-all with Yahoo!
Mobile. Try it now.
<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62
sR8HDtDypao8Wcj9tAcJ%20>
________________________________
Be a better friend, newshound, and know-it-all with Yahoo!
Mobile. Try it now.
<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62
sR8HDtDypao8Wcj9tAcJ>
--
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
________________________________
Be a better friend, newshound, and know-it-all with Yahoo!
Mobile. Try it now.
<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62
sR8HDtDypao8Wcj9tAcJ%20>
This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking
action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in, this
e-mail. If verification is sought please request a hard copy. Any
reference
to the terms of executed transactions should be treated as preliminary
only
and subject to formal written confirmation by Nomura. Nomura reserves
the
right to monitor e-mail communications through its networks (in
accordance
with applicable laws). No confidentiality or privilege is waived or lost
by
Nomura by any mistransmission of this e-mail. Any reference to "Nomura"
is
a reference to any entity in the Nomura Holdings, Inc. group. Please
read
our Electronic Communications Legal Notice which forms part of this
e-mail:
http://www.Nomura.com/email_disclaimer.htm
This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in, this
e-mail. If verification is sought please request a hard copy. Any reference
to the terms of executed transactions should be treated as preliminary only
and subject to formal written confirmation by Nomura. Nomura reserves the
right to monitor e-mail communications through its networks (in accordance
with applicable laws). No confidentiality or privilege is waived or lost by
Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please read
our Electronic Communications Legal Notice which forms part of this e-mail:
http://www.Nomura.com/email_disclaimer.htm
| | | |
|
|