IBM BigFix Version 9.5. WebUI Administrators Guide IBM

Transcription

1 IBM BigFix Version 9.5 WebUI Administrators Guide IBM

2

3 IBM BigFix Version 9.5 WebUI Administrators Guide IBM

4 Note Before using this information and the product it supports, read the information in Notices on page 63. This edition applies to version 9, release 5, modification level 5 of IBM BigFix and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright IBM Corporation US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

5 Contents Chapter 1. Introduction WebUI Audience Chapter 2. Deployment Requirements.. 3 Requirements Overview Hardware Requirements Disk Space Network Port Conflicts Microsoft Hotfix KB Chapter 3. WebUI Installation Install the WebUI Service Requirements Installation Checklist Remove the WebUI Service Change Ports Renew WebUI Certificates SSL Certificates Enable the WebUI (Platform V9.2.6 V9.5.2) Change Communication Ports SSL Certificates (Platform V9.2.6 V9.5.2) Send Notifications Access the WebUI Chapter 4. Provisioning Users Permission Effects in the WebUI Permissions for Executive Dashboard and Dashboard Editing Tools Permissions for BigFix Query Setting WebUI Permissions Chapter 5. Managing Application Updates Chapter 6. Editing Dashboards General Editing Techniques Working with Predefined Tiles Working With Custom Tiles Create a Key Numbers Tile Create a Summary Tile Create a List Tile Create a Checks Tile Create a Chart Tile Chapter 7. Performance Operator Performance Slow Filters Concurrence Administrator Performance Operator Shaping Environment Upgrades ETL Performance Chapter 8. Log Locations Chapter 9. WebUI Server Settings Access WebUI Server Settings Server Settings Definitions Chapter 10. SAML Chapter 11. WebUI and Distributed Server Architecture (DSA) Chapter 12. Supported Patch Sites Appendix. Support Notices Trademarks Terms and conditions for product documentation.. 66 Copyright IBM Corp iii

6 iv IBM BigFix: WebUI Administrators Guide

7 Chapter 1. Introduction WebUI Audience Welcome to the IBM BigFix WebUI Administrators Guide. This document is intended for IBM BigFix Master Operators who administer an IBM BigFix deployment. If you are a non-master Operator who does not have administration rights, or if you are looking for information about using the WebUI, see the IBM BigFix WebUI User's Guide. The web-based BigFix WebUI harnesses the flexibility and power of IBM BigFix. Using a browser, operators can log in to the WebUI and manage endpoints. The WebUI augments the IBM BigFix Console but does not replace it. BigFix WebUI components include Custom Content, Patch, Query, and Software Distribution. Use of the WebUI might not be suitable for all deployments. Some customers use both the WebUI and the Console to complete different BigFix tasks. The BigFix WebUI is a component of the IBM BigFix Platform; no separate executable file is required. All WebUI administration tasks are completed by using the BigFix Console. The WebUI is not intended for all IBM BigFix deployments, and is not currently as scalable as a traditional IBM BigFix deployment. Currently, the WebUI has the following upper use limits: v 30 concurrent users. v 60,000 managed endpoints. While nothing prevents the use of the WebUI in larger deployments, there might be significant impact to performance. For more information, see Chapter 7, Performance, on page 45. Copyright IBM Corp

8 2 IBM BigFix: WebUI Administrators Guide

9 Chapter 2. Deployment Requirements Requirements Overview Prepare your production environment for BigFix WebUI; before you deploy it certain requirements must be met. When your environment is ready the WebUI can be enabled. The WebUI is a component of a standard IBM BigFix deployment. Therefore, the primary step in WebUI enablement is the installation of the IBM BigFix platform. For detailed information on installing IBM BigFix, see the IBM BigFix Installation Guide. The BigFix WebUI is a component of a standard IBM BigFix installation from version onward. Environments that run version or later contain the software components that are required to enable the WebUI. The required hardware, software, and environment settings are summarized here, more detailed descriptions follow: v IBM BigFix or later. For detailed production environment requirements and installation procedures, see the IBM BigFix Installation Guide. If you are already running a previous version of IBM BigFix, upgrading to is sufficient. v The WebUI is accessed through a number of supported internet browsers: Internet Explorer 10 or later, Microsoft Edge, Firefox, updated to the latest version. Safari, updated to the latest version. Chrome, updated to the latest version. v Minimum screen resolution of 1024x768. v Minimum disk space of 50 GB. v A network port must be open for WebUI communication; the default port is 80 and 443 for HTTP and HTTPS. For more information, see Network Port Conflicts on page 4. v Microsoft Hotfix KB applied to Windows Server 2008 R2, if applicable. v Signed SSL Certificates (optional) ensure secure communication with your WebUI deployment. For more information, see SSL Certificates (Platform V9.2.6 V9.5.2) on page 14. System requirements for using the Executive Dashboard and dashboard editing tools: v BigFix version and later. v The WebUI enabled in your environment. System requirements for using BigFix Query: v BigFix version 9.5 Patch 2. v The WebUI enabled in your environment. v Web Reports enabled in your environment. v A licence for IBM BigFix Lifecycle, or IBM BigFix Security and Compliance. v To process BigFix Query requests, targeted clients must have: Copyright IBM Corp

10 Hardware Requirements The ability to receive UDP notifications. BigFix v 9.5 Patch 2 or later installed. v BigFix v 9.5 Patch 2 or later must be installed on all targeted clients and intermediate relays. The WebUI operates as part of a standard IBM BigFix deployment. However, additional hardware resources are required to power the WebUI. Baseline hardware requirements for an IBM BigFix deployment are described in the IBM BigFix Installation Guide. The WebUI requires more CPU and memory, and the amount varies depending on the number of concurrent users: Table 1. Additional Resources for WebUI Function Additional CPUs Additional Memory in GB WebUI Baseline Per 10 Concurrent Users (Linux) Per 10 Concurrent Users (Windows) For example, a Linux environment designed for 30 concurrent WebUI users requires 10 CPUs and 10 GBs of memory in addition to the baseline requirements. Disk Space Network Port Conflicts The amount of disk space that is required on your server is highly dependent on your deployment size. For deployments up to 60,000 managed endpoints, the recommended free disk space is 50 GB. Solid state drives are highly recommended. Traditional magnetic drives can be used, but performance is greatly degraded due to the heavy reliance on ETL procedures. IBM BigFix WebUI is set to communicate on ports 80 and 443, for HTTP and HTTPS, by default. However, these network ports can be set to any value during WebUI enablement. It is critical that the chosen ports remain open and not reserved for other applications within your environment. A possible conflict can arise between WebUI and the Web Reports component of IBM BigFix. Web Reports defaults to port 80 in IBM BigFix version X and earlier. As of release Web Reports defaults to port 8080 to avoid conflict with WebUI. When upgrading an existing deployment to or later, the port used for Web Reports is not changed. Therefore, it is possible to run a fully updated deployment while still encountering a port conflict. During WebUI installation any port conflict with Web Reports is detected and the option to change the Web Reports port is provided. For more information, see Enable the WebUI (Platform V9.2.6 V9.5.2) on page 10 and Change Communication Ports on page IBM BigFix: WebUI Administrators Guide

