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 0 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 (Platform V9.5.3 or later). 7 Requirements Installation Checklist Remove the WebUI Service Change Ports Renew WebUI Certificates Enable the WebUI (Platform V9.2.6 V9.5.2) Change Communication Ports SSL Certificates Send Notifications Access the WebUI Chapter 4. Provisioning Users Master Operator Permissions Non-Master Operator Permissions Operators and Roles in IBM BigFix Permission Effects in the WebUI Apply WebUI Permissions Explicit and Effective Permissions Setting WebUI Permissions Interface Login Privileges Create Actions Privileges 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. Supported Patch Sites Appendix. Support Notices Trademarks Terms and conditions for product documentation.. 66 Chapter 5. Managing Application Updates Chapter 6. Editing Dashboards General Editing Techniques Working with Predefined Tiles 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 47. 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 on page 13. 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 9 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 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 (Platform V9.5.3 or later). v To use the WebUI on BigFix Platform versions , use Enable the WebUI (Platform V9.2.6 V9.5.2) on page 9. v To use the WebUI in SAML-Only mode, use Enabling the WebUI in SAML-Only Mode on page 57. Install the WebUI Service (Platform V9.5.3 or later) 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: Copyright IBM Corp

14 C:\Program Files (x86)\bigfix Enterprise\BES WebUI 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 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 If you are not using the defaults, 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 When you are ready, deploy the Fixlet Install IBM BigFix WebUI Service (Version 9.5.3). Notes: v If the Fixlet fails, revoke the certificates that it generates and sends to the target machine. 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. 8 IBM BigFix: WebUI Administrators Guide

15 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. BESAdmin.exe /revokewebuicredentials /sitepvklocation:<pvklocation> /sitepvkpassword:<pvkpassword> 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 Enable the WebUI (Platform V9.2.6 V9.5.2) Use this procedure 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 Chapter 3. WebUI Installation 9

16 10 IBM BigFix: WebUI Administrators Guide 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.

17 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 Chapter 3. WebUI Installation 11

18 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 9. After the WebUI is enabled, the ports that are defined for WebUI and Web Reports can be changed using Fixlet IBM BigFix: WebUI Administrators Guide

19 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 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. Chapter 3. WebUI Installation 13

20 Send Notifications Access the WebUI Use the BigFix Send Notifications service to trigger an alert when a deployment fails (on a specified number of devices), or completes (on all targets). In the WebUI, Send Notification options are specified when configuring a deployment. To use this feature in the WebUI Send Notifications must be enabled in your deployment, and operators must have the Custom Content and Can Create Actions permissions set to "Yes." For instructions on enabling the notification service in your deployment, see the IBM BigFix Configuration Guide. For read about setting operator permissions, see Apply WebUI Permissions on page 20, and Create Actions Privileges on page 24. 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: 14 IBM BigFix: WebUI Administrators Guide

21 Chapter 3. WebUI Installation 15

22 16 IBM BigFix: WebUI Administrators Guide

23 Chapter 4. Provisioning Users Master Operator Permissions BigFix administrators and master operators set the permissions that govern (non-master) operators' access to the WebUI. WebUI permissions are implemented as an extra layer on top of the traditional BigFix permissions managed through the BigFix console. WebUI operator provisioning tasks start with defining Operators and Roles in the console, as you normally do for a conventional IBM BigFix deployment. For detailed information on permissions, see the BigFix Console Operator's Guide. It is helpful to have some understanding of how basic BigFix permissions operate before proceeding with WebUI permissions. The workflow for provisioning Operators for the WebUI follows: 1. Define, or use existing permissions for Operators and Roles in the BigFix Console to fit the needs of your deployment. By default, all Operators and Roles have access to all WebUI components and are only limited by their underlying, non-webui, permissions. 2. Use the WebUI-specific permissions layer to limit or customize any Operator's or Role s access to WebUI components. 3. Choose to disable any Operator or Role access to the WebUI so they cannot log in to the WebUI at all. Master Operators have complete access to all elements of the WebUI. In the course of setting permissions it is possible to seemingly deny a Master Operator s access to one or more WebUI elements within the IBM BigFix Console, but such settings have no effect. If a user is defined as a Master Operator, they always have full permission to all aspects of the WebUI. Non-Master Operator Permissions All BigFix operators and roles are given full WebUI permissions, by default. Operators can have access to elements in the IBM BigFix Console without having access to those elements in the WebUI. For example, an Operator might be given access to Patch content in the BigFix console and denied access to patch content in the WebUI. Giving an Operator s access to a particular WebUI element allows the Operator to see elements related to that content in the WebUI, but does not allow them to interact with that content if they do not have that permission outside of WebUI. For example, if an operator does not have access to Patch content in the BigFix Console, they will not have access to Patch content in the WebUI. The only exception to this is that any Operator can view actions that have been taken regardless of content type. This allows Operators to see a complete picture, but does not give them the ability to act on that content. Copyright IBM Corp

