WebUI install not working, no logs

[D.Dean]

I have reached out to our technical contact but I wanted to see if anyone here may have seen this issue.

We are trying to install the WebUI and I ran through all of the requirements, opened firewall ports to both the root server and the DB server. I ensure communication is working, I had the SQL account setup and gathered all of my data to use while running the “Install BigFix WebUI Service (Version 10.0.5)” task

I opened the “Install BigFix WebUI Service (Version 10.0.5)” taskand filled in all of the options, then I executed task. The task completed (success criteria is only success if the WebUI service exists). I checked the client log on the new server and no errors showed there either. There are no WebUI logs being produced.

I have sanitized the logs below to remove sensitive information… (Hostnames and IPs)

 At 13:43:36 -0500 - 
   Successful Synchronization with site 'opsite106' (version 1072944) - 'http://myBFserver.mydomain.com:52311/cgi-bin/bfgather.exe/opsite106'
At 13:43:58 -0500 - 
   DownloadsAvailable: checking for 'http://172.1.2.3:52311/bfmirror/downloads/1322976/0'
   DownloadsAvailable: true (action id 1322976)
At 13:44:00 -0500 - 
   DownloadsAvailable: checking for 'http://172.1.2.3:52311/bfmirror/downloads/1322976/0'
   DownloadsAvailable: true (action id 1322976)
   ActionLogMessage: (action:1322976) Non-Distributed - DownloadsAvailable
   ActionLogMessage: (action:1322976) Submitting download request
   ActionLogMessage: (action:1322976) Download url: 'http://software.bigfix.com/download/bes/100/BigFix-BES-WebUI-10.0.5.50.exe'
At 13:44:37 -0500 - 
   ActionLogMessage: (action:1322976) Action signature verified for Execution
   ActionLogMessage: (action:1322976) starting action
