8 posts tagged with "VM"

Symptoms​

Exclusions added to AppStack snapvol.cfg files are not excluded from Writables Volumes.

Writable Volumes still capture files that could be excluded in AppStack snapvol.cfg files. This could cause potential conflicts and unexpected behaviors.

Resolution​

These symptoms are caused because writable policy affects the whole system while AppStack policy affects only AppStacks.

Since AppStack exclusions will not apply to a writable, those exclusions need to be listed in snapvol.cfg files in order to prevent core applications and services from being broken. So, it’s necessary to list the same exclusions in both AppStacks AND writable snapvol.cfg files when attaching a writable.

To exclude a location, edit the snapvol.cfg file to add the full path that is to be excluded. Paths can be listed in any order, for example:

# File system exclusions

exclude_path=\ProgramData\ntuser.pol
exclude_path=\ProgramData\tempntuser.pol
exclude_path=\ProgramData\VMware

For more information about the snapvol.cfg file, see http://blogs.vmware.com/euc/2016/03/app-volumes-snapvol-cfg-writable-volume-customize-configure.html.

Note: Introducing a writable volume without the explicit exclusions added, re-breaks the same core apps and services. Re-adding the exclusions to the writable via the zip file method fixes this.

Symptoms​

After running an AppStack rescan, you experience one of these symptoms:

• AppStacks appears as disabled
• AppStacks appears as unprovisioned in the manager UI

Cause​

This issue occurs because a separate AppVolumes deployment is configured to use the same datastore, which is not supported.

AppVolumes modifies the metadata of AppStacks, especially in version 3.0. When rescanning, the system reads the metadata of the AppStacks on the datastore and reflects the changes in the UI.

Resolution​

To resolve this issue, change the configuration of the second AppVolumes deployment to point to another path on the datastore, use another datastore, or stop the service/server.

To prevent this issue from recurring, move the AppStacks on the production datastore to a different path on the datastore, import them, and recreate the assignments.

Part of the writables are not created upon login in a multi-vCenter environment

Symptoms​

AppVolumes 2.11 and above is configured to work with more than one vCenter.

Writables are created for an AD group and the writable creation is delayed until login time.

When logging in to VMs in one of the vCenters with a user which is part of the AD group, a writable is created for that user.

When logging in to a VM on another vCenter, a writable is NOT created for the user, and no writable is attached to the user.

The following log can be found in the Manager log corresponding to the login attempt:

DEBUG Cvo: Culling "DOMAIN\GROUP" because it does not have files accessible to the machine manager running "Computer <DOMAIN\MACHINE$>"

Cause​

When creating a writable volume for a group account, a writable volume is actually created for the group account, not a single user. Then this writable will be used as a source template for the direct writables which will be created for the users in the group.

When a user logs in, this writable is cloned.

Only one copy of the group writable is created on one of the vCenters that accepted the job and started the writable creation task.

Logging into a VM:

• on the same vCenter will create the writable successfully.
• on another vCenter will not create the writable, as this file is not accessible from another vCenter.

Resolution​

Storage used for the writable volumes should be common between vCenters, otherwise logging in to different vCenters will result in different writables splitting user data between separate VMDKs.

You need to follow these steps to import the group writable entry from the other vCenter:

1. Open the writable volumes screen by clicking Volumes > Writables
2. Click on Import Writables
3. Choose the common writables datastore related to the vCenter which is not able to create the writable volumes.
4. Click on the Import button and wait for the writables to be imported. Note: Each writable will have a separate record for each vCenter.
5. Log into a VM on the other vCenter. That will automatically create the writable using the group writable record for this vCenter.

Important: Do not forget to perform this import operation after all writables are created!

Note: Each writable must have as many records as the number of vCenters

This KB describes how to install and use Log Collection with App Volumes.

Introduction​

Currently, no method exists to collect Agent and Manager logs to a central location.

With the log collector, every agent and manager will periodically push their log files to a fileshare.

To start collecting logs, every Agent and Manager will call a .bat file depending on the bit version:

• 32-bit: C:\Program Files (x86)\CloudVolumes\DctLogCollector\support.bat
• 64-bit: C:\Program Files\CloudVolumes\DctLogCollector\support.bat

The Agent and Manager are configured to periodically push the log files to a fileshare; but if you need to manually collect logs, running the .bat file alone would also push log files to the fileshare.

Configuration of the Log Fileshare​

To make the Agent and Manager aware of the fileshare, configure the Log Fileshare in the following way.

