Logon Scripts And Fully Qualified Domain Names

[6Foot2]

We have a number of logon/logoff scripts which were working fine until a number of circumstances combined. I have ironed out most of the wrinkles [i think] but I am now left with the problem that the logon scripts do not run because they are not addressed in Active Directirory by their Fully Qualified Domain Names.

 

In AD/User Configuration/Scripts/Logon we have:

 

%LOGONSERVER%\NETLOGON\Scripts\logonaudit.vbe

 

We have %LOGONSERVER% because there is more than one server to authenticate logons. I have tried:

 

%LOGONSERVER%.domain.local\NETLOGON\Scripts\logonaudit.vbe

 

in the [desparate] hope that it would work, but it appears that it will not. Is there any way to allow these scripts to run from within Active Directory using Fully Qualified Domain Names [Any Syntax?] I could specify one of the servers only:

 

ServerName.domain.local\NETLOGON\Scripts\logonaudit.vbe

 

but I would like to avoid this if at all possible. Any ideas?

 

And no I can't go back to not using FQDN as we are now in a Consortium of three schools and our networks are linked. The servers have the same names at the NETBios level. That is why we are required now to use FQDN.

[BKGarry]

Our Domain is Called Gravesend,

 

and within there we have 2 logon servers, but the logon scripts run to either \\Gravesend\netlogon or Gravesend.local\Netlogon

 

There is also SYSVOL folder there where we keep our mandatory profiles.

 

This folder syncronises over the 2 servers and automatically connects to the server with the least load

 

Gaz

[6Foot2]

Thanks for that. I will give it a try. :-)

 

Dave.

[6Foot2]

I have now made the changes, but it looks as if [some] of the policy is not being applied. For example I have changed the Connection/Proxy Settings from:

 

ISAServerName: Port 8080

 

To:

 

ISAServerName.Domain.Local: Port 8080

 

This [and other AD settings] is not [are not] being set at the client stations. If I can get these settings to stick I think I can resolve a hatfull of problems here. Any ideas?

[Geoff]

Run DCDiag, Netdiag, GPMC modelling & Results. Also check the event log on the client for errors. If you still can't find a problem, enable user event debugging and check the IE branding logs..

[6Foot2]

Run DCDiag, Netdiag, GPMC modelling & Results. Also check the event log on the client for errors. If you still can't find a problem, enable user event debugging and check the IE branding logs..

 

OK. Will do, but your post leads me to believe that you have the impression that all of the problems are involved with Internet Explorer. In fact the proxy change not being applied is just one example. Others are not adding network printers, running logon/logoff scripts [which is where this post began], enforcing hash rules(?),…

[Geoff]

The above diagnostic steps apply equally to the other problems.

[IanB]

Have you tried using the domain\share path, in the form:

 

domain.local\netlogon\script

?

Because this accesses the domain through the sysvol , you don't need the actual server name. It will just connect to any domain controller in the domain.

Hope this helps

[BKGarry]

Our Domain is Called Gravesend,

 

and within there we have 2 logon servers, but the logon scripts run to either \\Gravesend\netlogon or Gravesend.local\Netlogon

 

There is also SYSVOL folder there where we keep our mandatory profiles.

 

This folder syncronises over the 2 servers and automatically connects to the server with the least load

 

Gaz

 

 

Have you tried using the domain\share path, in the form:

 

domain.local\netlogon\script

?

Because this accesses the domain through the sysvol , you don't need the actual server name. It will just connect to any domain controller in the domain.

Hope this helps

 

I love it when people read the whole post

[6Foot2]

Still having the issues. I have found this entry in the station Events and Errors Message Centre:

 

"Windows XP-based systems that use Gigabit Ethernet devices may not be able to join an Active Directory domain, which aborts the Group Policy"

 

These stations DO have Gigabit capable network cards [broadcom] but they are connecting at 100 Mb. Could this still apply?

 

I have found this KB article: 938115

 

Quoting from the article:

 

"RESOLUTION

To resolve this problem, update the Enterasys switch to run the latest version of the firmware."

 

and:

 

"WORKAROUND

To work around this problem, edit the 802.1X settings, and then do not save the changes. "

 

I don't know how to try either one of these. Can anyone help?

[6Foot2]

Despite the content of the Events and Errors Message Centre it appears that the KB article referred to earlier relates only to wireless networking [and we are not connecting wirelessly at Gigabit speeds]

 

I think I may have found a workaround for the printing problem now though. Here it is:

 

Logon as a user for whom printing is a problem on these stations. Allow the spool service to crash. Remain logged on. Logon to another domain enabled station. Right click MyComputer. Select Manage. Select Connect to another computer and pickup the computer where the non-admin user has just logged on. Select Services and applications on the remote computer. Find the spool service and select Start or Restart the service. Logoff the non-admin user restart the computer and logon as the same user. Test printing. Hey presto, it works. Now all I have to do is repeat this very long winded process at another 30 odd machines. Oh joy!