I am battling with the AFR Viewer at one of our customer sites and hope someone may be able to assist.
I have logged this with Epicor but so far 1st line support could not find the problem.
When I browse to the AFR Viewer URL I get a message that the service is not available. This worked though for a while until an update was loaded on the server where AFR is installed and the server was restarted. The ID of the server changed so I had to get a new license. I am not able to get into the Designer and run reports but the Viewer will not work again.
We have checked the AFR Server URL, SSRS Reports URL, SSRS ReportServer URL which all work. We also double checked the certificate for the AFR Web Site and Service.
There is an Epicor KB (EpicCare Login - EpicCare) for this error but already checked it. I am running AFR 10.2.1 and the KB article is for an earlier edition.
Usually this error appears when the AFR License service ( a service on the server where AFR/SSRS is hosted) is not running or responding. If you’ve restarted the server and still get the message, I’d track down the service and see if it’s running and check the event logs in case it’s getting an error when trying to start.
This version of AFR does not have the license service anymore. We have also checked Event Viewer for errors as well as SSRS logs and IIS logs but nowhere do we even find an error message.
Aye! I forgot the latest version doesn’t have the License Service any longer. Just had to check mine to be sure (We’re at 10.2.1 now)
Given what you’ve said so far, I’m going to say that your Https/Http urls are crossed up somewhere. I recalled having a similar issue when we upgraded about 6 months ago and thought it might have been the service, but now I’m thinking that it’s https. Something about SSRS Configuration/URLs and SSL certs… We couldn’t get HTTPS to work, so we’re still using regular HTTP. But check the areas below and make sure certs/urls/etc. are correct and that you are actually connecting to the correct URL.
We also not using HTTPS for SSRS so there is no SSL cert requirement that end. However I did add HTTPS to SSRS yesterday to test but still no luck. What did happen though is that when I had added the HTTPS protocol and I browsed to https://ssrs_server/reports it gave me the same “Service Unavailable” error. I had to restart the SSRS service then it worked.
So I am wondering that when AFR is trying to redirect/call the SSRS portal/api there is an issue. But I cannot determine what though and I cannot find any error messages to assist either.
I also changed the accounts for the AFR app pools to “AppPoolIdentity” and the SSRS service to “Virtual Service Account” as suggested by Epicor support but this did not work.
After a long evening of trying to remember, here is what I remember. This version uses a method where the installation alters the regular SSRS security by inserting a DLL to ‘handle’ all the requests for reports within the AFR report folders. This is now the ‘license’ server as we remember it. So there is no passing of requests between AFR and SSRS any longer - at least none that we can control. All connections are made through the SSRS url and as long as you are using the correct one, this should work fine.
Other data for you to ponder I may have misquoted earlier regarding SSL/certs as I was looking only at our SSRS config utlitiy.
IIS
Our app pools run with a AD domain user with ‘admin’ level privs called ‘epicorservice’. This makes sure that all access is granted to that user and that all inter-app communications works (and is controllable/stoppable) at the domain level instead o the OS/Service level.
This user also has high level access to both the AFR and Epicor SQL servers/databases.
We have a proper SSL cert (wildcard issued) from DigiCert installed in IIS at the server level.
Both our ARF Service and AFR WebSite IIS Sites use the 443 binding with the above SSL cert.
SSRS (SQL is locally installed)
Our service account is set to ‘virtual service account’
IE/Chrome url will connect using either HTTP or HTTPS - we use https://servername/Reports/browse
IE, if set properly will auto-login using AD creds, but Chrome will ask. You can ‘save’ them of course.
But ONLY the HTTPS will work to return data. The HTTP returns an ‘execution error’ - even though it looks like it’s going to work, it fails when you try to retrieve data.
So if you followed all of that, my IIS is working with SSL/Certs but my SSRS is NOT. Honestly, I’m not sure how this is working but it is. If I recall correctly, you connect to SSRS (via IIS) first, then when you open an AFR report and attempt to execute it, the ‘handler’ steps in and uses IIS/HTTPS to check your license and authentication inside AFR Database.
That’s all I can do for right now. See what you can figure out and let me know if you have more questions - but I think it’s time to enlist Epicor’s support.
Just an update. We busy looking at it with Epicor Support. So far have not found anything but there was an update of AFR for the version I had installed so I upgraded to the latest 2.2 now. It is still not working but Epicor Support said we need to patch SQL as well.
After hours with Epicor Support it seems like there is an issue with Kerberos authentication. The customer needs to register a SPN for the domain user that SSRS is using.
Also support said that we should always create separate SSRS instance for AFR.
(We’re at 10.2.1 now)
I may have misquoted earlier regarding SSL/certs as I was looking only at our SSRS config utlitiy.