New training course: Customizing SQL Prompt. Watch now.

SQLPrompt 10 in Horizon VDI environment....need to re-register license constantly

htcolburnhtcolburn Posts: 2 New member
**DISCLAIMER**  I'm not a SQLPrompt user, nor am I a code developer.  I'm a sysadmin responsible for maintaining the VMware Horizon environment at our company, so if I ask stupid questions regarding SQL Prompt, that's why.

Here's my problem.....

We have a large user-base of developers that use SQLPrompt version 10 in their development activities.  They run it with SSMS 18.6 in a VMware Horizon "Instant Clone" environment that utilizes a technology called App Volumes.  Basically what this means in this example is when a user logs in, they have what's called a "writable volume" that contains their login profile information and any/all applications or data they install.  This is where they install SQLPrompt, and when they logout, that volume is detached preserving all the data written to it for use in their next login session.

We also utilize a mechanism called Dynamic Environment Manager (DEM) that imports and exports other user-critical data for applications and their user experience.  For example, we capture registry settings that control their desktop background, application registry settings and files specific to that user, etc.  These files/settings/keys are captured when the user logs out, and then re-imported when they log back in.

Now that I've explained these parts, here's where the SQLPrompt question comes in.  When the users install SQLPrompt, they go through the license registration process just fine, and they can utilize all the functions/features just fine.  However, when they log out, there are times when they need to re-register the application in order to use it.  This is not across-the board though, which makes it difficult to troubleshoot.

Using DEM, I'm capturing the following items:

HKCU\Software\Red Gate
HKLM\SOFTWARE\Wow6432Node\Red Gate
c:\users\<username>\AppData\Roaming\Red Gate

Are there any other directories or registry keys that should be added to ensure the license information is propagated across login sessions?  I've been beating my head against the keyboard for weeks now trying to sort this out, and haven't gotten anywhere.

Any/all assistance is greatly appreciated!
Tagged:

Answers

  • Hi htcolburn,

    Thank you for your post. 

    When you mentioned that this issue was not happening across the board, is it constantly affecting the same users? Or does it only happen to a handful of people each time, but a different handful of people each time (maybe some overlap)? 


  • htcolburnhtcolburn Posts: 2 New member
    Honestly, I'm not 100% sure.  I can't seem to get the issue to reproduce in my sessions, but I do get reports of others having the problem.

    In looking at how the registration process works, I'm beginning to think that this will be a permanent issue for our non-persistent environment.  Every time the users logs into a new session, it's a different machine, so the machine hash won't match what gets captured into the registry which is probably the root of the problem.  As long as the user remains logged into that specific session, they should be fine though.

    Thoughts?
  • Unfortunately, our Licensing client doesn't do to well with non-persistent machines. There's no ideal way to run the software on this sort of environment. With it being a non-persistent machine and users getting a "fresh" machine each time, they will be required to login with their Redgate ID each time.

    You could also try capturing the files at C:\ProgramData\Red Gate\Licenses, and see it that has any effect, although I cannot guarantee it will. 
Sign In or Register to comment.