11 Microsoft Hotfix KB Windows Server 2008 R2 contains a bug related to kernel socket leaks. If your primary server is on this operating system the bug must be patched to avoid long-term issues related to WebUI. This hotfix must be applied to Windows Server 2008 R2 or the WebUI cannot be enabled. The only way to apply this Microsoft Hotfix is through direct download from Microsoft. To read more about the hotfix and download it, see If you have enabled WebUI on an IBM BigFix server running Windows Server 2008 R2, you must patch that computer with Microsoft Hotfix KB If KB is not applied you might see socket errors after some time has passed. After the WebUI has been enabled, you can quickly check your server's compliance: 1. From the IBM BigFix Console, navigate to BigFix Management > BES Component Management > WebUI, or locate Fixlet 2251 by your preferred means. 2. If Fixlet 2251 is relevant, you have a computer that matches all of these criteria: v v v WebUI is enabled, The operating system is Windows Server 2008 R2, and KB is NOT applied. 3. If Fixlet 2251 is relevant, the issue is not resolved. If Fixlet 2251 is not relevant, your WebUI deployment is properly patched. Note: Because the WebUI enablement Fixlet requires the hotfix to be applied to relevant servers, it is unlikely that the hotfix Fixlet will be relevant. This can occur, however, if the WebUI was manually enabled, which is not recommended. Chapter 2. Deployment Requirements 5

12 6 IBM BigFix: WebUI Administrators Guide

13 Chapter 3. WebUI Installation Install the WebUI Service Starting with BigFix Platform version 9.5.3, the WebUI is a separate service that can be started, stopped, and restarted independently of the BigFix Server. It can now be installed on the BigFix server or on a remote machine. Note: WebUI services installed by earlier versions of the BigFix Platform do not work on V Customers upgrading to V9.5.3 from an earlier version must reinstall the WebUI with the V9.5.3-specific installation Fixlet. Following installation, your pre-v9.5.3 data will be available when the first ETL process completes. Use the installation procedure that meets your requirements: v To run the WebUI on Platform V9.5.3, for example, to install the WebUI service on a remote machine, use the procedure Install the WebUI Service. v To use the WebUI on BigFix Platform versions , use Enable the WebUI (Platform V9.2.6 V9.5.2) on page 10. v To use the WebUI in SAML-Only mode, use Enabling the WebUI in SAML-Only Mode on page 55. Use this procedure to install the WebUI on Platform V Starting with V9.5.3 the WebUI is a separate service that can be started, stopped, and restarted independently of the BigFix Server. Installing on a remote endpoint can free up storage and processing resources on the BigFix Server. Requirements To install the WebUI service: v Customers upgrading to V9.5.3 from an earlier version of the Platform must run the V9.5.3-specific WebUI installation Fixlet. v If you are installing the WebUI service on a remote server, the operating system on the BigFix server and the remote server must be the same. Either: Windows Server 2008 (64 bit) or later, or Red Hat Linux 6 or 7 (64 bit). v If you are installing the WebUI service on a remote machine, that machine must be running thev9.5.3 BigFix Agent before you deploy the installation Fixlet. Using a BigFix relay as the remote server is recommended. Installation Checklist Before you run the V9.5.3 installation Fixlet, Install IBM BigFix WebUI Service (Version 9.5.3): v Have the host name or IP address of the target WebUI server ready. v The default installation directories are: On Windows machines: C:\Program Files (x86)\bigfix Enterprise\BES WebUI Copyright IBM Corp

14 On Red Hat Linux machines: /var/opt/beswebui and /opt/beswebui v If you are not using the defaults have the target drive and directory ready. On Windows systems the specified targets are created automatically. On Red Hat Linux systems: 1. Create the target drive and directory. 2. Symlink the default directory to the target directory. v If you are not using the default, have the database directory name ready. Specify it using the absolute path. The default database directory for Windows machines is: C:\Program Files (x86)\bigfix Enterprise\BES WebUI\WebUI\ETL The default database directory for Red Hat Linux machines is: /var/opt/beswebui/webui/etl v Verify that the WebUI ports you want to use are available on the target machine. The default HTTP redirect port is 80. The default HTTPS port is 443. v Port on the root server is used to allow communication between the root server and the WebUI. All network firewalls between the two machines must allow use of port as well. v For SAML to work correctly when you are installing the WeBUI on a separate remote server, you must set the _WebUI_AppServer_Hostname key of the BigFix server computer to the hostname of the computer where the WebUI is installed. When you are ready, deploy the Fixlet Install IBM BigFix WebUI Service (Version 9.5.3). Post-Installation Notes: 8 IBM BigFix: WebUI Administrators Guide

15 v If the Fixlet fails, revoke the certificates that it generates and sends to the target machine. v If the Fixlet is successful, port on the root server is used to allow communication between the root server and the WebUI. All network firewalls between the two machines must also allow use of port v The installation Fixlet does not remove anything from the BigFix server. Node executable files, log files, and site directories will remain, though node processes will no longer be running. If you are installing on the BigFix Server, it will move the webui.db and the WebUI sites directory. v Start, stop, and restart the WebUI process on a remote machine using services.msc on Windows, or through the terminal in Red Hat Linux. If stopped, the Fixlet BES WebUI Service not Started can also be used to start the WebUI. Remove the WebUI Service Customers on BigFix platform version or later can run Fixlet Remove WebUI Service to remove the WebUI from the BigFix Server or a remote machine. The server instance, including client settings, the ETL directory, and the working WebUI directory will be removed. Change Ports On BigFix Platform V9.5.3 and above use the Fixlet Change Ports for WebUI Service and Web Reports to change the communication ports on either the BigFix server or a remote machine. Use the Fixlet description to enter the port numbers you want to use. Renew WebUI Certificates On BigFix platform V9.5.3 or later use Fixlet 2558 Rotate WebUI Certificate, to generate new certificates. To revoke a certificate, use the BESAdmin tool on the root server. v Windows deployment BESAdmin.exe /revokewebuicredentials /sitepvklocation:<pvklocation> /sitepvkpassword:<pvkpassword> /hostname:<hostname> v Linux deployment./besadmin.sh -revokewebuicredentials -hostname=<hostname_of_the_instance> -sitepvklocation=<pvk_loc> -sitepvkpassword=<pvk_password> For more information about the BESAdmin tool see: support/knowledgecenter/ss63nw_9.2.0/com.ibm.tem.doc_9.2/platform/adm/ c_additional_besadmin_onwindows.html SSL Certificates Secure Sockets Layer certificates enable secure communication with your IBM BigFix WebUI deployment. Use this procedure to deploy WebUI SSL certificates for BigFix platform V9.5.3 or later. SSL certificates, signed by a licensed certificate authority, can be uploaded to your BigFix WebUI Server. This provides secure communication and is highly Chapter 3. WebUI Installation 9

