Provisioning

Last updated on Jun 24 2025.

Inuvika OVD Enterprise 3.4 adds the ability to integrate your OVD Session Manager directly with your choice of virtualization platform. This can be on premise, hybrid, or cloud-based utilising both simple hypervisors such as Nutanix AHV, Proxmox, VMware vSphere, and VergeIO through to cloud providers such as Zadara, Microsoft Azure, Google Cloud Platform (GCP), and Amazon AWS.

This new functionality allows you to deploy both shared and dedicated OVD Application Server instances that run either Windows 10/11, Windows Server, or a Linux Server based operating system (Ubuntu 22.04/RHEL8) from a gold master template, or multiple templates curated for different use cases.

You can spin up and spin down on demand, plus there is the ability to set a working hours schedule where required.

Pre-requisites

1. Firewall rules to allow the provisioning server to talk to other OVD Session Manager outbound on port 1111 and inbound on port 1112

2. Firewall rules to allow the provisioning server to talk to your cloud platform/hypervisor (generally via HTTPS)

3. Connectivity to api.inuvika.com via HTTPS (Port 443) to allow the platform list to be dynamically updated with the latest available options

4. A basic understanding of how virtual machine image management works (gold masters)

5. Full administrator access to your choice of cloud platform/hypervisor

How to enable Provisioning

Provisioning requires an additional role to be installed to allow it to be controlled from the Administration Console.

This can be installed on the OVD Session Manager via the OVD One Touch Installer (recommended), following the guidance on One Touch Installation, choosing the additional Provisioning Server option, and entering 127.0.0.1 when asked for the IP of the OVD Session Manager.

You can also install the Provisioning role on a seperate virtual machine, which may be more appropriate for firewall purposes in complex networks. In this case, enter the real world IP of your OVD session manager when requested.

Once Provisioning has been successfully installed and registered, you will now have a new Provisioning menu available in the Servers tab of the Administration Console.

This page allows you to configure Platforms - by this we mean your Hypervisor or Cloud Provider of choice.

