Home > Blogs > VMware Consulting Blog > Tag Archives: Jeffrey Davidson

Tag Archives: Jeffrey Davidson

VMware User Environment Manager and ADMX Settings

JeffSmallby Jeffrey Davidson

In this blog entry, I will walk through how to configure ADMX settings within the VMware® User Environment Manager™ Management Console. Additionally, I will discuss how User Environment Manager ADMX settings work together with existing Group Policy configurations.

In this example, I will be setting Google Chrome as the default browser using the ADMX settings.

Continue reading

App Volumes Writable Volumes Orphaned

JeffSmallBy Jeffrey Davidson

In this blog entry I will talk about App Volumes and how Writable Volumes can become orphaned.

In some cases Writable Volumes can become orphaned as shown below.

JDavidson Writable Volumes 1

This status message can be confusing. The status message makes it seem as if the Writable Volume may be missing, or there is some other issue at hand. However, that may not be the case.

In some cases this orphaned state occurs when the owner user account in Active Directory is disabled, as shown below.

JDavidson Writable Volumes 2

When an account in Active Directory has been assigned an App Volumes—or a Writable Volume is disabled or deleted—the users’ Writable Volume can become orphaned when App Volumes synchronizes with Active Directory. As a result of this process, the status of the Writable Volume changes to orphaned.


Jeffrey Davidson, Senior Consultant, VMware EUC. Jeffrey has over 15 years of IT experience and joined VMware in 2014. He is also a VCP5-DCV and VCP5-DT. He is a strong advocate of virtualization technologies, focusing on operational readiness with customers.

 

App Volumes AD Objects Move Issue

JeffSmallBy Jeffrey Davidson

In this blog entry I will talk about App Volumes and things to check when you are having trouble logging in.

There are times when a user may not be able to login to the App Volumes Manager Server. Users might get a message similar to “You must be in the Administrators group to login” as shown below. There can be a few reasons for this issue to occur.

App Volumes AD Objects Move Issue JDavidson 1

The first is that an administrators group needs to be defined in the App Volumes configuration, which is done during the initial setup of the App Volumes instance. Users need to be members of this group in order to login to the App Volumes Manager Server.

Secondly, you need to validate the App Volumes Manager Server to be able to communicate with the SQL instance configured during installation and Active Directory. The credentials for connectivity to both environments should be verified.

If you have validated that all of the above configurations are accurate and the services are running, there is one other thing you should investigate; this issue can occur if the user object has been moved in Active Directory. For example, a user was in the “Chicago” organizational unit (OU) and has been moved to the “Cleveland” OU. When an object is moved in this way, App Volumes can have trouble finding the user because its distinguished name (DN) value in Active Directory has changed. App Volumes stores the user DN value in the “Users” App Volumes SQL database table.

App Volumes AD Objects Move Issue JDavidson 2

To restore App Volumes functionality to the object, the App Volumes SQL database needs to be updated with the new Active Directory DN value. This is done by retrieving the correct DN value from Active Directory, then updating the database record for that user.

App Volumes AD Objects Move Issue JDavidson 3

Updating the SQL record can be done directly through SQL Server Management Studio.

If this issue is occurring for all users then you will want to validate that the Active Directory group—defined as the App Volumes Administrators group—has not been move. In this circumstance you will want to validate the DN of the group specified in the App Volumes SQL Database against its location in Active Directory. The administrators group DN is stored in the “group_permissions” App Volumes SQL database table.

App Volumes AD Objects Move Issue JDavidson 4

If the group has been moved you will need to update the App Volumes SQL Database with the DN value of the new group.

App Volumes AD Objects Move Issue JDavidson 5

This record can also be updated directly through SQL Server Management Studio.


Jeffrey Davidson, Senior Consultant, VMware EUC. Jeffrey has over 15 years of IT experience and joined VMware in 2014. He is also a VCP5-DCV and VCP5-DT. He is a strong advocate of virtualization technologies, focusing on operational readiness with customers.

 

Copying App Volumes AppStacks Between Environments That Use vSAN Storage

