Updated: Aug 18, 2020
Let´s start this off with "Why"
Since the release of User Environment Manager 9.1 (god, thats already three years ago) I was thinking from time to time about the introduced feature called NoAD mode and its purpose or potential for non-VDI use cases, but never found a proper answer to that question.
The NoAD mode is an alternative to configuring User Environment Manager with Active Directory Group Policy. In the NoAD mode, there is no dependency on Active Directory. You do not need to create a GPO, any logon and logoff scripts, or configure Windows Group Policy settings.
Then I recently read an outstanding article called Understanding Windows 10 Group Policies: VMware Workspace ONE Operational Tutorial written by Josué Negrón and other VMware EUC veterans where one sentence related to Baselines caught my attention:
Baselines are based on GPOs and depending on the policy can be applied on the device using DEM, SecEdit, AuditPol, or LGPO (only custom baselines)
This was also mentioned on the WS1 UEM Baselines Feature Walk-trough Video.
Which let me assume that DEM is meanwhile built-in to WS1 UEM Hub on Windows, which unfortunately turns out not being the case, as only a small fraction of DEM is baked into the Agent. Anyhow that inspired me to dig a little deeper if DEM in noAD mode would work on a WS1 managed non-domain joined device and what it can bring - Spoiler: it does work and I see great potential.
If this sounds interesting to you, continue reading. In this article I will describe how-to:
Install (Prepare & Deploy)
Configure (Define & Distribute)
Maintain (Update best-practices)
the combination of Workspace ONE UEM und VMware Dynamic Environment Manager.
To get DEM working in noAD mode you obviously need to deploy the Agent to your devices; the installation expect to find a license file (download yours from my.vmware.com) plus a so called NoAD.xml configuration file during installation.
msiexec.exe /i "VMware Dynamic Environment Manager 9.11 x64.msi" /qn LICENSEFILE="<pathto>\VMware DEM.lic" /l* InstallDEM.log NOADCONFIGFILEPATH=<pathto>\General
According to the product documentation the XML filename needs to be NoAD.xml and must reside in the…\General\FlexRepository\NoAD subfolder. Which means we need to transport this two files (lic & xml) before executing the installer.
But before that we need to create our NoAD.xml first, to define our configuration. You can find all available settings on VMware DEM Product Documentation page and make sure you save it in UTF-8 encoding.
<?xml version="1.0" encoding="utf-8"?> <userEnvironmentSettings> <setting type="noAD" ProfileArchivePath="C:\Users\%username%\OneDrive - <DEFINE TO FIT YOUR ENVIRONMENT>\DEM_Personalisation" BackupPath="C:\Users\%username%\OneDrive - <DEFINE TO FIT YOUR ENVIRONMENT>\DEM_Personalisation\Backups" BackupCount="10" BackupDaily="1" LogFileName="C:\Users\%username%\OneDrive - <DEFINE TO FIT YOUR ENVIRONMENT>\DEM_Personalisation\FlexEngine.log" LogLevel="1" HideProfileArchiveFolder="1" HideBackupFolder="1" DirectFlexNotification="1" ConfigPathMissingAction="0" ArchivePathMissingAction="1" AppBlockingEventLog="1" EventLog="1" EventLogAsync="1" EventLogDirectFlexRefresh="1" EventLogUEMRefresh="1" /> </userEnvironmentSettings>
Two remarks here:
My goal was to redirect DEM Personalisation (aka the Archive-Folder) to OneDrive for Business to allow Cloud-Roaming, please adapt to any path which better suite your requirements (Local Profile, GoogleDrive, whatever)
Even if I instruct DEM to hide the Personalisation and Backup Folder (HideProfileArchiveFolder="1"), I renamed them to something more meaningful for end-users who maybe have hidden files visible rather to call it "Archives"
Now we have three options deploying all we have so far:
Copy the two files (license + xml) using WS1 Product Provisioning and deploy the MSI incl. Parameters as Win32 Application
Wrap everything into one Package (eg. by using PSAppDeployToolkit) and use Copy-File (license + xml) just before kicking-off Execute-MSI
Modify the MSI to includes the two files (eg. by using Master Packager Free)
Choose a variant based on your preferences, I picked the first option for this article as I don`t wanted to go into packaging topics here (maybe on a later blog post).
Browse to Devices > Provisioning > Components > Files/Actions and instruct Windows to copy the files to the local location you want to reference during installation.
Note: Don´t forget that the installation process expects to find the xml in a specific sub-directory C:\ProgramData\VMware\DEM\General\FlexRepository\NoAD\NoAD.xml
As any other Win32 App deploy the MSI using Apps & Books > Applications > Native
msiexec /i "VMware Dynamic Environment Manager 9.11 x64.msi" /qn LICENSEFILE="C:\ProgramData\VMware\DEM\VMware-DEM-9.11.0-GA.lic" /l* C:\Windows\Logs\VMware_DEM_911_Setup.log NOADCONFIGFILEPATH="C:\ProgramData\VMware\DEM\General"
Leveraging Data Contingencies to make sure the files are present before starting the installation.
After deployment you will find all your settings (out of NoAD.xml) in the registry
Now that we have a working DEM environment, let's do some configuration.
Simply install the DEM Management Console (part of the MSI) on your admin machine; set
as your "DEM configuration share" location to get started.
Use the Management Console to configure whatever you like. Use the VMware DEM Product Documentation pages if you need guidance how to use the product.
After you have finished creating your settings and configurations you need to transfer them to your devices. Again you can choose using WS1 Product Provisioning or wrapping everything to a PSAppDeploy or MSI package to deploy the resulting configuration files out to your devices. The thing that matters is the location of you files.
Worth mentioning that everything you configure in "Personalization" is stored directly in the General path, all others things are stored within the FlexRepository folder and you must mirror the structure so that DEM Agent can "understand" your directives.
As before let´s use Devices > Provisioning > Components > Files/Actions and instruct Windows to copy the configuration files to the required paths.
The DEM Agent will then process them which gives great additional capabilities for managing and controlling Windows devices, such as:
File Type Associations
all powered by DEM´s extensive Condition Engine of course without the Active Directory parts; but who needs them in modern days ;-)
Plus writes everything personalised to our cloud location (OneDrive for Business in my example) for store, roam and if required recover individual user environment.
Last word on updating your configurations. If you have chosen Product Provisioning you need to remove the file from the product set first (X-Symbol) and then upload your updated file. Unfortunately WS1 UEM is yet not smart enough to offer you to update your version on a file which already exists.
Use versioning to increment the file version to keep track on your current deployment.
For Win32 deployment package variants make use of detection criteria by writing version information into the registry with your package and detect upon them.
Set-RegistryKey -Key 'HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware UEM\WS1_ManagedConfiguration' –Name 'Version' -Type 'String' -Value $appVersion Set-RegistryKey -Key 'HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware UEM\WS1_ManagedConfiguration' –Name 'Installed' -Type 'String' -Value 'true' Set-RegistryKey -Key 'HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware UEM\WS1_ManagedConfiguration' –Name 'Last Modified' -Type 'String' -Value $(Get-Date).ToString("yyyy-MM-dd HH:mm")