Smart questions
Smart answers
Smart people
Join Tek-Tips Forums

Member Login

Remember Me
Forgot Password?
Join Us!

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips now!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

Join Tek-Tips
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Jobs from Indeed

Link To This Forum!

Partner Button
Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

Web Access - Not working on certain PC's

gillis (IS/IT--Management) (OP)
17 Aug 05 14:46

Some of us routinely access email from remote PC's using web browser.  I can also access the service within LAN by entering the localserverIP/servlet/webacc so no reason to believe the service isn't running properly.

However, on some laptops and even the GM's home desktop the browser eventually times out with "page cannot be displayed".   Others, like myself, routinely use WebAcess without problems.  When working, you get a "redirection" message that resolves to a certificate request prompt.  Selecting Yes to accept brings you to the email login prompt.  On the PC's where it's NOT working, you get the "redirection" message but that's all.  After a time it gives up with page not found.

Since I don't believe it's a server/application problem my question is - what types of issues on the remote PC can prevent it from getting to the GW Web Access application?  Is it possibly firewall or security-related?  Java-related?  I'm at a loss to why some work, some don't.

Thank you for any insight,

MichiganRon (MIS)
17 Aug 05 16:30

It has been my experience that the WebAccess application does not work properly using some web browsers, namely, the AOL web browser. I've also seen the Earthlink browser cause problems.

The first thing I'd have you check is the web browser. Make sure they are using a recent version of either IE or FireFox. If needed, they can start up AOL to get the internet connection, then minimize the AOL interface and use IE.

Hope that helps,

“If you are irritated by every rub, how will you be polished?” ~ Mevlana Rumi

Do you live in Michigan? Join us in the Tek-Tips in Michigan forum.

IRudebwoy (IS/IT--Management)
17 Aug 05 18:19
Make sure a JVM is installed.  I suggest removing M$ JVM and install Sun's.

I get a similar problem when there is no JVM installed or the the JVM is M$.  Make sure the browsers in use support java.

Hope it helps.

## Just because you can do something doesn't mean you should.

Lorenzo Wacondo (System Administrator)

gillis (IS/IT--Management) (OP)
17 Aug 05 19:02
Lorenzo, I suspect it's something like you mention.  Everyone is using the IE browser so I don't believe it's related to that.  However, Sun Java 2 v1.4.2_03 is installed and checked so still stumped.

Jerry Giles
IRudebwoy (IS/IT--Management)
17 Aug 05 23:20
For the users that it doesn't work are they all going through a firewall?

From your post you said it works within the LAN without problems.  Where is the web front end located?  Is it all on the same server on the LAN behind the firewall?

## Just because you can do something doesn't mean you should.

Lorenzo Wacondo (System Administrator)

gillis (IS/IT--Management) (OP)
18 Aug 05 11:14
Sorry to all - new information!  Because I had used it from home just days ago I "assumed" it was working.  I've now tried all laptops here and had folks including myself try from home last night and - it ain't working!!

So scratch my concern that it was "selective".  It isn't working, period!  It was 2-3 days ago and we can't identify what has changed.

Jerry Giles
MichiganRon (MIS)
18 Aug 05 13:44
Can you get to the web server? Try port 8008 (or whatever port you have set up for server management).

If you can get to the web server, try restarting the web access agent.

Also, check to see if your server has abended.


“If you are irritated by every rub, how will you be polished?” ~ Mevlana Rumi

Do you live in Michigan? Join us in the Tek-Tips in Michigan forum.

gillis (IS/IT--Management) (OP)
18 Aug 05 14:30
Ron, no abends - server health is good; I restarted the agent yesterday and it didn't seem to help.   ??

Thanks for the ideas.

michigan (IS/IT--Management)
22 Aug 05 1:18
gillis -
To clarify, you can access the Web Access while you're at work, just not from offsite?

When attempting to access from offsite, did you still receive the redirecting page/certificate?

I would try rebooting the server first.  Just to ensure nothing between Apache/Tomcat/Enterprise Server/WA Agent or other services you have running haven't crapped out in the background w/out an abend.

Good Luck.
gillis (IS/IT--Management) (OP)
22 Aug 05 12:04
Response to clarification -

WebAccess works if you enter it from within the LAN (serverIP/servlet/webacc).   However equivalent external address doesn't work.  

Redirection "message" comes up but never gets to certificate page!


