Install Omnissa DEM Application Profiler

原文：Install Omnissa DEM Application Profiler — theDXT (Daniel Keer)

The Omnissa DEM (Dynamic Environment Manager) application profiler is a tool you can use to determine what you need to capture to make sure the user’s application settings and data are saved and roam with the user.

In this post, I will show you step by step how to install the Omnissa DEM Application Profiler.

Prerequisites

• A Windows VM running Windows 10 or 11 Professional or Enterprise edition.

If you plan to capture an application that will run on a terminal server, you should install Windows Server 2016 or newer to capture everything correctly.

What the Application Profiler Actually Does

Before installing anything it helps to be clear about the problem this tool solves, because it is easy to assume DEM will magically roam everything and then be surprised when it does not.

Dynamic Environment Manager works by applying a set of configuration files that tell it which folders, files and registry keys belong to which application, and how to handle them at logon, logoff, and when the application starts and exits. Those configuration files are only as good as the list of locations they contain. If the list misses the folder where an application stores its templates, or the registry key that holds the user’s layout, the user will find that their customisation is missing the next time they log on to a different desktop — and the reason will not be obvious.

The application profiler exists to work that list out for you. You give it a clean machine, install the application under observation, use it the way a real user would, and the profiler records every file and registry write the application makes. It then distils those changes into a report you can turn into DEM configuration. It is essentially a controlled experiment with a detailed audit trail, and it is far more reliable than guessing from documentation, which is very often incomplete.

The tool is sometimes confused with the DEM configuration editor or with the DEM management console. It is neither. It is a standalone analysis utility, installed on a throwaway machine, used to produce evidence, and then — in most workflows — switched off again. Understanding that keeps the installation topology simple.

Prerequisites and Planning

The installation itself is trivial. The preparation around it is what determines whether the profiling run produces useful results.

• A dedicated virtual machine. A Windows 10 or 11 Professional or Enterprise VM, used for nothing else. The profiler compares the system before and after, so anything else happening on the machine pollutes the results.
• Windows Server 2016 or newer if you are profiling for a terminal server. This is important and easy to get wrong. An application that behaves one way on a client operating system can behave differently in a multi-session environment, writing to session-scoped locations or splitting its configuration differently. Profile for the platform you intend to deploy on.
• A snapshot capability. The single most valuable thing you have is the ability to revert the VM to a clean state between runs. Take the snapshot before installing the application, not after.
• The matching DEM release. The profiler installer ships inside the DEM zip file. Its own version number frequently does not match the DEM version it came with, which is entirely normal. What matters is that you use the profiler from the DEM release you are actually deploying, because the output format needs to line up with the configuration editor you will use afterwards.
• A licence entitlement. The download comes from Omnissa Customer Connect and is tied to your entitlement, the same entitlement that covers Horizon and the rest of the EUC portfolio.
• A local administrator account on the profiling VM, and enough disk space for both the application and the profiler’s snapshot data. Some profilers can generate very large intermediate files on a chatty application; the Omnissa tool is comparatively well behaved, but a little headroom costs nothing.

The Process

• Download the Omnissa Dynamic Environment Manager from Omnissa Customer Connect.

• Extract the Omnissa DEM Application Profiler MSI from the Optional Components folder in the Omnissa DEM zip file.

It’s common for the Omnissa DEM Application Profiler installer version to not match the DEM version you are using. Just make sure you use the one included with the DEM version you are using.

• Connect to your Windows VM.
• Run the Omnissa DEM Application Profiler Setup as an Administrator.
• If you agree to the Omnissa General Terms, select I accept and click Next.

• On the Custom Setup screen, make any necessary changes and click Next.

• Click Install to start the installation.

• Wait while the setup wizard completes the installation of the Omnissa DEM Application Profiler.

• Click Finish to complete the installation and close the setup wizard.

Typically, when it’s time to profile an application, a snapshot is created on the Omnissa DEM Application Profiler VM before the application is installed giving you a clean slate to revert to after you’ve completed profiling your application.

That’s all it takes to install the Omnissa DEM Application Profiler.

Installing It Silently

The wizard is fine for a one-off, but if you are rebuilding profiling VMs regularly — and you should be, because a polluted profiler VM produces polluted results — it is worth knowing the unattended path. The profiler is a standard Windows Installer package, so it accepts the usual switches:

msiexec /i "Omnissa DEM Application Profiler.msi" /qn /norestart /l*v profiler-install.log

The /qn switch runs the package with no user interface, /norestart stops the installer from rebooting the machine, and the /l*v logging switch writes a verbose log that is invaluable when something goes wrong on a machine you cannot see. If you want to install it as part of a build pipeline, this is the line to use, and the exit code is your only reliable success signal — check it, and fail the build if it is not zero or 3010.