16 recommended, however signed certificates are not a requirement. If signed certificates are not used, communication within your deployment will be insecure unless other measures are taken, such as limiting it to local access or VPN access. Signed SSL certificates can be obtained from an authorized certificate authority. To deploy SSL certificates: 1. Copy the ssl.crt and ssl.pvk files provided by your CA to the following location on your WebUI server: v v Windows Deployment \\Program Files (x86)\bigfix Enterprise\BES WebUI\WebUI\ Linux Deployment //var/opt/beswebui/webui/ 2. Restart the BESWebUI service. Enable the WebUI (Platform V9.2.6 V9.5.2) Use the procedures in this section to run the WebUI on Platform versions In these versions, the WebUI is an embedded Platform component. Starting with v9.5.3 the WebUI is a separate service that can be started, stopped, and restarted independently of the BigFix Server. Use the enablement Fixlets to turn on the WebUI. The Fixlets check for potential WebUI and Web Report port conflicts and provide an easy way to change them if necessary. Extra security can be implemented in the form of SSL certificates To enable the WebUI and select its communication port: 1. In the BigFix console, navigate to BigFix Management > BES Component Management > WebUI. Three WebUI enablement Fixlets are available: v Fixlet Change Ports for WebUI and Web Reports v Fixlet Hotfix for KB v Fixlet Enable WebUI 10 IBM BigFix: WebUI Administrators Guide

17 1. Select Fixlet 2252 and view the Description tab of the Fixlet. Here you can select the HTTP and HTTPS ports that are assigned to the WebUI. The defaults are ports 80, and 443. Chapter 3. WebUI Installation 11

18 1. Run Fixlet 2252 by selecting Take Action and choosing your primary IBM BigFix Server as its target. Fixlet 2252 checks for a port conflict with Web Reports, if Web Reports is present. If a conflict is found an error message displays, and the Fixlet stops. Note: You cannot determine the target of Fixlet 2252 until you select it. Therefore, if you have multiple IBM BigFix Servers in your environment, Fixlet 2252 may not report a port conflict when one does exist with one of your individual IBM BigFix Servers. If so, Fixlet 2250 will fail, and you will need to select a different port, as described in the following step. This situation can be resolved later, as described in 12 IBM BigFix: WebUI Administrators Guide

19 Change Communication Ports. In addition, it is important to remember other applications in your deployment, unrelated to IBM BigFix, can cause a conflict. Note: The WebUI enablement Fixlet checks for the presence of Microsoft Hotfix KB if your server runs Windows Server 2008 R2. For more information, see Microsoft Hotfix KB on page 5. If your WebUI deployment is properly patched the Fixlet will not be relevant. 1. If a port conflict with Web Reports is detected, run Fixlet 2252 again and choose a different port for WebUI. Even if you plan to change either the Web Reports or WebUI ports, you must choose a non-conflicting port to enable the WebUI. For more information, see Change Communication Ports. 2. After the Fixlet has completed by restarting the BesRootServer, WebUI is enabled. To confirm, navigate to All Content > WebUI Apps. If the WebUI Apps menu item is not present, enablement has failed and Fixlet 2252 should be run again. There may be a small delay between enablement and the menu item displaying depending on your deployment. Change Communication Ports BigFix Management Fixlet 2250 allows the communication ports for WebUI and Web Reports to be changed. If either WebUI or Web Reports is enabled in your environment, you might want to change their communication port. As of IBM BigFix release 9.2.5, Web Reports defaults to port 8080 while the default port for WebUI is 80 for HTTP and 443 for HTTPS. However, in previous versions of IBM BigFix, Web Reports defaulted to port 80. If left unchanged, this might create a conflict during WebUI enablement.. This issue is resolved during WebUI enablement as described in Enable the WebUI (Platform V9.2.6 V9.5.2) on page 10. After the WebUI is enabled, the ports that are defined for WebUI and Web Reports can be changed using Fixlet Chapter 3. WebUI Installation 13

20 Use Fixlet 2250 as needed in your deployment. Use the Fixlet description to enter the wanted port numbers. If Web Reports is not present on your primary root server, the option to change its ports is not provided. This Fixlet restarts the BesRootServer to apply port changes. SSL Certificates (Platform V9.2.6 V9.5.2) Secure Sockets Layer certificates enable secure communication with your IBM BigFix WebUI deployment. SSL certificates, signed by a licensed certificate authority, can be uploaded to your IBM BigFix Server. This provides secure communication and is highly recommended, however signed certificates are not a requirement. If signed certificates are not used communication within your deployment will be insecure unless other measures are taken, such as limiting to local access or VPN access. Signed SSL certificates can be obtained from an authorized certificate authority. To deploy SSL certificates: 1. Copy the ssl.crt and ssl.pvk files provided by your CA to the following location on your IBM BigFix server: v v Windows Deployment \\Program Files (x86)\bigfix Enterprise\BES Server\WebUI\ Linux Deployment //var/opt/besserver/webui/ 2. Restart the BESRootServer service. 14 IBM BigFix: WebUI Administrators Guide

21 Send Notifications Access the WebUI Use the BigFix Send Notifications service to trigger an alert when a deployment completes on all targets, or fails on a specified number of devices. To use this feature the notification service and the WebUI service must be co-located on the same host. In other words, the notification service does not work on BigFix installations where the WebUI is installed on a remote machine. Send Notification will not appear as an option on the deployment configuration page. To use the Send Notification feature: v The Send Notifications service and the WebUI service must be co-located on the same host. v An operator's Custom Content permission must be set to Yes. v An operator's Can Create Actions permission must be set to Yes. For instructions on enabling the notification service, see the IBM BigFix Configuration Guide. To read more about permissions, see Permission Effects in the WebUI on page 17. After the WebUI is enabled it will initialize and perform its first ETL. This process might take several minutes, but it can take up to 3 hours: it is highly dependent upon your deployment size. The WebUI is not accessible until initialization is complete. To access the WebUI from a web browser, navigate to: <http_or_https>://<ip_or_fqdn>:<port_if_not_80/443> If the WebUI has initialized and is ready for use you are presented with the login prompt: If the initialization takes a long time in your deployment, it might be possible to resolve the WebUI URL before you can log in. In this case you are presented with the following message: Chapter 3. WebUI Installation 15

