So I wrote this little thing which does the same check as Epicor does for ssrs.
Unzip and run it
CheckSSRS.exe http://<tld>/Reports
What do you get? I’m assuming the same exception as before, run it from both inside the server and your work-station. Do you get different results?
Here’s the source code if you don’t trust my magic exe that will totally not mine bitcoins in your powerful servers 
I was literally just thinking that hacking your github/nuget/dropboz/discourse etc would be a way easier vector than getting a bunch of computers
It does indeed return the identical error.
I’ve got a case open, first thing Epicor asked was for screenshots of SQL and SSRS versions. It might actually be a dumb mistake like that.
My SQL configuration manager is 2017, and SSRS is 2016; but I see in SSMS that the node is version 13 - does that mean it’s actually the 2016 version?
I guess that will have to be step one, even if only to rule it out 
- can’t believe I missed that
What account are you using to run the installer? Is it a Domain account? or a Local Account?
What happens if you visit
http://<tld>/Reports/api/v2.0/Reports
If you are using a local admin account (not an AD) account. (Either way actually)
Open up Reporting Services Configuration
Click This Guy
Click Settings → Site Settings
Security
Add both your domain account and or your local account (if using one) for the installer. This is the account that you are physically logged in with to the server not the one that will run the AppPool.
Make them both System Administrators. I believe to reference a local account you can use .\localAcctUser
Then restart SSRS Configuration Services.
And try again.
I had this problem a couple of weeks back.
I contacted support and they said it was proberbly due to running an unsupported version of reporting server ( I think it was 2016).
Wiped the server installed SQL 2019 and RS 2019 and it worked.
Domain account, member of admins group on this and all machines
with /ReportServer/api etc, same as before. With /Reports/api etc, a 404 page
Don’t have a local account, but added myself explicitly.
Still get a 404 from your tool; but I’ll try deploying again.
Edit YOUR tool, not YOU tool - come back, come back!
Wait okay if you visit that URL above it should actually respond with a list of reports, if you are having 404 there then perhaps the issue goes deeper. You may indeed be in the wrong version of SSRS, they didn’t add REST until 2017
I can’t believe I missed this… must have pencil-whipped it in the upgrade guide.
We installed 2017 on both our Dev and Prod boxes this year but I guess installation doth not an upgrade make? I don’t know - I guess I will do some reading tonight.
Thanks a million for your support.
SSRS is separate from SQL as of ~2016
So just because you upgraded SQL doesn’t mean you upgraded SSRS, you need to download / install SSRS 2017 and that should / could / would fix your issues me hopes.
I’m not sure if the stack is going to be the issue. I’m having the exact same issue as you and I have a fresh Windows Server 2019 with SQL 2019 installation.
Edit: In my case it ended up being the silliest thing. Right-click and run the administration console as administrator and the report URL not valid issue went away.
I’m almost pleased to report that didn’t work for me. I’m in the process of upgrading SQL server already… can’t wait to hear if your users can only “print as administrator”
(Joking. Maybe. Hopefully.)
But thanks - that’s good to know.
At first just upgrading ssrs didn’t work.
So I tried to update SQL server but it failed because we had a standard license and I didn’t realize it; apparently 2016 std to 2017 dev isn’t ok.
I will get a license tomorrow, but in the meantime, I love it when I’ve got to the slash-and-burn stage because I’ve already broken everything so Ima havfto rebuild. So I uninstalled SSRS and removed its DBs, and reinstalled. It created itself a new instance called SSRS which appeared in the scale-out list alongside MSSQLSERVER. I deleted MSSQLSERVER and restarted, and now deploying the appserver works with SSRS.
I’ll still upgrade because W2016/SQL 2016 isn’t supported, but you were right - this will at least keep me working.
I am running SSRS on 2019 just fine.
The problem folks are having is that Epicor will bind to 443 and 80 and then they also try on a DEV BOX Bind SSRS to 80 or 443.
The best way is, if you have everything on a single-box just Bind SSRS to 127.0.0.1 and your Epicor to 192 ip or the hostname.
Interestingly, in the end this didn’t work. I wish I had captured the error because a week has flashed past and I don’t remember, but basically using SSRS 2017 with SQL 2016 was something I couldn’t make work. In the end I stripped out everything and installed SQL 2017, re-installed SSRS 2017, and everything seems ok. I still haven’t figured out windows auth but that’ll be another thread another day. Taking a week off to chop wood and carry water, or something
Thanks for this thread @SteveFossey. I had a similar problem today. Now I know I’m not crazy; just wrong.
Out of curiosity, anyone know what the new Web Portal setting is for in Epicor? I’ve used it outside of Epicor to edit reports; it’s a nice interface.
