The following issues are known to exist in JetPatch 2.10.1:
- Upon changing a physical endpoint hostname, it needs to be disconnected from JetPatch and then re-added.
- Changing the JetPatch service installation path causes endpoints that already have JetPatch 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 JetPatch 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 JetPatch 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 JetPatch 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 JetPatch cannot connect via hostname and via the primary IP address, if the secondary IP address has change, the JetPatch server may not be aware of the change and the connection may fail.
- Deploying JetPatch to a Linux endpoint will fail if the endpoint's shell startup script outputs unusually long messages upon login.
JetPatch Console Issues
- When using Internet Explorer 9, changing the window size may cause the JetPatch Console to behave unpredictably.
- Upon restarting the JetPatch 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 JetPatch 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 JetPatch 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 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.
- Upon upgrade, Policy rules are removed and need to be recreated.
- Operational Discovery scripts are not supported on Ubuntu backend servers.
- Upon upgrading JetPatch, where for the Connector only the build number changes (for example, from 188.8.131.52 to 184.108.40.206), the new automatically-created JetPatch 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 JetPatch-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.