AppVol Manager Can't Generate Self-Signed Certificate

[Levi Hayes]

I keep getting errors that the AppVol manager virtual machine cannot generate a self-signed certificate to connect to the database which resides on a different virtual machine. Upon investigating the generate_cert.log file, it states, "Failed to execute command. exit_code: 2, Error: The system cannot find the file specified".

But there is no file to specify when I want the AppVol Manager to generate a self-signed certificate.

Additionally, the log file states, "Errno: :EACCES: Permission denied @ rb_sysopen - C:/Program Files (x86)/CloudVolumes/Manager/config/CVPowershell.key (Errno: :EACCES)".

Lastly, I have yet to see any official YouTube videos or documentation from Omnissa on this which is a HUGE failure on their end and is only going to push customers to other solutions such as Azure cloud PC's or AWS Workspaces (especially considering the much more intuitive and ease of use methods that Azure and AWS provide).

If anyone can help, it would be greatly appreciated because Omnissa has been non-existent so far and about ready to drop Omnissa and go with a different solution altogether.

 

Kind Regards,

Levi

[D81]

Hi, 

Im experiencing exactly the same issue.

In my case it is a fresh installation of App volumes 4. Im using SQL server 2022 standard (clustered) and OS for the appvolumes is Windows Server 2022.

During the installation of App volumes manager wizzard I select the Cluster for the SQL server field, I set the SQL credentials and the Database name... Then I launch the installation and after some minutes it always fails on the same point showing an error related with self signed certificate.

Error generating self signed certificate"

"See log/generate_cert.log for details"

I see a redit thread with the problem:

https://www.reddit.com/r/VMwareHorizon/comments/1es45et/appvolumes_selfsigned_certification_failed/

There is a user that fixed the issue by manualy installing the trusted root CA of the MSI, but it doesnt work for me. He also mentioned a possible GPO that may prevent the creation of selfsigned certificates.

I havent find the GPO either but I have asked the customer to check it just in case...

 

Any help will be appreciated!

 

 

Edited August 19 by Dmartinez81

[Holly Lehman]

Hi Both, 

Thank you for raising this issue to us. I have reached out to someone on the App Volumes team to help here. 

They may need more information. But someone should jump on this thread fairly quickly. 

Thanks,

Holly

[Jeff Ulatoski]

Hello @Levi Hayes and @Dmartinez81,

Thank you for bringing this issue to our attention, and I apologize for the frustration it's caused.  

Our engineering team is currently investigating the error related to the self-signed certificate generation during the App Volumes Manager installation.

Based on the information you've provided, our engineering team believes the issue may be related to file permissions, specifically when the App Volumes Manager attempts to create the CVPowershell.key file in the Manager/config/ directory. This error typically occurs when the user account running the installation lacks the necessary privileges.

We recommend double-checking the permissions on the directory mentioned in the log (C:/Program Files (x86)/CloudVolumes/Manager/config/) and ensuring that the user account running the App Volumes Manager installation has the necessary permissions to write to the CVPowershell.key file i and location.

To help us assist you more effectively, could you please confirm if you have administrative privileges on the Windows machine where you're installing the App Volumes Manager? Additionally, if you haven’t already done so, I highly recommend opening a support ticket with Omnissa. This will allow our team to work with you directly and review any logs that might help diagnose the issue more quickly and precisely.

We are here to support you and will continue to monitor this thread for any updates. I’ll keep you posted as we learn more.

Best regards,

Jeff Ulatoski

App Volumes Product Manager, Omnissa

Edited August 21 by Jeff Ulatoski

[Levi Hayes]

Hi @Jeff Ulatoski,

The account that I am using has local administrative privileges and additionally full control to the folder/file path that you have specified via Windows security permissions. I have additionally gone a further measure and ensured that the two virtual machines are in an OU on the domain controller that doesn't not have any GPOs being applied to the virtual machines and still getting the same error.

