Azure VM ScaleSets and Autoprov_cfg

[wralondxc]

Greetings Fellow Community Members,

        I have an existing VMSS deployed in one Azure region and it has been running for a while now.  Recently, the need has developed to deploy a 2nd VMSS in a separate Azure region; but same tenant and subscription.  I have created a new template and controller for this, each with separate values distinct from the existing VMSS/CME(cloud management extension) configuration.  When I go to run the 'autoprov_cfg init' command with my new template and controller parameters, I always get the following warning:

warning: configuration exists, previous settings will be deleted. First make sure that there are no Gateways that are auto-provisioned with this configuration.To do so, terminate all the Gateways in the cloud environment and make sure that the objects that represent them in the SmartConsole are removed. Initializing the configuration before its Gateways are removed may cause unexpected behavior. Are you sure you would like to initialize the configuration? (y/n)

What concerns me about this warning message is the bit with "First make sure that there are no Gateways that are auto-provisioned with this configuration."  Since my entire CME configuration contains the previous and new settings, I DO in fact have a gateway auto-provisioned with this configuration.  Will there be any negative impact to my existing VMSS gateway if I proceed? Am I over thinking this?

Thanks in advanced!

~berto

[_Val_]

@Shay_Levin can you assist please?

[GBrembati]

Hi wralondxc,

You are correct, please do not initialize the CME again, or you will lose the current controller configuration.

The initialization procedure needs to be done only during the first deployment, in your situation, I see that you need to connect a second VMSS. For these, you would most likely want to create a new controller (way of authenticating against the new environment) and a new template (which says how to instruct the newly onboarded gateways).

In order to do so, you can use the "add" commands, which would not impact the current configuration:

# autoprov-cfg add template -help
# autoprov-cfg add controller -help

Since you are using the same Azure Tenant and subscription, you may want to avoid creating a second authentication for the CME. You can use the same controller (application registration in Azure) that you used for the first one, by just extending its permission to view the new RG and Vnet where the second VMSS is running.

In the end, you would just create a second template representing the second gateways configurations (blades/policy package/etc.):

# autoprov_cfg add template -tn CONFIGURATION-TEMPLATE-NAME> -otp <SIC-KEY> -ver <VERSION> -po <POLICY-NAME> 

And with the relevant fields for the blades that you want to use, you can take a look at the CME Template documentation here: https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CME/Content/Topics-CME/CME_Structure_...)

Hope it helps,
Giorgio

[wralondxc]

@GBrembati  - thank you so much for your reply.  One thing to re-iterate, I added a 2nd template and 2nd controller to the CME configuration for this.  That is wanted to confirm that I should not see any impact to my existing VMSS since I am running the init against a different controller/template pair. Kindly confirm that if you will.

       With regards to your comment about using the existing controller and credentials that currently deployed the existing VMSS... how would simply defining a new template be enough parameters for the manager to know that my intention is to spin up a new/different VMSS?  Meaning, if I create a new VMSS, and I extend the permissions of the existing controller to the new VMSS; what specifically in the template configuration differentiates the new VMSS from the previous?  From what I have observed, and from what you have pasted in your sample autoprov_cfg configuration above, there is nothing that tells the controller about the difference between the 2 VMSS's.  That is why I thought it prudent to create a new set of credentials to be used for the new VMSS.  Perhaps I overlooked something?

[GBrembati]

@wralondxc the management knows you are using a different VMSS by looking at the template name.

The way CME works is that when the management connects to Azure via the controller, it will look for VMSS that matches its configuration. The template represents a scalable group of machines (Virtual Machine Scale-Set in the context of Azure).

Whether you have deployed yours via ARM template (through the marketplace) or via Terraform, you would see that the VMSS machines have tags which is what the management will look for. One of the tags says the name of the management in the CME, which interface needs to be used for management purposes, and among the rest, the template name (which you want to be unique).

If all the tags match what is defined in the CME (management name, template name) then the CME applies the specific template configuration to this pool of gateways and provisions them (SIC connection, blade activation, 2 policy install).