Version: 2.14(included), 2.15
Date: September 2015
Intigua version 2.15 includes these new features:
- Click Through EULA
- Initiated By column added to Task List
Click Through EULA:
Intigua has added the End User License Agreement (EULA) to the initial login process. When the user logs in to the system for the first time, they will be presented with the EULA. The user must agree to the terms of the EULA before proceeding to use the Intigua system.
The integration of the EULA during the initial login process enables the user to familiarize themselves with the licensing information that is related to the Intigua product.
Initiated By column added to the Task List:
Intigua has added an Initiated By column to the Task List in the Intigua system. When using the Intigua system click View all tasks from the Activities tab. The Initiated By column displays the email address of the user that started each activity.
This information can be beneficial to the customer for internal tracking purposes.
The following screen capture is an example of the Task List with the new Initiated By information:
Intigua version 2.14 includes these new features:
- Agentless Support
- Personal Accounts
Intigua supports management tools, such as Zenoss, that do not require a remote agent to be installed, but perform back-end tasks only without interacting with the endpoint. The back-end server can be on-site or cloud based.
Agentless Support provides Intigua users with the following benefits:
- Single point of access for agent-based and agentless tools
- Automate and delegate responsibility for configuring agentless back-end systems
- Open ports used by agentless tools
- Create a unified service offering on top of multiple on-site back-end systems
- Throttle agentless activity on endpoints
Agentless Support usage example:
- The agentless support feature would be useful in a situation where an agent needs to be created for tools, such as Zenoss, that do not install an agent on the client.
The personal accounts feature allows Intigua users to create their own private server accounts, and to install the connector to an endpoint using it. That personal account can also be used to communicate with the endpoint afterward.
Personal Accounts provides Intigua users with the following benefits:
- Allows the use of personal accounts for server access, while preventing security issues due to account credentials being shared between users.
Personal Accounts usage example:
- The personal accounts feature would be useful in a situation where backup team members should not be able to use an account for monitoring team members.
Intigua 2.15 resolves the following previous issues:
- Can't create agentless package in AWS and AZure. The package can't recognize the backend using public or private IP address. Even though the backend server has the Intigua Connector, the following message is displayed - 'Back-end server must have an Intigua Connector deployed on it. Please deploy a Connector and try again'. Resolution: The fix was made in the backend search logic on the client so that Intigua now searches only by hostname.
- Click-through EULA
- Personal Accounts | Icon should not change when user is trying to use a personal account that is not related to him
- Positive/Negative Rules feature | Change the names to Exclude/Include rules
- Account default should be "Public" and not "Personal" for permitted users.
- Add output and stderr redirection to vstart
- Personal Accounts | Improve the error message when user is trying to run deployment with personal account that is not related to him
- Servers report doesn't present all dynamic columns
- sPackage | increase CLI timeout
- NPE during fetching data from Azure
- Seperate 3rd-party notices from EULA text
- misleading text in Azure discovery source definition
- Health Scripts | Running "ipy" improvments
- self learning | Networker | view files failed - parse xml failed
- 2.15 verification
- 2.15 regression before release
Intigua 2.14 resolves the following previous issues:
- Don't block user from logging in while server is starting up. Resolution: User login is no longer blocked during server boot time and the server will now start gradually.
- The credentials API is broken. Resolution: The credentials API now supports personal and public accounts.
- The linuxPreinstallScript.sh functionality needs to be integrated into the Linux connector. Resolution: The extension of the linux connector installer is now changed to .bsx.
Intigua 2.14 has the following known issues:
- Can't create agentless package in AWS and AZure. The package doesn't recognize the back-end server using public or private IP Address.
- Different versions of the same agent can be installed on a single server. This issue occurs when the Thin agent is installed first, and the Virt agent is then installed without removing the Thin agent.
- When upgrading the RPM an existing file won't be overwritten, and changes won't take effect, until the file is replaced manually.
- User deletion does not delete all corresponding personal accounts. When removing an LDAP group, the corresponding implicit users are not deleted, and the credentials and assignments are not removed.
- Editing tags won't change the corresponding smart group accordingly and will be empty from now on.
The following are known issues from previous versions of Intigua:
- Upon changing a physical endpoint hostname, it needs to be disconnected from Intigua and then re-added.
- Changing the Intigua service installation path causes endpoints that already have Intigua services in other locations to be displayed as Available, and to allow deploying them additionally to the new location, as though they did not already have Intigua services.
- Upon turning off a VM's network adapter and stopping its VMware Tools service, the endpoint continue to appear as Available.
- Upon attempting to deploy Intigua services to a Linux endpoint whose SSH service is down, the error message is uninformative.
- Upon upgrading an ESX server, its endpoints are listed as Disconnected until the Intigua server is restarted.
- Upon attempting to deploy the Connector to a vSphere VM, and the vCenter doesn't have the endpoint's IP address, the error message is non-informative.
- When connecting to a vSphere VM, if Intigua cannot connect via hostname and via the primary IP address, if the secondary IP address has change, the Intigua server may not be aware of the change and the connection may fail.
- Deploying Intigua to a Linux endpoint will fail if the endpoint's shell startup script outputs unusually long messages upon login.
- Hypervisor communications to endpoints (used when preferred channels are unavailable) fail when the Connector installation path is non-default.
Intigua Console Issues
- When using Internet Explorer 9, changing the window size may cause the Intigua Console to behave unpredictably.
- Upon restarting the Intigua web server while running operations, sometimes applied filters and the Tags column disappear.
- All endpoint actions and tasks are displayed to to users with any permissions.
- An Intigua User is able to delete a policy rule when it applies to a Saved Filter for which the User has permissions, even if it also includes a Saved Filter for which the User does not have permissions.
- Filter details are sometimes not displayed upon clicking the Filters button. The number of applied filters still appears.
- The Using saved filter indication disappears upon refreshing the browser.
- The endpoint list cannot be sorted by Status.
Managed agent Issues
Upon disconnecting an endpoint without first removing all vAgents, installed vAgents are properly removed, but the previously running conventional (non-virtual) agents are not re-enabled. To have the conventional agents restored, before disconnecting the endpoint, remove each of its vAgents, upon which the conventional agents are restored.
- LDAP authentication does not work with Active Directory 2003.
- Upon restarting the Intigua server, it may take up to 15 minutes until all endpoint statuses are updated.
- The log entry upon editing a management package incorrectly states Package Created.
- When Intigua is connected to multiple vCenter servers and one is shut down, turning it back on does not change its status in Intigua. If this happens, edit the vCenter connection and click Test Connection.
- Upon upgrade, Policy rules are removed and need to be recreated.
- Operational Discovery scripts are not supported on Ubuntu backend servers.
- Upon upgrading Intigua, where for the Connector only the build number changes (for example, from 184.108.40.206 to 220.127.116.11), the new automatically-created Intigua Connector management service is automatically added to the Policy as a rule, but not as the highest-priority rule. You'll need to manually raise the new rule's Priority.
- When vSphere communications are used, the vCenter logs contain many Intigua-related logs.
- Refreshing the browser clears the currently-applied smart group.
- Refreshing the browser while an Operational Status report is being generated cancels the report.
- Adding the same vCenter twice, once by its IP address and once by its hostname, is not prevented.
- Logs are marked with the date and time they are recorded in the database rather than by the time of event occurrence.