Autodesk Programs & Liquidware ProfileUnity/FlexApp

Yesterday at the Indianapolis CUGC meeting, Liquidware presented on their ProfileUnity solution.  Questions came up about Autodesk software in FlexApp and brought up an ongoing conversation about how to make this work both in FlexApp and with Portability/ProfileDisk.

Here are the issues I have encountered and how to resolve them or work around them.

Multiple Year Versions of the Same Product - FlexApp

As an architectural design firm, we utilize Autodesk Revit as our primary design software.  The model files from Revit are essentially single file databases which undergo a schema update when upgrading to newer versions.  Autodesk has decided against spending time to develop a solution for saving back to older versions, so once a file is upgraded it can no longer be opened in an older version.  This means we tend to keep a couple different versions of Revit installed to minimize the need to upgrade files mid project and to work with consultants that may not be on the latest version.

Why is this an issue?

FlexApp is not a typical layering product.  It does not do well with different (clashing) versions of the same file in different packages (although there have been some improvements in this area).  Since Autodesk's installers use some common folders among multiple year's products this creates some conflict.  Typically the last Autodesk FlexApp package mounted will work fine, but other versions will not.

How do you resolve it?

Easy, we need to install all Autodesk applications in a single FlexApp package.  This allows the installers to recognize the prior versions and replace and modify files as necessary to allow all versions to work together.

AutoCAD Secondary Installer Fails - FlexApp

AutoCAD is an interesting application.  When it is first run (or when it does not detect these keys and data already in the user's profile), it populates default user settings in a variety of places including in the registry and AppData.  Those locations are below:

File Paths:

C:\Users\%username%\AppData\Roaming\Autodesk\AutoCAD 20xx
C:\Users\%username%\AppData\Local\Autodesk\AutoCAD 20xx

Registry Keys:

HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\Rxx.x\ACAD-xxxx:40x

When this secondary installer runs, its primary job is to setup the user's settings, but it does a bunch of other things as well.  The problematic part of this is writing keys to the HKLM Installer\Folders folder which it later deletes.  During this process, about 95% of the time, the secondary installer fails without any useful message.

Why is this an issue?

I can't tell why this happens for sure, but I have a pretty good theory based on extensive testing.  It seems to have an issue with the small bit of added latency in writing to these Installer\Folders keys where it ends up trying to delete a key that isn't there anymore or it looks for a key it just created and it hasn't actually finished creating yet.  It sometimes shows as a permissions error, but even if you give Everyone permissions to the entire key, it still doesn't work the majority of the time.  This seems to be an issue with the virtualized registry and AutoCad's secondary installer not being very resilient at handling errors during the process.

How do you resolve it?

The answer is to avoid having FlexApp virtualize this part of the registry.  The tricky part is if anything in ANY FlexApp has keys here it causes a problem, not just these keys in the Autodesk FlexApp layer.  The key that seems to be the issue is:

HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\Folders

To delete this key, you need to use the CAP viewer.  This tool can be acquired from support and has publicly been teased as being released in the near future now (as part of the FlexApp Packaging Console) that its been redesigned and made much easier to use than the original internal troubleshooting and diagnostics tool.

To do this, you need to mount the FlexApp VHD and edit the appinstall.cap file.  I normally make a backup of the original as appinstall.bak and leave it in the VHD... Open the cap file in the CAP viewer and go to Registry and find the key above and delete the "Folders" key entirely.  Save and close the VHD.

Reminder: You need to check this for EVERY FlexApp that may coexist with an AutoCAD FlexApp package.

AutoCAD User Preferences - Portability & ProfileDisk

When using ProfileUnity there are two main profile "roaming" solutions, Portability and ProfileDisk.
Powershell script to flip from Portability to ProfileDisk and vice versa.  Short summary included below, but see the following link for more information.  Link:  https://blog.liquidware.com/2015/05/11/introducing-profiledisk-and-its-wonder-twin-profile-portability/

ProfileDisk utilizes a VHD mounted (typically) at "C:\Users\ProfileDisk" that then contains the users profile.  This means the user's profile exists at "C:\Users\ProfileDisk\%username%".  This is important to remember as this is what causes an issue.

Portability is a set of rules that defines what should be saved from a user session.  A portability rule for AutoCAD might define the AppData folders and Registry keys that need to be saved on logoff so we can restore them on logon to restore the user's settings in a non-persistent environment or when moving a user to a new machine.

Why is this an issue?

AutoCAD's registry entries contain hard coded paths to the user profile.  When we are using profileDisk those paths begin with "C:\Users\ProfileDisk\%username%", but when we use only portability the users profile is instead at "C:\Users\%username%".

How do you resolve it?

We need to utilize a script to change these keys by essentially just removing or adding "\ProfileDisk" as needed using a temporary registry file in our portability drive.

Disclaimer: I'm sure this script was partially stolen from someone for an unrelated task... No credit is given here, because I honestly don't remember.  That being said, script here:

# Put your portability path here...
$portabilityPath = "\\xd-uem01\UserShare"

# Makes window not show up
$t = '[DllImport("user32.dll")] public static extern bool ShowWindow(int handle, int state);'

add-type -name win -member $t -namespace native

[native.win]::ShowWindow(([System.Diagnostics.Process]::GetCurrentProcess() | Get-Process).MainWindowHandle, 0)

# Create Temp Folder if it doesn't exist

If(-Not (Test-Path $portabilityPath\$env:username\portability\AutoCAD))
{
    New-Item $portabilityPath\$env:username\portability\AutoCAD -type directory
}

# AutoCAD Architecture 2015
#Reg export HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\R20.0\ACAD-E004:409 $portabilityPath\$env:username\portability\AutoCAD\startRegistry.reg /y

#All AutoCAD Versions
Reg export HKEY_CURRENT_USER\Software\Autodesk\AutoCAD $portabilityPath\$env:username\portability\AutoCAD\startRegistry.reg /y

# If ProfileDisk Exists
If(Test-Path C:\Users\ProfileDisk)
{
    (Get-Content $portabilityPath\$env:username\portability\AutoCAD\startRegistry.reg) | ForEach-Object { $_ -replace "Users\\\\$env:username", "Users\\ProfileDisk\\$env:username" } | Set-Content $portabilityPath\$env:username\portability\AutoCAD\endRegistry.reg
}

# If ProfileDisk Doesn't Exist
Else
{
    (Get-Content $portabilityPath\$env:username\portability\AutoCAD\startRegistry.reg) | ForEach-Object {$_ -replace '\\\\ProfileDisk\\\\','\\'} | Set-Content $portabilityPath\$env:username\portability\AutoCAD\endRegistry.reg
}

Reg import $portabilityPath\$env:username\portability\AutoCAD\endRegistry.reg

# Empty Temp Folder
#Remove-Item -Path $portabilityPath\$env:username\portability\AutoCAD\* -recurse

If it is of interest, I can also post my portability rules for AutoCAD & Revit and try and summarize where the various user preferences reside.

Comments

  1. Hey Jeremy,

    Did you ever end up posting the portability rules for AutoCAD/Revit? Running a POC for liquidware and would love to see what you have!

    ReplyDelete
  2. the blog is very interesting and will be much useful for us. thank you for sharing the blog with us. please keep on updating.




    BIM documentation in USA
    AUTO CAD SERVICES

    ReplyDelete

Post a Comment

Popular posts from this blog

Dell R740 issues with XenServer 7.1/7.2

Autodesk in Virtual Environments and What is "Allowed"

NVIDIA GRID on Pascal - A Card Comparision