How to deal with Autodesk DWGTrueView and/or AutoCAD in a VDI environment with App Volumes.

Almost every medium to enterprise sized company will have users which need to make use of the Autodesk products like DWGTrueView, AutoCAD etc. on their computers. In a VDI desktop they will be flagged as a CAD/CAM users, but what if the user needs to work with it sporadically, just to view a *.dwg file or make some small adjustments… You don’t want to give the user a persistent desktop for this manner. right?

I got the task to find out if it is workable to put DWGTrueView and AutoCAD and in an AppStack.

An AppStack is the read-only disk (*.vmdk or *.vhd) from VMware App Volumes which got attached to the VDI desktop if you are member of a specific AD group or when you assign it to a specific VM group (via AD OU’s).

The App Volumes provisioning virtual machine I use is almost identical as my Windows 10 Golden/Base/Master Image, only without the VMware Horizon Agent (7.8) and User Environment Manager Agent (9.7). The App Volumes Agent version is 2.16.

You will notice, that the installation of DWGTrueView (2020) takes a little while during the AppStack provisioning process, compared to a normal installation without provisioning, but it succeeds with exit code 0.

After creating the necessary VMware User Environment Manager stuff (personalization entry for roaming settings and several shortcuts), I started a VDI machine with the AutoCAD Appstack attached to my user account.

Finding 1:
At application start, an active setup kicks in and very quick I got the following error message: Error 1325. Favorites/Documents is not a valid short file name. This happens with DWGTrueView and AutoCAD.

Solution 1:
This error is well described here by a Autodesk knowledgebase article. The solution they give you is changing your folder redirection path in the registry, because UNC-paths are not supported… Do you want to make a change globally in your Windows Infrastructure, by editing the Group Policy where your folder redirection is set or another possibility is creating a predefined setting for DWGTrueView/AutoCAD within VMware User/Dynamic Environment Manager, so the impact will be minimal, because of a select group of users? I went for the last one by changing the folder redirection via the registry only when the DWGTrueView or AutoCAD will start.

If you don’t fix Error 1325 and just click “OK”, DWGTrueView or AutoCAD will not start!

Click on the image to enlarge!

Finding 2:
After the active setup, you will see the Autodesk product splash screen with the text “first time setup” and “loading” and then……… it takes somewhere between the 7-10 minutes till the splash screen is going away and the application launches.




Normally the application launch time without AppStacks mounted is between the 5-10 seconds. So what’s going on in the background.
Via “Process Monitor” I saw +/- 630 entries saying something about “Windows Fonts”, with a SUCCESS result, but it repeats itself during the splash screen.

Click on the image to enlarge!

VMware has a KB-article (here) for applications which launches or run slow when an AppStack is attached. I’ve tried to implement this solution on my App Volumes 2.16 AppStack template, but it looks like the App Volumes Agent doesn’t process the “reverse_replicate_registry_key” entry in the snapvol.cfg.

Solution 2 for App Volumes 2.16 (and maybe lower?):
When App Volumes 2.16 (Agent) is used we couldn’t make it work and decided to place DWGTrueView in the Windows 10 golden/base/master image, because it’s free for download and use. AutoCAD on the other hand is an expensive product, so we will have no choice to flag it as unusable in a virtual desktop when AppStacks and/or Writable Volumes are used with version 2.16.

If one or more AppStacks are mounted (even if no Autodesk product is in the AppStack), the launch time of DWGTrueView is still +/- 10 minutes.
If no AppStacks are mounted (no assignments and attachments), the launch time of DWGTrueView and AutoCAD is the same as a non virtual desktop.

To fix this behavior you need to edit or copy the AppStacks template by following the procedure (here), this sample is for a writable volume, but it’s almost the same for the AppStack template. This means that all your AppStacks and/or Writable Volumes must include the two following lines inside the snapvol.cfg:

exclude_process_path=\Program Files (x86)\Autodesk
exclude_process_path=\Program Files\Autodesk


If you want you can also be more specific in the path depth, but pity enough by default all Autodesk products adds a year name in the installation folder, so you need to change your snapvol.cfg after every major release of the Autodesk products.

Solution 2 for App Volumes 2.17 (and later):
The other and personally my preferred way to get it work is to update the App Volumes environment (Manager, Templates and Agent) to at least version 2.17. Don’t forget to update your App Volumes Provisioning VM with the App Volumes Agent. When using the App Volumes 2.17 Agent or later, the “reverse_replicate_registry_key” does work and DWGTrueView and/or AutoCAD can be placed in an AppStack.

What do you need to do after upgrading your App Volumes version:
Follow this procedure for how to edit your snapvol.cfg (here) and add the following line under the “Registry” section:

