I am trying to setup the web interface for PageGate. I have followed the instructions in the support section. The client page loads when I use the URL, server followed by the group name. http://<SERVER>/pgweb
When I select the recipient, enter some text, and click send, the browser tab says waiting for <server>. If I look in the task manager, an instance of webgate32 is started and runs at 100% indefinitely. The page is not sent. The same recipient does work from the thick client.

That indicates that the user/usergroup on the workstation where it isn't working doesn't have sufficient permissions to the CGI data directory that the webgate.exe lives in. You'll want to go in to the properties of that folder on the web server, go under the Security tab and set that user/usergroup to have the Read and Execute permission.

Hm... that's peculiar and makes me wonder what the difference is between the workstations that are allowed to submit the information to our CGI executable and which aren't. In instances like this, where one machine can but another can't, it usually comes down to a permissions or directory access issue on the web server hosting the CGI executable.

So, in practice, what are the differences between the logons of the 'thick client' that you mentioned and the workstation where the submission isn't being allowed to happen?

There are a few things I'd like to check in the IIS Admin. If you would, open that and select the server object (first item in the left hand tree). On the right hand side, open the Handler Mappings. Once there, right click on CGI-exe and select "Edit Feature Permissions". Is execute checked?

Back in the main server object, if you open the ISAPI and CGI Restrictions, have you added an entry for PageGate's CGI executable (webgate.exe) and allowed it to execute?

Also, does the scripts directory exist as a virtual directory under your default web server?

Hm... this is getting peculiar. If CGI is allowed to execute and you've specified the webgate.exe in the ISAPI and CGI restrictions, IIS has been configured to allow the CGI parameters to be passed through, provided the user doing the submission has sufficient rights to the folder. What's doubly peculiar is that you're not getting a returned error like a 405 or a 1004 or anything, really. That means that the submission isn't actually being allowed to make it to the CGI executable in the first place, that's the only reason you wouldn't get a proper error in return.

So, question is, what's preventing those variables from being submitted? You've mentioned that the domain users group has the read and execute and modify permissions, so that should allow anyone part of that user group to submit the messages. I wonder, though... if you would, add IUSR to the security section of the scripts folder and allow it read and execute and modify as permissions.

When I click send from the web GUI, the server does launch webgate.exe, I can see it pop up in the task manager. At that point webgate.exe quickly ramps to 100% CPU and stays there until I end the task. I've let this go for up to 10 minutes with no change. Meanwhile the browser sits waiting on the server until the task is ended.

After adding IUSR to the scripts folder, the process completes. I get the webpage that says "message accepted", but I don't receive the page or email that should go out for the recipients. These recipients do work as expected from the thick client.