22 16 IBM BigFix: WebUI Administrators Guide

23 Chapter 4. Provisioning Users WebUI permissions control the options and functions an operator sees in the WebUI. For example, you can make the Patch and Software applications available on the Content menu, but hide the Custom and Query applications. WebUI permissions also control the appearance of the Overview and other pages. For example, the Patch Summary tile does not appear to operators who lack access to the Patch application. WebUI permissions also control access to the WebUI log-in page. BigFix permissions provide another layer of access control. For example, the data an operator sees in the WebUI, and the ability to act on that data (beyond simply viewing it) is controlled by their BigFix permissions. An operator's site, device, and role assignments, and the ability to see actions initiated by others all play a role. For more information about: v BigFix permissions, including the difference between explicit and effective permissions, see Permission Effects in the WebUI. v setting BigFix permissions, see the BigFix Configuration Guide. v managing operators and roles, see the BigFix Console Operator's Guide. Permission Effects in the WebUI Permission-related behavior works the same way in the WebUI as it does in the BigFix console. v Master Operators have full access to all WebUI elements and controls. v Operators that are restricted to a specific type of content or set of devices in the console have the same restrictions in the WebUI. For example, an operator who cannot patch Linux computers in the console cannot patch them using the WebUI. v The ability to view information in the WebUI does not imply permission to act on it. For example, access to the WebUI's Software application does not permit an operator who cannot create actions to deploy software. Access to the WebUI's Custom application does not permit an operator to create custom content. Deployment data is visible to all WebUI operators regardless of content type or source. For example, operators can see all the patches that have been deployed to an endpoint whether they have permission to patch, or not. Again, the ability to view this information does not imply permission to act on it, for example, to stop a deployment in progress. Explicit and Effective Permissions BigFix and WebUI permissions can be granted directly or indirectly. Permissions that are granted directly to an operator are explicit permissions; permissions that are granted indirectly, for example, through a role, to one or more operators are effective permissions. Both types are shown for each operator and role. Copyright IBM Corp

24 Effective permissions can also be granted using the WebUI's Enable For All Operators check box. When granted using this method the descriptor Allowed, in the Effective Permissions column becomes Allowed (Global). Conflicts can arise between an operator's explicit and effective permissions. For example, access to the Patch application can be disabled for Operator A, but enabled for a role to which Operator A is assigned. When this occurs BigFix applies the least restrictive of the two settings. And the result is shown in the Effective Permission column. Explicit and Effective permission values convey information about how and where permission was granted. When there is a conflict, check the Effective Permission column for the true state of the permissions. Table 2. Explicit and Effective Permissions Explicit Permission Setting Yes Granted to operator. Yes Granted to operator through a role. Yes Enable for All Operators box checked. No Disabled for operator. No Disabled for assigned role. No Enable for All Operators box clear. Effective Permission Yes No 18 IBM BigFix: WebUI Administrators Guide

25 Table 2. Explicit and Effective Permissions (continued) Explicit Permission Setting Yes Granted to operator. No Disabled for assigned role. No Enable for All Operators box clear. No Disabled for operator. Yes Granted to operator through a role. No Enable for All Operators box clear. No Disabled for operator. No Disabled for assigned role. Yes Enable for All Operators box checked. Effective Permission Yes Yes Yes Create Actions Privilege An operator whose Can Create Actions permission is set to No is not allowed to deploy content, though they can still see deployments made by others. You can use this function to grant a form of read-only access to an operator or role. To set Create Action permissions to No: 1. Go to All Content > Operators > Details or All Content > Roles > Details. 2. Scroll down to the Permissions pane and set Can Create Actions to No. 3. Click Save Changes. Send Notification Option The Send Notification option allows WebUI operators to send an alert to one or more recipients when a BigFix deployment completes or fails. To use this option several controls must be in place: v The operator's Custom Content permission must be set to Yes. Chapter 4. Provisioning Users 19

26 v The operator's Can Create Actions permission must be set to Yes. v The BigFix Send Notifications service must be enabled. For more information about the Send Notification option, see the WebUI Users Guide. Permissions for Executive Dashboard and Dashboard Editing Tools All BigFix users can see the BigFix Overview and Executive Overview dashboards, but only master operators can edit them. Master operators see the Edit Dashboard button at the top of their dashboards, non-master operators do not. Master operators see all dashboard elements and data. Users who do not have permission to use a WebUI component do not see data that is related to that component on their dashboard. For example, a non-master operator who does not have access to the Software component do not see information that is related to software packages. Operators that are limited to a specific set of devices see device totals that reflect their device assignments. For example, their dashboard totals will be different than totals for master operators, and might include zeros. Permissions for BigFix Query Access to BigFix Query is controlled in the same way as access to other WebUI applications, as described in Permission Effects in the WebUI on page 17. Operators who have access to BigFix Query can: v See the Query menu item in the Content menu. v See the Query button on the Overview and Device document pages. v Access the Query landing page directly by using the URL. Master Operators can use the BigFix Console to do the following tasks: v Set the Custom Content permission to assign Content Creator privileges. v Set the Can Submit Queries permission to specify which operators can run queries. v Create custom sites to share queries. v Assign operator permissions to access the content of a custom site. Can Submit Queries Permission The Can Submit Queries permission is an operator-specific or role-specific setting. It controls whether an Operator's request can be submitted to the REST API that supports queries. Because processes other than the BigFix Query also submit such requests, a REST-specific setting for operators is used. This is how the Can Submit Queries permission works: v When Can Submit Queries is set to Yes an Operator who submits a query can receive results. v When Can Submit Queries is set to No an Operator who submits a query does not receive results. Instead the error message is displayed: The logged in user is not allowed to submit queries. 20 IBM BigFix: WebUI Administrators Guide

