Pre-requisite
Discovery Source Prioritization for Smart Group Assignments
In JetPatch, discovery-source.priority-list determines which source’s metadata wins when multiple sources report the same endpoint. If you rely on a particular source’s attributes for Smart Group assignments (e.g., AWS tags, AD organizational units), make sure it has the highest priority.
Key Rules to Remember
-
Priority List Order
- The source listed first has higher priority than those following it.
-
Not Listed = Higher Priority
- Any source not explicitly mentioned in the list outranks all sources that are listed.
- Default Value (4.2.7+):
AD > WSUS in 4.2.7+ (Default Behavior)
As of 4.2.7+, JetPatch now internally prioritizes AD over WSUS. Thus, AD metadata will override WSUS data if both discover the same endpoint.
-
Why does this matter?
- If you’re using AD attributes (like organizational units) to assign endpoints to Smart Groups, AD’s higher priority ensures they aren’t overwritten by WSUS data.
However, if you only include AD,WSUS
in your property file (omitting all other sources), then any unlisted sources (vSphere, AWS, etc.) will outrank both AD and WSUS. Keep this in mind if you want AD to outrank every other source.
Make AD the Top Priority Overall
- Effect: By listing all sources, none is automatically higher due to being omitted. AD is now the absolute top priority, followed by vSphere, then AWS, etc., with WSUS last.
Use this if AD attributes must outrank all other sources for Smart Group assignments.
Implementation Steps
- SSH to JetPatch Server
-
Edit
intigua.properties
- Locate or add the line:
discovery-source.priority-list=AD,VSPHERE,AMAZON_EC2,ARM,ASM,WSUS
- Locate or add the line:
- Save & Exit
- Restart Tomcat
Change Discovery Source Timeouts
Note1: For WSUS Discovery, see this article.
Note2: In order to manually force a discovery source refresh, you can disable, then re-enable that discovery source.
- SSH to the JetPatch application Server
- Edit /usr/share/tomcat/default/conf/intigua.properties
- Add and configure the relevant discovery sources to the properties file
// Amazon
discovery-source.AWS.success.sleep-time.min (default 10)
discovery-source.AWS.error.sleep-time.min (default 20)
// Active directory
discovery-source.AD.success.sleep-time.min (default 10)
discovery-source.AD.error.sleep-time.min (default 20)
// VCenter
discovery-source.VC.success.sleep-time.ms (default 500)
discovery-source.VC.error.sleep-time.min (default 5)
// Azure ARM
arm.sleep.success.minutes (default 5)
arm.sleep.error.minutes (default 5)
Active Directory Syncing
Regular Syncing (Every 10 Minutes by Default, Assuming Success):
- JetPatch checks for and adds new computers created or changed in the last 10 minutes.
- However, it does not immediately remove computers or update changes in security groups.
Full Scan (Every 24 Hours):
- Every 24 hours, JetPatch performs a full scan to update all computers, including removals and security group changes.
- In order to manually force a full scan source, you can disable, then re-enable Active Directory discovery.
Sync Timing:
- After a successful sync, JetPatch waits 10 minutes before the next check.
- If there’s an error, JetPatch waits 20 minutes before trying again.
- These intervals can be configured using the polling properties mentioned in the previous section.
AWS Organizations Multi-Account Support
JetPatch can connect to the Master (or Trusted) account in a given AWS Organization, allowing the user to have access to list the available child (or Trusting) accounts and to assume the role of all child accounts.
Initial configuration
In the AWS Organizations management account, perform below steps
- Create IAM user demo-master
- Attach AWS-managed inline policy
- AmazonEC2ReadOnlyAccess
- AWSOrganizationsReadOnlyAccess
Create customer inline policy demo-sts-assume-policy. Below is the JSON
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:ListRoles",
"sts:AssumeRole"
],
"Resource": "*"
}
]
}
In the AWS organization member account, perform the below steps
- Pre-requisite- All the member accounts should have IAM Roles created
- Create IAM Role example member-role
- Attach AWS managed inline policy
- AmazonEC2ReadOnlyAccess
- Under Trusted relationships add Trusted entries as below
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<managemnt-account-number>:<user>"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
In JetPatch In order to use this feature, you must enable it in intigua.properties
aws.members.fetch=true;
In order to modify the default member role, use the “aws.members.role“ in intigua.properties
aws.members.role="demo-slave-role";
For any troubleshooting, search for AssumeRole in the discovery.log of the manager logs.
Comments
0 comments
Please sign in to leave a comment.