24 Operators and Roles in IBM BigFix IBM BigFix allows permissions to be set for individual Operators as well as by Roles, which can encompass many Operators. For detailed information about the concepts of Operator and Role, see the BigFix Console Operator's Guide. However, it is important to note that Operator and Role permissions are additive. That is, IBM BigFix will always favor increased permissions. For example, if an Operator is denied a particular permission but that same Operator is part of a Role that is granted that permission, the Operator will gain the permission. The reverse is true, if an Operator is granted a permission, but is denied it, as part of a Role they are a member of, they will still retain the permission. This concept is discussed within the context of the UI in Explicit and Effective Permissions on page 21. Permission Effects in the WebUI Permissions granted to Operators affect their ability to view WebUI elements and conduct activities in the WebUI. For the most part, the effects of permissions are clear: an Operator who is not granted Patch permissions will not have access to the Patch workflow in the WebUI. However, there are a few nuances that should be discussed. The WebUI Overview incorporates information from many elements of your deployment. Permissions have a direct impact on the information relayed to any given Operator on the Overview. For example, patch related counts are not displayed to an Operator without Patch access. It is important to note that all Operators see deployment related data regardless of content type. It is limiting if an Operator views an endpoint but cannot see that a patch was deployed to that endpoint, even if that Operator does not have Patch permissions. However, that Operator will not have the ability to take Patch actions or alter that deployment. Operators see all deployments regardless of source. The WebUI offers a window into your deployment and it is not self-contained. Actions initiated from the traditional IBM BigFix Console, external sites, or the REST API will be reflected in the WebUI. The WebUI allows messages, associated with performed actions, to be sent. The ability to send these notifications requires this feature be enabled within the IBM BigFix console, as described in Send Notifications on page 14. Because these notifications are enacted through custom content, Operators must have Custom Content and Can Create Actions permissions to see the associated workflow within the WebUI, allowing them to use this functionality. Finally, it is possible for an Operator to login to the WebUI without having permissions for any WebUI applications: custom, patch, or swd. This situation should be avoided, but if it occurs, the Operator will see the following message only after logging in: Access to WebUI applications forbidden. 18 IBM BigFix: WebUI Administrators Guide

25 For more information on how this can occur, see Setting WebUI Permissions on page 22 and Interface Login Privileges on page 23. 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 All Master Operators have access to BigFix Query. The All Content > WebUI Appspermissions control access to the Query and other WebUI components. Like the other WebUI components, access to the Query application defaults to Yes for all operators. The All Content > WebUI Apps > Enable for all operators check box is checked by default, so the effective permission for all WebUI components is Allowed (Globally). To change an individual operator s Query permissions settings, clear the Enable for all operators check box. Then, change permissions for individual users and roles. Note that the WebUI Apps Effective permission are None only if all of the WebUI Apps > Query permissions are None for Operators, Roles, and All Content. If any of them are set to Allowed, the Effective Permission is Allowed Operators who do not have access do not see Query in the Content menu, and cannot access the Query landing page through the URL. Operators with access see the Query button on the Overview and Device document pages. Can Submit Queries An operator s Can Submit Queries setting does not control access to the WebUI Query component, All Content > WebUI Apps permissions does. An operator s Can Submit Queries permission controls whether their requests can be submitted to the REST API that supports queries. Since processes other than the Query app also submit such requests, a REST-specific setting for operators is used. v When Can Submit Queries is set to Yes an operator who submits a query receive results. v When Can Submit Queries is set to No an operator who submits a query does not receive results, but the error message, The logged in user is not allowed to submit queries. For more information about configuring BigFix Query s 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. Chapter 4. Provisioning Users 19

26 Apply WebUI Permissions All Operators and Roles have full access to the WebUI by default, but it is possible to customize access by Operator or Role. Currently, the WebUI is composed of three components: custom, patch, and swd. Permissions for each component can be granted or denied independently. Permissions can be set in three places within the IBM BigFix Console: v All Content > WebUI Apps v All Content > Operators v All Content > Roles While the implementation is slightly different from a UI perspective, setting permissions in any of these locations is reflected in all other locations. When WebUI is enabled, you will find a new WebUI Apps tab in the Operator and Roles windows. You are free to edit permission in any location you desire, however to avoid redundancy, we will primarily consider the All Content > WebUI Apps location in the Console. 20 IBM BigFix: WebUI Administrators Guide

27 Select a WebUI component from the list of WebUI Apps, such as Patch, or SWD. Permissions are defined in relation to each component. Once selected, the Operators tab displays a list of operators, and the Role tab displays a list of roles. Explicit and Effective Permissions Permissions are set for specific Operators, but other sources of permissions can alter an Operator s effective permissions. In the Operator Permissions tab there are two sets of permissions listed: Explicit Permissions and Effective Permissions. Explicit permissions are those permissions that are granted directly to that Operator. Prior to WebUI, these are the permissions set per Operator in All Content > Operators. Explicit permissions are the base permissions for any given Operator. They do not exist for Roles and are therefore not listed as a column in the Role Permissions tab. Effective Permissions reflect permissions granted by either the Operator s explicit permission or permissions granted by either the Operator s Role or the global Chapter 4. Provisioning Users 21

