I have a critcial VDI issue with my VDI 4.6 View pilot.
I am recieving the error message below:
Domain status error detected. View Administrator is unable to perform operations related to domain.
No users can login to my VDI system. Unfortanetly, I bought my View licenses through HP. So calling HP support for VMWare support is really useless.
Any direction out there on a resolution????
Thanks in advance...
I would first verify that there are no domain controller issues going on in your environment. Then I move on to verifying dns on the connection brokers.
That is the first thing I reviewed and checked. I have two connection brokers behind an NLB VIP. When I RDP'ed to node 1 yesterday, I noticed the license for my Win2k8 R2 64-bit server was indicating it was not genuine. I tried to manually license it with the SLMGR commands and could NOT get it licensed. Is that probably my issue? I have actually shutdown this node 1 with hopes that node 2 would allow View to authenicate AD, but NO dice there. So I don't thinkit is from node 1 being un-licensed.
DNS looks fine. DNS Servers are confirmed up and running, etc.
Thoughts?
I know this is simple but have you rebooted the connection brokers? Also you might want to consider trying to rejoin the domain.
Naturally, I tried rebooting. No luck. I actually tried to remove node one from the domain and re-dd. On the re-add portion, I got a an error message about joing the domain. However, it allowed me to join successfully upon the reboot. I was able to login to the domain on node 1 and get my drive letters, etc. However, inside the View admin GUI, all my VMs had a (missing) next to all 100 or so under the Status column. That was to scary so I reverted to a snap shot of the View connection server from probably two weeks back.
This server appears to be very sluggish even though I can not pin point a culprit in task manager. Any more thoughts???????
Maybe just build a new server as a replica and then retire the older broken server. This way you have a new one on ont he domain and then you also hav the most up to date ADAM database.
I hear what you are saying, but that is like getting a splinter in your finger and cutting off your hand to get around the issue. Plus what happens if this issues occurs again, I would like to possible know where to start troubleshooting....
That may be my only resolution....
Not really like cutting your hand off. Your setting up a replica server which allows your users to start working and then you can remove the failed servers from the NLB which would allow you to troubleshoot without the users being affected.
I have removed both my connection servers from the domain and re-added them. The Domain issue seems to be cleared up as it is nice and green. However, I try to access my VDI VM view the View client and now users are getting a "The VCS authenication failed. You are not entitled to use the system"
On another good note, all the VMs do NOT have the missing status listed in the View admin GUI....I think I am getting close...
Had this issue yesterday when I removed a user account and re-added them back into the domain.
You will have to re-create your user entitlements to the pools (UserA entitled to use PoolA) and go through the list.
Probably not what you want to hear, but it was the only way I have found it works.
We had a similar issue when we lost our AD server over a year ago, took me over 24 hours of straight work to get our users back up and on the system.
Just try with one or two users and have them re-connect to see if they can log back in.
Hope that helps!
Once I re-joined my 2 View connection server back into the domain. My Domain when from Red to Green within the View admin GUI. So that was nice!
However, all media pools were disabled and all VMs where in mainteance mode. I simply had to enable all media pools and perform an "Exit Maintanence" on all VMs.
So I am basically back to square one now.... life is good, but I still have several VDI users that are timing out getting their desktop internally or extenally. So I know it is not a connection broker, their VMs, or a Security server. Something else....still searching...
Interesting note here...the few users that are still having this timeout issue are isolated to a specific View media pool. I determined this by adding the problematic user to a different media pool and was able to get a desktop. Then I tried the old media pool and it still timed out.....
So it is not an AD issue per say...