Global.asa file not doing what it should - please help

[newbie~wan]

Within our internal network we have built a site to automate the installation of software. The problem is that some of the code contains windows script host command line calls that the browser sees as a call to an active x control. Our our machines (were talking like 20,000 here - so no way to change) IE intranet settings to not allow unsigned active x, which it sees our script as.

Our circumvention of this involves starting at the main window and asking the user if its okay to run a vbs script that uses registry hacks to reduce browser security settings. Upon approval, it then launches a child window from that one and kills the parent. Then the child will have the settings to allow our "unsigned active x" control to work. When that child window is closed, the settings go back to the way they were (since they only applied to that window anyway).

Basically, we want to avoid having to prompt the user to approve the vbs and then lauch another window. We have tried setting up the global.asa file to include:

function Application_OnStart()

So that the script to lower browser security would be run upon IE launch, not just session launch, but it doesnt appear to be doing it?

Any ideas would be greatly appreciated. You'd be helping me score some serious brownie points and I would be indebted to you.

[^hyd^]

a couple things come to mind.

first, it's not a 'function', it's a subroutine, so instead of "function Application_OnStart" try "sub Application_OnStart"

next, is it in the root directory of your ASP application* ??

The Global.asa file must be stored in the root directory of the ASP application, and each application can only have one Global.asa file. Changes to the Global.asa file require a reboot for the server to recognize them.
linkage

* In order for the web server to know to look for this file you need to set up your directory as an application in IIS. This is done by navigating to the appropriate web site or directory in Internet Services Manager and right clicking on it and selecting "Properties" from the pop up menu. Then select the "Directory" or "Home Directory" tab and on the bottom half of that window you will see the "Application Settings" section. If it's not already, you need to make the directory an application by pressing the "Create" button. Click "Ok" to save the setting and exit.
linkage

try them two suggestions, hope they help... be back later to see how it goes!!

cheers!

[newbie~wan]

Were using javascript, so I think it should be "function".

I will try that other stuff on monday. I don't have access to the Internet Information Services MMC on the server, so I'll relay those ideas to the other guy and we'll see how they go. ASP is fairly new to both of us (hes worked with it just months, me just DAYS!! )

[^hyd^]

oic, ya it might be 'function' then... didn't realise you were using javascript!!

g'luck!!

[UncaDanno]

I don't think Application_OnStart will give you what you want.

It fires when the Application starts, not when someone points their browser to your site. In the ASP world Application_OnStart fires when the website fires up, either via the Stop/Start drill in IIS or via rebooting the server.

The other option, Session_OnStart fires when someone points their browser at the site. And whatever settings are made here, given you don't reset them elsewhere in the site, remain in effect until the browser is shut down or until no pages in the site are hit and the session timeout (also set in IIS) lapses.

Here's a scenario for you:
The server boots up or someone does the Stop/Start deal in IIS. This fires Application_OnStart.
Someone's browser visits a page on your site. Session_OnStart fires.
The visitor goes to another page in the site or clicks on a link that launches a new instance of IE pointed to another page on your site. Neither event fires! The Application, the website, started long ago and the visitor hit the first page in the site already so the session for the visitor has already started.

As a side note: most usability experts would tell you that it is better to ask a user's permission before monkeying with settings (the way you already have it set up) than to go ahead and change settings without the user's knowledge.

As a matter of fact, Senator Fritz Hollings is hard at work to make it a felony to do so.

[^hyd^]

good point on the differences of the application/session OnStart events UncaDanno!! ..very good point... heheh, didn't even think of that...

since it's their intranet and the companies computers(I would guess), it might not matter (in this case) about changing settings without the users permission. but for a public website, it definately would matter!!

cheers!

[newbie~wan]

Thank you both for your responses. The guy who built the site is still not in today, but the other day he was trying to demonstrate the problem to me and he wasn't rebooting the server after making changes to global.asa, so that could be the problem. BTW, isn't that a bit much to ask? To expect someone to be able to reboot a server to make a few changes? This server isn't necessarily vital, but it does host a number of sites and shares that numerous people are using everyday.

^hyd^, I checked out the "home directory" tab in the directory's "properties", and under the block labeled "application settings" there is no "create" button, only a "remove" button, so I think it must already be running as an application. Here is the global.asa file's contents:

*****************************************
<SCRIPT LANGUAGE="VBScript" RUNAT="Server">

Sub Session_OnStart()
set WshShell = CreateObject("WScript.Shell")
WSHShell.run "regedit \\ohaephqas001\eap\lower.reg",0,0
set WSHShell = nothing
End Sub

Sub Session_OnEnd()
set WshShell = CreateObject("WScript.Shell")
WSHShell.run "regedit \\ohaephqas001\eap\higher.reg",0,0
set WSHShell = nothing
End Sub

</script>
**********************************************

Keep in mind that I really don't understand much about the web client/server relationship, but if ohaephqass001 is the name of our server, then shouldn't we be running the "regedit" command on the client machine, not our server? I don't see what good it does to edit the registry of the server, its the client machine that we're trying to get to allow the change.

[^hyd^]

hello again!

I checked out the "home directory" tab in the directory's "properties", and under the block labeled "application settings" there is no "create" button, only a "remove" button, so I think it must already be running as an application.

yes, sounds to me like it is already set as an application.

regarding rebooting the server, I think that the quote in my other post stating to do this is misleading. as mentioned in UncaDanno's post, I'm pretty sure you can just stop/restart the WWW service, either via the services control panel or in the Internet Services Manager or with Net Stop w3svc/Net Start w3svc from a 'run' box. (may also have to stop/restart iisadmin also, but not too sure; probably best to just use Internet Services Manager)

not to sure how the script for the regedit would work. I myself am just a junior programmer, with alot to learn yet!! if it is running regedit on the server rather than the client, could you not include the regedit portions at the start and end of your software install scripts?? I'm thinking not, as this is what gives you the prompt at the client asking to run an unsigned activex control as you mentioned...

hhhmmmmm.... I'll think some more, and by then maybe someone else will be by to give some more assistance!! need to spend some more time on my fruitless job hunt as well...

ciao 4 now!!

^hyd^

[newbie~wan]

Okay, I just talked to the guy and here was his thought process. He was thinking that since the Application_OnStart() contains the statment "RunAt=Server", that all the commands would be executed on the server, hence, the windows script host object wshshell would be created at the SERVER not the CLIENT. In other words, he doesnt see why the client is getting a message about an atempt at creating an activeX control when he thought it was being created at the server.
He then thought that this environment setup (w/ the lower.reg settings - which merely lower IE activeX security) would be the environment of the IE browser window on the client machine. If this was the case, then we would be able to run a script on the client machine that contained numerous "wshshell.run ___" commands.

I realize that this is probably clear as mud, but if anyone (by some miracle) sees what I'm getting at and where our thinking is wrong, please help me out.

[UncaDanno]

RunAt=Server
Aye, there's the rub. In the (pre-.NET) IIS world, all ASP scripts run on the server. Even without the RunAt=Server command. This includes the contents of the global.asa file.

Here's the problem: you are trying to lower the security settings in IE on client machines. By running a shell script. IE will only allow the shell script to run if its security settings were ALREADY lowered.

Can't really think of an elegant way, via an intranet site, that you can change settings on a client machine. For intranets, this is usually handled with SMS. And even then the client machine has to connect to and log into the domain in order for SMS to do its thing.