28 checkbox Enable for all operators. Effective permissions are additive; if an Operator is granted permission to a component by any means, it is reflected in Effective Permissions. In summary, Explicit Permissions are permissions a Master Operator has directly defined for an Operator. Effective Permissions reflect an Operator s explicit permissions, Role permissions, and global permissions in an additive manner. In the end, Effective Permissions reflect an Operators current permission level for each WebUI component. Setting WebUI Permissions Once the core concepts of permissions are understood, setting Operator permissions is a simple task. To set permissions by Operator, Role, or apply a global permission set, perform the following steps: 1. From All Content > WebUI Apps, select the WebUI component whose permissions you wish to alter: v v v Custom Patch SWD 1. In the Operator Permissions tab, check the Enable for All Operators checkbox to toggle permissions for all Operators. This affects all Operators effective permissions and leaves their explicit permissions as is. 22 IBM BigFix: WebUI Administrators Guide

29 1. Select the desired Operator and use the Allow or None buttons to set the explicit permissions for that Operator. This is the same as setting the Operator s explicit permissions in the All Content > Operators site. 1. Use the Role Permissions tab to change effective permissions for any Roles. Selecting a defined Role and using the Allow and None buttons sets the Role s permissions in an identical manner as using the All Content > Roles site. Interface Login Privileges 1. Use the Save Changes button to save your permission settings. Related to permissions, Operators and Roles can be granted or denied login rights to the WebUI. Chapter 4. Provisioning Users 23

30 Regardless of permissions granted to an Operator explicitly or effectively, the ability to login to the WebUI can be set. This option simply rejects a user s login credentials barring them from accessing the WebUI in any way. Such a user is given a prompt directing them to their administrator when they attempt to login to the WebUI. To deny WebUI login, perform the following steps: 1. Navigate to All Content > Operators (or All Content > Roles). 2. Select the appropriate Operator or Role. 3. Navigate to the Details tab and scroll down. 4. From the Interface Login Privileges pane set the Can Use WebUI dropdown menu. Create Actions Privileges Setting this value for an Operator sets the explicit value. The effective value is also displayed, which is only altered by the same setting in a Role that the Operator is a member of. As in all permissions, this permission is additive between Operators and Roles they are members of. If setting this value within a Role, you are setting the effective value for any associated Operators. Note: The WebUI Interface Login Privileges affect the ability to login to the WebUI only. They do not affect an Operator s ability to login to the traditional Console. Separate settings allow control over Console and REST API usage. Similar to Interface Login Privileges, the ability to create actions can be denied an Operator or Role. 24 IBM BigFix: WebUI Administrators Guide

31 This permission affects action creation in a traditional IBM BigFix deployment, but it also affects the WebUI. As its name implies, denying this permission means an Operator cannot take actions, but it does not affect their ability to view taken actions. Essentially such an Operator becomes a read-only Operator. Within the WebUI, they are denied the ability to deploy, etc. To set create action permissions, perform the following steps: 1. Navigate to All Content > Operators (or All Content > Roles). 2. Select the appropriate Operator or Role. 3. Navigate to the Details tab and scroll down. 4. From the Permissions pane set the Can Create Actions dropdown menu. Setting this value for an Operator sets the explicit value. The effective value is also displayed, which is only altered by the same setting in a Role that the Operator is a member of. As in all permissions, this permission is additive between Operators and Roles they are members of. If setting this value within a Role, you are setting the effective value for any associated Operators. Chapter 4. Provisioning Users 25

32 26 IBM BigFix: WebUI Administrators Guide

33 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

34 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 28 IBM BigFix: WebUI Administrators Guide

35 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. Chapter 5. Managing Application Updates 29

36 30 IBM BigFix: WebUI Administrators Guide

37 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

38 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. 32 IBM BigFix: WebUI Administrators Guide

39 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 36. 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 33

40 34 IBM BigFix: WebUI Administrators Guide

41 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 35

42 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 36 IBM BigFix: WebUI Administrators Guide Select a custom tile from the Edit Dashboard page to display the Build Tile page.

43 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 37

44 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. 38 IBM BigFix: WebUI Administrators Guide

45 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 39

46 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. Continue refining a tile and its filters until you click Done. At that point, they can no longer be edited. 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. 40 IBM BigFix: WebUI Administrators Guide

47 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 41

48 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. 42 IBM BigFix: WebUI Administrators Guide

49 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 43

50 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. 44 IBM BigFix: WebUI Administrators Guide

51 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 45

52 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. 46 IBM BigFix: WebUI Administrators Guide

53 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 48. Copyright IBM Corp

54 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

55 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 51. Note that these settings should not be altered under most circumstances and should be reserved for very specific situations. Copyright IBM Corp

56 50 IBM BigFix: WebUI Administrators Guide

57 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

58 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 9. _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 52 IBM BigFix: WebUI Administrators Guide