reverse_replicate_registry_key=\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts



Just to be clear, the two lines from Solution 2 for App Volumes 2.16 must not be in!!!

Create now an AppStack based on the AppStack template which we just edited. Perform the installation of DWGTrueView and/or AutoCAD on the updated App Volumes Provisioning VM. Assign the AppStack to your user account and you will see that the application will start in a reasonable time. Of course it will depends on the virtual hardware of your VDI image. In my home lab the launch time of DWGTrueView is around 15 seconds. My Windows 10 image has 2 vCPU, 6GB RAM, 60GB Thin-Provisioned on local SSD storage and 28.19GB Video Memory (No GPU).

TIP:
What I have also noticed when using floating Instant Clones (even if you capture “Active Setup” settings via VMware UEM/DEM), that every time we start DWGTrueView the Active Setup kicks in. To solve this you need to capture the following locations with your User Environment Tool (in my example VMware UEM/DEM):

[IncludeRegistryTrees]
HKCU\Software\Autodesk\DWG TrueView
HKCU\Software\Autodesk\DWGCommon

[IncludeIndividualRegistryValues]
HKCU\Software\Autodesk\CurProd

[IncludeFolderTrees]
<LocalAppData>\Autodesk\DWG TrueView 2020 - English
<AppData>\Autodesk\DWG TrueView 2020 - English
<AppData>\Autodesk\PLC0000037

Getting Autodesk DWGTrueView and AutoCAD to work in a VMware Horizon + App Volumes environment from the customer took a while to find this out, so I hope this will help you all out to solve it more quickly.

UPDATE (ADDITION) 16-01-2020:
At the customer we were implementing above solution, we found out that it still didn’t work, but in my lab environment at home it worked.
After pointing the issue to Active Directory in combination with App Volumes. We were using nested Active Directory Groups (Domain Local Group is member of Domain Global/Universal Group and then because of administration hassle, we put the department AD group in there). It seems that Autodesk products or (App Volumes) doesn’t like that kind of level nesting. When we point all AppStacks to only one AD Group level deep the 10 minutes splash screen loading time from DWGTrueView and AutoCAD was gone.

Our conclusion is: Don’t nest to many groups and assign them to an AppStack! VMware Support says that there isn’t any limitation. Our other AppStacks doesn’t seems to have issues, but when you want to use Autodesk products, you need every AppStack mounted on one level deep AD Group!

UPDATE (ADDITION) 02-03-2020:
Yes (sorry) another update of this blog, after some more tests we were back to zero, the 10 minutes loading time was suddenly back again. How, you should think… I promise this will be the last finding, because we are running it now in the customers production environment…

We used for every AppStack another AD security group for the assignment, on second thoughts that was not a good idea, because in this case you are not able to play around with the AppStack precedence (on group level). We found out that when your customized Autodesk AppStack template is loaded before other AppStacks with the out-of-the-box template, the loading time is back to the 10 minutes. The out-of-the-box template overrides the customizations we have done in the Autodesk template. Look at the screenshot below and verify that the Autodesk AppStack template is last in line by thick the “Override Precedence” checkbox and change the order with the arrows.

TIP:
Don’t assign AutoCAD Lite and AutoCAD Full to a user or group at the same time, because they share the license service and that will not work!!! DWG Trueview doesn’t contain a license, so no problem with that one.

UPDATE (ADDITION) 15-12-2020 – RESOLVE SLOW STARTS IN APP VOLUMES 4:
Personally I didn’t had the change to dig into this slow starts of Autodesk products in App Volumes 4, because it was back there and in App Volumes 4 the Snapvol.cfg isn’t in the AppStack anymore, but VMware placed it in the App Volumes Agent installation directory. So on your VDI base image. Nivlheim aka @Le_Pouic (see comments below) pointed me, that my solution for App Volumes 2.x didn’t work for App Volumes 4. VMware Support helped him to get it work on App Volumes 4.

Follow the steps below to fix slow startups of Autodesk products with use of App Volumes 4:

  1. The App Volumes 4.x agent needs to be installed on your VDI base image.
  2. Create an empty/clean snapvol.cfg on your VDI base image.
  3. Add the following line:
    exclude_registry=\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts
  4. Save the file (as snapvol.cfg).
  5. Copy the file (on your VDI base image) to location:
    C:\Program Files(x86)\CloudVolumes\Agent\Config\Custom\System\
  6. To be sure restart the App Volumes 4.x agent service.
  7. Take a new snapshot of your VDI base image.
  8. Push the new image to your VDI Pool(s).

Credits for this additions of my blog goes to @Le_Pouic and VMware Support.

6 replies

Comments are closed.