27 For more information about configuring BigFix Query optional settings and using its REST API s, see Getting client information using BigFix Query in the BigFix Platform Configuration Guide. Administrators might be interested in learning how to set query time-out limits for Master Operators and Non-Master Operators. Custom Content Permission From BigFix Query Release 2 onwards, and depending on the value assigned to the Custom Content permission, the following types of Non-Master Operator can access the BigFix Query: Content Creators They are Non-Master Operators for which the Custom Content permission is set to Yes. A Content Creator can: v Create query categories. Categories are used to group queries. v Load sample queries. v Create custom queries. Queries must be saved in at least one category. v Create or edit parameters in custom queries. v Edit the following query information: Title of the query, which is not case-sensitive. Categories and the site to which the query is saved. Description of the query. Relevance expression. Operators They are Non-Master Operators for which the Custom Content permission is set to No. Operators can select and run queries belonging to custom sites that they are allowed to access. They can: : v Filter queries by categories. v Search queries by title. v View the descriptions of a query and edit the value of the parameters. Operators use parameters to assign a value to a variable in the query when the query is run. Values assigned to parameters at runtime are not persistent. v Select the target devices where to run the query. Targets can be individual devices, manual groups or dynamic groups. v Run the query and see the results, if Can Submit Queries is set to Yes. v Save the query results to a file. Operators cannot: v See the Relevance expression specified in the query. v Save, delete or edit a query. For more information about how to set the Custom Content permission, see Adding Local Operators. Chapter 4. Provisioning Users 21

28 Setting WebUI Permissions Permissions for the different WebUI applications can be granted or disabled independently. You can prevent access to the WebUI entirely by disabling access to its log in screen. To summarize, use: v All Content > WebUI Apps to manage access to WebUI applications for operators and roles. v All Content > Operators > WebUI to manage operator access to WebUI applications. v All Content > Operators > Details to manage operator access to the WebUI log-in page. v All Content > Roles > WebUI to manage role access to WebUI applications. v All Content > Roles > Details to manage role access to the WebUI log-in page. Set WebUI Permissions: WebUI Apps Screen Use All Content > WebUI Apps to set WebUI permissions for operators and roles. Use the Enable for All Operators check box to grant application access to all operators with one click. 1. Select a WebUI application in the top pane. 2. Select the Operator or Role tab in the lower pane. 3. Select an operator (or role). 4. Click Allow or None to grant or disable access. 22 IBM BigFix: WebUI Administrators Guide

29 5. Click Save Changes. Set WebUI Permissions: Operators Screen To grant or remove access to WebUI components for an operator: 1. Go to All Content > Operators > WebUI Apps tab. 2. Select an operator. 3. Select a WebUI application. 4. Click the Allow or None to grant or disable access. 5. Click Save Changes. Set WebUI Permissions: Roles Screen To grant or remove access to WebUI components for a role: 1. Go to All Content > Operators > WebUI Apps tab. 2. Select a role. 3. Select a WebUI application. 4. Click the Allow or None to grant or disable access. 5. Click Save Changes. Disable Log-in Access to the WebUI You can completely disable WebUI access for an operator or role by turning off access to the log-in page. This option rejects a user s log-in credentials. To grant or remove WebUI login access for an operator: 1. Go to All Content > Operators > Details tab. 2. Scroll down to Interface Login Privileges. 3. Set Can Use WebUI to Yes or No. Chapter 4. Provisioning Users 23

30 4. Click Save Changes. To grant or remove WebUI login access for a role: 1. Go to All Content > Roles > Details tab. 2. Scroll down to Interface Login Privileges. 3. Set Can Use WebUI to Yes or No. 4. Click Save Changes. 24 IBM BigFix: WebUI Administrators Guide

31 Chapter 5. Managing Application Updates Use the Application Update Manager to view and apply available updates to WebUI applications. Use the AutoUpdate feature to automatically gather and apply new versions of WebUI applications as they become available. When AutoUpdate is On, use the AutoUpdateDelay setting to control the timing of automatic updates. Set them to install immediately, or delay auto updates for up to 30 days. Reasons to delay might include: v Scheduling an update for off-peak hours. v Providing time to update a procedure that will change as a result of new features. v Trying a new version of an application on a test deployment before updating a production system. v Staying on a specific WebUI version for a period of time. AutoUpdate defaults to On at WebUI installation, and AutoUpdateDelay defaults to 0 days. To update WebUI applications manually, turn the AutoUpdate feature to Off. Use the Update Manager to install an update at any time, whether AutoUpdate is running or not. WebUI services remain available during updates. The Application Update Manager Use the Update Manager to view and apply available updates, and to see which versions are currently running. Click the Settings icon on the navigation bar to open the Update Manager. Only Master Operators see this icon. To install an update: 1. Click Select to display a confirmation dialog that shows the version you will be running following the update. 2. Click Update Now to complete the operation, or Cancel to return to the Update Manager. Copyright IBM Corp

32 Note that while you can update an application to a newer version, you cannot roll back to an earlier version. When you run an update, the release you selected and all the updates preceding it are applied. In other words, selecting an update installs all the updates up to, but not beyond, the indicated point in time. The number following the release date shows the number of updates included in that release. Internal dependency checks prevent you from updating an application that depends on a version of another application that is not yet available. For example, you cannot install a version of the WebUI Patch application that depends on features in the Common Application that have not yet been released. The application version number is shown for each update, and reflects the application site. For example, the Patch application resides in the WebUI Patch site, the Custom Content application resides in the WebUI Custom site, and so on. The WebUI application itself, which includes the Common application, the ETL application, and the Login application, resides in the Common site. The Update Manager application resides in the Application Administration site. Notes v If AutoUpdate is On and the delay period is set to zero, the number of available updates in the Update Manager will also be zero, because new updates are automatically applied. v If AutoUpdate is On and the delay period set to 30 days, the number of available updates will extend back 30 days, because updates older than 30 days have been applied. v If AutoUpdate is Off, the number of available updates will extend back in time for an indefinite period. AutoUpdate and AutoUpdateDelay Use the BigFix Console to adjust the AutoUpdate and AutoUpdateDelay settings on the computer where the WebUI service is installed. Note: The first time that you change the AutoUpdate and AutoUpdateDelay defaults following installation of the WebUI, you will be adding the client settings specified below, not updating them. To add a setting for the first time, in Step 3 of 26 IBM BigFix: WebUI Administrators Guide

