If you are installing a default configuration, Setup must have permission to create a report server database on the SQL Server instance on which you are installing. NET Framework version 2. Report Server Configuration Manager Does not start. Reporting Services PowerShell cmdlets are not available and commands are not recognized. You see an error message indicating the URL is not configured. Setup fails on a computer with SharePoint installed but it is not configured.
SharePoint Central Administration Page is blank. You see an error Message when you try to create a new Report Builder Report. Reporting Services is architected for the SharePoint service architecture.
Troubleshoot Problems with SharePoint Mode installations. Right-click the icon and click Run As Administrator. Run the following three cmdlets from the shell:.
Description: When you try to run a Reporting Services PowerShell cmdlet, you see an error message similar to this one:. Install the first Report Server in SharePoint mode. Use Central Administration to verify and fix one or more of the following issues:. The SSRS service application proxy is not configured. Use the SSRS service application pages to configure the proxy.
The SSRS service application is not mapped to this web application. Workaround: The error message contains three suggested steps to correct this issue. The first suggestion in the message 'A report server URL is not configured. More Information: You will see this error message when attempting to use any of the Reporting Services functionality that requires a connection to the Reporting Services service.
This includes:. Description: If you select to install Reporting Services SharePoint Mode on a computer that has SharePoint installed but SharePoint is not configured, you will see a message similar to the following and setup will stop:.
If SharePoint is not configured, the service installation fails, causing setup to fail. However when you browse to Central Administration, you only see a blank page:. Workaround: This issue is not specific to Reporting Services but is related to the configuration of permissions in your overall SharePoint installation.
Here are some suggestions:. At service startup, the report server checks the database schema version to verify that it matches the server version. If the database schema version is an older version, it is automatically upgraded to the schema version that is required by the report server. Automatic upgrade is especially useful if you restored or attached an older report server database. A message is entered in the report server trace log file indicating that the database schema version was upgraded.
The Reporting Services Configuration Manager upgrades a local or remote report server database when you select an older version to use with a newer report server instance. In this case, you must confirm the upgrade action before it happens. The Reporting Services Configuration Manager no longer provides a separate Upgrade button or upgrade script. Those features are obsolete starting with SQL Server due to the automatic upgrade feature of the Report Server service.
After the schema is updated, you cannot roll back the upgrade to an earlier version. Always back up the report server database in case you need to recreate a previous installation. The schema is upgraded automatically after setup and service startup, or when you select a SQL Server Native mode report server database in the Reporting Services Configuration Manager that is an older version.
In addition, the Report Server service checks the database version at startup. If the report server is connected to a database that is an earlier version, the report server will update the database during startup. Security descriptors are upgraded on first use of the report server database after the schema is updated. Published reports and compiled report snapshots are updated on first use. One additional question I do have, I noticed that most of the "content" database show the same message "Database is up to date, but some sites are not completely upgraded".
Anyone have any idea what Reporting Service installation is doing to the content databases? When I check the detail upgrade status of the databases the "current" and "maximum" versions match. So I'm not sure why it's wanting an upgrade. Simply running the "pgrade-SPContentDatabase" fixes it, but I'm wondering why the installation of Reporting Services is touching the content databases. Or did you schedule downtime.
I need to install Reporting Services and PowerPivot into production and I'm wondering whether I should do this while users are active or not. Those steps work on a clean SSRS install? What about the upgrade? I wouldn't do the upgrade with users online. If the pwoerpivoit install is as complicated as it was on r2 there no way i would do it online. With regards to your comment on a "clean SSRS install". Do you mean an existing farm that does "not" have SSRS installed?
If so, that's what I'm doing. Here is the sequence:. You can ignore this message safely. I've done exactly this without any errors but you need to make sure to export the encryption key. Again, per the code, these databases are not "upgradable", but SharePoint thinks they are which is why we see the status message in "Review database status". Or did you schedule downtime and block access via the load balancers or something similar? We did the installation after-hours, but did not specifically schedule downtime.
Given there should be no downtime you're not recycling Web Application App Pools with this work , I don't see why this couldn't be configured during working hours.
Have you deployed PowerPivot to production as well? If so, did you schedule downtime for that? Did you lock the users out, or did you just schedule downtime and let users know that the solution deployment would cause an IISRESET, but still allow users access. Basically disable the WFE load balancer to stop traffic adding local host entries on each farm member pointing back to one of the WFEs.
Shutdown the farm, snapshot the VMs all farm members are VMs and backup the databases for a recovery point if needed. For our downtime, we simply tell the users when it will be unavailable. If they're doing something and we're forced to do a restore or they're kicked off due to web app resets, etc.
I didn't realize MS doesn't support snapshoting before maintenance. I've not done this in production, but in test I shutdown the farm, snapshot the 4 farm members and then do SQL Server database level snapshots with the farm still down no VM snapshots on the database. I do this to try different scenarios and it works great. Never had a problem restoring the snapshots as long as the farm is shutdown during the snapshot as well as the restore of the snapshots.
So under a restore scenario in production, restoring the content database is very easy, my concern with doing SharePoint maintenance has always been the farm config or some other unrecoverable issue with the farm. It would make for a long night to have to rebuild the farm and remount the restored databases. I'm reasonably new with SharePoint, but it sounds like you have a lot of experience.
Have you ever run into any issues with maintenance or the installation of new features like SSRS or PowerPivot where you had to recover? Sorry for all the questions, but sometimes with SharePoint I feel like I'm deserted island when it comes to figuring out the best practices for this kind of thing.
0コメント