This article explains how license activation works when using ZappySys SSIS PowerPack or ZappySys ODBC PowerPack in environments where machines or runtime resources are created dynamically.
This is especially useful when you are using:
- Dynamically created VMs
- Scripted VM provisioning
- CI/CD-based VM rebuilds
- Azure templates, ARM, Bicep, Terraform, or similar automation
- Azure Data Factory SSIS Integration Runtime
For simplicity, this article refers to ZappySys SSIS PowerPack and ZappySys ODBC PowerPack together as ZappySys PowerPack.
Why activation issues can happen
ZappySys PowerPack license activation is associated with a stable machine or resource identity.
If the same environment is stopped and started again, activation usually continues to work without any issue.
However, if the machine or Azure resource is deleted and recreated with a different name or identity, the licensing system may treat it as a new environment. This can cause activation to fail if the license is already assigned to the previous machine or resource identity.
Scenario 1: Azure Data Factory SSIS IR
If you are using ZappySys PowerPack inside Azure Data Factory SSIS Integration Runtime (SSIS IR), you usually do not need to reactivate the license every time the SSIS IR is stopped and started.
As long as the Azure resource identifier remains the same, the license activation is remembered and reused automatically.
For example, the license is typically tied to a resource path similar to this:
/subscriptions/40b04efc-xxxxxx/resourcegroups/adf/providers/Microsoft.DataFactory/factories/mycompany-adf-prod/integrationruntimes/ssis-ir-1
Activation should continue to work if the following items remain the same:
- Azure Subscription
- Resource Group
- Data Factory name
- SSIS IR name
Stopping and starting the SSIS IR normally does not cause a new license activation, as long as the SSIS IR resource itself is not recreated with a different identity or name.
Scenario 2: Self-hosted or dynamically created VMs
If you are installing ZappySys PowerPack on your own VM, the license is usually associated with the machine identity.
If you recreate the VM using scripts or automation, activation should continue to work as long as the machine name remains the same.
However, if your automation generates a new random machine name every time the VM is deleted and recreated, the licensing system may treat it as a different machine. In that case, activation can fail because the license may already be assigned to the previous VM or machine name.
Recommended approach
To avoid unnecessary activation issues, keep the machine or resource identity stable.
For self-hosted or dynamically created VMs, use a fixed machine name when provisioning or rebuilding the VM.
Good example:
ssis-prod-vm-01
Avoid random machine names such as:
ssis-prod-vm-a8f92x
ssis-prod-vm-k29d7q
ssis-prod-vm-20260428-random
For Azure Data Factory SSIS IR, keep the same Data Factory name and SSIS IR name when restarting or redeploying the runtime.
Keeping the machine name or Azure SSIS IR resource name stable helps ensure the license is reused for the same environment instead of being treated as a new activation.
Summary
Use a stable identity whenever possible:
- For Azure Data Factory SSIS IR, keep the same Azure resource path.
- For self-hosted or dynamically created VMs, keep the same machine name.
- Avoid randomly generated VM names if the VM is meant to replace the same environment.
This helps avoid unnecessary reactivation problems when the same environment is rebuilt, restarted, or redeployed.