After recently completing a ProfileUnity 6.7 to 6.8 upgrade, I received a login message within AWS WorkSpaces that stated, “No ProfileUnity License server defined. Please contact your system administrator.”
This message, to me, seems expected at some level as the licensing file I obtained from Liquidware for version 6.7 was to be replaced with a new 6.8 license that was generated using both a License and Activation code via the Liquidware Activation Portal. The license code was sent to me in an email from Liquidware and the Activation code can be seen within the ProfileUnity Management Console. To activate your new ProfileUnity license, perform the following:
- Retrieve the activation code from the ProfileUnity console by hovering over your user name and select Licensing from the drop down list
- Connect to the ProfileUnity Activation Portal and paste in your license and activation codes and click Proceed
- On the License Retrieval screen, copy the license text
- Open the ProfileUnity Management Console, return to the License Management page, and then click Update
- Paste the license contents into the License Import page and then click Import
- With the license updated, click Deploy Client Settings
- When you deploy the client settings, you have the option to choose Domain, Cloud, or Download. Basically you are telling ProfileUnity where to send the ClientSettings.xml file, which contains the ConnectionString and LicenseMode settings. In this instance, AWS WorkSpaces is utilized to provide virtual desktops, thus I choose to deploy clients settings to the Cloud as I wanted to copy the ClientSettings.xml file to the ProfileUnity S3 configurations bucket. On the Deploy Client Settings window, select the deployment Platform that aligns with your standards and click Deploy.
I really thought that this was going to fix the issue I was experiencing but alas, it did not. I still received the message that no ProfileUnity license server was defined when logging into an AWS WorkSpace instance. I dug a little bit more on the Liquidware support site and found an article addressing the problem. However, stepping through its steps did not provide a resolution in my case though I was able to use the article to confirm that my WorkSpace could communicate with the licensing server on port 5672 which indicated to me that I wasn’t dealing with a network and/or firewall issue.
If you are troubleshooting this issue, I recommend stepping through the Liquidware support article (link above) prior to performing the steps I detail below.
After trying a couple more things on my own, I decided to open a case with Liquidware support and the following steps were completed to resolve the issue:
- I was told, and saw that it was indeed true, that the ADM template with ProfileUnity 6.8 provided additional machine-based GPO settings. To obtain the updated ADM file, open the ProfileUnity Administration page, scroll to the ProfileUnity Tools section, and click Download Client Tools.
- With the client tool downloaded, extract the contents of the zipped folder. The new ADM/ADML/ADMX files should be located on the root directory. Copy those files to your preferred GPO template location. In this instance, I created and then copied them to the GPOFiles folder on the domain Netlogon share.
- Open Group Policy Management and edit the GPO which contains the settings applied to the virtual desktops. Right-click Computer Configuration | Policies | Administrative Templates and select Add/Remove Templates
- On the Add/Remove Templates screen, click Add.
- On the Policy Templates screen, browse for and then select the appropriate ADM template. Click Open.
- When returned to the Add/Remote Templates screen, click Close.
- Within the Group Policy Management screen, expand Administrative Templates | Classic Administrative Templates | Liquidware Labs | ProfileUnity. Under ProfileUnity, you’ll see 32 Bit and 64 Bit, select the option that pertains to your configuration. There are (2) settings that will be Enabled: Client Settings Path and Amazon S3 Storage Credential.
- Right-click Client Settings Path and select Edit. Set the policy to Enabled and then under the Client Settings Path, enter the path to the ClientSettings.xml file created earlier. When I deployed the new ClientSettings.xml file, I choose Cloud as my deployment method, thus the Client Settings Path in this policy should point to the S3 Configuration bucket in which the ClientSettings.xml file resides. Click OK.
- Assuming you have chosen to deploy the ClientSettings.xml file to an S3 bucket, you’ll need to enter Amazon S3 Storage Credentials. When setting up ProfileUnity to use S3/Cloud Storage, you’re prompted for Cloud Credentials. In the case of AWS S3, you’re prompted to enter the Access and Secret Keys for an IAM account created for ProfileUnity. ProfileUnity then encrypts this information and that is what you need to enter on this policy. To retrieve the encrypted credentials, open the ProfileUnity Administration page and within the Cloud Storage section, click the copy button next to the desired credentials.
- Edit the Amazon S3 Storage Credentials policy, paste in the Encrypted credentials and click OK.
- At this point, I ran a gpupdate /force on the WorkSpace and rebooted for good measure. After doing so, the undefined ProfileUnity license server message was not displayed at login.
It’s entirely possible that this solution may not be the ideal solution for every situation in which you receive the “No ProfileUnity License Server defined” message. In my case, I am using AWS WorkSpaces AND I had a Computer Startup Script specified. If you are not using WorkSpaces, maybe you are using VMware Horizon or Citrix XenDesktop, AND if you don’t have a Computer Startup Script, you may find that the resolution for your use case is to update the gold image or the ProfileUnity application layer just as the Liquidware support article states.
Regardless of your specific resolution steps, I believe you’ll still find it helpful/beneficial to import the ProfileUnity 6.8 ADM template(s) into your Active Directory.