To create a Log Fileshare, go to http://localhost/log_fileshares/new and input the following Log Fileshare fields:

Other Fileshare actions

Note: Every setup can have only one Log Fileshare.

Agent log collection​

The Agent will request for the Log Fileshare credentials by sending a GET request to:

<manager’s ip address>/log_fileshares/active

After the Agent gets these details, the Agent will run the log collector periodically, based on the time configured.

Note: While the collection is running, the user’s desktop CPU usage will spike until the collection ends.

Note: The tool’s performance has not yet been tested and validated at large scale.

Manager log collection​

The Manager has a ruby job running called collect_logs which will periodically call the support.bat file with the required parameters.

To configure the time for the manager to collect logs, change the duration in the clock.yml file. The Manager logs are collected every 12 hours.

Switching off log collection​

You can deactivate log collection by unchecking the Is active checkbox in the Log Fileshare configuration page.

Running batch scripts on Agents and Managers​

In Windows, no setup is required. The .bat script is shipped with the Agent and Manager images. In order to collect Agent logs, make sure https is enabled; otherwise, this feature will be turned off in the Agent.

Note: The .bat script needs administration privileges to run.

The .bat script can be run from:

C:\Program Files (x86)\CloudVolumes\DctLogCollector\support.bat

The following are the parameters for support.bat:

Example of running the script:

support.bat -destination C:\Logs -fhhost \\10.33.99.231\uem\logs -fhdomain <domain> -fhuname <username> -fhpwd <password>

Symptoms​

At logon, printers are recreated, but the default printer is not being retained at each login. Also printers set to Default by UEM are not the Default anymore.

Users have to manually set their default printer again.

The user is connecting through VMware View or Horizon client from a PC or Thin Client.

Cause​

This is caused by ThinPrint default printer redirection.

Default behavior of ThinPrint is to redirect the default local printer to the user session. This overwrites the default printer setting from the session.

Resolution​

This can be solved by changing the behavior of ThinPrint.

You have three options:

Introduction​

VMware User Environment Manager comes with built-in templates for some common applications such as Office and Adobe Reader, which are optimized and typically work for most customers.

In some scenarios, customers want to create those templates themselves by using the UEM Application Profiler. The problem is that the Application Profiler has a built-in blocklist to make sure customers use the provided templates.

If you want to work around this limitation, there is an option available to allowlist those applications and still use the Application Profiler to create your own UEM Configuration files.

Solution​

Add the following registry key to be able to profile applications that are blocked by default:

[HKEY_CURRENT_USER\Software\Immidio\Application Profiler\2.0\Profiling\Options\WhiteListedApps]

Create a reg_sz value with a random name, for instance 1 and make the value the executable name, as in:

"1"="acrord32.exe"
"2"="winword.exe"
"3"="outlook.exe"

Symptoms​

The checkbox Run Once for UEM configurations (like shortcuts) can still run multiple times when a Local User Profile is used. This could be unwanted behavior of UEM, and this KB describes how to change this behavior to really run once.

Resolution​

User Environment Manager has support for a runOnceSpecial attribute in UEM XML configuration files (like shortcuts and printer mappings for example).

If this attribute is used, it only has effect if run-once is enabled, and the User Profile type is local.

This is how the behavior works technically:

• If no run once flag file exists matching .[L-computername.1], we check for .[L-*.1].
• If match is found, we consider the UEM action as having run before, but we also create .[L-computername.1] (in the standard way, so at logoff) to ensure that run-once logic remains working correctly in case the special attribute is cleared later on.

How to enable:

• Manually edit the UEM configuration file (i.e. the Notepad.XML file for the shortcut to Notepad)
• Add the XML-attribuut: runOnceSpecial="1"
• The result looks something like this: ... runOnce="1 "runOnceSpecial="1" ...

Symptoms​

You have an expired UEM license file that needs to be replaced.

Resolution​

VMware UEM stores the license file locally on each computer where the UEM agent is installed.

The license file is stored in the installation folder of the UEM agent. The default location of the license file is C:\Program Files\Immidio\Flex Profiles\FlexEngine.lic

The process of changing the license file is straightforward and you have two options:

• Change the license file automatically when upgrading to a newer version of UEM
• Change the license file manually

With the release of UEM 9.0 a change has been made to the license file check; on computers where the Horizon Agent is installed, a UEM license file is not needed. In this case the MSI installer will not ask you for a license file.