33 the procedure select Add Computer Setting, rather than Edit Computer Settings, and enter the required setting name and value. Make subsequent adjustments to the AutoUpdate and AutoUpdateDelay settings using the Edit Computer Setting option. 1. On the BigFix Console, select Computers. 2. Right-click the WebUI server (either the BigFix server, or a remote machine). 3. Select Edit Computer Settings. 4. Select the setting that you want to change. v v For AutoUpdate, select _WebUIAppEnv_APP_UPDATE_ENABLE_AUTO. When set to 1, WebUI applications automatically update to the most recent versions in the Pending Sites cache. When set to 0, AutoUpdate is Off. For AutoUpdateDelay, select_webuiappenv_app_update_delay_days. Enter the number of days to wait between updates. The Delay range is 0-30 days; the default is 0 days. Disaster Recovery If it is important in your environment to be able to quickly restore specific versions of your WebUI applications after a system crash, schedule regular backups of the Sites and Pending Sites folders, located in the WebUI folder on your WebUI server. The Sites folder stores the versions of the WebUI applications you are currently running. The Pending Sites folder (within the Sites folder) stores the versions that have become available but have not yet been installed. v To restore your system using backups, drop the backed up files into the Sites and Pending Sites folders. v To use the latest versions of the WebUI applications following a crash, restart the WebUI server. v To generate a list of the most recent versions of each application you were using before the crash, check the dashboard variable using the Relevance statement: shared variable ( WebUIAppAdmin, Current_Sites ) Should the backups become unavailable, contact Technical Support; they will be able to provide additional options. Chapter 5. Managing Application Updates 27

34 28 IBM BigFix: WebUI Administrators Guide

35 Chapter 6. Editing Dashboards Use the WebUI s new editing tools to customize the WebUI Overview and Executive Overview dashboards. Extract and present BigFix data in an array of formats to summarize key information from across your enterprise. Drag tiles to arrange them, and preview dashboard designs as you build. Draw from a library of pre-defined tiles, or design your own. Pre-defined tiles include Environment Overview, Patch Compliance, Patch Severity, New Releases, and Deployments in the last 30 Days. While the WebUI s default overview tiles are useful to many users, the custom tiles enable you to place critical information specific to your own deployment on the WebUI and Executive overviews. Use the five custom tile types to design and build your own tiles: Key Numbers, Summaries, Lists, Checks, and Charts. Copyright IBM Corp

36 General Editing Techniques All users can see and use the WebUI dashboards, but only Master Operators can edit them. Changes made to either dashboard become the default design for that overview for all users. Dashboard elements and data are adjusted to reflect the BigFix permission levels and assignments of Non-Master Operators. Four screens are involved in editing and building tiles: v Edit Dashboard - Arrange, delete, and add tiles. v Select Tile - Select pre-defined tiles and custom tile templates. v Build Tile - Select top-level data objects, arrange tile elements, and preview designs. v Define Filters - Refine tile data and perform complex joins. To edit a dashboard, click the Edit Dashboard button. Use the Edit Dashboard page to: v Add and delete tiles. v Reposition tiles on the page. v Turn the Tile Performance Monitor message on and off. 30 IBM BigFix: WebUI Administrators Guide

37 The WebUI's Tile Performance Monitor displays a message across dashboard tiles that load slowly. ( The filters used in this tile took over 10 seconds to load... ). Use the Performance Monitor switch to turn off the message, or turn it back on. To delete a tile, click the X in the upper right corner. To reposition a tile, drag it to a new location. To add a tile: 1. Click the Add Tile button. Place up to six tiles on a dashboard. To add a tile to a dashboard that already has six, delete one first. 2. Select a tile from one of the tile libraries. Working with Predefined Tiles v v To add a custom tile, click the Add Custom Tiles bar. For instructions on building custom tiles, see Working With Custom Tiles on page 34. To add a predefined tile, click the Add From Tile Library bar. Select a tile and drag it to the required location. For a description of each tile and its elements, see Working with Predefined Tiles. The tiles on the WebUI's default dashboards can be used in any combination. To add a predefined tile to a dashboard: 1. Click the Edit Dashboard button. 2. On the Edit Dashboard page, click Add Tile. 3. On the Select Tile page, click Add From Tile Library. 4. Click a tile to add it. The new tile is placed on the page below any existing tiles. 5. Drag tiles to arrange them on the page. 6. Click the Save button in the upper right corner of the page or Cancel to exit without making changes. Chapter 6. Editing Dashboards 31

38 32 IBM BigFix: WebUI Administrators Guide

39 Note: In larger deployments, the Patch Compliance tile can be slow to load. If your deployment has over 10,000 endpoints, you might experience dashboard delays in loading data with this tile. Administrators building dashboards may want to refrain from using this tile. Chapter 6. Editing Dashboards 33

40 Working With Custom Tiles Use the Build Tile and Define Filters screens to create five types of custom tiles. The basic process for creating custom tiles is described here, and instructions for creating each type follow. v Key Number v Summary v List v Check v Chart 34 IBM BigFix: WebUI Administrators Guide Select a custom tile from the Edit Dashboard page to display the Build Tile page.

41 1. Entering a title for the tile. The Preview area on the right side of the page shows the tile-in-progress. 2. Select a BigFix object from the Build Tile drop-down list: v v v v v Devices Deployments Packages (Software) Patches Tasks (Custom Content) 3. Click Add Item to display the Define Filters page. 4. Use the Define Filters screen to select object-specific conditions and values. v v To display a value for every instance of a top-level object (ALL devices), click the Add button, next to Back, at the lower left corner of the page. To further refine the filter, for example, to return Devices with critical patches, click Add Condition and Add Value. The process of building filters is described below. Chapter 6. Editing Dashboards 35

