Archive | App Volumes RSS feed for this section

Export VMware App Volumes – Writable Volumes from VSAN Datastore

28 Nov

If you have a VMware VSAN environment and you wanted to export a App Volumes – Writable Volumes from the vsanDatastore to another datastore, storage or for VMware GSS/R&D for further analysis go ahead and read further!

Background – The traditional way of exporting the Writable Volumes from the source vsanDatastore was to attach the *.vmdk to a dummy VM as a “Existing Hard Disk” and export the dummy VM using the “Export OVF Template” option from the vCenter. Repeat all the steps on target datastore where-in it needs to be imported. However, if you want an alternate and easy method than the dummy VM then follow the below steps.

Step by Step Instructions:

— SSH to any ESXi Host Resource Cluster where the WV is stored and browser to the cloudvolumes/writable directory location:

# cd /vmfs/volumes/vsanDatastore/cloudvolumes/writable (This is the location where all end-user writable volumes are stored)

— Now search for the end-user (E.g twood) for which you want to export the Writable Volumes.

# ls -lh | grep twood
User to export WV

— Now lets open the *.vmdk file using “cat” command to retrieve the Object ID information. Make a note of the ObjectID

# cat DOMAIN!5C!twood.vmdk

Cat to find ObjectID

— In my scenario the Object ID was properly pre-created I didn’t have to use the objtool to find out the Object opened. However, in some cases you might have to run the following command

# /usr/lib/vmware/osfs/bin/objtool open -u (Where Object ID is displayed using the ‘cat’ command

This screenshot below is an example of situations where in the Object ID is not properly pre-created. It will provide you with an output Object Opened at path:
Objecttool Output

— Now using WINSCP login to the same ESXi Host and go to the path:
Object ID – /vmfs/device/vsan/d17efe58-5610-4dd2-0d9e-ecf4bbea2830 (my scenario)
Or/else Object opened at path in the screenshot above.

Download the file “d17efe58-5610-4dd2-0d9e-ecf4bbea2830” which is Writable Volumes (*.vmdk) file and move the files to local or remote location that you are using the WINSCP tool.

— Rename the Object ID to a friendly name shown in the cloudvolumes/writable Directory Folder. I renamed it (DOMAIN!5C!twood.vmdk)

— You don’t need the *.vmdk.metedata file

— The Writable Volumes is now exported out of the VSAN environment you can attach the *.vmdk to a non App Volumes Agent machine to look at the contents inside the Writable Volumes. If you are going to send the vmdk to VMware GSS/R&D make sure to zip it before uploading

I hope you will find these steps useful and help you export a Writable Volume from your vsanDatastore. I haven’t been able to try AppStacks with this method its on my to-do list.

Thanks,
Aresh Sarkari

McAfee Exclusion for VMware App Volumes 2.x – 100% CPU Issues

27 Nov

In your Virtual Desktop Infrastructure with the following configurations:

If you start noticing 100 % – CPU Usage for prolonged period of time and the Horizon Session getting disconnected from time to time after launch then you might need to include the following exclusion within your Writable Volumes (UIA+Profile) snapvol.cfg file:

#McAfeeExclusion
exclude_process_path=\Program Files\Common Files\McAfee\SystemCore

My colleague Daniel Bakshi has written an extensive blogpost on how to modify the snapvol.cfg for individual or group of end-users please reference it to make the necessary changes – Using the VMware App Volumes snapvol.cfg File to Customize Writable Volumes

I hope you will find these exclusion useful and will help you resolve a similar issue a lot quicker. A big thanks to Art Rothstein in helping to troubleshoot and resolve the issue.

Thanks,
Aresh Sarkari

Error 1303 The installer has insufficient privileges to access this directory – Upgrade from App Volumes 2.12 to 2.12.1

12 Apr

With the latest version of App Volumes 2.12.1, you don’t have to uninstall the older version of App Volumes Manager. The latest App Volumes Manager 2.12.1 installer takes care of uninstalling, fresh-install and retain all the configuration details and settings automatically for you.

During the upgrade I encountered the following error:

“Error 1303. The installer has insufficient privileges to access this directory: C:\Program Files(x86)\CloudVolumes\Manager\log. The installation cannot continue. Log on as an administrator or contact your system administrator.”

