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.
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.
File Paths:
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?
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
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?
HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\Folders
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:
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.
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?
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:
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.
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.
Hey Jeremy,
ReplyDeleteDid you ever end up posting the portability rules for AutoCAD/Revit? Running a POC for liquidware and would love to see what you have!
the blog is very interesting and will be much useful for us. thank you for sharing the blog with us. please keep on updating.
ReplyDeleteBIM documentation in USA
AUTO CAD SERVICES