JeffSmallBy Jeffrey Davidson

There is an issue copying App Volumes AppStacks (VMDK files) if using Secure Copy (SCP) from one environment to another when using VSAN storage. This is not an App Volumes problem; it is related to the way VSAN stores VMDK data.

Clients will often want to create AppStacks in a test environment, then copy those AppStacks to a production environment, and finally import them into App Volumes. In situations where any of those environments use VSAN storage, you will not be able to copy (SCP) AppStacks (specifically VMDK files) between environments.

In this blog entry I will discuss a workaround to this issue, using an example in which the client has two VSAN environments (DEV and PROD), and needs to copy VMDK files between them.

The VMDK files created by App Volumes are nothing special and are traditionally comprised of two files.

What we normally identify as <filename>.vmdk is a type of header/metadata file. Meaning it only holds information regarding the geometry of the virtual disk and, as such, references a file that contains the actual data.

The file referenced is often called a “flat” file; this file contains the actual data of the VMDK. We can identify this file as it has the naming pattern of <filename>-flat.vmdk

On traditional block level storage these two files are normally stored together in the same folder, as shown in the example screenshot below.

JDavidson1

But VSAN storage is different; if you look at the contents of the “header” file you see something similar to the screenshot below. In this screenshot, the section in red is normally a reference to a “flat” file (example: Adobe_Acrobat_Reader -flat.vmdk). In the case where VSAN is the storage platform, we see something different. The screenshot below shows a reference to a VSAN device.

JDavidson2

VSAN storage employs object-level storage, which is different from traditional block-level storage. The VSAN objects are managed through a storage policy which, for example, can allow for greater redundancy for some virtual machines over others. Because the reference in the VMDK file points to a VSAN DOM object, it cannot be copied through traditional means (SCP).

To work around this issue you will need traditional block-level storage which acts as a “middle man” to allow the SCP copy of VMDK files between environments. You will also need SSH access enabled on one host in each environment.

The first step is to clone the VMDK you wish to copy from the VSAN volume to the traditional storage volume. Once on traditional storage you will be able to copy (SCP) the two VMDK files directly to a host in a different VSAN environment. After you have copied (SCP) the VMDK files to a destination VSAN environment, you will need to perform a clone action to re-integrate the VMDK with VSAN as a storage object, so it can be protected properly with VSAN.

The diagram below is an overview of the process to copy AppStack (VMDK) files between VSAN environments.

JDavidson3

The example below shows the commands required to copy an App Volumes AppStack (VMDK) between environments that use VSAN storage. Before executing these commands you should create a staging area in each environment where AppStacks will be copied temporarily before being copied between hosts for getting re-integrated in the destinations’ VSAN storage.

For example:

In the source environment, create the folder <path to block level storage>/AppVolumes_Staging

In the destination environment, create the folder <path to cloud volumes root folder>/cloudvolumes/staging

Step 1:

SSH into the host where the AppStack currently resides.

Execute the following command to clone the AppStack to block-level storage. Note that after you execute this command there are two files on the block-level storage. One is the header file, and the other is the “flat” file, which was previously integrated with VSAN as a storage object.

vmkfstools -d thin -i <VSAN path to App Stack>/cloudvolumes/apps/<filename>.vmdk <path to block level storage>/AppVolumes_Staging/<filename>.vmdk

Example:

vmkfstools -d thin -i /vmfs/volumes/vsan:4a65d9cbe47d44af-80f530e9e2b98ac5/76f05055-98b3-07ab-ef94-002590fd9036/apps/<filename>.vmdk /vmfs/volumes/54e5e55d-97561a60-50de-002590fd9036/AppVolumes_Staging/<filename>.vmdk


Step 2:

Execute the following commands to copy (SCP) an AppStack from one environment to another.

scp <path to vmdk clone on block level storage>/<filename>.vmdk root@<esxi mgt IP>:<path to staging folder>/<filename>.vmdk

scp <path to vmdk “flat” file clone on block level storage>/<filename>-flat.vmdk root@<esxi mgt IP>:<path to staging folder>/<filename>-flat.vmdk

