You suppose they pass a header in the request from the Client that’s missing from the web page?
Yes. The help files don’t work unless called by the client. Even hosting your help files, loading them with a browser gives you a notice that it can’t run.
The 10.2.600 Help URL works again for me.
Did you ever figure this out @MikeGross? I’m getting the same thing that you are, and it doesn’t matter which URL I put in there. It’s the same 403 -forbidden message that I get no matter what.
@Banderson for help use
https://help.epicor.com/102300/
https://help.epicor.com/102400/
https://help.epicor.com/102500/
https://help.epicor.com/102600/
https://help.epicor.com/102700/
Yeah, I tried. For some reason I always get this error. It seems to only be my computer though. It works fine for other people in my company.
You might need to go to Control Panel and clear any saved credentials for
https://help.epicor.com/102500/
If you launch IE 11 and go to the url manually I wonder if you get the same error… Your IE may also be going through a Proxy or something… Hard to tell unless you install Fiddler and trace the Request it does behind the scenes.
@Banderson - nope. still a problem. Just checked again… and it’s just my computer - same user, logged on to a different computer is fine. Tried default browser, trusted sites, allowed content settings in Edge, and anything else I could find…
I’ve been out of town, so I’ll reach out to Support when I get back next week…
Run tracert help.epicor.com
on your computer, and again on one that help works on. To see if they’re taking different routes.
Drastically different routes. I don’t really know what I’m looking at, but they diverge, and then start timing out on the computer that it doesn’t work on. On the good computer, it’s exactly the same if I run it twice. 7 hops.
EDIT they are actually the same. I switched around epicor and help, so I was looking at epicor.help.com on one and help.epicor.com on another.
We have Help installed on our App server(\App01), so I did some tests.
tl;dr: No definitive findings. Just that it really wants the help to be run from the client. And very odd that the Epicor hosted help server seems to know the difference between requests from my laptop, vs ones from the workstation on our LAN.
Some definitions:
- App01 - the box running E10.2.300. Help is installed on this, but the E10 Apps are set to use the Epicor URL (https://help.epicor.102300)
- WS - A remote “worktstation” (actually its a WinServer 2016 VM box not acting as a server). This is on the same network as App01. Client for E10.2.300 is installed on the WS.
- HL - Home laptop that I use to connect to WS01. No E10 client installed on laptop, nor a VPN connection to work LAN.
- Help URL - Epicor hosted help for 10.2.300 (https://help.epicor.102300)
-
RDC’d into WS, launched a browser (IE 11), no E10 clients running
a. Help URL yields a 403 Error (the following is the IE11 generated page)
.
b. Help URL with/Help_NoAccess.htm
yields:
.
c. Help URL with/update.txt
yields:
.
d. Help URL with/Web.Config
yields a server generated version of a 403 error.
-
On Home Laptop, launched Chrome
a. Help URL yields a 403 Error (the server generated format)
b. Help URL with/Help_NoAccess.htm
yields a 403 Error (the server generated format)
c. Help URL with/update.txt
yields a 403 Error (the server generated format)
-
On WS
a. Browsed to hosted help URLhttp://App01/UAT_102300-Help
, got server generated 403 msg
b. Browsed to hosted help URL with/update.txt
and got:
On WS, trying URL https://help.epicor.com/102300/enu/Standard/
redirects to
https://epicor-help-prod-102300-westus2.azurewebsites.net/enu/Standard/
And gives the “Unable to Load Online Help” page (similar to /Help_NoAccess.htm
)
trying the.../enu/Standard/
on my home laptop yields no re-direction. Just the server generated 403 page.
One last thing, the Help URL (adjusted for version) with /update.txt
returns the following:
.../102300/update.txt
→ Mon 01/28/2019
.../102400/update.txt
→ Fri 05/10/2019
.../102500/update.txt
→ Sat 02/01/2020
.../102600/update.txt
→ Wed 12/16/2020
.../102700/update.txt
→ Tue 12/15/2020
@ckrusen - Yep similar results here. Looks like the Help servers are behind a load balancer or some other device blocking the tracert ping packets so it never reached its destination address.
@Banderson - I tried the server and my laptop (both on the VPN and not on the VPN) and still get the same traceroute path until it times out, but it still works from the server and not my laptop.
Thanks to both of you (and @hkeric.wci) for the ideas. I’ll put the ticket in with support on Monday and @Banderson you can I can double up on them
Happy New Year guys!!
also @Banderson
FYI - I have an open case on this as well: CS0002365922
Nothing helpful so far from support, but they asked for my config file today.
To the 403 Access Denied Error… I remember once on a Shopfloor IE would show 403 Access Denied… but when I right click on IE and did Run As Another User… it worked fine… almost as if IE is trying to pass thru your SSO Credentials. Thats why I can only think to clear temp-files and any saved passwords, cookies…
As for Self Hosted make sure IIS_IUSR or whatever the group is has access to your IIS AppPool
Update on this.
I opened up internet explorer (like the old crappy one) and cleared the cookies out of there. That fixed it for me. To find that out we used fiddler to see which browser it was using. (why it took us so long to figure out?? I don’t know)
open Internet Explorer
Go to Internet Options
Click Delete
Check Everything Except the First Option
Click Delete at the Bottom
Close IE, Close Epicor Completely and try agani.
none of them working for me
Try Jose’s suggestion.
It might be a “permanent redirection” issue. A web server can redirect your request in a couple of ways. One of them is with a permanent redirct. This tells your browser what the redirected URL, and instructs your browser to use that in the future.
For examlpe,
- The published URL is
example.com/v1.html
. - The server has a permanent redirct of
v1.html
tov2.html
. - Your browser requests v1.html and the server supplies v2.html (even though it displays v1.html), and tells browser to use v2 in the future.
- The next time v1 is needed, the browser knows to ask for v2, saving the server from having to do the redirect.
Redirection info would be saved in the browsers cache. This could exain why different users see different results. Some might have the redirect “stuck” in their cache.