At 13:44:37 -0500 - actionsite (http://myBFserver.mydomain.com:52311/cgi-bin/bfgather.exe/actionsite)
   Command succeeded parameter (action:1322976)
   Command succeeded parameter (action:1322976)
   Command succeeded (evaluated true) continue if (action:1322976)
   Command succeeded (evaluated true) continue if (action:1322976)
   Command succeeded (evaluated true) continue if (action:1322976)
   Command succeeded parameter (action:1322976)
   Command succeeded delete (action:1322976)
   Command succeeded delete (action:1322976)
   Command succeeded parameter (action:1322976)
   Command succeeded parameter (action:1322976)
   Command succeeded parameter (action:1322976)
   Command succeeded parameter (action:1322976)
   Command succeeded folder delete (action:1322976)
   Command succeeded folder create (action:1322976)
   Command succeeded appendfile (action:1322976)
   Command succeeded (file created) appendfile (action:1322976)
   Command succeeded appendfile (action:1322976)
   Command succeeded move (action:1322976)
   Command succeeded (file created) appendfile (action:1322976)
   Command succeeded appendfile (action:1322976)
   Command succeeded move (action:1322976)
   Command succeeded (file created) appendfile (action:1322976)
   Command succeeded appendfile (action:1322976)
   Command succeeded move (action:1322976)
   Command succeeded (Prefetch download manager collected file) prefetch (action:1322976)
   Command started - wait (action:1322976)
At 13:44:40 -0500 - BES Support (http://sync.bigfix.com/cgi-bin/bfgather/bessupport)
   Fixed - Remove WebUI Service (fixlet:2557)
At 13:44:50 -0500 - 
   Report posted successfully
At 13:44:54 -0500 - actionsite (http://myBFserver.mydomain.com:52311/cgi-bin/bfgather.exe/actionsite)
   Command succeeded (Exit Code=0) wait (action:1322976)
   Command succeeded folder delete (action:1322976)
   Command succeeded parameter (action:1322976)
   Command succeeded (evaluated true) continue if (action:1322976)
At 13:44:54 -0500 - BES Support (http://sync.bigfix.com/cgi-bin/bfgather/bessupport)
   Fixed - Install BigFix WebUI Service (Version 10.0.5) (fixlet:5037)
At 13:44:54 -0500 - 
   ActionLogMessage: (action:1322976) ending action
At 13:44:54 -0500 - mailboxsite (http://myBFserver.mydomain.com:52311/cgi-bin/bfgather.exe/mailboxsite546292934)
   Not Relevant - Install BigFix WebUI Service (Version 10.0.5) (fixlet:1322976)
At 13:46:00 -0500 - 
   Report posted successfully
At 13:47:37 -0500 - 

Event Viewer

Without a log to refer to I am not sure where to look next.

Any suggestions?

[RhondaSTK_HCL]

This sounds like something for which opening a case with our Support teams might be the best option, though I’m sure many of our community have run into it before.

Rhonda Studnick Kaiser - Director, Customer Experience

[menglish66]

Try running 2687 “Deploy/Update WebUI Database Configuration” and see if that fixes the issue.

[D.Dean]

I have reached out to Kathy N and she is going to setup a call to look at it. If we don’t make progress, I will get a ticket open.

I would like to get it fixed soon but we are in a change freeze so if a change is needed, we would need to wait.

[D.Dean]

Is it safe to assume that if this fixlet is not applicable to anything, therein lies the problem?

That fixlet has several relevance statements for server, client, service and registration versions greater than 9.5, which all of them are 10.0.5

That leaves …

exists setting "_WebUIAppEnv_WebUI_DIR" whose(exists folder(value of it))of client

and

(value of key "version" of json of file "package.json" of folders "datasync-app" of folders whose (name of it starts with "WebUI Data Sync") of folder (value of setting "_WebUIAppEnv_WORK_DIR" of client)) as string >= version "1.0"

I will look into those.

[menglish66]

If you’re trying to reconfig/reinstall using the fixlet, just wipe out the relevance and replace with true.

[JasonWalker]

For the earlier question of “where to look next”, basically here’s the order of operations -

1. Check whether the “BES WebUI” service exists and whether it starts successfully.

2. Check the service_wrapper.log beneath the “BES WebUI” directory. The Service_Wrapper.log is the first log that WebUI writes. The Service Wrapper is responsible for gathering WebUI sites from the root server, if there are database connection errors (to BFEnterprise) or failures authenticating to the root server or gathering sites, those should be reflected here.

3. Check the logs beneath “BES WebUI\WebUI\logs”. These logs are generated by the Node.JS servers that make up WebUI. They won’t be written until Service_Wrapper successfully launches Node.JS. The most likely places to find errors affecting WebUI startup would be in service-app.log or datasync.log

What to look at next depends a lot upon what’s found in those logs.

Also check whether the WebUI ports are open.
netstat -anob
This will show listening ports and the executable & PID that has the port open. By default WebUI uses port 443 for its web interface, but also uses a number of ports for the various Node.JS services - I believe by default ports in the range of 5000 - 5100 are listed for potential use, in practical terms I usually see 5000 - 5030 or so depending upon how many WebUI apps are actually enabled. (These are used in a Loopback fashion, they don’t need to be accessible outside of the WebUI host itself, so no firewall rules needed for them.)

Check whether there is another application listening on any of those ports. I recall the Nutanix Guest Additions, if this is a Nutanix VM, tends to use port 5000 and in that case we would need to move WebUI’s port range. WebUI would be using these ports as “node.exe”.

[D.Dean]

with that I was able to find the error. First, there are no logs under the log folder.
The Service Wrapper tells me it can’t reach the the root server.

– [WebUI] Failed to retrieve all sites info from Root Server: HTTP Error 28: Timeout was reached: Connection timeout after 10000 ms

The WebUI server is a remote server requiring routing and firewall changes.

So let me ask about API. Does it use the Web Reports Port? Another Port?

During all of the changes I had opened 52311 between the new (WebUI) server and the root server
Opened the DB ports (1433) between the WebUI server and the Database Server (Not the same as the root server)
Looking at my change for the access to web reports, I didnt realize it was rejected due to the change freeze so I will have to do that later but the WebUI install instructions make it appear as if it is required but then it says it will only prevent some sites from loading…

https://help.hcltechsw.com/bigfix/9.5/webui/WebUI/Admin_Guide/c_deployment_requirements.html

BigFix Web Reports must be installed, running, and reachable via the REST API. If that prerequisite is not met, the WebUI will not be able to load some WebUI sites and applications such as Query and Profile, and Patch Policies or services like the Send Notification will not be available. Even when the BigFix Web Reports is installed on a remote server, and the datasource configured after the WebUI was started, these applications will not be available until the WebUI server is restarted.

If the REST API is the issue, I just need to know if it uses the Web Reports Port.

Currently, nothing is listening on 443 or 80 and there is something listening on 5001, 5002, 5005 and 5006, looks like a Palo Alto Traps App cyserver.exe

[itsmpro92]

Seems like Palo Alto is on 50,001 rather than 5,001 - yes?

[D.Dean]

good eye, you are correct

[D.Dean]

Looks like REST API uses the BigFix port assigned, We use the default, 52311

So it not being able to connect is a mystery.

[JasonWalker]

There’s actually another API port from the Root Server that is used only by WebUI. Port 52315/tcp by default. That should be opened to allow connections from WebUI to the Root Server.

[JasonWalker]

I actually had a little difficulty finding the reference to this as well. I would have expected it listed in the “Deployment Requirements” link at https://help.hcltechsw.com/bigfix/10.0/webui/WebUI/Admin_Guide/c_deployment_requirements.html , but it’s actually listed a few steps farther along in the “Installation Procedure” at
https://help.hcltechsw.com/bigfix/10.0/webui/WebUI/Admin_Guide/c_before_running_fixlet_2556___i.html

Also, as far as I know, WebUI doesn’t contact Web Reports directly. Like other API connections for /api/query, it’s sent to the Root Server (on port 52315 in the case of WebUI) and from there it is proxied to the Web Reports service. This means Web Reports needs to be online and accessible from the Root Server, not from WebUI. If Web Reports cannot be reached (by the root), WebUI will not load the apps from the LifeCycle entitlement - “Query” and “Profile” for example - but the other WebUI apps should load regardless of Web Reports.

[D.Dean]

Going to have to put this on hold for a couple weeks because I now have a couple of change controls to execute and we are in a change control freeze until 2023.

I am gong to have all the changes occurring at the same time so I can have a wiggle room to get this working.

Thanks for everyone’s help. I will update once the change is executed.