VBScript with Internet Explorer as interface

[Vachaun22]

I have a login script that does various drive mappings and printer installations written in VBScript.

The script creates an IE object in order to show a linux init style status window as to what processes succeed or fail, however on Windows 7 (and most probably Vista) a non-administrator user cannot create an internet explorer object that navigates to anything other than about:blank.

The same code, however, run with admin privs loads the page as expected.

I am looking for a way to create the IE object as administrator in order to navigate to the HTML page that acts as the scripts interface.

I tried using a .hta and running all the code in that, but since it's a single thread the interface never gets updated.

Any suggestions?

 

[markdmac]

How about showing your code so we can offer advice on alternate ways to accomplish what you are doing.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.

 

[Vachaun22]

Sure, here is the code that creates the IE object, then navigates to the file (this does not navigate to a web address, but to a UNC path to a file):

Function CreateIE(objIE, strFullName, strComputerName, strServer, strOSName)
'---------------------------------------------------------------------------------------------
'
' Function: CreateIE
' Input:
'	object objIE
'	string strFullName
'	string strComputerName
' Output:
'	returns error code
'
' Purpose: Creates Internet Explorer object, and loads the logon html status page.
'
'---------------------------------------------------------------------------------------------
	On Error Resume Next

	Set objIE = CreateObject("InternetExplorer.Application")
	with objIE
		.navigate "\\" & strServer & "\netlogon\logon.htm"
		.resizable = 0
		.height = 500
		.width = 640
		.menubar = 0
		.toolbar = 0
		.statusBar = 0
		'.scrollbars = 0
		.visible = 1
	end with

	Do while objIE.Busy
		'wait for page to load
		Wscript.Sleep 100
	Loop

	'' Show Username and Machine and OS name in IE window
	Dim strInfo
	strInfo = strFullName & " on " & strComputerName & " running " & strOSName
	'objIE.document.all.uname.InnerText = strFullName & " on " & strComputerName
	objIE.document.all.uname.InnerText = strInfo
End Function

The objIE object is declared in the calling function, which is actually the main script function. Also, the variables that are passed in are assigned values by other functions.

This script does work if the user is an Administrator, but not a domain user (limited user). Sometimes the script fails with various errors that are never consistent (ranging from interface not found to a null error), other times the script gets stuck waiting for IE to not be busy. There doesn't seem to be any consistency.

However, it seems a limited user can navigate to some webpages (ie, google home page worked, others failed).

It definitely seems to be security related when navigating to a UNC path, and I have also tried giving "Everyone" full access to the directory I'm trying to navigate to.

My next course of action is going to be set up a directory in the IIS, and navigate to it as a website not a UNC path. I'm also going to set the address as a trusted site in IE. Hopefully I won't have to do this as this would make it very difficult for this to work in a domain setting.

Ideally, I would just be able to use the \\domaincontroller\netlogon\file.htm path to navigate, as IIS would not need to be used. But if I must do it that way, then so be it.

 

[markdmac]

I would recommend that you proceed as planned and post the web page on in internal IIS server. You can add the site to trusted sites programatically or via Group Policy.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.

 

[withanh]

Don't know if this will make a difference or not, but according to a thread on a different board I had with a Microsoft tech, you should store your login scripts in a different place. See below:

===========================================

Based on my experience, it is also possible that the same error may occur
when the logon script file is stored in the Netlogon folder. I would
suggest we store it in
\\domain.com\sysvol\policies\{GUID}\user\scripts\logon. To do so, please
follow the steps below:
1. Select the correct OU and open Group Policy Editor for that OU(can be
done in domain level as well).
2. Expand to User Configuration-> Windows Settings->Scripts(Logon/Logoff).
3. Double click Logon in the right pane.
4. Click Show Files button and the script folder will show up.
5. Copy the loginscript.vbs file to the folder and then close the folder.
6. Click Add button and click Browse, the script folder will pop up.
7. Select loginscript.vbs that you have just copied.
8. Click OK twice and close Group Policy Editor.
9. Open a command prompt and type gpupdate /force.
10. On the client side, logon and test. Run gpupdate /force if necessary.

Please note that the loginscript file has put in the right folder. Again,
the file is located under
sysvol\domain.com\policies\{GUID}\user\script\logon. Please ensure that you
have done steps 4 and 5 above.
Also, please run gpupdate /force to refresh the group policy. Group policy
is refreshed every 5-15 minutes on the server side. If the problem
persists, please check whether you have configured the GPO on the correct
OU and or domain level.

After doing this, please ensure fast logon optimization is disabled as well.

===============================

 

[Vachaun22]

withanh,

my logon script is actually stored in the group policy logon directory as you have posted. The only files that are stored in the shared directory (netlogon) are only the ones related to the html page (logon.htm, some javascript files, images) and the ini file that the script reads from to determine what all it is to do for a particular user, OU, or global.

markdmac,

I will have to check into the GPO setting the trusted IE settings. That right now seems as though it will be the best option. I'm in the process of doing some upgrades, but when they are complete I will try this method.

Thanks to both for your insight.

 

[markdmac]

Adding to trusted sites is just a simple registry write.

'add the [URL unfurl="true"]http://Sample[/URL] site to trusted sites.
Set WshShell = CreateObject("Wscript.Shell")
WshShell.RegWrite "HKCU\Software\microsoft\Windows\Currentversion\Internet Settings\ZoneMap\Domains\Sample\http",2,"REG_DWORD"

If unclear to you what to set from my example, manually add the site on one PC and check the above registry path.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.

 

[mrmovie]

personally the idea of an elaborate interace / information for a logon script is a bad idea. a correctly written logon script will take less time to execute (otehr then for the first time a user is logging onto the workstation) than the time it take for you to load your pretty IE webpage.
The dependancies that your logonscript has should be kept to minimum (unless, in this example, your goal is determine if IE is functioning correctly before allowing a user to logon) Placing additional dependancies on any process is not good design and will increase potential points of failure ultimately leading a slower, less robust solution.

sorry, it sounds like you have invested time in your IE solution already which just means i am having a wasteful rant ;-)

good luck with IE7 thing and additional security lock down, looks like these sorts of issues with be the main stumbling blocks for vista/2008 etc

 

[Vachaun22]

mrmovie,

I agree with what you are saying. Under normal circumstances I wouldn't waste my time with an interface. But I've found that M$ tends to make odd decisions that effect things negatively.

The script didn't use to have an interface to be honest. We were running a Citrix server on a 2000 server. But 2000 OS waits for the domain controller before allowing a user to log in to a system, which pretty much guaranteed that the script would run. When we put XP in place, it caused an issue as XP doesn't do this. It will simply log the user on using cached credentials and worry about the domain controller later (you know, to make it appear as though it's ready sooner).

This caused a problem as the scripts were not being executed. So I put an interface to the script to popup when the script runs so our very non techy people would know what's going on (other wise explaining to them is like explaining brain surgery to a janitor no offense).

So basically the script simply sends a succeed or fail message to a function which simply outputs what the current process is and whether it succeeds or fails (ie, mapping a drive, loading a printer). All in all the script runs actually considerably fast, maybe 2 seconds, including domain lookups, printer lookups, reading an INI file containing user, OU, or domain wide settings. So the interface isn't slowing anything down to a speed that I'm concerned about.

Guess I am just a little over zealous with my script is all.

markdmac,

thanks for the tip and I will definitely look into that when I get ready to work on it again.