The following issues are known to exist in JetPatch 2.6:
- Upon changing a physical endpoint hostname, it needs to be disconnected from JetPatch and then re-added.
- Repairing the VMware Tools installation on a vSphere endpoint causes the JetPatch connector to be removed and all vAgents to be stopped.
- connector installation paths for Linux may not contain spaces.
- Changing the connector installation path causes endpoints that already have connectors in other locations to be displayed as Available, and to allow deploying an additional connector to the new location, as though they did not already have a connector.
- Upon turning off a VM's network adapter and stopping its VMware Tools service, the endpoint continue to appear as Available.
- When web connectivity to a vSphere VM is not available and the connection is reliant upon the hypervisor channel, the endpoint may become disconnected for no apparent reason. In this case, restart either the tomcat service on the JetPatch server or VMware Tools on the endpoint.
JetPatch Console Issues
- When using Internet Explorer 9, changing the window sized may cause the JetPatch Console to behave unpredictably.
- When operating the JetPath Console for several hours, the browser may begin to use an excessive amount of computer memory. If this happens, refresh the browser.
- Upon restarting the JetPatch web server while running operations, sometimes applied filters and the Tags column are removed.
- All endpoint actions and tasks are displayed to to users with any permissions.
- A JetPatch User is able to delete a policy rule when it applies to a Dynamic Group for which the User has permissions, even if it also includes a Dynamic Group for which the User does not have permissions.
- It is impossible to change the name of a Dynamic Group that is used in a Policy rule.
- Filter details are sometimes not displayed upon clicking the Filters button. The number of applied filters still appears.
- To upgrade a vAgent from one version of the agent to another, the vAgent needs to be fully removed and the new version then applied.
- Upon disconnecting an endpoint, installed vAgents are properly removed, but the previously running conventional (non-virtual) agents are not restored. To have the conventional agents restored, before disconnecting the endpoint, remove each of its vAgents, upon which the conventional agents are restored.
- Upon changing the port number in the agent-specific settings of a new vAgent package and deploying the package to a Linux endpoint, the new port number is not added to the endpoint's iptables as a firewall exception.
- Management server plugins cannot unregister a vAgent from its management server upon removal.
- Active Directory authentication does not work with AD 2003.
- Applying a vAgent as an unauthorized user generates the wrong error log ("vLink no found").
- Upon restarting the JetPatch server, it may take up to 15 minutes until all endpoint statuses are updated.
- Upon attempting to deploy a connector to a Linux endpoint that is not running SSH, the error message does not clearly describe the problem (the message is: java.net.ConnectException: Connection refused).
- The log entry upon editing a management package incorrectly states Package Created.
- When JetPatch is connected to multiple vCenter servers and one is shut down, turning it back on does not change its status in JetPatch. If this happens, edit the vCenter connection and click Test Connection.
Please sign in to leave a comment.