Articles in this section

See more

How to Configure JetPatch if your Environment has a lot of Dynamic IP Addresses

WARNING - The following changes are recommended only in environments where endpoints have Dynamic IP address.  

Summary

Add the following properties into the intigua.properties file, then restart tomcat For versions prior to 5.0 and restart docker for post 5.0.

ep.communication.prefer-hostname.enabled=true 
ep.communication.prefer-hostname.ip-fallback=false
endpoint.merge.hostname-only=true
connector.deploy.footprint-test=false
connector.deploy.footprint-match.all=false

Note: If after setting the correct variables for your environment, you still see incorrect merges, then please provide manager logs and DB dump to support@jetpatch.com.

For additional details on what these properties do, please read the following three sections:

Change connector communication to prioritize hostname first then IP address second

By default, JetPatch prioritizes IP addresses over hostname.  In an environment with dynamic IP addresses, you want JetPatch to prefer hostname and disable fallback to IP address by adding the following property into the intigua.properties file

#use hostname as a preferred address of communication
ep.communication.prefer-hostname.enabled=true #default false

#fallback to IP if hostname connection failed
ep.communication.prefer-hostname.ip-fallback=false  #default true

Merge multiple endpoint records on hostname only

By default, JetPatch is merging the endpoints only if the Hostname and IP provided from the Connector are the same.  In an environment with dynamic IP addresses, you will want to change the merging criterion to be Hostname only by adding the following property into the intigua.properties file
endpoint.merge.hostname-only=true #default false 

Dynamic IP causing installation of the connector on the wrong endpoint

Endpoints using fast dynamic IP addresses (like VPN connection) change much more frequently than static endpoints, which can cause resolving issues to your DNS, and in the case of connector installation, it could occur on the wrong endpoint.

To resolve this issue JetPatch created a script capable to check if the endpoint selected for the connector installation is resolving the correct endpoint IP, MAC address, and Hostname by pairs.

(Pairs example: IP-MAC, IP-Hostname, Hostname-MAC)

You can enable this configuration, by adding the following line in the intigua.properties file. 

connector.deploy.footprint-test=true #default false

If the following property is set to false, then JetPatch will check one of the pairs (IP-MAC, IP-Hostname, Hostname-MAC) and only one must verify. This is important because in VPN environments, MAC addresses tend to be artificial addresses.

connector.deploy.footprint-match.all=false #default false

 

Note On Duplicate Endpoints Due to Hostname vs FQDN Mismatch

In environments where the local hostname and the fully qualified domain name (FQDN) do not match, the same server may appear as two separate endpoints in JetPatch.

The connector first retrieves the short hostname from the operating system (for example, ssanexus7). It then performs a DNS lookup to resolve this hostname to an FQDN (for example, dfwlnpbuild-04.jetpatch.com). If the short hostname and the resolved FQDN differ, the connector will always prefer and report the FQDN.

As a result, when data sources or integrations reference the short hostname while the connector reports the FQDN, the same physical machine may appear twice under different names. This behavior is expected and is caused by hostname and DNS configuration inconsistencies.

Recommendations (If Hostname Standardization Is Not Possible)

1. DNS Alias (CNAME) Workaround

  • Create a CNAME record so that the short hostname and the FQDN resolve consistently.

ssanexus7 → CNAME → dfwlnpbuild-04.jetpatch.com

Benefit:

  • DNS resolution becomes consistent
  • Reduces duplicate endpoint detection

Limitation:

  • Still relies on DNS behavior
  • Requires DNS team involvement

2. Static Hosts File Mapping (Last-Resort)

Manually map the hostname to the FQDN in the OS hosts file:

Windows: C:\Windows\System32\drivers\etc\hosts

Linux: /etc/hosts

10.10.10.5 ssanexus7 dfwlnpbuild-04.jetpatch.com

Benefit:

  • Forces consistent name resolution locally

Limitations:

  • Manual maintenance
  • Not scalable
  • Risky if IPs change
  • Not recommended long-term

3. Exclude One Data Source in JetPatch

If both vCenter and connector discovery are enabled:

  • Consider disabling one discovery source (usually vCenter) for the affected machines.

Benefit:

Prevents duplicate endpoint entries

Trade-off:

Reduced metadata (power state, VM relationships, etc.)

4. Manual Endpoint Cleanup / Ignore Strategy

If duplicates are unavoidable:

  • Identify the authoritative endpoint record (usually FQDN-based)
  • Manually ignore or decommission the duplicate entries

Benefit:

  • Operationally simple
  • No infra changes required

Limitation:

  • Ongoing manual effort
  • Not scalable in large environments

Related articles

Comments

0 comments

Please sign in to leave a comment.