404 Error Epicor CRM Mobile App... root cause?

Does anyone know where I can start to troubleshoot issues with mobile CRM?

We installed an SSL Cert (not self signed).

When we go to put the https://domain/(environment) into the CRM mobile app it gives us a 404 error.

When we go to a browser and put in that address it gives us a 403 - Forbidden: Access is denied. message.

On the other hand, if I go to the domain/(environment)/api/help/vi I can get into the Epicor REST API v.1 Help page. Not sure what this means other than REST endpoints are working?

Are there any logs out there that I can dig through for answers?

Anyone else had this happen before?

Thanks in advance for any help. I have been referencing Update/Install guide for 10.2.500.X and the CRM Install guide for 10.2.500.

You’ve got the BAQs installed, Tokens turned on in the Appserver, and the other stuff from the install directions?
Do you have a pinhole in the firewall to allow entry and forwarding to the appserver?
And you’ve got CRM licenses?

It’s been a while since I made this all work, so I’ll think on it some more and let you know.

1 Like

If you don’t you’ll use regular licenses.

I don’t know if it makes a difference, but on my CRM mobile app, I didn’t put the https:// in front of the server. So on mine it’s just server.domain.com/(environment)

If you can reach your api/help/v1 … from the outside, then chances are your firewall is set up correctly. If you can’t, then I’d check that first.

1 Like

Good points Doug, I forgot that about hte licenses… they changed that after the beta program (which we did) so I’m still mentally stuck on the old rules…

And I agree - no need for the https:// on the server string - a very common mistake for first-timers.

1 Like

We can reach it from the outside. Maybe it is just the https://. We have the fall back to regular CRM license tag in the web config per the install guide.

@MikeGross we have the tokens turned on and firewall configured.

Thank you both for your input! I will get back to you about the https://

It was, in fact, the “https://.” I updated Epicor in epiccare so they are aware of the solution. Hopefully the next person who has the same issue can avoid 45 minutes on the phone troubleshooting.

Thank you both!