Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Script errors only when ran from a specific DC

Status
Not open for further replies.

DotNetNewbie

Programmer
Mar 3, 2004
344
GB
Hi,

I have recently added a new Domain Controller (DC) to my network. The login script that is being used has worked perfectly up until this point.

When users validate against the new DC they get an error when the script runs, the error is below:

Line 60
Char 1
Error: ActiveX component can't create object: 'InternetExplorer.application'
Code: 800A01AD
Source: Microsoft VBScript runtime error

Below are the lines before and after line 60:

57 envLogonServer = wshenv("LogonServer")
58 Set WshNetwork=wscript.CreateObject("Wscript.Network")
59 Set filesys = CreateObject("Scripting.FileSystemObject")
60 Set MSIE = CreateObject("InternetExplorer.Application")
61 Set adsSystemInfo = CreateObject("ADSystemInfo")

Any help most grateful.

.net
 
the script it loaded and run locally on the client at logon.
cant see how the call to CreateObject InternetExplorer will be affected by a DC. seems pretty far fetched to me.

anyway, in script terms. accept this as a possibility and code round it. so, you cant access IE (why you would want to do this in a logon script i can only guess at some elaborate GUI which hopefully will only be displayed for a split second and the user will ignore it as he is busy scratching his bum or drinking his coffee or chatting to his pal about last nights X'factor), then just call some subroutines for displaying to the screen wscript.echo rather then IE. make sure you are centrally logging the individual progress of each users run of your logonscript, you can then write a script to look through the log files and see which machines are suffering from this, if it is all your clients, just a few who have installed something or their IE is fundamentally knackered
 
MrMovie,

Thanks for your prompt reply.

I agree, it does seem odd that it is affected by the DC. However after doing some extensive testing I can prove it only happens when the user validates against a specific DC, using either of the other 2 works fine.

Part of the script displays the companies compliance statement for ISO 27001, which the user has to click to accept - though I did like the comment about drinking coffee ;)

I was lead to believe it was more professional to use an IE window, however if the wscript.echo command works just as well then perhaps I will look to change it.

However I would like to know why it occurs.

Cheers.

.net
 
hmm, still doesnt make any sense to me why the call to IE would fail when the machine/user is authenticated against that DC. not that familiar with group policy but does the script get copied locally before it is executed? that shouldnt make a blind difference either.

saying that, i have been out of world of logon scripts for some time especially with the new client OS's and IE and its security settings? you do have all sorts of IE trust zone settings but these are usually domain specific.

ok, so, the root cause seems beyond me, i am not in your environment, dont know your clients and what software config they are running.

but, the script. at the end of the day you want your logonscript to complete / run to the end and not fall over when somethign it is depending on is not available.

so, i would recommend something like:

On Error Resume Next
Err.Clear
Set MSIE = CreateObject("InternetExplorer.Application")
If Err.Number <> 0 Then
blnIEOK = False
End If
On Error Goto 0

....
....
Call DisplayMsg(...




Sub DisplayMsg(ByRef MSIE, ByVal blnIEOK, ByVal str2Display)
If blnIEOK = True Then
'hmm not sure what or when you do something with IE
Else
Wscript.Echo str2Display
End If
End Sub
 
the root cause, the machines which get this issues are the ones which authenticate against the new DC...without forcing them to authenticate against a specific DC this implies they have something else incommon with each other? i.e. are in the same place? are they subject to anything else which is different? software configuration, GPO's etc
 
MrMovie,

All the computers and laptops are build from an image so they are all the same - even Windows Update deployment is controlled via WSUS!

The only difference would be the actual user who logs into the PC/Laptop. My initial thoughts were it was a profile issue and as such recreated the profile, however this did not resolve the issue.

As for any other commonality - the PC's/Laptops are in different buildings - albeit on the same LAN. I can force a computer to only use a specific DC, but I see no merit in it as it negates the need for multiple DC's.

As it is the newest DC that is the issue I wondered if there was something missing, or some sort of permission issue, but I cannot see anything in the event logs.

GP's are applied dependant on the individual, there might be a slight difference, but this will be down to what departmental drives they have mapped and have access too, other than that I cannot see any difference in the users and which GP's are applied.

.net
 
ok, how about running the logonscript manually, after the user has logged on.
you should be able to browse to the sysvol (if thats the right place) on each of the DC's whilst the user is logged on and reproduce the issue? or at least highlight a difference in the outcome between each DC? (i personally doubt there would be any difference when you try and reproduce it like this but, it will eliminate certain possibilities)

i only mentioned forcing machines to use a specific DC because you assert that machineA logging on via DC1 is ok, but machineA logging on via DC2 is not ok. by this i mean for testing purposes you must have forced the machine to logon via two different DC's?
 
MrMovie,

That is an interesting idea, I did not think of running it manually from SysVol. I will give that a go and see what happens.

Cheers,

.net
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top