App Volumes Upgrade Error

Resolution:
In our scenario we have VMware vRealize Log Insight Agent installed on the App Volumes Manager VM’s which is doing Syslog. The Log Insight agent captures the logs(production.log) inside the folder “C:\Program Files(x86)\CloudVolumes\Manager\log”. As the service is in the running state, it didn’t allow the folder to delete and left a ghost folder on the filesystem.

Log Insight Agent Service

After going into the services.msc and stopping the VMware vRealize Log Insight Agent service and click Retry, the setup manages to complete the upgrade successfully.

I hope this workaround helps you during your upgrade if you encounter a similar error message.

Thanks,
Aresh

Export Writable Volumes from vSAN Datastore

15 Nov
In certain scenarios such as uploading the Writable Volumes *.vmdk to VMware support team to analyze issues due to Writable Volumes or you simply want to export the WV from one vSAN datastore to another vCenter or vSAN Datastore
Following is the step by step procedure to export Writable Volumes from vsanDatastore for troubleshooting purposes:

Source vCenter or vSAN Datastore:

  • Create a dummy VM (No need to power on the VM)
  • Add a HDD to the dummy VM – Use existing disk option – Locate the Writable Volumes under –  /vmfs/volumes/vsandatastore/cloudvolumes/writables) and click OK
  • Now you can export the dummy VM as a OVA or OVF to another vCenter or vSAN datastore
  • Save the OVA to a File Share or GSS FPT for further troubleshooting

Target vCenter or vSAN Datastore

  • Import the OVA into the target vCenter
  • SSH to a host in the cluster from which the Writable Volumes (WV vmdk) needs to be copied to the correct path cd /vmfs/volumes/vsandatastore/cloudvolumes/writables
  • Copy the files *.vmdk from dummy VM Folder to the writable folder
    • cp /vmfs/volumes/DummyVM/AV-WV/domainname!5C.aresh.vmdk /vmfs/volumes/vsandatastore/cloudvolumes/writable
  • Go to App Volumes Manager – Writable Volumes – Import Writable Volumes
  • Now you should see the writable for that user
Following are the step the engineer needs to perform for further troubleshooting it can be GSS, R&D or L3.
  • Import the template into the environment
  • Click on convert to virtual machine
  • On any existing Windows 7 VM without AV Agent (make sure not AV agent is installed). One needs to have a Windows 7 VM pre-build
  • Add HDD and select the existing disk option. Search for the vmdk in the folder previously imported
  • Assign the volume a driver letter and you can browse the contents of the WV
  • Troubleshoot further!

I hope this post will save you a lot of time when exporting WV from VSAN Datastore

Thanks,
Aresh

Solving Microsoft Outlook (.OST) issues by combing VMware UEM and App Volumes

28 Jun

The long outstanding challenge of Microsoft Outlook *.ost files within Windows 7/8/10 floating desktops. Using VMware User Environment Management (UEM) and App Volumes together can overcome this challenge. Microsoft never supported or recommended keeping .ost files on File Shares and with O365 into equation the .ost file could be enormous sizes and would be unable to provide optimal end-user experience like you would be running from your PC devices.

App Volumes

  • Writable Volumes with the User Installed Applications template will be used to store the Outlook .ost and profile configuration details (.xml)
  • The .ost is stored within the writable volumes. Hence there is no performance impact like storing it on remote file shares
  • Depending upon the mailbox sizes you can create larger custom Writable Volumes – UIA template (The default template in AV is 10 GB). Like in O365 scenarios its normal to have 25GB mailbox size. Customer can create larger WV depending upon the requirements

UEM

  • Use the ADMX based setting for the Microsoft Office 2013/2016 cache settings. Policy – Default location for OST files
  • The most import step here is to point the .ost location to “C:\Snapvolumestemp\writable\Outlook”. Note this path is not virtualized, there is no over ahead of the filter driver

Using this technique, we can now quickly re-direct the .ost files to writable volumes and continue offering floating desktops to our end-users

There is also a VMware UEM video which demonstrates this steps in more details here – https://www.youtube.com/watch?v=bzy4X5xbURY (Thanks to Pim Vandeis from the UEM team)

Thanks,
Aresh

Newer Entries →