[ActiveDir] DC replication
We just installed a server offsite. It is connected by VPN through a PIX 525 and a PIX 501. After installing it, it was decided that it needs to be a domain controller. Ran dcpromo on it and there were no errors reported. The problem I have with it now is that it seems to be replicating in one direction only. All DC's running 2000 server. Active Directory Sites Services on DC01 and DC02 has all 3 servers listed. DC01 and DC02 do not show any entries in the NTDS settings for DC03. DC03 shows the correct entries for all 3 servers. If I manually add a new active directory connection from DC01 or DC02, it shows all 3 of the DC's in the selection box. After adding it and selecting replicate now, I receive the RPC server is unavailable error. That error refers to DNS errors. I can ping by name to all DC's. Are there other tests I need to run to check DNS? Repadmin shows correct inbound and outbound neighbors on DC01 and DC02. DC03 shows correct inbound neighbors, but no outbound neighbors. DC01 - Main domain controller at main officeDC02 - Secondary domain controller at main officeDC03 - New domain controller at offsite location, VPN connection Thanks in advance Mike Michael P. Williams Information Technology Carlyle Van Lines (660) 747-8128 X 3816 [EMAIL PROTECTED] www.carlylevanlines.com
RE: [ActiveDir] DC replication
There are a number of ports with TCP and UDP/TCP required that must be available for full communication from DC to DC to succeed. Likely one or more of these are blocked and a ping is great for basic connectivity. From both sides of the VPN, run DCDIAG /v dcdiag.log and a netdiag /v netdiag.log Send those pack to us in the list and we'll help you through. As a quick test, try telnet name or IP of DC 389, where name or IP of DC is the DC on the other side of the VPN. Do from both sides. this is just one of the ports that you need. Another would be 445. Rick [msft] --Posting is provided "AS IS", and confers no rights or warranties ... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike WilliamsSent: Tuesday, October 18, 2005 10:40 AMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] DC replication We just installed a server offsite. It is connected by VPN through a PIX 525 and a PIX 501. After installing it, it was decided that it needs to be a domain controller. Ran dcpromo on it and there were no errors reported. The problem I have with it now is that it seems to be replicating in one direction only. All DC's running 2000 server. Active Directory Sites Services on DC01 and DC02 has all 3 servers listed. DC01 and DC02 do not show any entries in the NTDS settings for DC03. DC03 shows the correct entries for all 3 servers. If I manually add a new active directory connection from DC01 or DC02, it shows all 3 of the DC's in the selection box. After adding it and selecting replicate now, I receive the RPC server is unavailable error. That error refers to DNS errors. I can ping by name to all DC's. Are there other tests I need to run to check DNS? Repadmin shows correct inbound and outbound neighbors on DC01 and DC02. DC03 shows correct inbound neighbors, but no outbound neighbors. DC01 - Main domain controller at main officeDC02 - Secondary domain controller at main officeDC03 - New domain controller at offsite location, VPN connection Thanks in advance Mike Michael P. Williams Information Technology Carlyle Van Lines (660) 747-8128 X 3816 [EMAIL PROTECTED] www.carlylevanlines.com
RE: [ActiveDir] DC replication
Title: Message run dcdiag /s:servername and netdiag on that server and see what they report. You can then run a netdiag /fix to fix trivial errors. You can pipe these to a file as such: netdiag netdiag_servername.txt dcdiag /s:servername dcdiag_servername.txt Make sure your VPN is passing all required traffic for replication. See this article for more info: http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/confeat/adrepfir.mspx Regards, David Chianese -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike WilliamsSent: Tuesday, October 18, 2005 11:40 AMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] DC replication We just installed a server offsite. It is connected by VPN through a PIX 525 and a PIX 501. After installing it, it was decided that it needs to be a domain controller. Ran dcpromo on it and there were no errors reported. The problem I have with it now is that it seems to be replicating in one direction only. All DC's running 2000 server. Active Directory Sites Services on DC01 and DC02 has all 3 servers listed. DC01 and DC02 do not show any entries in the NTDS settings for DC03. DC03 shows the correct entries for all 3 servers. If I manually add a new active directory connection from DC01 or DC02, it shows all 3 of the DC's in the selection box. After adding it and selecting replicate now, I receive the RPC server is unavailable error. That error refers to DNS errors. I can ping by name to all DC's. Are there other tests I need to run to check DNS? Repadmin shows correct inbound and outbound neighbors on DC01 and DC02. DC03 shows correct inbound neighbors, but no outbound neighbors. DC01 - Main domain controller at main officeDC02 - Secondary domain controller at main officeDC03 - New domain controller at offsite location, VPN connection Thanks in advance Mike Michael P. Williams Information Technology Carlyle Van Lines (660) 747-8128 X 3816 [EMAIL PROTECTED] www.carlylevanlines.com
Re: [ActiveDir] DC replication
Mike Williams wrote: We just installed a server offsite. It is connected by VPN through a PIX 525 and a PIX 501. After installing it, it was decided that it needs to be a domain controller. Ran dcpromo on it and there were no errors reported. The problem I have with it now is that it seems to be replicating in one direction only. All DC's running 2000 server. (...) DC01 - Main domain controller at main office DC02 - Secondary domain controller at main office DC03 - New domain controller at offsite location, VPN connection Thanks in advance Which DNS service were You pointed when You dcpromed DC3? Does all DCs have correct DC3 information in DNS server they are using? If you want to be sure that You are free from DNS issues try to set DC3 to the same DNS server which is used by DC1 and DC2 and restart netlogon service on DC3 to re register DC records. Do You have objects corresponding to DC3 in NTDS settings on DC3 and DC1\DC2? If not try to create connection in opposite direction from DC2 or DC1 to DC3. -- Tomasz Onyszko http://www.w2k.pl List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] DC replication
Thanks, I'll get this information and send it back Mike -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Rick KingslanSent: Tuesday, October 18, 2005 10:59 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] DC replication There are a number of ports with TCP and UDP/TCP required that must be available for full communication from DC to DC to succeed. Likely one or more of these are blocked and a ping is great for basic connectivity. From both sides of the VPN, run DCDIAG /v dcdiag.log and a netdiag /v netdiag.log Send those pack to us in the list and we'll help you through. As a quick test, try telnet name or IP of DC 389, where name or IP of DC is the DC on the other side of the VPN. Do from both sides. this is just one of the ports that you need. Another would be 445. Rick [msft] --Posting is provided "AS IS", and confers no rights or warranties ... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike WilliamsSent: Tuesday, October 18, 2005 10:40 AMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] DC replication We just installed a server offsite. It is connected by VPN through a PIX 525 and a PIX 501. After installing it, it was decided that it needs to be a domain controller. Ran dcpromo on it and there were no errors reported. The problem I have with it now is that it seems to be replicating in one direction only. All DC's running 2000 server. Active Directory Sites Services on DC01 and DC02 has all 3 servers listed. DC01 and DC02 do not show any entries in the NTDS settings for DC03. DC03 shows the correct entries for all 3 servers. If I manually add a new active directory connection from DC01 or DC02, it shows all 3 of the DC's in the selection box. After adding it and selecting replicate now, I receive the RPC server is unavailable error. That error refers to DNS errors. I can ping by name to all DC's. Are there other tests I need to run to check DNS? Repadmin shows correct inbound and outbound neighbors on DC01 and DC02. DC03 shows correct inbound neighbors, but no outbound neighbors. DC01 - Main domain controller at main officeDC02 - Secondary domain controller at main officeDC03 - New domain controller at offsite location, VPN connection Thanks in advance Mike Michael P. Williams Information Technology Carlyle Van Lines (660) 747-8128 X 3816 [EMAIL PROTECTED] www.carlylevanlines.com
RE: [ActiveDir] DC Replication Bandwidth Issue
only glanced over this thread - tough to read it all in a minute ;-) however, I don't think it mentions, that Win2k3 has actually reduced the compression ratio over the benefit of less CPU usage on DCs. I.e. the compression is now not as good as it was in 2000 (can be changed back to the 2000 mode though), but a 2003 DC can thus handle many more incoming connection-agreements... (will be benefitial specifically in branch-office env.) don't have the numbers handy, but I simply wouldn't build on the compression as a method to reduce network bandwidth usage - I tend to replicate more often to reduce bulk replication of changes and thus also have little impact on remote DCs. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Dienstag, 9. März 2004 07:06 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DC Replication Bandwidth Issue Hmmm, you tempt me to go looking through 2/3 year old PST files to see if I can find numbers. Maybe I should just try to find my notes from the field as I recall pages of boring numbers... I do recall the numbers be being better than fairly small. But the planning part is the key thing, depends on what you are shooting for. There is definitely a point where the compression doesn't get much better, that is the whole tuning business and is completely dependent on the profile of traffic. If you don't need the info completely up to date all of the time which is generally the case (now that the password change during pdc-chaining fix is in place) you can go a while between replications and is great for sites with so so lines they are trying to keep low traffic on or have some LOB taking up some x% of the traffic guaranteed. I do agree that most changes are small impact, however the constant chatter across the lines for super low latency is something that MS was attempting to fix by allowing us to tune replication timing. Can live with more latency, you get to have the traffic on the line less often and hopefully less of it overall. Is this something I would spend a lot of time trying to tune and figure out? Most likely not, in my current position, absolutely not, I am full boat replicate as fast as possible (would set the links to 5 minutes if they could be set to that but don't want change notification). However, if the primary concern was amount of data over the line, I would look seriously at my replication profile and see if I could better tune how the data was being sent. If I got even 20% better avg compression stacking changes up for an extra 30 minutes it could be worth it. Depends on the circumstance. The nice thing is that the flexibility exists to do it. At one point I thought I was going to have to do something along these lines as we have a division that dedicates through hardware traffic shaping about 70% of their lines to a LOB app and as they moved from NT 1.0 to Windows 2000 I was expecting to hear we were chattering too much as we process a lot of changes every hour. I started thinking ahead to what would need to be done, saying we just wouldn't replicate during the day wouldn't have been an option. It would have been trying to work out the least replication with the least latency and seeing where it landed. - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Tuesday, March 09, 2004 12:20 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DC Replication Bandwidth Issue Point taken, but I'd argue your savings, over the long haul, are probably fairly small. Existent, sure, but not worth planning over. If this is really what you're looking at you're better off going to w2k03 to get lvr, SIS and tunable compression settings. As long as you're not notifying across the site boundary you won't really get a huge win here, but maybe that's just my gut. I can't speak to it anecdotally. That said, unless you have a heavily constrained pipe typically replication is done on an as-acceptable basis, not as compression benefits. Compression is a benefit, not a reason to schedule replication. Considering that we replicate per attribute (and with lvr, per value) there is a very small cost to changing a single attribute even on a large object. Metadata + new value. The cost savings, if looking at aggregate bandwidth, could be viewed as the fact that you replicate the attribute only at the interval rather than per change. So you could change it 10 times today but you only replicate once if the interval is 24 hours vs. every hour where you may replicate it 10 times. Unless of course the 10 changes are all value adds/removes using LVRthen it's no different. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, March 08, 2004 11:07 PM To: [EMAIL PROTECTED] Subject: RE
RE: [ActiveDir] DC Replication Bandwidth Issue
LOL. I wouldn't expect a lot of replication unless you are making lots of changes, but you can tune it by modifying the schedule to get the max benefit out of the replication packet compression. Actually you will probably have less traffic as your logons and other things using the DCs don't have to traverse the WAN. Make sure you have SP4 or the out of band quickie password replicate hot fix in place unless you make sure you change passwords on the remote DC for the users there. As you turn up the latency to tune replication, that could become more troublesome but for the hotfix/SP. joe - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Network Administrator Sent: Wednesday, March 03, 2004 10:17 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] DC Replication Bandwidth Issue I have an upcoming project that I'd like to seek some input on. I'm looking at building a third domain controller for a tiny domain of about 250 users. Currently, we have two domain controllers at a central location where approximately 85% of our users reside. The rest of our users are at branch locations connected by 128k links that aren't horribly taxed. I'd like to place the third domain controller at one of the branch locations as a disaster recovery box that will be capable of processing domain authentications and other DC-related functions in case our central locations is hit by some catastrophe. Since this is a single site, single domain, single forest topology, I don't necessarily need this box to do anything other than replicate domain information and critical services (DNS, WINS, etc.) on a semi-regular basis. How much bandwidth do you guys think this box will take? Again, it is a tiny domain with approximately 250 users and 225 workstations. It won't hold any FSMO roles, I'll just seize them from the console at the branch location if Joe's volcano makes it all the way over to Kalamazoo. -James R. Rogers List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] DC Replication Bandwidth Issue
I'll bite. I wouldn't expect a lot of replication unless you are making lots of changes, but you can tune it by modifying the schedule to get the max benefit out of the replication packet compression What does that mean? I don't see the relationship between frequency of replication and compression benefits. Short of not pushing metadata more than once when you replicate less frequently for a rapidly-changing object (and a few other small attributes that are brought along for the ride) what benefit do you realize here? How does frequency of replication play in to compression of changes? ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, March 08, 2004 9:33 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DC Replication Bandwidth Issue LOL. I wouldn't expect a lot of replication unless you are making lots of changes, but you can tune it by modifying the schedule to get the max benefit out of the replication packet compression. Actually you will probably have less traffic as your logons and other things using the DCs don't have to traverse the WAN. Make sure you have SP4 or the out of band quickie password replicate hot fix in place unless you make sure you change passwords on the remote DC for the users there. As you turn up the latency to tune replication, that could become more troublesome but for the hotfix/SP. joe - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Network Administrator Sent: Wednesday, March 03, 2004 10:17 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] DC Replication Bandwidth Issue I have an upcoming project that I'd like to seek some input on. I'm looking at building a third domain controller for a tiny domain of about 250 users. Currently, we have two domain controllers at a central location where approximately 85% of our users reside. The rest of our users are at branch locations connected by 128k links that aren't horribly taxed. I'd like to place the third domain controller at one of the branch locations as a disaster recovery box that will be capable of processing domain authentications and other DC-related functions in case our central locations is hit by some catastrophe. Since this is a single site, single domain, single forest topology, I don't necessarily need this box to do anything other than replicate domain information and critical services (DNS, WINS, etc.) on a semi-regular basis. How much bandwidth do you guys think this box will take? Again, it is a tiny domain with approximately 250 users and 225 workstations. It won't hold any FSMO roles, I'll just seize them from the console at the branch location if Joe's volcano makes it all the way over to Kalamazoo. -James R. Rogers List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] DC Replication Bandwidth Issue
I was simply going by the idea that the less often you replicate the more changes that pile up to be replicated. The more data that has to be compressed *generally* the better the compression ratio's you get - this is standard compression algorithm magic involving the pattern reductions that can be accomplished with larger data sets. The more often (and larger) patterns that present themselves, the better your crunch ratio. The exception being when your data is specifically all over the map such as password hashes which tend to compress horribly due to very little pattern repetition. Also until you hit, I think 32k in data volume, you don't get compression at all. So if you are replicating a few changes often your chances of compression and the ratios you get out of it if any are lower. Say you make some change that is 10k in size, you make the change 3 times an hour and are set to replicate every 15 minutes. You will not get compression. You set your replication to once an hour you should hit compression point at which point you will send less data in that hour (not even including meta data). Go two hours and you will most likely get even better compression ratios and even a greater savings in traffic over replicating every 15 minutes (and again not even including meta data). If your changes are all password hash changes, all bets are off because that is some of the most random data that will go across the replication thread. When we did initial testing of this way back when I seem to recall getting some pretty good compression numbers when pushing larger volumes of data. I guess you could say that the Windows Replication compression algorithms give a static compression ratio across the board so that you get a constant savings whether replicating 100k or 200k and I will say ok but I seem to recall seeing differently in our testing. joe - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Monday, March 08, 2004 11:43 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DC Replication Bandwidth Issue I'll bite. I wouldn't expect a lot of replication unless you are making lots of changes, but you can tune it by modifying the schedule to get the max benefit out of the replication packet compression What does that mean? I don't see the relationship between frequency of replication and compression benefits. Short of not pushing metadata more than once when you replicate less frequently for a rapidly-changing object (and a few other small attributes that are brought along for the ride) what benefit do you realize here? How does frequency of replication play in to compression of changes? ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, March 08, 2004 9:33 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DC Replication Bandwidth Issue LOL. I wouldn't expect a lot of replication unless you are making lots of changes, but you can tune it by modifying the schedule to get the max benefit out of the replication packet compression. Actually you will probably have less traffic as your logons and other things using the DCs don't have to traverse the WAN. Make sure you have SP4 or the out of band quickie password replicate hot fix in place unless you make sure you change passwords on the remote DC for the users there. As you turn up the latency to tune replication, that could become more troublesome but for the hotfix/SP. joe - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Network Administrator Sent: Wednesday, March 03, 2004 10:17 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] DC Replication Bandwidth Issue I have an upcoming project that I'd like to seek some input on. I'm looking at building a third domain controller for a tiny domain of about 250 users. Currently, we have two domain controllers at a central location where approximately 85% of our users reside. The rest of our users are at branch locations connected by 128k links that aren't horribly taxed. I'd like to place the third domain controller at one of the branch locations as a disaster recovery box that will be capable of processing domain authentications and other DC-related functions in case our central locations is hit by some catastrophe. Since this is a single site, single domain, single forest topology, I don't necessarily need this box to do anything other than replicate domain information and critical services (DNS, WINS, etc.) on a semi-regular basis. How much bandwidth do you guys think this box will take? Again, it is a tiny domain with approximately 250 users and 225 workstations. It won't hold any FSMO roles, I'll
RE: [ActiveDir] DC Replication Bandwidth Issue
Point taken, but I'd argue your savings, over the long haul, are probably fairly small. Existent, sure, but not worth planning over. If this is really what you're looking at you're better off going to w2k03 to get lvr, SIS and tunable compression settings. As long as you're not notifying across the site boundary you won't really get a huge win here, but maybe that's just my gut. I can't speak to it anecdotally. That said, unless you have a heavily constrained pipe typically replication is done on an as-acceptable basis, not as compression benefits. Compression is a benefit, not a reason to schedule replication. Considering that we replicate per attribute (and with lvr, per value) there is a very small cost to changing a single attribute even on a large object. Metadata + new value. The cost savings, if looking at aggregate bandwidth, could be viewed as the fact that you replicate the attribute only at the interval rather than per change. So you could change it 10 times today but you only replicate once if the interval is 24 hours vs. every hour where you may replicate it 10 times. Unless of course the 10 changes are all value adds/removes using LVRthen it's no different. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, March 08, 2004 11:07 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DC Replication Bandwidth Issue I was simply going by the idea that the less often you replicate the more changes that pile up to be replicated. The more data that has to be compressed *generally* the better the compression ratio's you get - this is standard compression algorithm magic involving the pattern reductions that can be accomplished with larger data sets. The more often (and larger) patterns that present themselves, the better your crunch ratio. The exception being when your data is specifically all over the map such as password hashes which tend to compress horribly due to very little pattern repetition. Also until you hit, I think 32k in data volume, you don't get compression at all. So if you are replicating a few changes often your chances of compression and the ratios you get out of it if any are lower. Say you make some change that is 10k in size, you make the change 3 times an hour and are set to replicate every 15 minutes. You will not get compression. You set your replication to once an hour you should hit compression point at which point you will send less data in that hour (not even including meta data). Go two hours and you will most likely get even better compression ratios and even a greater savings in traffic over replicating every 15 minutes (and again not even including meta data). If your changes are all password hash changes, all bets are off because that is some of the most random data that will go across the replication thread. When we did initial testing of this way back when I seem to recall getting some pretty good compression numbers when pushing larger volumes of data. I guess you could say that the Windows Replication compression algorithms give a static compression ratio across the board so that you get a constant savings whether replicating 100k or 200k and I will say ok but I seem to recall seeing differently in our testing. joe - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Monday, March 08, 2004 11:43 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DC Replication Bandwidth Issue I'll bite. I wouldn't expect a lot of replication unless you are making lots of changes, but you can tune it by modifying the schedule to get the max benefit out of the replication packet compression What does that mean? I don't see the relationship between frequency of replication and compression benefits. Short of not pushing metadata more than once when you replicate less frequently for a rapidly-changing object (and a few other small attributes that are brought along for the ride) what benefit do you realize here? How does frequency of replication play in to compression of changes? ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, March 08, 2004 9:33 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DC Replication Bandwidth Issue LOL. I wouldn't expect a lot of replication unless you are making lots of changes, but you can tune it by modifying the schedule to get the max benefit out of the replication packet compression. Actually you will probably have less traffic as your logons and other things using the DCs don't have to traverse the WAN. Make sure you have SP4 or the out of band quickie password replicate hot fix in place unless you make sure you change passwords on the remote DC for the users there. As you turn up the latency to tune replication
RE: [ActiveDir] DC Replication Bandwidth Issue
Hmmm, you tempt me to go looking through 2/3 year old PST files to see if I can find numbers. Maybe I should just try to find my notes from the field as I recall pages of boring numbers... I do recall the numbers be being better than fairly small. But the planning part is the key thing, depends on what you are shooting for. There is definitely a point where the compression doesn't get much better, that is the whole tuning business and is completely dependent on the profile of traffic. If you don't need the info completely up to date all of the time which is generally the case (now that the password change during pdc-chaining fix is in place) you can go a while between replications and is great for sites with so so lines they are trying to keep low traffic on or have some LOB taking up some x% of the traffic guaranteed. I do agree that most changes are small impact, however the constant chatter across the lines for super low latency is something that MS was attempting to fix by allowing us to tune replication timing. Can live with more latency, you get to have the traffic on the line less often and hopefully less of it overall. Is this something I would spend a lot of time trying to tune and figure out? Most likely not, in my current position, absolutely not, I am full boat replicate as fast as possible (would set the links to 5 minutes if they could be set to that but don't want change notification). However, if the primary concern was amount of data over the line, I would look seriously at my replication profile and see if I could better tune how the data was being sent. If I got even 20% better avg compression stacking changes up for an extra 30 minutes it could be worth it. Depends on the circumstance. The nice thing is that the flexibility exists to do it. At one point I thought I was going to have to do something along these lines as we have a division that dedicates through hardware traffic shaping about 70% of their lines to a LOB app and as they moved from NT 1.0 to Windows 2000 I was expecting to hear we were chattering too much as we process a lot of changes every hour. I started thinking ahead to what would need to be done, saying we just wouldn't replicate during the day wouldn't have been an option. It would have been trying to work out the least replication with the least latency and seeing where it landed. - http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Tuesday, March 09, 2004 12:20 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DC Replication Bandwidth Issue Point taken, but I'd argue your savings, over the long haul, are probably fairly small. Existent, sure, but not worth planning over. If this is really what you're looking at you're better off going to w2k03 to get lvr, SIS and tunable compression settings. As long as you're not notifying across the site boundary you won't really get a huge win here, but maybe that's just my gut. I can't speak to it anecdotally. That said, unless you have a heavily constrained pipe typically replication is done on an as-acceptable basis, not as compression benefits. Compression is a benefit, not a reason to schedule replication. Considering that we replicate per attribute (and with lvr, per value) there is a very small cost to changing a single attribute even on a large object. Metadata + new value. The cost savings, if looking at aggregate bandwidth, could be viewed as the fact that you replicate the attribute only at the interval rather than per change. So you could change it 10 times today but you only replicate once if the interval is 24 hours vs. every hour where you may replicate it 10 times. Unless of course the 10 changes are all value adds/removes using LVRthen it's no different. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, March 08, 2004 11:07 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DC Replication Bandwidth Issue I was simply going by the idea that the less often you replicate the more changes that pile up to be replicated. The more data that has to be compressed *generally* the better the compression ratio's you get - this is standard compression algorithm magic involving the pattern reductions that can be accomplished with larger data sets. The more often (and larger) patterns that present themselves, the better your crunch ratio. The exception being when your data is specifically all over the map such as password hashes which tend to compress horribly due to very little pattern repetition. Also until you hit, I think 32k in data volume, you don't get compression at all. So if you are replicating a few changes often your chances of compression and the ratios you get out of it if any are lower. Say you make some change that is 10k in size, you make
[ActiveDir] DC Replication Bandwidth Issue
I have an upcoming project that I'd like to seek some input on. I'm looking at building a third domain controller for a tiny domain of about 250 users. Currently, we have two domain controllers at a central location where approximately 85% of our users reside. The rest of our users are at branch locations connected by 128k links that aren't horribly taxed. I'd like to place the third domain controller at one of the branch locations as a disaster recovery box that will be capable of processing domain authentications and other DC-related functions in case our central locations is hit by some catastrophe. Since this is a single site, single domain, single forest topology, I don't necessarily need this box to do anything other than replicate domain information and critical services (DNS, WINS, etc.) on a semi-regular basis. How much bandwidth do you guys think this box will take? Again, it is a tiny domain with approximately 250 users and 225 workstations. It won't hold any FSMO roles, I'll just seize them from the console at the branch location if Joe's volcano makes it all the way over to Kalamazoo. -James R. Rogers smime.p7s Description: S/MIME cryptographic signature
RE: [ActiveDir] DC Replication Bandwidth Issue
I wouldn't expect it to be excessive, and you can always set your site replication schedules to coincide with low usage times. Pull up perfmon on one of your DCs, and watch the NTDS\DRA Inbound Bytes... counters for a day or so. The DRA Inbound Bytes Not Compressed (Within Site) counters will give you a worst case scenario, as intra-site replication traffic won't be compressed but inter-site replication traffic will. Hunter -Original Message- From: Network Administrator [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 8:17 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] DC Replication Bandwidth Issue I have an upcoming project that I'd like to seek some input on. I'm looking at building a third domain controller for a tiny domain of about 250 users. Currently, we have two domain controllers at a central location where approximately 85% of our users reside. The rest of our users are at branch locations connected by 128k links that aren't horribly taxed. I'd like to place the third domain controller at one of the branch locations as a disaster recovery box that will be capable of processing domain authentications and other DC-related functions in case our central locations is hit by some catastrophe. Since this is a single site, single domain, single forest topology, I don't necessarily need this box to do anything other than replicate domain information and critical services (DNS, WINS, etc.) on a semi-regular basis. How much bandwidth do you guys think this box will take? Again, it is a tiny domain with approximately 250 users and 225 workstations. It won't hold any FSMO roles, I'll just seize them from the console at the branch location if Joe's volcano makes it all the way over to Kalamazoo. -James R. Rogers List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