42 Working with conditions (object properties) and their values on a tile is analogous to working with filters on WebUI list screens. In the diagram below, the image on the left shows a patch list filtered to show critical patches. On the right, the same operation is shown on the Define Filter page. Patch is the top-level object. Severity is the condition (object property), and Critical is the Severity value. The next example illustrates the use of multiple filters. On the left: critical patches with 10 or more vulnerable devices on Windows machines. On the right: the same operation in a tile filter. On a tile, you can display data based on more than one high-level object by using a complex filter. (List filters don't perform this type of operation.) Complex filters appear at the end of an object's Condition list. 36 IBM BigFix: WebUI Administrators Guide

43 The complex filters for each object: v Devices: Deployments, Applicable Tasks, Applicable Packages, Relevant Patches. v Deployments: Targeted Devices, Source Tasks, Source Packages, Source Patches. v Packages (Software): Deployments, Targeted Devices. v Patches: Deployments, Vulnerable Devices. v Tasks (Custom Content): Deployments, Targeted Devices. In a complex filter the condition box is nested inside the top-level object. A basic understanding of how complex filters are processed will help you use them effectively. 1. A query is performed on each top-level object: some combination of Devices, Patches, Software Packages, Tasks, and Deployments. Every instance of each condition specified is found. 2. A set intersection on the results of both queries is created using an identifier common to both, and the results are returned to you. For example, a complex filter that involves devices, creates a list of Device IDs that meet the conditions specified for each object. The set of Device IDs common to both lists is returned. Examples of efficient complex filters include: v How many Windows 7 machines are vulnerable to the critical patches released by Microsoft in the last 5 days? Chapter 6. Editing Dashboards 37

44 v How many actions has the operator Dexter taken against devices in the device group Watson in the last 10 days? v How many Adobe software package installations failed between May 1, 2016 and May 31, 2016?" Tile Editing Tips v On the Build Tile page, drag a line item to change its order in the Items list. Click the X to delete it. v Click the pencil icon to edit a line item. v The Define Filters page prevents you from accidentally selecting the same condition twice (they are inactive in subsequent drop-down lists). v Tile results that are derived from complex filters are not clickable (hyper-linked to related data). v Filters that are concise and limited in scope run more efficiently. Broad, general filters that return large data sets take longer and use more resources. Performance is not static, and various factors can influence it, including hardware changes, changes in the number of endpoints, and the amount of data an operator has access to. v If a complex filter returns unexpected results, check for: An empty set. If one of the filters returns 0 (for example, because you did not specify a condition), any intersection with that set will also return 0. A very large set. If one of the filters returns every instance in the set, for example, all devices that have an applicable patch, the results will contain all instances. While accurate, they might be so broad as to be meaningless. 38 IBM BigFix: WebUI Administrators Guide

45 Create a Key Numbers Tile To create a key numbers tile: 1. From the Overview page, select Edit Dashboard > Add Tile > Add Custom Tiles. 2. Select List. 3. Enter a name for your tile. 4. Select an item (BigFix object) from the drop-down list, and click Add Item. 5. Enter a description for this line item on the tile. 6. Specify data conditions and values (filter criteria). a. Click Add Condition. 1) Select a condition from the drop-down list. 2) Select a condition value. Click Add Value again to further refine your conditions. 3) Use the Add Condition and Add Value buttons to specify more conditions as required. b. To include every instance of an object (for example, ALL Software Packages), proceed to Step Click Add to add this line item to your tile and return to the Build Tile page. Or click Back to exit without saving. 8. Repeat Steps 4 7 to create up to five more line items for the tile. Check the Preview pane to see how your tile looks as you build. Drag and drop line items to rearrange them, or click the X to delete a line item. 9. Click Done. On the Edit Dashboard page, move the new tile to the place you want it on the dashboard. Chapter 6. Editing Dashboards 39

46 Create a Summary Tile To create a summary tile: 1. From the Overview page, select Edit Dashboard > Add Tile > Add Custom Tiles. 2. Select Summary. 3. Enter a name for your tile. 4. Select an item (BigFix object) from the drop-down list, and click Add Item. 5. Enter a description for this line item on the tile. 6. Specify data conditions and values (filter criteria). a. Click Add Condition. 1) Select a condition from the drop-down list. 2) Select a condition value. Click Add Value again to further refine your conditions. 3) Use the Add Condition and Add Value buttons to specify more conditions as required. b. To include every instance of an object (for example, ALL Software Packages), proceed to Step Click Add to add this line item to your tile and return to the Build Tile page. Or click Back to exit without saving. 8. Repeat Steps 4 7 to create up to five more line items for the tile. Check the Preview pane to see how your tile looks as you build. Drag and drop line items to rearrange them, or click the X to delete a line item. 9. Define a summary for the tile. Using the drop-down lists, select two line items to express one as a percentage of the other. For example, a percentage of all devices with patches that are critical. Enter a description for your summary. 10. Click Done. On the Edit Dashboard page, move the new tile to the place you want it on the dashboard. 40 IBM BigFix: WebUI Administrators Guide

47 Create a List Tile To create a list tile: 1. From the Overview page, select Edit Dashboard > Add Tile > Add Custom Tiles. 2. Select List. 3. Enter a name for your tile. 4. Select an item (BigFix object) from the drop-down list, and click Add Item. 5. Enter a description for the list. 6. Specify data conditions and values (filter criteria). a. Click Add Condition. 1) Select a condition from the drop-down list. 2) Select a condition value. Click Add Value again to further refine your conditions. 3) Use the Add Condition and Add Value buttons to specify more conditions as required. b. To include every instance of an object (for example, ALL Software Packages), proceed to Step In the field Sort the list by, select a sort option. 8. Click Add to add the list to your tile and return to the Build Tile page. Or click Back to exit without saving. 9. Repeat Steps 4 8 to create more lists for this tile as required. To preview a tile with multiple lists, use the button in the Preview pane to select the list you want to see. A similar control is used to select between multiple lists in the completed tile. 10. Click Done. On the Edit Dashboard page, move the new tile to the place you want it on the dashboard. Chapter 6. Editing Dashboards 41

48 Create a Checks Tile Use this tile to track device compliance for specific patches and custom content (tasks and baselines). Percentages for each bar are calculated by dividing the number of unique non-relevant devices by the total number of devices. The tile total is calculated by dividing the number of unique non-relevant devices by the total number of devices for all line items on the tile. For example, in the sample tile pictured, 20% of all devices are compliant with Fixlets A, B, and C. To create a checks tile: 1. From the Overview page, select Edit Dashboard > Add Tile > Add Custom Tiles. 2. Select Checks. 3. Enter a name for your tile. 4. Select Patches or Custom Items from the drop-down list, and click Add Item. 5. Enter a label for this line item on the tile. 6. Select a compliance threshold value for this item. Expressed as a percentage, compliance rates equal to or above the threshold are shown on the tile in blue. Compliance rates below the threshold value are shown on the tile in red. The default is 80 percent. 7. Hover the mouse over a patch or task name to display the Select button. Click Select to add a compliance line item to the tile. To find a specific patch, task, or baseline, enter its name in the Search box. Click a name in the list to open its document in a separate browser window. 8. Repeat Steps 4 7 to add up to 5 more compliance line items to the tile. Check the Preview pane to see check tile design as you work. On the Build Tile page, drag compliance line items to arrange them, or click the X to delete a line item. 9. Click Done. On the Edit Dashboard page, move the new tile to the place you want it on the dashboard. 42 IBM BigFix: WebUI Administrators Guide