marvhuffaker (MIS)
22 Aug 05 12:19
Is it possible that you are redirecting to either an IP address or DNS name on the inside that is not valid from the outside?

For example, are you going to your Webaccess page like this:

MAIL.DOMAIN.COM... but that same DNS name does not resolve from the outside?

Or..  Your redirect references the server name, not the DNS name?  So from the inside it works fine, but on the outside it tries to do something like: http:\\\Servlet\webacc   OR http:\\SERVERNAME\SERVLET\WEBACC?

That's my guess.  Or if you post your main URL, maybe we could look at it and see right away what's happening.


Marvin Huffaker, MCNE

gillis (IS/IT--Management) (OP)
22 Aug 05 12:41

All addresses, DNS should be fine; the current configuration worked up until last Monday and has worked for a few years.  The redirection is pointing to our external IP and you'll see if show up appropriately.  It just never gets connected for some reason.  I was about ready to reboot server but if that fixes the problem I won't know what was wrong so I've put it off so far.  Will have to do it soon however.

Address is if you'd like to try it.

Thanks again to all for trying.

marvhuffaker (MIS)
23 Aug 05 11:37
Do you have multiple IP addresses on that server? Or how is the IP configured?  I don't get anything when it tries to redirect.

It appears that port 443 is listening, but nothing ever comes back. Maybe your routing isn't working correctly into your network from the outside.

I know you said nothing changed, but something must have.  If webaccess is working internally, then I dont' see how it could be  a server problem.

Marvin Huffaker, MCNE

michigan (IS/IT--Management)
25 Aug 05 1:13
gillis -
Looking up your entry as stated in your earlier post, I discovered the following: MX IN [Preference = 0] MX IN [Preference = 10] NS IN NS IN A IN A IN A IN A IN A IN A IN
((TTL was listed as 10800 for each entry))

I must admit, I'm not the best at analyzing MX/DNS records, but I don't think your first entry should = 0.  I also think there should be something with "" in one of your entries (to resolve).  I looked up a couple accounts that I know use GroupWise Web Access and each had an entry for their name to resolve against.  Again, I could be wrong on this.  Perhaps someone with more experience could offer some feedback with these entries.