To confirm the installation landed, check the product registration:

Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* |
    Where-Object DisplayName -like "*Application Profiler*" |
    Select-Object DisplayName, DisplayVersion, InstallLocation

The executable itself typically lands in C:\Program Files\Omnissa\DEM Application Profiler, and the shortcut appears on the Start menu of the machine you installed it on.

Running a Profiling Session Properly

The installation is the least interesting part of the workflow, so it is worth covering what surrounds it. A well-run profiling session looks like this:

1. Take the snapshot. Revert to a clean Windows image, confirm there is no leftover application data anywhere, and take a snapshot before installing anything. The cleanest runs start from a freshly reverted snapshot every time.
2. Install the application as the user would. Use the same installer type, the same options, and the same privileges a real deployment would use. If the application is deployed per-user in production, do not profile a per-machine install.
3. Launch the profiler and start the analysis before the application is first started, so that the first-run configuration — which is usually the most interesting part — is captured.
4. Exercise the application thoroughly. Change the theme, set up a template, open and close a document, add a toolbar button, change a default folder, log in and log out. The profiler can only record what you demonstrate, and the most common cause of a broken DEM configuration is an incomplete demonstration rather than a tooling problem.
5. Stop the analysis and review the report. The profiler lists the files and registry keys it observed being written, grouped and annotated. Read it rather than accepting it blindly — some entries belong to the operating system rather than to the application, and those should not end up in your DEM configuration.
6. Revert the snapshot. Do this before the next application, every time. Profiling two applications on one dirty VM produces a report you cannot trust.

The general-purpose capture advice is to be decisive about scope. If you profile an application that writes to a shared location used by other applications, you will capture entries that cause problems when DEM applies them elsewhere. When in doubt, capture less and add entries deliberately rather than capturing everything and hoping.

Common Issues and How to Handle Them

The installer will not run. It needs elevation. Right-click and run as administrator, or launch it from an already elevated PowerShell session. If it fails silently, run the MSI with logging and read the log.

You cannot find the MSI. It is inside the DEM zip, in the Optional Components folder, not on the main download page. Extract the whole archive rather than opening the MSI directly from inside the zip — Windows will often refuse to run it from a temporary extraction path.

The report is empty or nearly so. The analysis was not started before the application ran, or the application was exercised too briefly. Start the profiler first, then launch the application, then use it meaningfully.

The report contains hundreds of irrelevant entries. The profiling VM was not clean. Revert the snapshot and start again — this is the single biggest determinant of report quality, and there is no way to filter your way out of a dirty baseline afterwards.

The captured configuration does not roam in production. Usually one of two things: a missing entry that was never demonstrated, or entries captured from a client OS being applied on a terminal server where the application behaves differently. Check the platform version you profiled against the platform you deployed to.

The app behaves differently on different machines after DEM applies the config. This generally means the configuration is capturing something machine-scoped — a licence key tied to hardware, or a path that exists on the profiling VM and nowhere else. Exclude those entries explicitly rather than relying on DEM to guess.

Frequently Asked Questions

Can I install the profiler on my golden image? No, and it is worth being firm about this. The profiler is a diagnostic tool for a throwaway machine. Leaving it installed adds surface area to every desktop built from that image and creates a temptation to profile against a machine that is not clean.

Do I need a separate licence for it? No. It ships as an optional component of the DEM entitlement you already have.

Why does the profiler version not match the DEM version? The component is only updated when it needs to change, and it changes far less often than the rest of the product. Always use the copy from the DEM release you are deploying so that the report format and the configuration editor line up.

How long does a profiling session take? Fifteen minutes for a simple utility, considerably longer for anything with an installer that has a lot of first-run configuration. The exercise step almost always takes longer than the capture step.

Can I automate the whole capture? The capture itself is interactive by nature, because you have to use the application. What is worth automating is the surrounding hygiene: building the clean VM, installing the profiler, taking the snapshot, and reverting afterwards. That is where the reproducibility comes from.

Final Thoughts

Installing the Omnissa DEM Application Profiler takes about five minutes: download DEM, pull the MSI out of Optional Components, accept the terms, and click through the wizard. The value is not in the installation, it is in the workflow around it — clean machine, honest snapshot, thorough exercise of the application, and a careful read of the report afterwards. Get those right and DEM configurations stop being guesswork.

If you want to read more about the Omnissa DEM Application Profiler installation, here is the Omnissa documentation.

Related reading on this site: the walkthrough of a non-persistent desktop scenario in Deploy Claude Desktop on Non-Persistent VDI is a good practical example of the kind of application where a correct DEM capture makes the difference between a usable desktop and a broken one, and the guide to configuring the Omnissa UAG with Horizon covers the access layer that typically fronts the estate you are profiling for. If you are still bringing up the platform itself, building a Horizon desktop pool without vCenter is a useful companion piece.