Yesterday I upgraded my dev environment from 9.5.5 to 9.5.7. The main upgrade itself went smoothly. I had a WebUI installation on 9.5.5 that was functional before the upgrade. During the upgrade, I had the service turned down as the release notes advised. Post server upgrade, I upgraded the client on the server running WebUI to 9.5.7. The fixlet for database configuration became relevant. I entered the appropriate values and ran the task against the WebUI server successfully. I started the service and waited a while. It came up to the splash screen. A day later it was still at the splash screen. I verified I could access the database from the WebUI server. Rebooted the WebUI server. Waited several hours … still at the splash screen. Anyone else have this experience? This is a relatively small dev environment with 250 computers, so it shouldn’t take super long to initialize the WebUI.
I just found @AlanM advice to check the datasync.log. It has the following error:
bf:datasync:reset:error Error in reset RequestError: The specified schema name “webui” either does not exist or you do not have permission to use it.
The service account I’m using to connect has full DBO rights to the database. Not sure what I’m missing?
Are the rights of this account limited to the schema ‘dbo’ then? WebUI uses a different schema for its tables: ‘webui’, so you’d also need to grant permission for that schema for that account.
So simply being the “Database Owner” (dbo) is not sufficient in terms or rights?
I asked my DBA who said that post-9.5.7 upgrade there are some WebUI tables, but not a WebUI schema per se. The account I’m using is DBO.
I looked again at the WebUI upgrade instructions, but the only thing it mentions is to run the fixlet to add or change database settings (which I’ve done). Did I miss something about updating the database schema somewhere?
This WebUI environment was functional on a remote server on 9.5.5 prior to the upgrade to 9.5.7. Any insights would be appreciated? It feels like there is a missing step in the upgrade instructions.
I have a support ticket in for this too. Biggest thing of note I have found is in prfmgr.log.
Mon, 30 Oct 2017 15:12:06 GMT bf:database:error Error acquiring connection: { [Error: [IBM][CLI Driver] SQL30081N A communication error has been detected. Communication protocol being used: "TCP/IP". Communication API being used: "SOCKETS". Location where the error was detected: "{ip}". Communication function detecting the error: "selectForConnectTimeout". Protocol specific error code(s): "115", "*", "*". SQLSTATE=08001
]
errors: [],
error: '[node-odbc] SQL_ERROR',
message: '[IBM][CLI Driver] SQL30081N A communication error has been detected. Communication protocol being used: "TCP/IP". Communication API being used: "SOCKETS". Location where the error was detected: "{ip}". Communication function detecting the error: "selectForConnectTimeout". Protocol specific error code(s): "115", "*", "*". SQLSTATE=08001\n',
state: '08001' }
Mon, 30 Oct 2017 15:12:06 GMT bf:bfdbpool:error Error: connection is closed in query SELECT * FROM WEBUI_TABLES WHERE name='PRFMGR_PROFILES'Our error in prfmgr.log is a bit different:
bf:bfdbpool:error Failed to query the BigFix database. Failed with error: { [RequestError: Invalid object name 'WEBUI_TABLES'.]
name: 'RequestError',
message: 'Invalid object name \'WEBUI_TABLES\'.'Oh geez, I didn’t know that you guys were posting WebUI related problems inside of the release announcements sub-forum. I kinda stumbled upon this by chance. So we have an internal slack that looks for new webui posts from this area: https://forum.bigfix.com/c/usage-and-config/webui so maybe in the future begin posting there for help on configuring WebUI things?
ANYWAYS…
@JonL if you had WebUI with direct database access working at 9.5.5, it should also work for 9.5.7, given the same database user. The permissions requirements for the database hasn’t changed because of the platform release. I also think that since your environment is only 250 machines, it should be relatively straightforward to do the initialization step. To diagnose further I’d actually like a whole set of logs to figure out what’s going on. It kind of sounds like this needs to turn into a support case.
Logs that you should have on hand are basically everything in the WebUI\logs directory, and the service-wrapper log found in WebUI\service-wrapper.log. Having those on hand or just as part of the trouble ticket helps speed up the remediation process…
@masonje If you’ve filed a support ticket I’m sure I’ll see it soon. I’d also be interested in the other WebUI logs to see if there’s hints there about what’s going on with your environment.
Actually Jon I see your case and the logs now we’ll be taking a look.
Yes, case TS000026536.
On 9.5.5 I was still using ETL. After upgrading to 9.5.7, I ran the database config fixlet. That’s where I ran aground.
Have you been following this thread too? It seems there are several folks with similar issues.
Would you keep us posted once this is resolved? I’m watching closely because I committed to speaking about AutoPatch at THINK and I’m about to apply for CAB approval for the 9.5.7 upgrade so we can get started.
This case remains pending with L3 at IBM.
From L3 today, it appears that some aspect of the DB schema update silently failed. This particular Bigfix instance was upgraded from 9.5.4 (where some aspects of the DB schema remain) to 9.5.5 last spring to 9.5.7 shortly after it was released. The upgrades all appeared to be successful, however they were apparently not fully complete in terms of DB schema.
Normally running the Admin tool does a schema check, updating as necessary. That isn’t properly catching and updating.
If you haven’t upgraded to 9.5.7 yet and care about WebUI, you might consider watching for a resolution to this one. (Otherwise the 9.5.7 upgrade went smoothly for me.)
I recall you:
- Upgraded BES to 9.5.7 on your DEV system
- Ran the DB update fixlet on your WebUI (which was still 9.5.5)
- Ran the 9.5.7 upgrade fixlet on your WebUI
If that is correct, can you say if the WebUI worked correctly after item #1 above?
I ask because we use the WebUI, we are on BES 9.5.5 and we already did the DB update on the WebUI. I had wanted to upgrade BES to 9.5.7 in December (and hadn’t planned the 9.5.7 WebUI update until things looked good).
Unfortunately I didn’t check WebUI at that point. I know that the WebUI update had gathered while it was still on 9.5.5.
There seems to be something missing or down version within the database relating to WebUI. It still isn’t clear if there was a QA gap in the upgrade process or something that is unique to my environment or unique about the specific chronology of events. My case remains at L3.
@AlexaVonTess I’d highly recommend performing your upgrade plan steps on a dev environment first. Hopefully you don’t run into the same issues.
Thanks for the info. We have deployed to DEV and I didn’t have the issue you had (where you’re still getting the splash login screen). Mine actually functioned though the upgrade to the WebUI 9.5.7 kind of hung there.
The 9.5.7 WebUI Service has some extra security on it which it will enable when it starts up for the first time so it may be a bit slower, but the service logs should indicate that it is working.
So a convoluted and embarrassing ending to this issue. It turns out that our dev Bigfix SQL database was migrated to another server. The old server wasn’t turned down, but left running with an old, down-version copy of the database.
For some unknown reason, the trouble-shooting steps our DBA performed were against the old server. We banged our heads why the DB schema was down-level and lacked a WebUI schema! We started thinking unpleasant thoughts that the schema upgrade was silently failing. Fortunately we discovered the database discrepancy and all is well now. 
Thanks for the update! That makes me feel a bit more confident when I upgrade my production from 9.5 to 9.7 (still TBD).