Deploy Viscosity Windows under a GPO Group Policy Environment
As of version 1.4.5, Viscosity Windows can now be completely deployed and managed via a Microsoft Group Policy Object (GPO). This means for Enterprise users, there is no need to create custom bundles anymore, and you can have much more control over Viscosity’s settings directly from your Domain Controller (DC).
In order to deploy Viscosity, it must first be rolled into a Microsoft Secure Installer (MSI). This is a simple process and there are several tools for this task. You can find one method below.
On Windows 8.1 and below there are a few simple steps that must be done to allow for a completely silent installation. As Viscosity requires a driver to function correctly, you will need to distribute Viscosity’s Signing Certificate before Viscosity is installed. On Windows 10, the Viscosity Virtual driver is WDK signed, so this step is not necessary.
To get this certificate:
- Download the latest version of Viscosity.
- Start the installer and follow the steps. IMPORTANT: When prompted by Windows Security to install the Sparklabs Network adapters, tick “Always trust software from Sparklabs”, then click Install.
- Finish the Installer.
- Open the Certificate Manager (Start -> Run, certmgr.msc, OK).
- Navigate to Trusted Publishers->Certificates, you should see a Sparklabs certificate here.
- Export the certificate by right clicking it and navigating to All Tasks -> Export…
- Add this certificate to your trusted store via GPO to computers that will have Viscosity Installed.
Once this is done, you then need to create an MSI. For a silent install, the MSI should run Viscosity Installer with the following commands:
/SP- /verysilent /NORUN
Creating an MSI (Microsoft Installer)
Please see this article for information on how to wrap Viscosity's Installer into an MSI.
Many automatic package managers have restricted system permissions. One thing this leads to with Viscosity is the need to stop and start Viscosity's Service when updating. You may need to do this manually via scripting with your deployment. There is no special commands that need to be run, simply stop the service with a command like Service Command (sc), update Viscosity by running the latest installer, and then restart the service once installation/updating is complete.
First, grab the GPO ADMX templates here: viscosity_admx.zip
This zip bundle includes two ADMX templates and a matching ADML English language file.
The legacy ADMX file is updated for Viscosity 1.7.5. This template uses older registry locations for preference storage which are not removed when set back to Not Specified. This may be required behaviour for some.
The Viscosity.admx file is new and supported from Viscosity 1.7.6. This uses traditional policy locations for storing preferences and will remove preferences when they are set back to Not Specified in the policy editor. If this template is used (and at least one option defined), any settings defined by the legacy template will be ignored.
Create a new GPO and add the Template. The template will allow you to set settings on a per-user, or per-machine basis. We recommend using per-user settings where possible, but per-machine settings should be used for sensitive settings you do not want your users changing. Settings deployed via GPO will overwrite a user’s settings each time they start Viscosity. If you wish to have settings that a user can change, instead configure and deploy a Settings.xml either via GPO when Viscosity is installed, or by creating a Bundle (Please see Bundling Viscosity with VPN Connections & Preferences (Windows)).
In the same way that settings set on a User level via GPO will overwrite a user’s preferences, settings set on a Machine level will overwrite all other settings for all users each time Viscosity starts. String settings need to appear in your GPO exactly the same way as they appear in a Settings.xml (without tags). For example, to distribute a License:
- Install Viscosity and register the copy using your site license.
- Exit Viscosity.
- Navigate to %appdata%\Viscosity, and edit the Settings.xml file.
- Copy out the string located between the <string> tags under the License key.
- Enable the License setting in your Group Policy Object, and paste the string you copied out into the field provided under Options. (You can find the License object under Policies -> Administrative Templates -> Classic Administrative Templates (ADM) -> SparkLabs -> Viscosity Preferences).
The vast majority of settings are simple check box on or off. Only enable settings you want to set.
Deploying Connections via GPO is the same as deploying any other files.
First, we recommend you configure a copy of Viscosity with connections. Once this is done, exit Viscosity and navigate to %appdata%\Viscosity\OpenVPN. If possible, we recommend you deploy this folder as is to the same place on each user’s PC, as changes made to these configurations, or configurations added by a user, will only be usable/visible by the user who made them. Also, if you have Roaming profiles set up, configurations will follow the user from PC to PC.
If you wish for shared configurations, this is possible by setting a path in the Custom Profile Location setting. There are some caveats to this though:
- The path must be both readable and writable by a standard user.
- It must be a direct path. Viscosity will not be able to expand environmental values.
- Any changes made to connections, or connections that are added or deleted will appear for all users of that PC.
You may also wish to not have connections deployed with Viscosity at all. Viscosity has a very simple Import process, with an import from File process that requires the user to only browse to the configuration, or a simple process to import from OpenVPN-AS, allowing you to distribute sensitive or user specific connection files or .visz packages any way you wish, knowing your users can import them trouble free.
NOTE: We highly recommend you use Single Adapter Mode (Windows) when deploying and/or updating connections via GPO or Roaming Profiles. Normally, the adapter a connection uses is stored in the connection config. If the connection is replaced with a different dev-node, or it is removed, Viscosity will be unable to find the adapter and will create a new one for this connection.
Viscosity automatically updates by downloading the latest installer to %temp% and running it from here. We understand many enterprises lock down this area removing execute rights. In this scenario, you have two options:
- Disable automatic updates and push updates manually:
This is the method we recommend for enterprises with a large install base as it allows you to control updates. While all caution is made with updates via internal and beta testing to ensure stable releases do not cause issues, some enterprises do have setups or differences to a default Windows install, thus we do recommend testing is done on releases before your users are updated. Pushing an update is exactly the same as deploying Viscosity. You do not need to include any bundling as no settings or connections are overwritten, but you can use an update as an opportunity to push new connections as well.
- Allow Viscosity updates to be run from %temp%:
By far the easiest way to allow automatic updates is to simply setup an AppLocker policy for a Viscosity installer. To do this, create a new AppLocker group policy, ensuring Rule Enforcement is already configured. When setting up rules, we recommend the following:
- Set the rule to Allow and set your group, usually the "Everyone" group
- Browse for a Viscosity installer and allow the defaults, this should be the Viscosity signature and publisher. If a filename is used, we recommend setting this up as a wild card for Installers, for example "Viscosity Installer*.exe" to allow for version numbers in installer names.
While planned for a future release, currently connection updating is not supported by Viscosity. It is easy enough however to simply push new connections via GPO, but there are some caveats:
- If allowing Viscosity to manage adapters, the dev-node command must be migrated from the old connection profile to the new or a new network adapter will be created on the next connection attempt.
- Alternatively, we recommend Single Adapter Mode (Windows). Though this will only allow a single connection at a time, this is fine for most setups.