AnsweredAssumed Answered

Suppress EULA Agreements VDI

Question asked by Randall Brown on Nov 14, 2014
Latest reply on Mar 26, 2020 by Marco Laffra

Good morning.

 

I am the VDI system administrator for a university. We currently use Solidworks 2013 in a VMware linked clone VDI environment. We currently have one gold image which is pushed out to a pool that multiple students could potentially use. These linked clones are randomly assigned, and every time a user logs out the linked clone is refreshed.  I have been given a mandate to remove all pop-ups from any programs installed on said images.

 

With the 2013 program, this was not an issue. One acceptance of the EULA was sufficient. When I pushed that acceptance to the default image via sysprep, then every user going forward on a linked clone will not get that prompt. Here is the registry key from the Solidworks 2013 EULA, for example:

 

[HKEY_USERS\S-1-5-21-3201...\Software\SolidWorks\SolidWorks 2013\Security]

"Lic Agreement Accepted"="Yes"

 

With the installation of Solidworks 2014, however, that license agreement prompt has changed with regards to how the registry displays the user's acceptance. After doing some registry mining, I was able to locate what I believe are the keys which affect these prompts. Here are those keys:

 

[HKEY_USERS\S-1-5-21-3201...\Software\SolidWorks\SolidWorks 2014\Security]

"EULA Accepted 2014 SP2.0 TEST-LFSW-1 onfire247"="Yes"

 

[HKEY_CURRENT_USER\Software\SolidWorks\SolidWorks 2014\Security]

"EULA Accepted 2014 SP2.0 TEST-LFSW-1 onfire247"="Yes"

 

Looking at these keys reveals the problem. TEST-LFSW-1 is the computer name generated from the linked clone test group, and onfire247 is the test login I use to access the pool. In other words, if there is ever a new machine name or user name, it will prompt the popup again and add a second entry to the list. Considering the number of students we have who could potentially access it, and the number of possible machine names, pre-loading registry keys will not resolve this.

 

Does anyone have a work around for this?

 

I have tried adding generic names for those specific fields without success. I also considered scripting the VMware volatile environment key that shows the user's name, but that will not help with the machine name. Additionally, I don't think that option will work since the HKEY_USER key can change.

 

Any suggestions would be greatly appreciated.

Outcomes