AppManager 9.2 includes new features, improves usability, and resolves several previous issues.
Many of these improvements were made in direct response to suggestions from our customers. We thank you for your time and valuable input. We hope you continue to help us ensure that our products meet all your needs. You can post feedback in the AppManager forum, our online community that also includes product information, blogs, and links to helpful resources.
The documentation for this product is available on the NetIQ website in HTML and PDF formats on a page that does not require you to log in. If you have suggestions for documentation improvements, click comment on this topic at the bottom of any page in the HTML version of the documentation posted at the AppManager Documentation page. To download this product, see the Downloads page.
The following outline the key features and functions provided by this version:
AppManager 9.2 adds support for the following Microsoft operating systems and databases:
For all components, Microsoft Windows Server 2016 Standard or Datacenter edition (GUI mode only)
For the Task Scheduler service, Windows agent, and Control Center and Operator consoles, Microsoft Windows 10
For the AppManager repository (QDB) and Control Center repository (CCDB), SQL Server 2016 Standard and Enterprise editions
For the Windows agent:
Windows Server 2016 Core
Microsoft Windows Server 2008 R2 Core
Microsoft Windows Server 2008 Core
Starting with version 9.2, AppManager no longer supports the following operating systems:
Microsoft Windows Vista
Microsoft Windows Server 2003 R2
Microsoft Windows Server 2003
Microsoft Windows XP
AppManager 9.2 includes the following enhancements:
AppManager 9.2 introduces the concept of base and derived Knowledge Scripts. A base Knowledge Script is checked in to the AppManager repository (QDB) and holds all of the Knowledge Script settings (the schedule, parameters, and Advanced tab) and the script logic. A derived Knowledge Script is a copy of a base Knowledge Script (a direct copy or a member of a Knowledge Script Group) and shares the logic with the base Knowledge Script but has its own settings. For example, a base Knowledge Script might have a default threshold of 10 for a certain parameter while the derived Knowledge Script has a default threshold of 20. The two Knowledge Scripts share the script logic, but the settings are different.
Because a base Knowledge Script and a derived Knowledge Script share logic, when the logic for a base Knowledge Script changes, AppManager can automatically update the logic for the derived Knowledge Script without updating the settings.
With AppManager 9.2, when you install a new version of a module, AppManager can automatically update the logic of the derived Knowledge Scripts without changing any defaults or settings. For new QDB installations, this is the default behavior. For upgrades, you must enable the automatic propagation feature. To enable the feature, in the Knowledge Scripts options in the Control Center console, select Automatically update Derived KS properties for checked in Base KSs.
The automatic propagation feature includes monitoring policy jobs but not ad-hoc jobs. For ad-hoc jobs, you must manually propagate changes from the base Knowledge Script to the derived Knowledge Script. With both automatic and manual propagation, the target Knowledge Script or job retains its settings (such as thresholds and schedule). If a base Knowledge Script includes new values or removed values, AppManager also propagates those changes to the derived Knowledge Scripts.
If you do not enable the automatic propagation option, when you log in to the AppManager consoles and base Knowledge Scripts have been updated, AppManager informs you that Knowledge Scripts are pending propagation to running jobs and provides the option to start the Knowledge Script Propagation Wizard to select which Knowledge Scripts to propagate. The wizard includes options to propagate to both derived Knowledge Scripts and to ad-hoc jobs. In Control Center, when you select a Knowledge Script on the Propagation to Ad Hoc Jobs tab, you can see the QDBs where the job is running and can choose to propagate to ad-hoc jobs in specific QDBs.
For more information about automatic and manual propagation, see the Control Center User Guide for AppManager.
To allow you to more easily diagnose issues with remote deployment, AppManager 9.2 includes the ability to view deployment rule processing details in the Control Center console.
After you create and enable a deployment rule, AppManager evaluates the rule for processing and displays the status in the Control Center console. To view the evaluation history, click Rule History in the Deployment view of the Navigation pane.
The Rule Processing History portion of the pane indicates whether processing was successful. If AppManager was not able to create a deployment task for the rule, it provides details about the error in the Task Comment column.
If the evaluation status changes the next time that AppManager evaluates the rule, AppManager updates the rule history. AppManager does not update the rule history if the evaluation status does not change.
Version 9.2 incorporates data scalability improvements from version 9.1 into the user interface for improved console performance. In test environments, improved response times were observed in large environments.
AppManager 9.2 includes changes to expected behavior. The following sections provide more information:
In previous versions of AppManager, when you used the Operator Console or the Developer’s Console to check in a Knowledge Script (or Knowledge Script Group in the Operator Console) to an AppManager repository (QDB) where the same script or group already existed, AppManager overwrote the existing script or group properties (for example, the schedule and threshold values) with the properties of the script or group that you checked in. In version 9.2, AppManager merges the new script or group properties with the existing script or group properties.
AppManager 9.2 includes an update of the OpenSSL version from 1-0-1m to 1-0-2j and replaces the DES encryption algorithm, which is not FIPS-compliant, with AES128, which is FIPS compliant.
With previous versions of AppManager, in environments using the authentication and encrypted communications security level, the management server used the DES encryption algorithm to encrypt and decrypt public key data that it shared with UNIX agents. In environments where FIPS is enabled, OpenSSL 1-0-2j does not allow using the DES encryption algorithm. However, when you upgrade a management server to version 9.2, the management server must decrypt public key data that was encrypted using the DES algorithm. To allow a version 9.2 management server to continue working with existing UNIX agents without requiring you to rekey the agents, when the management server starts, AppManager temporarily disables FIPS mode so that it can use the DES algorithm to decrypt the public key data and then restores FIPS mode when the decryption is complete.
A new option in the Control Center console Security options, Disable Vulnerable TLS Versions, allows you to disable any Transport Layer Security (TLS) versions that are considered vulnerable (for example, TLSv1.0). This option is selected by default. If you have a management server that communicates with UNIX agents using the encrypted communications only or authentication and encrypted communications security level and this option is selected, the management server will not be able to communicate with the agents because they require TLSv1.0. You must deselect the option to restore communications.
In previous versions of AppManager, the NetIQOLE automation object required a version-specific .dll file (netiqole.dll) to run command line scripts against different versions of the QDB. For example, to run a script against a version 8.0.x QDB, NetIQOLE required netiqole80.dll and to run a script against a version 8.2 QDB, NetIQOLE required netiqole82.dll.
Starting with AppManager 9.2, you can use the netiqole.dll that is included with version 9.2 to run command line scripts against version 8.2, 9.1, and 9.2 QDBs. There is no longer a need to use a version-specific .dll when running commands against these QDB versions.
For more information about the NetIQOLE automation object, see the Administrator Guide for AppManager and the NetIQOLE Object Reference Guide.
Before you upgrade to version 9.2, all components must be version 9.1, with the exception of the Windows agent. You can upgrade version 7.0.4 and later Windows agents to version 9.2. At this time, the UNIX agent does not support upgrading to version 9.2.
AppManager version 9.2 requires that the CCDB and the primary QDB be the same version. You can either create a new version 9.2 primary QDB or upgrade your existing version 9.1 primary QDB to version 9.2. You cannot upgrade QDBs earlier than version 9.1 to version 9.2.
A version 9.2 CCDB will support version 9.1 QDBs as non-primary QDBs.
Before you upgrade the CCDB to version 9.2, ensure that it does not contain any QDBs that are earlier than version 9.1. If it does, either remove the QDBs or upgrade them to version 9.1.
For detailed information about hardware and software requirements, see System Requirements in the Installation Guide for AppManager.
For information about installing AppManager, see the Installation Guide for AppManager.
For information about upgrading AppManager, see the Upgrade and Migration Guide for AppManager.
NetIQ Corporation strives to ensure that our products provide quality solutions for your enterprise software needs. The following issues are currently being researched. If you need further assistance with any issue, please contact Technical Support.
Issue: AppManager 9.2 is not compatible with Operations Center versions 5.7 and 5.6. In environments with Operations Center 5.7 or 5.6, upgrading to AppManager 9.2 will break the link between Operations Center and AppManager.
Workaround: A patch that will allow a complete upgrade for environments with Operations Center is in progress. For further clarification or for more information about the patch, contact Technical Support.
Issue: During upgrade of a QDB, if the installation program detects that any of the following conditions exist for Knowledge Scripts that are present in the QDB, it displays details about the scripts that are causing the error and will not allow the installation to continue:
Multiple versions of the same script are present.
Scripts do not strictly adhere to XML standards.
Scripts with missing script logic are present.
The conditions listed above can occur in environments where a version 5 or earlier QDB has been upgraded to AppManager version 9.1. The installation program does not make any changes to your environment when it detects these conditions.
Workaround: Contact Technical Support for assistance in resolving the error. After the error is resolved, you can continue the upgrade.
Issue: When you migrate a QDB that uses SQL Server authentication to a new SQL Server, Control Center is not able to create a new linked server after you update the SQL Server information in Manage Repositories in the Control Center console.
Workaround: Use SQL Server Management Studio to manually create the new linked server:
Expand SQL_Server_Name\Server Objects.
Right-click the Linked Servers folder and select New Linked Server.
On the General page, in the Linked Server field, specify the name and instance, if applicable, of the SQL Server that hosts the QDB for which you are creating the link.
On the General page, for Server type, select the SQL Server radio button.
On the Server Options page, set the RPC and RPC Out values to True, and then click OK.
Issue: After you propagate a Knowledge Script Group member to ad hoc jobs, the right-click option to propagate to ad hoc jobs might still be available, but the list of ad hoc jobs that are pending propagation is empty. This occurs if the changes are made in the repositories before the next refresh interval for the Knowledge Scripts view. At the next refresh interval (one hour by default), the changes are reflected in the view.
Workaround: Manually refresh the Knowledge Scripts view by clicking Refresh Current View or pressing F5.
Issue: In Microsoft Windows Server 2016 environments, deployment package checkin fails with the following error message if the Windows Firewall service is not available:
Unknown error code from BITS: 800706D9
There are no more endpoints available from the endpoint mapper.
The error occurred while the remote file was being processed.
Check that the deployment web service is installed and active.
The error occurs for package checkins during Control Center installation and for manual checkins.
Workaround: Resolve issues with the Windows Firewall service. For more information, see the Microsoft article Cause of 800706D9 error (Windows update, firewall etcetera).
Our goal is to provide documentation that meets your needs. If you have suggestions for improvements, please email Documentation-Feedback@netiq.com. We value your input and look forward to hearing from you.
For detailed contact information, see the Contact Support page.
For general corporate and product information, see the NetIQ Corporate website.
For interactive conversations with your peers and NetIQ experts, become an active member of our community. The NetIQ online community provides product information, useful links to helpful resources, blogs, and social media channels.
For information about NetIQ legal notices, disclaimers, warranties, export and other use restrictions, U.S. Government restricted rights, patent policy, and FIPS compliance, see https:/www.netiq.com/company/legal/.
Copyright (C) 2017 NetIQ Corporation. All rights reserved.
For information about NetIQ trademarks, see http://www.netiq.com/company/legal/. All third-party trademarks are the property of their respective owners.