The underlying technology used here is Terraform, so as long as the platform you wish to integrate has a Terraform Provider (see https://registry.terraform.io/browse/providers to search for yours), it can be added. If you use a platform we don't currently list, please contact Inuvika Support to get it tested and added in.

Adding a Platform

To add your platform (or platforms) to the Administration Console, navigate to Servers > Provisioning

Click the magnifying glass button which will load the Choose a Platform menu. We have included the most common hypervisors and cloud providers in this list which are fetched from an online service for easy configuration.

Note

When running OVD without internet access, an offline list is used, but it could be outdated.

Some additional files might be required from the Terraform registry in order to get the Provisoning functional.

For unlisted providers, you can either add this via the Advanced button by filling in the Terraform and Metadata sections, or you can contact the Inuvika Support Team, and we can add your platform to the supported list which will then preconfigure several fields within the Provisioning feature.

Choose your platform from the list, and you will be taken back to the Provisioning Tab now pre-filled with basic platform information.

Proceed to fill in your platform information, and click Test. If successful, you will get a confirmation message. This test only checks the syntax but not the connectivity to the platform/hypervisor.

Press Save.

What to do if the test fails?

If the test is unsuccessful, please check the details entered and try again

Note that all fields may be case sensitive depending on the platform used, and it is important that all spaces are included or excluded as required.

Linking your Platform to your OVD Provisioning Server

On the Provisioning tab, click Manage against your newly created platform.

Scroll down the page and you will see the OVD Provisioning Servers section

Usually, you will only see one server in this list. However, in a more complex environment, you may see multiple choices.

Click the Link button, which will ensure that your chosen Provisioning Server (usually the Session Manager) has permission to use and control the Platform you have added.

Now you have linked your Platform to your OVD Provisioning Server, we are ready to create our Gold Master image.

Gold Master Images

Important things to note:

1. OVD has no visibility or control over anything the Gold Master Image contains

2. OVD cannot perform the vm-to-template conversion (or vice-versa), so this has to be performed manually on your platform.

3. OVD expects your platform to be able to both create and destroy virtual machines in a reasonable time frame. If your platform is too slow, this may affect logon speeds if virtual machines cannot be deployed fast enough, where users are waiting for a VM to be deployed.

4. OVD does not control any networking, therefore your deployment network will need to use DHCP, and your Gold Master Image set to use DHCP instead of Static IP Addressing.

Creating your Gold Master Image

Deploy an OVD Application Server as per the guidance in the One Touch installation or Manual Installation Guide.

Give your VM a sensible name as this will be needed in the next step.

You should then proceed to install and configure all software that will be included with your Gold Master Image ahead of converting.

Next, you should register the OVD Application Server on the Administration Console. You can either Register or Register as a Template.

Register creates a standard Application Server which you have the option to convert to an OVD template, whereas Register as a Template skips the conversion step and automatically creates your new Application Server as a template.

Note

We would recommend using Register as a Template for simplicity.

Once registered as a template, a new section will appear in Registered Servers named Provisioning Templates. Your new Application Server Template should show in this list as In Maintenance.

If using Windows 10/11/Server, you can now proceed to configure SYSPREP via Server Scripts inside the OVD Administration Console or via the Template Settings if your hypervisor supports it (currently VMware and Nutanix only - you may however prefer to use the OVD Server Scripts approach as it does provide more control). If using Ubuntu/RHEL, then perform any prep as required using cloud-init or similar.

Once your VM has been fully prepared, shut it down and convert it to a template directly on your chosen platform. OVD cannot perform this step for you.

Your new Application Server Template should now show in the Provisioning Templates list as In Maintenance.

Performing SYSPREP via Server Scripts

OVD 3.4.1 brings a new functionality called Server Scripts which allows you to choose a templated script from our library, or run something completely custom. These scripts are exectuted by the Inuvika OVD Desktop Agent running at service start-up, or service shutdown. They can be configured to run one, or run at every start-up/shutdown event as required.

One primary use of this functionality is the ability to do SYSPREP on start-up for templated application servers/desktop images.

To get started, we need to create a Server Group that contains your newly created Gold Master template.

On the administration console, go into Servers > Server Groups. Choose an appropriate name (and description) and click "Add". Your newly created group will automatically load.

Now, in the List of servers in this group section, select your template from the drop down list. ** There may be multiple templates to choose from, so choose carefully **

Next, go into Servers > Server Scripts.

Click the Magnifying Glass, choose Sysprep, change the Name: field as appropriate, then select "Add This Script"

Proceed to click the name of the new script you have created in the list now showing.

Scroll to the top of the text editor window where you can now uncomment (by deleting the '#' on each line as appropriate) the settings you require to set.

At minimum, you must configure the following fields (shown with placeholder information)

• 'organization': 'name of your organization',
• 'admin_password': 'what you want the local admin password to be',
• 'domain_name': 'domain name in FQDN format i.e. inuvika.com',
• 'domain_username': 'Domain join username',
• 'domain_password': 'Domain join password',
• 'machine_ou': 'Destination OU for the VM i.e. OU=OVD VDI,DC=inuvika,DC=com',

We recommend creating a service user that has the ability to Join the domain only for this purpose. Do not use a Domain Administrator account.

machine_ou must be in DN format. This is accessible via Active Directory Users & Computers > View > Advanced Features (tick), then create the new OU (if required), right click it, Properties, Attribute Editor > Select distinguishedName and click View. Proceed to copy and paste the value into the machine_ou field in the SYSPREP script.

Warning

dns_servers, timezone and vm_locale are optional and should only be used if explicitly required.

Once you have uncommented and changed each field as appropraite, click "Modify"

Now at the bottom of the page, inside List of Server Groups including this script, click inside the drop down and choose the Server Group containing your template that you created earlier.

Once this link-up has been performed, your template will run SYSPREP at first boot.

Note

When using on Windows 11 or Windows Server 2025, you may have issues with SYSPREP where it struggles to remove existing Appx packages. We have created a removal script inside the template library to deal with this which you apply in the same manner as above. Copilot is used in the example script, but you can pull the correct package name from the Status & Reports > Log > Provisioning Logs. Note that scripts are ran in alphabetical order, therefore you removal script should be named alphabetically before your sysprep script.

Note

It is also important to note that Bitlocker may be enabled by default. You must disable Bitlocker to be able to deploy machines based on gold maste templates.

Configuring Template Settings

Click into your newly created template from the Provisioning Templates list

In here, you can configure all the template specific settings related to deployment and general virtual machine function.

Below is a summary of all settings, explaining what each setting does.

Summary of Configuration Section

• Display Name: Set a custom display name instead of the automatically generated name

• RDP port for this server: If you are using a custom RDP port instead of 3389, please change this as required

• Switch to Maintenance/Switch to Production: This allows you to take the template in and out of maintenance mode. When in maintenance mode, no automatic provisioning will take place.

• Revert to Regular Server: You can convert an OVD Provisioning Template back to a standard OVD Application Server. Note that you must convert the template back to a VM, and ensure it is running on your chosen platform before a conversion is possible. Then set the correct IP address in the FQDN field.

• Clone: Make a copy of the current template allowing additional customisation with different working hours or published groups, for example.

• Delete: Remove this OVD Provisioning Template from your environment. Deletion cannot be undone and all dependant VM instances will be deleted during the top-of-the-hour collection.

Summary of Template Configuration Section

• Deployment Mode: There are two options here:

  • Shared, meaning an application server delivering application and desktop sessions to multiple users usually running Windows/Linux Server Operating Systems.

  • Dedicated, meaning an application server for one user only for either an application or desktop-based session (commonly known as VDI) usually running Windows 10/11 but could also be Windows/Linux Server Operating Systems. Dedicated mode also enables Protected mode, which prevents the instance from being automatically deleted when unused.

• Instance protected by default: It prevents the instance from being automatically deleted when unused. Instances assigned to user in Dedicated mode will never be automatically removed, regardless of this option.

• Power-Save Idle Instances outside working hours: This option is available only if supported by the target platform. When enabled, OVD will shut down unused instances outside the defined working hours to save resources.

• Power-Save Idle Instances inside working hours: This option is available only if supported by the target platform. When enabled, OVD will shut down unused instances inside the defined working hours to save resources.

• Delete instance on logout (Dedicated mode): Instance is deleted when the linked session is finished.

• Maximum Instances: The absolute maximum number of instances that OVD will provision from this template. This is a safe-guard feature to prevent over-provisioning.

• Minimum available sessions outside working hours: Where working hours have been specified, OVD will ensure that there are enough instances to support the defined number of users outside of the defined working hours.

• Minimum available sessions inside working hours: Where working hours have been specified, OVD will ensure that there are enough instances to support the defined number of users inside of the defined working hours.

• Defined Working Hours Used in conjunction with the two settings above. This allows you to set a time window your business working hours to allow for different VM numbers based on a time schedule.

• Apply Instantly: This button will apply the configuration changes immediately instead of waiting for the top-of-the-hour timer to apply them

Summary of Terraform Configuration Section

• Platform: Choose which platform this template is accessible, and will be provisioned from

• Virtual Machine Type: This will vary depending on your chosen platform. Some platforms allow for multiple different VM types, so please choose correctly based on your needs.

• Advanced:

  • Terraform: Allows you to customise the Terraform provider further to suit your needs if required. See Terraform for more information.

  • Metadata: Allows you to customise the Terraform metadata further to suit your needs if required. See Metadata for more information.

Some dynamic parameters will show depending on what the Metadata field contains. They have different meaning depending on the platform or the type of VM created. For example, a Proxmox provider VM could look like:

• Template Name: This is the name of the Gold Master Image template created in the previous step. Please enter this exactly as it is named.

• VM Name Prefix: Customise the prefix that OVD will apply to virtual machines cloned from your template. The default machine name would be ovd-sum7skt for example, where the ovd- section is customisable.

• Cores: Define how many Cores (vCPUs) your cloned instances will have

• Memory: Define how much memory in MB your cloned instances will have

Summary of Instances section

• New Instance on Demand: This allows you to create a new instance based on the configuration of the previous section instantly. Useful for testing

• Rebuild Instances: Automatically rebuild your existing instances based on an updated Gold Master Template or where you have changed the Cores and Memory in the previous section, for example.

Summary of Role: Application Server - Access Parameters section

• Current Access Policy: There are two options here:

  • Open to All Users: This allows the provisioned instances to be accessed to all users as per their application group publishing rules.

  • Restrict to Group Membership: Restricts the provisioned instances so they can only be accessed by the defined user groups regardless of application group publishing rules

• Advanced Priority: Set to 0 as default. This is a weighted metric useful, for example, where you have multiple platforms accessible to the same users, but want to steer users to a primary platform first (through the use of multiple templates with different priorities set).

• List of Server Groups including this server: Where server groups are in use, you can see what groups this template has been added to and add/remove it if needed.

Summary of Role: Application Server - Server Parameters section

• Number of available sessions on this server: Defines the number of concurrent users (sessions) each instance will permit.

• Activate Memory allocation enforcement: Where memory has been defined in Resource Restrictions, this setting guarantees that users will always have the memory their session requires. If the application server does not have sufficient free memory, the session will not be allowed to start.

• Reserved System Memory: Allows you to set the amount of memory in MB that should be reserved for Operating System use to ensure performance.

Summary of Role: Application Server - Applications available on this server section

This shows a list of detected applications from the Start Menu (or equivalent folder) on the Gold Master Image

What needs to be set on the Template Configuration Page

You will need to go through and at a minimum set:

• Template Configuration

  • Choose a Deployment Mode

  • Define working hours and instance limits (if required)

• Terraform Configuration

  • Check the Platform in use

  • Set the Virtual Machine Type

  • Set the Specific VM Type settings

• Role: Application Server - Access Parameters

  • Set the Current Access Policy

  • Add to a server group (if required)

  • Set the Number of available sessions on this server

  • Set the Reserved System Memory

How to do Pooled Session Based Apps/Desktops

A pooled session-based desktop is where a user is allocated to an application server based on their group membership and/or access policy defined on the template. User profile data roams with the user, but any specific VM customizations will not follow them. This can be Desktop OS or Server OS based, and many users can connect at one time up to the defined limit.

To publish pooled session-based desktops

• Choose Shared Deployment Mode

• Set Number of available sessions on this server as appropriate based on resources

• (somewhere 30-60 users is the recommended figure)

How to do Pooled One-to-One Desktops

A pooled one-to-one desktop is where a user is allocated to an application server based on their group membership and/or access policy defined on the template. User profile data roams with the user, but any specific VM customizations will not follow them. This can be Desktop OS or Server OS based, but only one user can use an instance defined this way at any point in time.

To publish pooled one-to-one desktops

• Choose Shared Deployment Mode
• Set Number of available sessions on this server to 1

How to do Non-Pooled (Persistent) One-to-One Desktops

A non-pooled (persistent) one-to-one desktop is where a user is allocated to their own instance, and it remains theirs until it is destroyed. When they log into OVD for the first time, the user will be automatically allocated and locked to a specific instance. Administrators can also manually assign users to instances by clicking inside the instance and setting the Assign to Specific User field. This can be Desktop OS or Server OS based, but only one user can use an instance defined this way at any point in time.

To publish non-pooled desktops

• Choose Dedicated Deployment Mode

Note

Note that there is no requirement to publish any applications to your users. They will receive a desktop automatically.

Pushing your Template into Production Mode

Once you have made your changes, ensure you hit Change/Save as appropriate for the setting configured.

Then, at the top, click Switch to Production

Finally, press Apply Instantly which will trigger the Gold Master Image template to begin deploying on your Platform up to the defined limits.

You can now proceed to configure your Application Group to User Group publishing and any other configuration as per a standard OVD environment

Useful Troubleshooting Information

The Provisioning logs on the Status & Reports > Logs tab can be very useful to diagnose issues in your provisioning process. It is important to remember that due to way that Terraform works, OVD simply asks the hypervisor/platform to go and provision a VM based on configuration as set. If the hypervisor/platform does not report back, OVD is unaware that the process has been successful or experienced failure, so the logs may need careful interrogation in case of unexpected behaviour.

If you end up in a situation where Terraform becomes locked and cannot proceed, you can stop this process via Servers > Provisioning > Choose your Platform > Scroll down to the "OVD Provisioning Servers" and click Abort Execution as appropriate.

Advanced configuration

Terraform

The Terraform field contains the equivalent of a .tf HCL file with some Jinja2 templating. The available template variables are defined in the associated Metadata field with some additional values.

For a Platform configuration, the fields contains:

• ovd_backend: Is a configuration to add to the terraform {} structure in order to store the Terraform state and lock in the OVD Database.

• hypervisor_name: The internal unique identifier given to this hypervisor.

For a Virtual Machine configuration, the fields contains all the parameters from the Platform configuration plus:

• name: The unique internal name of this Virtual Machine, to be used as the Terraform resource ID (e.g. resource "aws_instance" "{{ name }}" {}).

• server_type: windows or linux

• server_version: The detected Operating System Details

• server_hash: A big integer uniquely identifying the current server instance. This can be used as a seed for random host fencing.

• counter: An incremental number defined for the template that starts from 1 and is reused, removing gaps.

• initialization: Used to define template initialization sections set to true only for the first VM in the file.

Some additional Jinja2 filters are available in addition to the defaults:

• b64decode: Decode a base64-encoded string and returns a binary data. Compose with str to render a string. E.g., name = "{{ name|b64decode|str|e }}"

• b64encode: Encode a binary or string data to a base64 string. E.g., data = "{{ 'some value'|b64encode }}"

• bool: Converts the value to an HCL boolean value. E.g. secure = {{ secure|bool }} results in either true or false

• bytes: Convert to binary data. E.g., value = "{{ "data" | bytes }}"

• e and escape: Are used to protect the String values in HCL syntax. E.g. name = "{{ name|e }}" correctly escape the quotes " and special characters like \n or \.

• hash: Generate a hexadecimal-encoded hash of the data. Supported algorithms include: sha1, sha256, md5 and more. E.g. name = "{{ name|hash('sha256') }}" returns the sha256 of name.

• hexdecode: Decode a hexadecimal-encoded string and returns a binary data. Compose with str or b64encode to render a string. E.g., data = "{{ '68656C6C6F'|hexdecode|str|e }}"

• hexencode: Encode binary or string data to an hexadecimal-encoded string. E.g., data = "{{ 'some value'|hexencode }}"

• str: Convert to a string. E.g., value = "{{ 34 | str }}"

• tag: Convert the String to a lower case value containing only a-z, 0-9, and -. This is useful to generate predictable filenames or VM names. E.g. With name set to My New #Server, name = "{{ name|tag }}" results in my-new--server.

• xmlescape: Escape XML/HTML strings. E.g., {{ '<a b="c">' | xmlescape }} results in <a b="c">

Metadata

The Metadata field allows to create custom UI elements in the OVD Administration Console to configure the Terraform Jinja2 template.

It is defined as a Json document containing a list of fields to display.

Each field is defined with a map containing:

• id: The variable name

• name: The caption to display in the Administration Console

• type: The type of variable, one of text, password, integer, bool, select

• defaultValue: The default value

• values: (optional) lists all the possible values for a select field

• required: (optional) true or false indicates if the field is required or not. Defaults to true.

Example:

[
    {
        "id": "image",
        "name": "Image Id",
        "type": "text",
        "defaultValue": "ami-"
    },
    {
        "id": "api_token",
        "name": "API Token",
        "type": "password"
    },
    {
        "id": "thin",
        "name": "Thin provisioning",
        "type": "bool",
        "defaultValue": true
    },
    {
        "id": "cores",
        "name": "Number of CPU Cores",
        "type": "integer",
        "defaultValue": 8
    },
    {
        "id": "tenancy",
        "name": "Tenancy of the instance",
        "type": "select",
        "values": ["dedicated", "default", "host"],
        "defaultValue": "default"
    }
]

How to stop Terraform deployment

Terraform deployment is a blocking action that may take some time to complete. In some cases, aborting the process may be necessary.

In the Provisioning page, under the Platform management section, an orange status indicator shows that the plaform is busy and which Ovd Agent is managing the action. You can click on Abort Execution to stop Terraform.

Warning

Stopping the pending action can leave your infrastructure in an inconsistent state. This might result in:

• Partially applied changes.
• Resources not being properly created, updated, or destroyed.
• Terraform being locked.

Manual intervention may be required to fix the state, so unless absolutely necessary, it is recommended to allow the action to complete.