Is box connected to (the right) LAN?

[PiqueABoo]

Someone must have thought about this.. I've got a teensy logon script and I want it to quickly figure out whether the box has a hope in H. of talking to a DC e.g. it's:

 

a) Not connected to a network.

b) Is connected to a home/other network somewhere

 

If possible I'd like it to be generic i.e. no comparing current IP address against some hard-coded value.

 

Any ideas on what's the best thing to look at or test?

[FN-GM]

2 Questions,

 

What type of script is it?

 

Why do you need it to know if the DC is online?

 

Z

[PiqueABoo]

1) Any script (it will be JS but I can translate almost anything).

 

2) So I can skip doing something that wants to talk to a DC and thus avoid timeouts and scary messages.

[SYNACK]

There are a few VBScripts floating about that can do this that you could convert:

 

Ping Computers (VBScript)

Check the status of your servers

[PiqueABoo]

Mmm.. this is a GPO-attached logon script.. which runs when user logged on to domain normally or with cached credentials. The frustrating bit is that in the latter case the system already knows it can't talk to the domain, so I've been naively assuming you ought to be able just ask the system about that (somehow) rather than repeating one or more networky things the system has already done.

 

If I have to talk to the network I suppose I have to, but that would be annoying on principle.

[SYNACK]

If it has an active network adapter during logon ie home wireless it will continue to attempt to contact the domain controller all the way through the logon process and even when it has logged in anyway. I don't know of any way to detect if the machine is using cached credentials and so the easiest way is to simply try the network as the machine is hitting the network around every 3-4 seconds anyway during logon to try and contact the DC.

 

I guess that you could use WMI to return the DNS suffix of all active connections and check to see if any of them match but its probably overkill, the code from here could help:

Retrieve Client-Side Networking Settings through VBScript

[PiqueABoo]

I don't know of any way to detect if the machine is using cached credentials

 

Once upon a time you'd just look at the LOGONSERVER environment variable (would be the local computers name when offline) but that's always set to the last DC that logged you on now.

 

What I've done isn't much harder: Look for an occurence of the USERDNSDOMAIN environment variable in the stdout from an 'ipconfig /displaydns' command. When it's connected and you logon you get at least one DC FQDN in the DNS cache, otherwise I'm saying it's offline.

 

There's probably a loophole or two e.g. depends on no name resolution for the internal domain name outside your network, but it seems OK so far.

[PiqueABoo]

..and then I accidently invoked a nice solution. Instead of setting a GPO to invoke a single logon script located on the PC which does this or that according to whether it thinks it's connected to the domain or not, I make two scripts based on this concept:

 

1) Make a logon script e.g.

HelloWorld.js, contents: WScript.Echo("Connected to domain");

Throw that in the GPO's Scripts\Logon folder and add it as a logon script.

 

b) Make another script with the same name but different contents e.g.

HelloWorld.js, contents: WScript.Echo("Disconnected from domain");

Push that out to %windir% on the target computers.

 

Basically when it's connected to the domain it runs the GPO logon script from the DC, but when it's offline it runs the local one from %windir% (or presumably anywhere else you want to put it in the PATH).

 

Dunno about everyone else and YMMV, but I didn't know you could do that.

 

This isn't why I'm playing with it, but an example of a potentially useful thing you could do with this is to automatically take the tick out of the IE proxy box when it's not online to your domain i.e. in the local version of the script invoke reg.exe to set the HKCU "ProxyEnable" value to 0, [& if necessary put it back to 1 again in the 'partner' script on the DCs]

Edited October 9, 2008 by PiqueABoo

[maniac]

Now that's a neat solution if it works, going to have a play tomorrow as that would solve a lot of problems I think!

[PiqueABoo]

I've been trying to explain it, but nearest I can get is that (being User policy in this case) the GPO logon script [path]names end up in a "Script" value under this key:

 

HKCU\Software\Policies\Microsoft\Windows\System\Scripts\Logon\n\m

 

Where I think 'n' and 'm' are numbers dependant on how many GPOs have logon scripts, and how many scripts any given GPO has respectively. This key is one that SysInternal's "Autoruns" and similar utils report on (looks like it has occasionally been abused by malware).