As for opening a support case. I have attempted to contact Omnissa about not being able to open support cases due to my account not being assigned any product licenses and my colleague had contacted Omnissa support and was able to get a ticket open for the same issue but unfortunately it was closed prematurely with zero remediation. We still cannot open support cases as of this writing.

Kind regards,

Levi

[Jeff Ulatoski]

Hello @Levi Hayes

Thank you for the detailed update.

It sounds like you've taken all the necessary steps on your end, including ensuring that the account has administrative privileges, verifying file path permissions, and removing any potential GPO interference. I apologize for the difficulties you've faced with opening a support case and for the premature closure of the previous case—this is certainly not the level of service we aim to provide.

Given the persistence of the issue despite these measures, it’s clear that further investigation is needed. I’m escalating this matter internally to ensure that you receive the support you need. I'll also make sure that your concerns about the support ticket process are addressed, so this doesn’t happen again.

I will coordinate with our support team to reopen the previous case or ensure that a new one is created immediately. In the meantime, I’ll keep you updated on any progress or additional steps we might need from you.

Thank you for your continued patience, and I assure you that we’re committed to resolving this issue.

Best regards,

Jeff Ulatoski

App Volumes Product Manager, Omnissa

[Levi Hayes]

Hi @Jeff Ulatoski,

Thank you for your quick replies. I have had a member of the support team reach out to me via email and have updated them on the two issues as described here and have provided a link to this page for support to get up-to-speed as well.

Thank you for sticking with this and to help investigate and look for a resolution, it is greatly appreciated. I can also provide the full log file to support if needed and have additionally requested a working troubleshooting session for tomorrow (Saturday) or first thing Monday morning if weekend support is not available.

Kind regards,

Levi

[Jeff Ulatoski]

Hi @Levi Hayes,

Thank you for the update, and I'm glad to hear that support has reached out to you. I appreciate your cooperation in providing the necessary information and linking this page to help our team get up to speed.

I’ll ensure that the support team is aware of your request for a troubleshooting session, and my team will stay closely involved to make sure everything moves forward smoothly. If you could share the full log file with the support team, that would be very helpful in diagnosing the issue more accurately.

Thank you again for your patience and collaboration. We’re committed to resolving this as quickly as possible.

Best regards,

Jeff Ulatoski
App Volumes Product Manager, Omnissa

[D81]

Hi

Please provide any update of the resolution here, we are experiencing the same issue on a brand new App Volumes installation over Windows Server 2022.

Thanks in advance!

EDIT: Someone has fond the hotfix and as it was initialy pointed it is something regarding GPOs
 

 

Edited August 19 by Dmartinez81

[hatem Shahudh]

Yes, for sure it was GPO. As mentioned the resolution is very simple:

Create an OU that blocks GPO's

Move the VM to that OU temporarily while conducting the installation.

Reboot the VM and start the AppVolumes Installation. Once done then you can move the VM to whatever OU you need it to be. Let me know if you have any further issues and Good luck! 

[Levi Hayes]

Hi @hatem Shahudh

I can confirm that my two virtual machines are in an OU that has inheritance disabled and no GPO's being applied and still receiving the generate self-signed certificate failure followed by the installation manager rolling back the installation.

Kind regards,

Levi

[hatem Shahudh]

I had this happened to me once when I retried the install on the same VM that failed before. I'd do a gpupdate /force 

reboot and then retry again or better yet try a new server VM fresh, but make sure it doesn't go in ay OU, but the disabled GPO OU.

I think the reason why it isn't working is because it's trying to run PowerShell to generate that self-signed ssl key as you can see in the screenshot. 

v/r

Hatem Shahudh

Edited August 19 by hatem Shahudh
screenshots

[hatem Shahudh]

You can see logs under C:\Program Files (86)\CloudVolumes\Manager\log

[Levi Hayes]

Hi @hatem Shahudh

I can confirm that I have already ran a gpupdate /force command, rebooted the machine, and still get the same errror.

I am spinning up a new fresh virtual machine to see if there will be any differences.