49 Create a Chart Tile When you work with bar charts on the Define Filters page, start by gathering the data for your chart by using the Add Condition and Add Value buttons. Then, use the fields in the Set Bars pane to visually represent the components of that data. The Create chart bars based on field prevents you from inadvertently duplicating the conditions used in the filter by disabling them in the drop-down list. To create a bar chart: 1. From the Overview page, select Edit Dashboard > Add Tile > Add Custom Tiles. 2. Select Chart. 3. Enter a name for your tile. 4. Select an item (BigFix object) from the drop-down list, and click Set Bars. 5. Specify the data conditions and values (filter criteria) for the chart. a. Click Add Condition. 1) Select a condition from the drop-down list. 2) Select a condition value. Click Add Value again to further refine your conditions. 3) Use the Add Condition and Add Value buttons to specify more conditions as required. b. To include every instance of an object (for example, ALL Software Packages), proceed to Step In the Set Bars pane, select a category for your chart from the Create chart bars based on drop-down list. For example, categories for patches include Severity, Operating System, Issue Date, Category, and Name or ID. 7. Click the Add Bar button to create bars for the values in that category. For example, in a chart that shows patch severity, make bars for Critical, Important, Moderate, Low, and Unknown. Type the bar's name in the field to the right of its value to label it. To delete a bar, click the X. v Bar names must be unique. v To specify a date range, click in the bar field to display a calendar and select start and end dates. v When you enter values for Issued By, type the operator's BigFix user name. Chapter 6. Editing Dashboards 43

50 8. Click Add to add the chart to the tile and return to the Build Tile page. Or click Back to exit without saving. 9. On the Build Tile page, drag the bars to rearrange them, or click the X to delete a bar. Check the Preview pane to see your changes. 10. In the field below the tile title, type a description of the chart's X axis. 11. Click Done. On the Edit Dashboard page, move the new tile to the place you want it on the dashboard. 44 IBM BigFix: WebUI Administrators Guide

51 Chapter 7. Performance Operator Performance IBM BigFix is renowned for its scalability. While remaining extremely scalable, due to increased overhead, the WebUI was some performance considerations. The WebUI is realized through a secondary WebUI specific database. Most performance impacts revolve around the ETL functions between the IBM BigFix server and the WebUI server. Operators functioning within the WebUI may encounter performance issues. Due to the inherent design of the WebUI, Operators ability to affect performance is limited. If an Operator runs a query that that takes 5 seconds or longer, a message acknowledging the delay and pointing operators to possible solutions is displayed. All relevant information pertaining to this error is encapsulated in this Administration Guide. Slow Filters The following causes of slow performance can be addressed by administrators by shaping Operator access, endpoints managed, and schedules. Filtering options can cause query delays. The following filters currently create the most overhead and avoiding them might help alleviate the issue: Concurrence v Deployments List > Failure Rate v Patch > Sort by Name v Patch > Sort by Release Date A source of slow WebUI performance can be concurrence, or the number of Operators accessing the WebUI at the same time. If an Operator is experiencing slow performance, returning to the WebUI when there are fewer concurrent users might help. If this issue is ongoing, addressing the problem using Operator and Role shaping can be helpful. For more information, see Operator Shaping on page 46. Copyright IBM Corp

52 Administrator Performance Master Operators can take specific steps to help alleviate WebUI performance issues. These include environment upgrades as well as modifying Operators permissions. Operator Shaping One way to limit the load on the WebUI at any given moment is to shape your Operators ability to interact with endpoints. Defining Operators and Roles to specific content and/or subsets of endpoints can greatly reduce query overhead. If a given Operator is only concerned with a subset of endpoints, such as Windows endpoints, best practice is to define their role accordingly. Removing unnecessary content can greatly reduce the load on the server. Environment Upgrades Several key environment considerations can greatly increase WebUI performance. Increasing the CPU cores of your server machine to support WebUI is both a requirement and an option to help alleviate performance issues. However, the nature of the WebUI favors faster cores over more cores. If your CPUs are clock limited, increasing the clock speed will have an enormous performance impact. Upgrading your deployment to faster clocked cores will have a significantly bigger impact than increasing the number of cores. The other environment consideration is your server OS. Currently, there is a significant increase in performance when using a Linux server as opposed to a Windows server. The performance increase can be up to double on identical hardware. We strongly recommend using a Linux server in your deployment. ETL Performance The single biggest performance factor is the ETL process between the IBM BigFix server and the WebUI server. Currently the ETL is not multithreaded and is performed on a single CPU core. It is expected behavior to see CPU usage spikes when the ETL is running. Upgrading your CPU clock speed can help alleviate this performance bottle cap. It is possible to modify the timing of the ETL. It is possible that performance increases can be made by altering this schedule. For more information, see Chapter 9, WebUI Server Settings, on page IBM BigFix: WebUI Administrators Guide

53 Chapter 8. Log Locations All WebUI logs are stored in one default location. Logs are stored on the WebUI Server in the following locations: Windows Deployment \\Program Files (x86)\bigfix Enterprise\BES Server\WebUI\Logs\ Linux Deployment //var/opt/besserver/webui/logs/ It is possible to change the location where logs are written as well as alter the verbosity of the log files. These options can be performed by creating or editing several server settings as described in Chapter 9, WebUI Server Settings, on page 49. Note that these settings should not be altered under most circumstances and should be reserved for very specific situations. Copyright IBM Corp

54 48 IBM BigFix: WebUI Administrators Guide

55 Chapter 9. WebUI Server Settings A series of server settings that control advanced aspects of the WebUI can be created or modified on your WebUI Server. These settings are for advanced users only and chiefly exist to help troubleshoot issues or tweak behaviors to optimize performance for your specific deployment. As a rule, these settings should not be changed unless specifically required; some of these settings can drastically affect the behavior and performance of your deployment. The BesRootServer service must be restarted to apply any of these settings. Access WebUI Server Settings The WebUI Server Settings are accessed through the IBM BigFix Console as a function of your WebUI server. Locate your WebUI Server by navigating to All Content > Computers. Select your server computer and right click. Select Edit Computer Settings to display the Edit Settings dialogue box. For detailed instructions on adding or editing server settings, see the IBM BigFix Console Operator's Guide. Server settings are written in the following format: <server_setting_name>=<value> Click Add or Edit to create or edit a new server setting. Note that all server settings begin with an underscore. The BesRootServer service must be restarted to apply any of these settings. Copyright IBM Corp

56 Server Settings Definitions The WebUI Server Settings are defined below along with a brief description of their impact. Any default settings are noted. If a setting has no default, the parameter itself may not appear in the IBM BigFix Console, unless you create it. Note: The BesRootServer service must be restarted to apply these server settings. _WebUI_AppServer_IsEnabled Enables and disables the WebUI. The default is 0. Value 1 enables the WebUI. This parameter is set by Fixlet 2252 as part of WebUI enablement as described in Enable the WebUI (Platform V9.2.6 V9.5.2) on page 10. _WebUI_Logging_Filter The value of this parameter is a regular expression that filters events to be logged. The default is: bf*error,bf:bfetl:debug,bf:bfapp:debug,bf:appmonitor:debug To enable verbose logging for all IBM BigFix events use: bf* To log all debug events including third party applications use simply: * _WebUI_Logging_LogPath 50 IBM BigFix: WebUI Administrators Guide