Example:

scp /vmfs/volumes/54e5e55d-97561a60-50de-002590fd9036/AppVolumes_Staging/<filename>.vmdk root@10.10.10.10:/vmfs/volumes/vsan:265d91daeb2841db-82d3d8026326af8e/6efbac55-f2f7-f86a-033f-0cc47a59dc1c/Staging/<filename>.vmdk

scp /vmfs/volumes/54e5e55d-97561a60-50de-002590fd9036/AppVolumes_Staging/<filename>-flat.vmdk root@10.10.10.10:/vmfs/volumes/vsan:265d91daeb2841db-82d3d8026326af8e/6efbac55-f2f7-f86a-033f-0cc47a59dc1c/Staging/<filename>-flat.vmdk


Step 3:

Run the commands below to delete the AppStack from the staging folder on the source environment.

rm <path to staging folder>/<filename>.vmdk

rm <path to staging folder>/<filename>-flat.vmdk

Example:

rm /vmfs/volumes/54e5e55d-97561a60-50de-002590fd9036/AppVolumes_Staging/<filename>.vmdk

rm /vmfs/volumes/54e5e55d-97561a60-50de-002590fd9036/AppVolumes_Staging/<filename>-flat.vmdk


Step 4:

SSH into the host where the AppStack has been copied to. In this example the host IP address is 10.10.10.10.

Run the command below to clone the copied AppStack from the staging folder to the App Volumes “apps” folder, and re-integrate the VMDK into VSAN as a storage object.

vmkfstools -d thin -i <path to staging folder>/<filename>.vmdk <path to cloud volumes root folder>/cloudvolumes/apps/<filename>.vmdk

Example:

vmkfstools -d thin -i /vmfs/volumes/vsan:265d91daeb2841db-82d3d8026326af8e/6efbac55-f2f7-f86a-033f-0cc47a59dc1c/Staging/<filename>.vmdk /vmfs/volumes/vsan:265d91daeb2841db-82d3d8026326af8e/6efbac55-f2f7-f86a-033f-0cc47a59dc1c/apps/<filename>.vmdk


Step 5:

Run the commands below to delete the AppStack from the staging folder on the destination environment.

rm <path to staging folder>/<filename>.vmdk

rm <path to staging folder>/<filename>-flat.vmdk

Example:

rm /vmfs/volumes/vsan:265d91daeb2841db-82d3d8026326af8e/6efbac55-f2f7-f86a-033f-0cc47a59dc1c/Staging/<filename>.vmdk

rm /vmfs/volumes/vsan:265d91daeb2841db-82d3d8026326af8e/6efbac55-f2f7-f86a-033f-0cc47a59dc1c/Staging/<filename>-flat.vmdk
After completing these steps, you will have successfully copied a VMDK from one VSAN storage platform to another.

App Volumes also creates a “metadata” file during the creation of an AppStack, as shown in the screenshot below.

JDavidson4

The “metadata” file is a “text” file and should be copied to the destination environment so the AppStack (VMDK) can be imported into the destination App Volumes instance. Because this is a “text” file, it can be copied (SCP) without the cloning process and need for block-level storage as described in steps 1–5 above.


Jeffrey Davidson, Senior Consultant, VMware EUC. Jeffrey has over 15 years of IT experience and joined VMware in 2014. He is also a VCP5-DCV and VCP5-DT. He is a strong advocate of virtualization technologies, focusing on operational readiness with customers.

VMware User Environment Manager and Application Profile Settings

JeffSmallBy Jeffrey Davidson

There has been a lot of focus on VMware UEM (formerly Immidio) in recent months since its acquisition and release as VMware User Environment Manager (UEM).

In this blog entry I will walk through the process of capturing Google Chrome settings and incorporating that configuration into UEM.

UEM can be deployed with configuration items for common applications like Microsoft Office, which saves a lot of work. For applications not included in UEM, you can use the UEM Application Profiler to capture specific configuration settings. Deploying UEM is generally not a time-consuming task, though it does require some thought and planning. A majority of your time will be spent configuring UEM, specifically, applications you wish to add to your UEM environment.

