Setting up a new App server and SQL server (they are separate boxes), and we continuously got errors when trying to deploy an app with SSRS enabled.
The SSRS system would checkout just fine prior to the deployment, And deployement would be successful. But then checking out SSRS (outside of Epicor) would show it was down.
Microsoft support got involved and they determined the problem was due to the file rssrvpolicy.config getting changed by something during the deployment by EAC. MS said that this file should not be changed by other programs.
If we restore a copy of rssrvpolicy.config from prior to the deployment, then stop and restart Reporting services, SSRS appears to work again.
Anyone every see anything related to this?
(paging @MikeGross - as you said you have lots of experience with SQL deployments)
So i’m looking at my version of the file and all I see that is Epicor related are a number of lines for some function libraries that the Epicor reports use (lines to make sure anyone can use those libraries).
That means that the Appserver creation process inserts/copies those files to the SSRS ReportServer\Bin location and updates that file. So I would reason that the user you are logged in as on the Appserver (whose security context is being used to create the appserver AND manipulate the reportserver) does NOT have the appropriate permissions to modify the Report Server file.
Do you have these two files in this location? If not, I definitely think it’s permissions.
I would also reason that the code behind the SSRS update (as part of the Appserver creation) is lacking some error checking/displaying when individual tasks fail. Like that little pop up window that lists all the things it’s doing and checks them off - I’ve never seen an error message from any of that, and it kind of bothers me that everything works fine all the time
My installation is one server (SQL and SSRS) and another two servers (Appserver for full clients and another appserver for remote/web/CRM app users). I only do installation of SSRS on appserver #1 and I always sign on as a AD Domain Admin (all my servers are in my AD).
Did you create a ReportServer ‘share’ with Everyone = Full Access? (I did, but I forget where I was told to do that)
The user specified on the SSRS tab of the App configuration. Or if configured as below, it would use the user name that I logged into the server with? (or possibly the user that EAC was lanuched with?)
1 & 2 - for me this is always an AD Domain Admin, and always the same (my login, or Administrator)
3 - this user is the user I talked about in my other post - it’s a domain admin as well, but used for all servers, app pools, and inter-application communications where appropriate. This user also has sysadmin role at the SQL Server level of my SQL/SSRS server so it has access to all the data.
4 - yes, I leave this as Windows Auth b/c it uses the AppPool Identity user (as far as I know).
As to be truthful, I’ve never tried to figure out which security context the appserver installation routine uses to write to the Reportserver directory. Seeing your installation screen leads me back to the share I was talking about. In the image for question#4, for “SSRS ReportServer Location” I have “\hostname\ReportServer”
I think my problem comes from my rights being lowered.
When I set up our LProduct APP and SQl servers, I had domain admin rights. But since I’m not part of the IT group, I’ve had them “reduced”. I think I just have Admin rights at the machine levels (would you call that “local admin”?).
Maybe I’ll ask my friend in the IT group to try deploying it and see if he has any better luck.
My problem persists. What I’ve boiled it down to is, that when EAC deploys an App with SSRS enabled, SSRS stops working.
To recap:
App server is on a different box than the SQL server
Both boxes are Windows 2016, SQL 2016 is on the SQL server.
My login has local admin rights on both boxes.
With SSRS working (the Web Portal URL page displays), deploying an App with SSRS enabled will succeed, but causes SSRS to stop working.
Trying to redploy will fail as SSRS is not working (and is one of the first checks during deployment - when SSRS is enabled for the app)
Stopping and Restarting SSRS via the Reporting Services Config Manager(RSCM), does not fix it.
The only way to get SSRS working again is to
Stop SSRS via RSCM
Restore files rssrvpolicy.config and web.config, with backups from prior to deploying
Restart SSRS via RSCM
During the deployment an error is logged in the SQL servers event log. The error detail is:
The description for Event ID 0 from source .NET Runtime cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
ProcessName: ReportingServicesService
So in a nutshell … Deploying an App with SSRS enabled, breaks SSRS.
Hmmm… the “source .Net runtime cannot be found” make me wonder if you have the .Net 4.7.x package installed? (One of those little notes in the install doc that everyone seems to glance over but is required to get the Appserver to install correctly. I think it had to do with the Data Model regen specfically)
Perhaps that is part of the problem. I know it has to be installed on the Appserver, and it’s installed on my SQL/SSRS server… but I’m just grasping at straws.
Also, if your SSRS directory (in the Appserver’s SSRS config tab) is a share on the SSRS server, Local Admin might not be enough. I think the share’s permissions override ‘local admin’ in the case where you are simply accessing files on the share versus logging in.
It is just a guess, but it looks like it was a rights issue for the account used for the Application Pool Username in EAC.
Because I’m required to change password every 90 days, I had to enter another account for the App Pool Username (one that never expired). And even though both my user account and the one used for the App Pool had administrator rights on both the App server and the SQL server, the account used for the App Pool could not access a folder for my user acct, for temporary files.
So I gave full rights to the account used for the app pool, to my users folder on the App server.
And I’m a bit relieved to know I was barking up the right tree (in my first response) with user permissions!! A little validation of troubleshooting prowess is always a good confidence builder.
