Robdutoit
(Hey THIS is FUN)
2012-12-13 09:17 PM
Issue with @Domain variable

Yes its me again. Twice in one day ! But I know you guys love me \:\)

I will be back at the client tomorrow and do some more digging up on the issue, but I thought that I would see if anyone else has had this issue before!

With my shiny new script, I have already setup three networks and I am on my fourth network upgrade which consists of a new software image using WDS and so on. The first two networks were brand new servers, the second network, was a pre-existing Windows 2008 server and this network is also a pre-existing windows 2008 server. I mention this specifically, because I do believe the problem is some missed setting somewhere on this server.

With the first three networks, the @domain function works flawlessly and the script works as expected although I am modifying it almost weekly to take into account differences on each new network.

At this client, the @domain function only works perfectly if you logon and manually run the startup script as administrator and the files are copied across correctly from the netlogon location. However, it does not work if you boot up the computer and have the script run in the startup script. It did perfectly on the first three neworks - no problem.

So the problem is not the script, not the fact that its running in the startup location of the GPO and its not the @domain variable as this works on the previous 3 networks.

Hence, the problem must be something about the server at this location. After doing some testing earlier today, and also at home I have determined the following:

The @domain or %userdnsdomain% does not work when run as a startup script.
However if you put in the name of the \\server\netlogon, this works fine in the startup script. So its not NTFS Permissions on the Netlogon folder, which should be using the default permissions anyway.

The @Domain does work if you run the startup script manually while logged on as administrator, so the script syntax is obviously correct and obviously it worked on the other networks.

Also interestingly enough the @domain variable returns the Netbios name, not the FQDN, so I was thinking it was a Netbios issue with this server, but it works when you logon and run the script manually.

so I was just wondering if anyone else has had this issue where the @domain variable works when the script is run manually, but does not work when booting up the computer and running from the startup script. The entire startup script runs when the computer boots - I have tested this by changing registry keys to be the opposite of what the script will change them to and I can see that the startup script is running, because the changes are being made. The only things that are not working is any line with the @domain variable in it. But if you put in \\servername\netlogon the entire script works as should be.

Any idea why the @domain fails on bootup?
I will be hard at working on that server tomorrow, so I will see if I can find any clues to the cause of the problem. as the client computer is freshly imaged, and the script is a new and working script as per the previous three networks that I have just upgraded, my conclusion is some setting on the pre-existing server is somehow interfering with the netbios resolution on bootup?

Thanks in advance for any ideas!


Robdutoit
(Hey THIS is FUN)
2012-12-14 02:34 PM
Re: Issue with @Domain variable

Update on the problem. After much troubleshooting, and screaming at everyone (just kidding), I have unearthed the dear sweet problem
I have put a sleep for 120 in the script and it works perfectly. Aargh - It is obviously running the entire startup script too quickly and hasn't loaded the information for @domain yet.

What can I do to get the startup script to wait for the @domain info to be loaded prior to execution of the script
I have added this to the script, but it does not seem to work, so for the moment I am going to have to use the sleep for 60 seconds option to force the script to wait.

 Code:
? "Domain name is " @Domain
while
@Domain = ""
sleep 0.3
? "sleeping for 300 milliseconds"
loop

Hope this helps somebody ele


Glenn BarnasAdministrator
(KiX Supporter)
2012-12-14 03:54 PM
Re: Issue with @Domain variable

Not likely a script problem..

Make sure that your have a Computer GPO defined that enables "Always wait for the network at computer startup and logon". This has been discussed here several times, along with the "Run logon scripts synchronously", which prevents the dsesktop from displaying before the script completes. Without the former setting, the login process will start before all network services are ready.

I include these policies at every client site and never have these kind of issues once they are in place.

Glenn


Les
(KiX Master)
2012-12-14 04:03 PM
Re: Issue with @Domain variable

LOL
I think the OP has a GPO aversion.


Robdutoit
(Hey THIS is FUN)
2012-12-14 08:05 PM
Re: Issue with @Domain variable

the man mocks me! GPO is just slow. I like a fast network. I will see if I can find a solution to the problem without having to resort to always wait for network as that defeats part of the object of the network upgrade, which is to improve login time. cheers

ShaneEP
(MM club member)
2012-12-14 11:38 PM
Re: Issue with @Domain variable

You could create your own "wait for network" loop like so...

 Code:
While not OSping("google.com")
  ? "looping"
Loop

Function OSping($sComputer, OPTIONAL $timeout)
   $timeout = IIf(Len($timeout),$timeout,500)
   Shell '"'+%COMSPEC%+'" /c ping -n 1 -w '+$timeout+' '+$sComputer+' |find /C "TTL=" >nul'
   $OSping = not @ERROR
EndFunction