Windows applications generally store configuration information in the registry and/or files on the computer. The UEM Application Profiler “watches” an application, and captures the location where its settings are stored. This process is referred to as “application profiling,“ which basically is the process of understanding where an application stores its settings. The UEM Application Profiler can also capture specific settings, which can then be stored in UEM and enforced at logon. Today we will focus on capturing or “profiling” a new application and bringing that configuration into UEM.

There are a few things I’d recommend you do if you plan to profile applications.

  1. Install at least one desktop with the applications you wish to profile. We will refer to these systems as the UEM capture systems. In larger environments you may wish to deploy additional capture systems.
  2. Install the UEM Application Profiler on the capture systems. It is important to note that you cannot install the UEM client on the same system as the UEM Application Profiler. The UEM Application Profiler installation files are found in the “Optional Components” folder of the VMware-UEM-x.x.x.zip file.JDavidson UEM 1
  3. Take a snapshot of the capture systems in case you need to roll back.

We are now ready to begin profiling applications. We will begin by launching the UEM Application Profiler from the Start Menu on your capture system. We see a blank “Flex Config File” this is the file that will contain the application configuration once the “application profiling” is complete.

JDavidson UEM 2

It is helpful to have an understanding of the application before capture begins. I recommend researching where an application saves its configuration data before starting the profiling process; it will be time well spent.

In the case of Google Chrome, we know the application stores much of its configuration and settings in files in the user profile (C:\Users\username\AppData\Local\Google).

UEM Application Profiler has built-in registry and file system exclusions that prevent the Application Profiler from capturing data unrelated to the application being profiled. In order to successfully profile an application’s behavior, you may need to modify the exclusions path if an application saves configuration data in one of these locations.

In the case of Google Chrome, we know the application saves data in the local AppData folder; so we remove the exclusion so UEM Application Profiler will profile Chrome’s behavior in this location.

This is done by selecting “Manage Exclusions” above “File System” and removing the <LocalAppData>\* line as shown in the screenshot below.

JDavidson UEM 3

To begin the profile process, click “Start Session” and navigate to the location of Google Chrome and click “OK.” In order to profile an application, UEM Application Profiler must launch the application.

JDavidson UEM 4

It is generally sufficient to modify a few common settings, unless there is specific configuration/behavior you need to capture. In the case of Google Chrome, making a few common changes is sufficient. Once you’ve made these changes close Google Chrome and choose “Stop Analysis” in the Analyzing Application dialogue box.

JDavidson 5

After the profile process is complete you will see that the previously blank Flex Config File contains configuration data that can be saved and integrated into your UEM implementation. In some cases it may be necessary to edit the Flex Config File in order to remove any unwanted configuration paths. The image below shows the correct Flex Config for Google Chrome.

JDavidson UEM 6

To save the Flex Configuration click the save button and choose “Save Config File,” then navigate to the UNC path of your UEM config share.

I like to create a separate folder for each application to keep the folder structure clean. In this case it would look something like this:

\\UEMserver\uemconfig\general\Applications\Google Chrome\Google Chrome.ini

I recommend saving the new configuration to a UEM test environment first. The settings can be validated and changed, if necessary, before moving to a production UEM environment.

JDavidson UEM 7

This saves the configuration from the profile process to the UEM environment. The next time you open or refresh the UEM Management Console application list, you will see Google Chrome listed as an application.

JDavidson UEM 8

UEM users who log in after the new configuration has been added will have their Google Chrome settings persist across sessions.

The goal and benefit of UEM is capturing application-specific settings and maintain that application experience across heterogeneous desktop environments without conflicts.


Jeffrey Davidson, Senior Consultant, VMware EUC. Jeffrey has over 15 years of IT experience and joined VMware in 2014. He is also a VCP5-DCV and VCP5-DT. He is a strong advocate of virtualization technologies, focusing on operational readiness with customers.