I was able to pull the logs and send them to support that are in the path that you specified. Additionally, I copied and pasted the specific errors from the logs and put them in quotes in my original post on this thread. Please see my original post to see the error messages which still have not changed.

Kind regards,

Levi

Edited August 19 by Levi Hayes

[hatem Shahudh]

You might have enable PowerShell Execution on the Server that you are testing on right now temporarily and try:

 

Set-ExecutionPolicy -ExecutionPolicy Unrestricted  -Scope LocalMachine

Or try this command

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

Also run this to see what you have 

Get-ExecutionPolicy -List 

Edited August 19 by hatem Shahudh
More commands

[Levi Hayes]

@hatem Shahudh,

I just attempted the following command:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted  -Scope LocalMachine

And then proceeded through the installer and still came out with the same error.

[Levi Hayes]

After talking with three level three support technicians who didn't feel comfortable or confident to stay in a zoom call longer than an hour and couldn't review the log files that they have collected, I have figured out the issue on my own, as well as a remediation path to move forward and proceed with installation. I do not have time currently to post my findings but will do my best to post them and the solution to proceed by end of the week.

Kind regards,

Levi

Edited August 20 by Levi Hayes

[D81]

17 hours ago, Levi Hayes said:

After talking with three level three support technicians who didn't feel comfortable or confident to stay in a zoom call longer than an hour and couldn't review the log files that they have collected, I have figured out the issue on my own, as well as a remediation path to move forward and proceed with installation. I do not have time currently to post my findings but will do my best to post them and the solution to proceed by end of the week.

Kind regards,

Levi

Hi

Im in the same situation, please share your hotfix as soon as possible, many thanks in advance!

 

[Jeff Ulatoski]

Hi @Levi Hayes,

I appreciate your persistence in finding a solution, and I’m truly sorry that our support couldn’t provide the assistance you needed during this process. My team and I will be following up internally with our support team leaders to address your feedback.

I would also like to schedule a follow-up meeting with you personally. As a product manager, anything related to the product is my concern, and I’m very interested in hearing more about your experience—not just with this specific issue, but with our overall product and support. I’ll send you a private message so we can coordinate our calendars for a Zoom call.

Thank you again for your understanding, patience, and diligence in finding a solution.

Jeff Ulatoski
App Volumes Product Manager, Omnissa

Edited August 21 by Jeff Ulatoski

[Levi Hayes]

@D81

Okay,

I have some time to post findings. In the documentation, it states that whether using a single virtual machine for the database and manager, or using separate virtual machines for the database and manager, to utilize the Windows Integrated Authentication. When selecting this option in the installation of App Volumes, it specifies that it will "automatically use this server's SYSTEM account" of the local machine where App Volumes is being installed. And this is the issue.

