There is no direct documentation or feature in InterSystems Package Manager (IPM) that specifically addresses handling System Default Settings for CI/CD pipelines. However, here are potential approaches based on available information:

1. System Default Settings: These settings simplify management of environment-specific configurations, such as file paths, port numbers, etc., and can be exported/imported using methods like %Export and %Import. It is advisable to integrate these methods into your pipeline processes to automate these tasks [1][2].

2. Custom Automation: While not directly tied to IPM, you can use tools or scripts, such as the GetSettingsFromProduction method, to gather and setup System Default Settings efficiently during the deployment process. This method allows filtering specific settings and automating their migration to the system defaults table [3][4].

3. Source Control: System Default Settings can be exported and tracked in version control. Each branch or CI/CD environment can include specific setting files, which can then be applied programmatically during deployment [2].

If Invoke scripts are acceptable for your case or specific automation needs, they could wrap around these export/import or automation methods to ensure smooth integration without extending IPM itself. For completely eliminating custom solutions, consider submitting a feature enhancement request on InterSystems Developer Community.

Sources:

1. To list a user and their properties, including roles, you can use ObjectScript commands with the Security.Users class in the %SYS namespace. An example of listing the properties of a user is:

NEW $NAMESPACE
SET $NAMESPACE="%SYS"
SET status = ##class(Security.Users).Get("Username", .properties)
IF $$$ISOK(status) {
    ZWRITE properties
}

This retrieves the user's properties into a reference variable and displays them [1][2].

2. To add a user and set their properties, including roles, you can use the Create method of the Security.Users class. For example:

NEW $NAMESPACE
SET $NAMESPACE="%SYS"
SET properties("FullName") = "New User"
SET properties("Password") = "securepassword"
SET properties("UserRoles") = "%Developer,%Operator"
SET status = ##class(Security.Users).Create("NewUser", .properties)
IF $$$ISOK(status) {
    WRITE "User created successfully."
}

This creates a user with specified roles and other details [1][2].

3. To set a user's password, you can use the Modify method to update the relevant property, as in:

NEW $NAMESPACE
SET $NAMESPACE="%SYS"
SET status = ##class(Security.Users).Get("Username", .properties)
IF $$$ISOK(status) {
    SET properties("Password") = "newpassword"
    SET status = ##class(Security.Users).Modify("Username", .properties)
    IF $$$ISOK(status) {
        WRITE "Password updated successfully."
    }
}

This updates the user's password [1][2].

Sources:

The use of a separate license server in an HA mirroring environment, such as hosting it on the arbiter machine, might alleviate licensing issues during failovers. Below are key considerations regarding licensing and communication between mirrored servers and users:

1. Role of ISCAgent and Arbiter: The ISCAgent on arbiter machines assists the failover process by ensuring communication reliability between mirror members, even during failovers [1][2]. It does not directly manage user sessions but enables seamless failover between mirrored servers.

2. Licensing Impact on User Sessions: The documentation does not explicitly mention whether adding a license server to the arbiter would prevent users from logging back in after failovers. However, setting up proper failover mechanisms and ensuring that the ISCAgent process is correctly configured on all mirror members can help maintain application continuity during failover [1][2][3].

3. Configuring ISCAgent for Communication: The agent can be configured using /etc/iscagent/iscagent.conf to define the server port and interface. Proper configuration of this communication layer can strengthen connections between mirrored members [3].

Without further specific documentation on the license server itself, you might need to test or consult with support to understand potential benefits or issues before adopting such a setup.

Sources: