Error Installing Cisco DCNM 11.5(4) on Windows Server 2022

Issue

After launching the DCNM installation, InstallAnywhere gets to 100% and then throws a Fatal Application Error:

Clicking the Details... button gives you the following text:

Flexeraaw_$aaa: Windows DLL failed to load
at Flexeraaw_.af(Unknown Source)
at Flexeraaw_.aa(Unknown Source)
at com.zerog.ia.installer.LifeCycleManager.init(Unknown Source)
at com.zerog.ia.installer.LifeCycleManager.executeApplication(Unknown Source)
at com.zerog.ia.installer.Main.main(Unknown Source)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at com.zerog.lax.LAX.launch(Unknown Source)
at com.zerog.lax.LAX.main(Unknown Source)

Resolution

This error is due to the version of InstallAnywhere used to package this version of DCNM that only supports up to Windows Server 2016.

1. Go to Start->Settings
2. Search for view advanced
3. Select the search result View advanced system settings
4. Click the Environment Variables button
5. Click New... in the System variables section
• Variable name: JAVA_TOOL_OPTIONS
• Variable value: "-Dos.name=Windows Server 2016"
6. Click OK and your new System variable should look like this:
   
   
   
   
7. Click OK to close the Environment Variable window
8. Click OK to close the System Properties window
9. Close the Settings window
   

HOW-TO: Force IE11 to disable Adobe PDF Reader (or any other) add-on once and for all!

 There are plenty of how-tos out there about how to disable Adobe's PDF Reader add-on in IE11. For their part, it gets the job done. That is great if you are a home user or even a power user at work and would rather take care of it yourself than call the helpdesk. Translation: It is a per-user setting.

As a network admin, I needed to disable the add-on for all users which usually means group policy is involved. Again, there are existing articles out there that explain which group policy to enable and how to configure it. And again, it gets the job done...or so I thought.

After finding out the CLSID of the Adobe PDF Reader add-on, I added it to my add-on list with a value of 0 to disable it and not allow changes. A quick gpupdate later and I verified the add-on was now showing up as disabled in IE with the options disabled to change it. With everything looking good, I browsed to URL of a .pdf and watched with disappointment as it loaded right up in IE.

This is where we fire up an upbeat track from the 80's and cut to a montage.

My first discovery was that if you manually disable the add-on, everything works as expected. Of course that defeats the purpose of having a group policy...

Logged into a workstation as a user who's add-on would persist despite everything saying it was disabled, I 'reg load'ed up an NTUSER.dat from another user who's add-on was truly disabled. Since the behavior varied by user, I suspected the fix was buried somewhere in the HKCU hive. I searched for the CLSID and noted they keys/values from the mounted hive and compared it with the logged-in user's HKCU hive. When I added the key below, the add-on behaved correctly (in that it acted disabled) for the logged in user. Further testing with additional users proved the case.

Here is the exported key:

 Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{CLSID}]
"Flags"=dword:00000001
"Version"="*"

Replace {CLSID} with the CLSID of the offending add-on.

In my case, we use Ivanti Environment Manager so I was able to inject that key into a user's HKCU after logon but you could also do this in a logon script.

I suspect you'll see this similar behavior with any add-on that you have added to your group policy when it's key is not found in the above path.

 

Non-Persistent VDI: Adding RDP Passwords With Ivanti Environment Manager

Scenario:

Users accessing a non-persistent virtual desktop use an application via an RDP connection to a server. 

Problem:

When users launch the RDP shortcut, they are prompted for credentials. All users need to use the same service account local to the server but:

1. Users should not have to remember the service account username.
2. Users should not need to know the password.
3. Users should be automatically logged in.

The username/password can no longer be entered into the .rdp file by one user and read by another.

Solution:

Use a combination of Ivanti Enviroment Manager and Powershell to add an entry to the users' Credential Manager.

For this example, I will assume the reader has knowledge of Ivanti EV. I have a Reusable Node for creating desktop shortcuts where these steps are stored. The reusable node is then added under User > Logon > Pre-Desktop so all shortcuts are available immediately after logon to the VDI desktop:

1. Create a Powershell script to launch the RDP session:
   
   
   start-process -filepath "mstsc" -argumentlist "/v:servername"
   exit
   
   
   
2. Save the script to whatever share used to copy files to desktops in Environment Manager
3. In EV, Create a User Group condition for the AD group that will need the shortcut (Optional if not all users need this shortcut)
   
4. Under that condition, create a Copy File action to copy the script created in step #1 to the desktop
5. Under that action, create a Create Shortcut action to place a shortcut on the users' desktop
   
   
   The target of the shortcut is the path to Powershell (eg. C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe)
   Parameters: <Path to Powershell Script copied in step 2> -windowstyle hidden
   
   
   
6. Under the condition in step 3, create a Session Variable action. Enter a session variable name and set it's value to the password of the RDP user.
   Note - This does mean that the password is being stored on the Ivanti service in plain text. Make sure proper NTFS and/or SQL permissions are set to prevent unauthorized users from opening the configuration file. Actions in next steps prevent the plaintext password from being accessible on the client.
   
7. Under the session variable action, create a custom action of type Powershell and add the following code to the bottom of the script substituting in the user nane and server name for the RDP session, as well as the session variable created in step 6:
   
   
   $user = "Domain\RDP_Username"
   $server = "RDP_Servername"
   $password = (Get-SessionVariable "sessionVariable")
   
   cmdkey /delete:"$server" # clears the credentials
   cmdkey /generic:"$Server" /user:"$user" /pass:"$password"
   
   Remove-Variable password # deletes plaintext password in memory
   
   
   
8. Under the custom action, create a Delete Session Variable action. Specify the same session variable created in step 6.

The result will create a desktop shortcut that launches a remote desktop session to the specified server and automatically logs in using the credentials stored in Credential Manager. All without the user needing to know the server name, user name, or password. Additionally, the plaintext password is not stored anywhere on the VDI desktop.