Thank you.
gillis (IS/IT--Management) (OP)
25 Aug 05 12:22
In case it helps - internal email is handled locally by the Novell server (

External email (WebAccess) is redirected by the company Isomedia from to our external ip/servlet/webacc

marvhuffaker (MIS)
26 Aug 05 2:21
I didn't see anything in that DNS info that looked wrong..  How is your translation being handled from external to internal. I think that's where your problem is at.  It looks like other ports are being translated okay.. I mean, I can get to your RILO card on its port. But something is wrong with the 443 port.  The port appears to be listening, and I can connect to it, but nothing comes back.


Marvin Huffaker, MCNE

gillis (IS/IT--Management) (OP)
26 Aug 05 12:54
At this point, think I'll just bounce the server and see if things come back.  We may not learn anything but pressure from managers is getting too much to ignore.

Thanks to everyone for your ideas and willingness to assist.  If I figure it out, will post the answer.

gillis (IS/IT--Management) (OP)
26 Aug 05 15:47
Update - server reboot didn't change anything.  I'm absolutely stumped.  We made absolutely no conscious changes to the system; yet, it just up and stopped functioning (externally).  Still works fine if you access from inside the firewall  ?????!?!?!?   

Marvin,  I appreciate your comment re:443 but can't understand how the port can go bad?  From your testing is there any doubt the signal is reaching our router/firewall/server?   i.e., can we rule out a redirection problem at Isomedia and acknowledge the problem to be in-house?

marvhuffaker (MIS)
26 Aug 05 22:04
Ok, I think I may have missed something you said earlier.. And I think I see what is going on, but I need to understand a few things....

What is the public IP address that your GroupWise Webaccess is sitting on?  Where is it related to your GWIA?  To get to Webaccess, your users try to use WEBMAIL.WASHINOMICASIONO.COM?

You have two different things going on:


Is one of these your Webmail's IP address? Which one is correct? Why do you have ISOMEDIA redirect this? Why not just have an A record in DNS for WEBMAIL instead of redirecting?

Honestly, this is very complex and you might need to spend a couple hours with someone just going through all your configurations and making sure all the ducks are in a row. It's difficult to ask all the right questions or provide the right answers for something like this.

Marvin Huffaker, MCNE

gillis (IS/IT--Management) (OP)
27 Aug 05 12:24

public ip is
GWIA is on that ( is Isomedia site where redirection takes place; goes to this address which then redirects to our public ip/servlet/webacc.

redirecting because, frankly, I don't have the in-house knowledge to do what you suggest.  Isomedia hosts our website so had them redirect as well.

You're right about consulting; unfortunately, what happens is our contractor came in and set it up but is not available consistently when we have a problem like this.  I'm considering a support agreement with Novell.

Thanks again,


gillis (IS/IT--Management) (OP)
31 Aug 05 19:30
In case anyone out there is still following this saga, here's an interesting twist!

After Novell convinced me the GW WebAccess application was working fine, I contacted Cisco to see if some problem may have affected our router/firewall system.  During some troubleshooting with them I asked the tech to try our URL so he could see first-hand what happened at the browser level.  He did and - it worked!!!  Tried it a number of times and even had him send me a copy of the TraceRt path (he was in CostaRica) to see if there was some "hop" problem near us.  However, now we've had numerous other folks try it from close and not-so-close geographic proximity and found that some get in, some do not.

The problem simply can't be on our end... we've tried flushing the IE browser cache, disabling popup blocker, etc... but those PC's that couldn't get in, still can't.  Yet for some reason others can.   Mind-boggling!?!?!?!?

michigan (IS/IT--Management)
1 Sep 05 0:25
gillis -
Yeah, I'm still following this.  I've tried a few things to see what I may discover.  I too was able to trace (here in Michigan) just fine:

  1    13 ms    12 ms    11 ms
  2    12 ms    13 ms     *
  3    20 ms    19 ms    19 ms
  4    67 ms    66 ms    66 ms []
  5    72 ms    71 ms    70 ms []
  6    67 ms    67 ms    66 ms []
  7    64 ms    69 ms    67 ms []
  8    79 ms    67 ms    67 ms []
  9    66 ms    66 ms    66 ms []
 10    70 ms    70 ms    68 ms [12.1
 11    70 ms    70 ms    69 ms [216.57.
 12    73 ms    75 ms    74 ms
 13    72 ms    71 ms    71 ms
 14   136 ms   583 ms    91 ms []
Trace complete.

However, walking through a few other attempts this evening I got some very interesting results.  Each time I entered the same IP

1st attempt - just sat there.  No redirection.  Looks like it was trying but no results.
2nd attempt - Again, just sat there.
3rd attempt - This is where it got interesting.  I was redirected, but it wasn't to the typical WebAccess login screen, I was taken to "Welcome Site/Site Administrator" screen.  I saved the screen shots if you'd like them for future reference.  The URL it redirected me to was:

I pretty much stopped at that point.  Please keep us updated.  I'm interested in the fix/resolution for this one.
gillis (IS/IT--Management) (OP)
1 Sep 05 10:54

It's even more interesting - if you can, please just try the DNS name   We now are finding that people can get in once; subsequent attempts sit at the redirection page and don't go to the Certificate splash screen.  Is it possible there's something wrong in the certificate process?

marvhuffaker (MIS)
1 Sep 05 23:15
This is why I think you should get rid of the redirection... That SIte administrator looks like a general page that any of ISOMedia's subscribers would use to login and manage their websites. Which also leads me to believe that their systems are failing, not yours.

All you'd need to do is create an A record and call it whatever you want, and point it to your real IP address. If your company owns the domain, you should be able to manage the DNS records. Or contact your ISP and see if they can help.

Marvin Huffaker, MCNE

michigan (IS/IT--Management)
1 Sep 05 23:41
gillis -
Yeah, I would say anything is possible.  You know, you can disable your Certificate/SSL (only temp) just to see if has something to do with the certificate.  If nothing else, it would rule out that variable.
This TID explains how to do so.  Their scenario & version is a little different but should react the same:

Also, you know how some AOL users can't get WebAccess to load?  Perhaps you try their fix in this situation it may rule out various IP cache variables:
Change the line Security.UseClientIP.enable=true to Security.UseClientIP.enable=false.
Restart the WebAccess and web server.

And lastly, the following TID explains how to reset your WebAccess Timeouts.  Personally, I don't think it's a timeout issue, however the steps involved also clears all WebAccess cache too - I didn't realize old connections (that didn't hit "LogOut") will continue to tax memory on the server -- GWINTER.NLM -- even after they've disconnected.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Back To Forum

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close