1

In this SF question, I asked how to determine which DC a server was talking to. We are doing some resilience testing and need to demonstrate to the client that if a DC fails, there are additional DCs available to take the strain.

With nltest, I can determine which DC I'm talking to at any given time. But if we fail the current DC, how do we force the server to re-evaluate which other DCs it can talk to and then connect to one... such that 'nltest' will reflect the new DC?

Ideally I've like some sort of operation I can run within the same Windows session, but thus far we logged out and back in again. My concern with logging in/out is that cached credentials might complicate the picture.

In short, in the event of a DC failure, what is the simplest/quickest/safest way of making the server connection to a secondary DC?

Community
  • 1
CJM
  • 730
  • 2
  • 12
  • 28
  • You mean forcing it? Because the reason nltest may show the old one is that there was simply no need to TALK to the server. It is not like a windows machine asks it's DC every second about something. – TomTom Nov 13 '13 at 16:33
  • 1
    Actually this "failover" mechanism should happen automatically. DNS client (whenever we talk about a Server o Workstation) will ask to its primary DNS server for a DC, so the mechanism is ask the DNS server for an aditional DC. You can use nltest /sc_reset to reset the Net logon secure channel and then restablish it again. – SantiFdezMunoz Nov 13 '13 at 16:39
  • I guess my key point is that, during witness testing, I need to **demonstrate** to the client that the system is resilient to a DC failure... but I don't know the best way to do this. – CJM Nov 13 '13 at 16:52
  • 1
    I think best way to prove that "failover" is to simulate a fail in the DC (for example, unplug the Ethernet if is that possible) and then check again the net logon secure channel with nltest (you should use the /force modifier in order to bypass any cached information) – SantiFdezMunoz Nov 13 '13 at 16:57
  • Ah, `/Force` might be do the trick - I'll try at the first opportunity. – CJM Nov 13 '13 at 17:21
  • It really really really depends on what your "server" is doing, and how *exactly* it depends on AD. – mfinni Nov 13 '13 at 18:42
  • The server could either be a physical database server (SQL Server) or a virtual web server (IIS), but in either case, it won't be doing much of anything seeing as it is currently not in use. – CJM Nov 14 '13 at 09:36
  • @SantiFdezMunoz - whilst TomTom and Ryan have provided sensible solutions that look like they will work, `nltest /force` seem to work well for me (just tested) and is the simplest solution. If you'd care to create a *post* with this information in, I'll accept it as my solution. – CJM Nov 14 '13 at 11:31
  • @CJM - glad to help!! :) – SantiFdezMunoz Nov 14 '13 at 11:36

3 Answers3

5

In short, in the event of a DC failure, what is the simplest/quickest/safest way of making the server connection to a secondary DC?

Type set log on the client to see which DC you logged on with. Kill that DC. Run Wireshark/Netmon while you run klist purge and then C:\> net stop netlogon & net start netlogon on the client.

Or just wait until the client needs something from AD. It's smart enough to try other DCs in its site if it can't contact the first one.

As an opinionated aside, it's pretty stupid of your client to ask you to demonstrate for them the advertised capability of the #1 directory service in the world, used by literally millions of people around the globe... but then again, I understand that clients sometimes ask for stupid things.

Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
  • Or type "echo %logonserver%", without the quotes. – joeqwerty Nov 13 '13 at 21:26
  • 1
    To be fair to the client, they're probably not challenging AD itself, but are checking we've implemented it sensibly and that our comms configuration is working. – CJM Nov 14 '13 at 09:46
4

Login with 2-3 accounts on a fresh machine. Login 1, turn down current dc, logout, login second account. As those accounts have no profile on the machine, it will demonstrate failover.

TomTom
  • 50,857
  • 7
  • 52
  • 134
  • This had already been suggested to me; it seems perfectly sensible, but slightly more effort and more time-consuming that I'd hoped. I was hoping for *check dc > fail dc > do something > check dc > restart dc > do something > check dc* – CJM Nov 14 '13 at 09:45
  • The problem is that computer/dc is not a permanent connection, as such you need to force a scenario where it is needed. – TomTom Nov 14 '13 at 10:08
1

Actually this "failover" mechanism should happen automatically. DNS client (whenever we talk about a Server o Workstation) will ask to its primary DNS server for a DC, so the mechanism is ask the DNS server for an aditional DC. You can use nltest /sc_reset to reset the Net logon secure channel and then restablish it again.

I think best way to prove that "failover" is to simulate a fail in the DC (for example, unplug the Ethernet if is that possible) and then check again the net logon secure channel with nltest (you should use the /force modifier in order to bypass any cached information)

SantiFdezMunoz
  • 330
  • 1
  • 6