Thanks a lot Rich. Unfortunately, for me and fortunately for everyone else, the IP addresses don't change at all when the machine moves from St. Louis to Denver. I did some testing, and it looks like latency is reasonable. Logon times are noticeably longer, but not too much, and in the event of a real true DR we can bring one of the St. Louis DCs over to Denver. So, as of now I think this is doable and it has answered everyone's questions. Thanks again. Ryan
From: [email protected] [mailto:[email protected]] On Behalf Of Milburn, Rich Sent: Friday, June 5, 2015 4:49 PM To: [email protected] Subject: [adgpo] RE: AD and OTV Hi Ryan. First question - is it a problem for them to authenticate remotely? The quick answer is probably, not a problem. However that is assuming a few things: 1) You don't have tons of GPOs or large GPOs or intensive login scripts that will be running remotely. 2) Your latency is low to match your 10GB bandwidth 3) Your 10GB pipe is not saturated In any event, I'm thinking you most likely have enough of your 10GB bandwidth available to handle a couple of remote authentications across it. Second question - can it be pointed at a local DC when it's in Denver? You said it's staying on the same subnet. Is it keeping the same IP? If not, you might be able to subnet your subnets... for example, if you have 10.200.10.0/24 (255.255.255.0) spanning St Louis and Denver, you could define the following subnets in AD: 10.200.10.0/26 defined to St Louis 10.200.10.65/26 defined to St Louis 10.200.10.129/26 defined to St Louis 10.200.10.193/26 defined to Denver Then you could move the IP from one of the lower ranges to the upper range. Same network subnet, but AD would see it in a different site, and choose a Denver DC. You can manually adjust the DC used to authenticate against, such as: nltest /Server:<yourservername> /SC_RESET:domain.com\denverdc but that is a temporary solution, it will revert back after a short time and it doesn't affect DC selection at logon. You can also set the site manually in the registry, as discussed in this article: http://msexchange.me/2014/07/06/connect-exchange-shell-to-different-ad-site-exchange-server/ Rich Milburn From: [email protected] [mailto:[email protected]] On Behalf Of Ryan Shugart Sent: Friday, June 5, 2015 11:07 AM To: [email protected] Subject: [adgpo] AD and OTV Hi: We have our corporate HQ in St. Louis and our DR site in Denver. We have a 10GB link going between the two sites for DR replication. Currently each site has its own subnet (non-DR related work goes on in Denver) and in AD these are two different sites and each site has their own domain controlers. We have just finished implementing OTV so that a machine brought from St. Louis to Denver for DR will keep its existing subnet and not realize its 700 miles away. As I mentioned, there are domain controlers in Denver, but they're assigned to the Denver site and subnet so that workstations and Denver specific servers will authenticate against them. My thinking is if a machine comes over from St. Louis for DR (right now mainly DR testing) it will come up and authenticate against a St. Louis DC even though its in Denver. First question, assuming St. Louis domain controlers are available, and the 10 gig link works, should this present any problems? I'm thinking no, someone logging in shouldn't notice a single difference but wanted to check. Second, and I think the answer to this is no, if I wanted a domain controller in Denver, on the St. Louis subnet but for the purpose of authenticating machines when they were moved to Denver for DR, but only then, is that possible? In other words, without changing a machine's subnet and site, can I get it to authenticate against a different DC in the DR site instead of trying to contact one of its normal DCs across the WAN? Thanks. Ryan Ryan Shugart LAN Administrator MiTek USA, MiTek Denver 314-851-7414 MiTek Holdings, Inc., 2011-2014, All Rights Reserved ________________________________ This communication (including any attachments) contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it is strictly prohibited. If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
