We use viewdbchk every now and again to cleanup pools in Horizon, when the View Admin console is having issues doing such. Just like everyone else. However, since the move to 7.3.2, we can't seem to run it.
According to the release notes there was a change:
This is fine, we know what credentials to use. When we run the command though ("viewdbchk --removeMachine --machineName Xyz --noErrorCheck"), and are prompted for our service account password for vCenter (https://vcenter.fqdn:443/dsk) and for Composer (https://composer.fqdn:18443), when we enter, no characters show not even masked (this might be by design), and when we hit enter to confirm anyway, we are greeted with "ERROR: Cannot get password for user "service_account".
We know the password, we even tested it separately. Anything we can provide within the command differently perhaps?
Thanks in advance.
I have ran into this same behavior on one of our two connection servers as well. Not sure why it never happens on the other connection server.
I tried what you suggested and logged in with another admin account. Running script and entering password under this account works fine...
I've seen this as well while troubleshooting an issue with a View environment. We opened up a ticket with VMWare for the root-issue and this was brought up as a sidenote. One of the VMware engineers seemed to think it had to do with permissions and the original installer of View on that server. For example, a colleague could run it on a connection server he installed but I could not and vice-versa.
I'm hoping this has been addressed in 7.5 and look forward to testing it.
I think I just found a solution- At least for View 7.4.
As I mentioned above, Viewdbchk seemed to work for the people that installed or last upgraded the connection broker but not for anyone else. I started looking at file permissions for any unique/explicit permissions to user accounts but came up empty. I also compared path/environment variables between users and nothing came of that either. I then started poking around the registry and here's where it gets interesting!
I found a pair of keys that only had explicit permissions to individual users in our domain. For example, Connection Broker 1's keys had "Special" permissions for Mikey and Connection Broker 2's keys only had permissions for Suzy. They could run Viewdbchk from their respective brokers but not vice-versa. The keys I found were:
HKLM\SOFTWARE\VMware, Inc.\VMware VDM\KeyVault\vmware_view_java
HKLM\SOFTWARE\VMware, Inc.\VMware VDM\KeyVault\vmware_view_java\1
HKLM\SOFTWARE\VMware, Inc.\VMware VDM\KeyVaultCNG\vmware_view_java
HKLM\SOFTWARE\VMware, Inc.\VMware VDM\KeyVaultCNG\vmware_view_java\1
I added Domain Admins to each top level key (vmware_view_java) with Full Control (which propagated to the "\1" key) and could then run Viewdbchk under other user accounts from each connection broker.
I hope that helps everyone else!
Hi, had the same problem, added local administrators group on both our connection servers on the Java key. Works just fine now!
HKLM\Software\VMware, Inc.\VMware VDM\KeyVaultCNG\java.
MrCheesecake had the solution !!
Also had the same issue and found this post during our investigation.
Thank you MrCheesecake for sharing your findings.
Once permissions were granted to the reg key, the command worked.