A computer object and its SYSTEM account cannot be added to an SQL database and given permissions (at least not to my knowledge), and only user accounts can (whether it's an SA login that is created within the SQL database or an Active Directory Windows authenticated login). Therefore, App Volumes attempting to use the local machines SYSTEM account will fail every time unless there is a way to add another machine's SYSTEM account to the SQL database and give it permissions, which again, I have not found a way to do so and there is no documentation from Omnissa/VMware on how to do so either.

The resolution is actually quite simple, it's just not anywhere in the documentation. If you plan to utilize two virtual machines and separate the database from the app volume manager, you need to login to the database virtual machine, open SQL Server Management Studio and connect to the database, right-click on the database and go to Properties, in the properties window, click on Security, and then change it from Windows Authentication Mode to SQL Server and Windows Authentication Mode and then click OK.

 

Ensure that your SA account is enabled for login by expanding Security > Logins on the left hand side, right-click the SA account and go to properties. In the Properties window, click Status and change login from Disabled to Enabled and click OK. You can create a secondary SA account with less permissions to the databases and only give what is necessary for App Volumes if you want to stay a little more secure on the database side of the implementation.

Now, when you run the App Volume installer, and get to the section of choosing your remote database server, select the radio button for "Server authentication using the Login ID and password below" and supply the SA credentials. Uncheck the box for "Enable SQL Server certificate validation" and proceed with the rest of the installation to your desired settings and it should successfully install.

@D81, I included screenshots as I'm personally a visual learner and know others would additionally benefit from screenshots. Please let me know if you run into any additional issues or if it is successful for you. I would like to know if my method works for others.

 

@Jeff Ulatoski, would not mind syncing up with you and discussing further on this and the product overall as a whole. I have even thought about making an instructional YouTube video to specifically show this method for installation to better help administrators and engineers but would need some temporary licenses to be able to create the videos and show the process.

 

Kind regards,

Levi 

Edited August 21 by Levi Hayes

[D81]

Hi Levi,

Many thanks for sharing your hotfix. I was able to fix the problem with your help! 

However I would like to share my scenario to help to understand the problem for future users:

First of all notice that in my case I am using an external database that is created on a SQL cluster.  This cluster is a Failover Cluster with Always On, and after creating the database I will configure on it an Availability Group as a real HA solution. Also notice that I'm using one SQL server 2022 standard which has some restrictions. One of the restrictions is that you can only create an Availability Group (which is OK for me because I just need one for the Appvolumes instance), also notice that the any credentials that you create localy on one SQL server are not automaticaly sync into the second SQL server, so you must manually create them on the secondary server.

So in my case I created a specific AD service account for SQL that was added to the SQL servers and also a local SQL user (different from "sa") to improve security (In both cases I have check that these accounts have "login - enable").

That said, I initialy tested the Appvolumes installation in different ways with these results:

• Setting SQL AD windows credentials. --> it fails on the "self certificate creation"  ❌ 
• Setting SQL AD with SQL user (different from "sa") --> it fails on the on the "self certificate creation"  ❌ 

At this point I discover the thread where someone tolds about creating an OU with blocked GPOs and move them the servers.

• Using specific OU with blocked GPOs --> using SQL AD windows credentials --> it fails on the self certificate creation  ❌ 
• Using specific OU with blocked GPOs ---> using SQL specific user (different form "sa") --> it fails on the self certificate creation ❌

I was getting desperate, then I read you explanation and I realize that I have never tested the "sa" option for creating the database, so I tested it in that way:

• Using specific OU with blocked GPOs ---> using SQL "sa" user --> it works!!! ✅

 

So at this moment Im not sure if it was me that wrongly configured the SQL user or if it was a problem with the GPOs of the previous testd or maybe a combination of both, but anyway I was able to fix the issue!!!

Thanks againg for your help and I hope Omnissa will fix it on the next update (or at least improve the docummentation to include the hotfix resolution).

Regards

.............................

EDIT: I have done a second test and I can confirm that in my case the installation can only be made with the following combination:

• Using specific OU with blocked GPOs ---> using SQL "sa" user --> it works!!! ✅

So probably the SQL specific user that I initially created didn't have the right permissions (Im not SQL expert)

Edited August 23 by D81

[hatem Shahudh]

I'm very happy you guys were able to get this fixed. My experience was different because I used SQL Express since I was only working in Lab Environment. It sounds like in Prod you will need the solution you pointed out:

• Using specific OU with blocked GPOs ---> using SQL "sa" user) --> it works!!! ✅

Thank you again and I hope people benefit from this!

 

v/r

Hatem Shahudh

[Jeff Ulatoski]

Hi @Levi Hayes, @D81, and @hatem Shahudh,

Thank you all for sharing your experiences and solutions in such detail. Levi, I especially appreciate the thoroughness of your findings and the inclusion of screenshots—they're incredibly helpful for others who might face similar challenges.

Levi, I sent you a private message to coordinate a meeting so we can discuss your experience, the product, and your idea about the YouTube video. 

To everyone else, thank you for contributing to this thread. Your collaboration is exactly what makes this community so valuable. We’re always working to improve, and your feedback is crucial in helping us refine both our product and our documentation.

Thanks @Holly Lehman for connecting us!

Best regards,
Jeff Ulatoski
App Volumes Product Manager, Omnissa