BES Server Upgrade quirk with Web Reports previously removed

Just wanted to report a quirk in case it’s helpful to anyone.

Several months ago, I migrated my BESWebReports off of my BES Root Servers and onto new dedicated hosts. After installing Web Reports on the new hosts and verifying them, I stopped and disable the BESWebReports service and detached the BESReporting SQL database. I didn’t see a way to uninstall Web Reports without uninstalling the root server.

When I upgraded to 9.5.6 this morning, the server upgrade initially failed citing a failed login to the BESReporting database. This is before the option is presented for which server components to upgrade.

I had to reattach the BESReporting SQL database in order to get the server installer to continue past this point. During the server installation, I selected the BES Root Server to upgrade, and deselected BES Web Reports. After the upgrade, the BES Admin Tool reports that Web Reports does not appear to be installed, so I think that’s cleared up the reference to Web Reports.

After the upgrade, I again detached the BESReporting database and manually uninstalled the Web Reports service using ‘sc delete BESWebReportsServer’. Hopefully the next upgrade won’t try to touch the BESReporting database, but this time I’m keeping the detached database files around so I won’t have to restore them from backup next time.

@JasonWalker

You may want to rethink the complete removal of BESWebReports from your root BES server. While we have a stand-alone WebReports server for our users, our root BES server still has the BESWebReports service running for REST API integrations. The instance on our root BES server is locked down to service accounts only.

Something to note, when you have multiple instances of WebReports in an environment, it’s likely that it’ll be necessary to reorder the dbo.aggregatedby table in the BFENT database so that REST invokes the BESWebReports instance on your root BES server vs. forwarding to the remote, stand-alone instance (PMR#44654,082,000 & RFE#107992).

Hope this helps.
—Casey