TechMassey's Posts

If your unfamiliar with the issue of Appdata with folder redirection, I would at this point suggest seeking VMware professional services. Another option is VMware reccomended VAR. The reason being is appdata, the profile network drives, and the profile management are just the beginning of the challenges your going to face. This is the challenge with implementing VDI as it requires knowledge of multiple software and infrastructure platforms. I'll try to help though on Appdata. The short answer is Appdata contains files that are often not friendly with UNC paths. In some cases apps crash when they see the UNC. Microsoft also does not support Outlook OSTs on UNC paths.

First, I would review your security server settings in the View Administrator. See screenshot below. It is possible the PCOIP secure gateway is misconfigured from the update. The external URL should be External IP:4172 Second, I didn't see you mention if the clients were updated. Let us know if you have and tested it. Third, logs, logs, logs. Logs are the only thing thats going to help us here. You need to review the client logs, agent logs, and security server logs. Good news is VMware made a nice KB that gives you all that info. I suspect the security server log will clearly show why the connection dropped. Here is the Horizon View Logs KB: VMware Knowledge Base

The Persona Management ADMX template can be configured to not redirect for each folder. Such as my docs, picturs, etc. Which would result in the windows folder redirection functioning normally. I strongly advise you do not redirect the appdata folders.  I also strongly advice against using Persona Management. While free, it causes more headaches than wins. There are other options out there like Liquidware Labs or Appsense.

Could you confirm if the affected VMs had a 169 IP before rebooting? With you mentioning that not as many IPs are available as expected. The likely cause is the recomposing where desktops with new MAC addresses get a lease. While the old MAC addresses hold on to existing leases until expiration. Even if DHCP is not the issue in this case. I would cut the lease time to 10 minutes. I have been doing VDI for many years and that will save you a lot of headache in recomposes. There is essentially zero risk.

One of the great parts of Horizon View is the logging capabilities. There is a log for MSI installations and that will tell you where it ran into an error. Here is the KB with All Log Locations: VMware Knowledge Base MSI Installer Log Path: %TEMP%\vmmsi.log_date_timestamp . General Install Log Path: %TEMP%\vminst.log_date_timestamp

Actually, disabling provisioning still allows you to delete desktops in the pool. It is a very good strategy if you want to clear out the VDI desktops AND the replica. However, in this case it would not assist his issue.

These are great tips to check out. From experience, here is what to do and avoid the need to edit the ADAM database. 1. Wait until the delete times out or try to place it in maintenance mode. 2. Power down the VM 3. Now were going to do a two pronged attack 4. Start the delete task on the VM in the View Administrator 5. Then delete the VM from vcenter (make sure to delete and not remove it from inventory) What happens is composer sees that the VM has been removed from vCenter and is then happy. It then deletes the VM from the ADAM database and thus the pool inventory.

Very nice your digging into the logs! The connection server logs will absolutely help us narrow this down. Verify the Horizon View Connection Server and Web Component service is running. Also, verify the friendly name on your cert is 'VDM'. If it is not, fix it, and then reboot My final tip is if you have two connection servers, shut both down. Then start up only one and let it sit to get its services running, then try accessing the again. Good Luck!

I did some digging as this more and more doesn't seem to be a horizon specific issue. Check out this old forum link: LinusTechTips. I know you mentioned you disabled DPI but did you disable DPI scaling on the chrome exe AND reboot. Then shutdown and snap.

The first item to focus on is if the host in fact disconnected. Correlate the error in the events for the pool with the events on the named host. Likely, the host did disconnect and vCenter tracked it. This isn't an uncommon scenario in Horizon View depending on number of concurrent operations. If the host is healthy and if in Horizon View Administrator, the host shows green in the health view. Then disable provisioning on the affected pool and then enable provisioning. The error should then be cleared.

If you set the global SSO setting in View Admin to greater than 15 min, it should resolve this issue. I would set it to 30 min, start a new login session, lock it, come back after 20 min. You should be able to get back to the desktop with only the initial authentication at the thin client. 

I suspect the ports on the vSwitch or vDS whichever you are using. Before rebooting, go find the port they are connected to and refresh it. See if the connection is restored. I would also set static binding on the portgroup being used by the VDI desktops.

Also I want to mention that this is a common escalation I see. You can quickly confirm by looking at the event logs for the VDI pool they are logging into. You will see the user login several times and each time Horizon View sends them to the same desktop. That is when you delete that desktop.

If your accessing the VDI desktop from the vSphere console and it still logs you out. It likely is an OS/and or group policy issues. You will need to review the system and application event logs. I would also further try to isolate the issue by logging in with a local account.

Total respect on trying to tackle this difficult issue. I love Bomgar as well. Here are a few thoughts as this is a very unique challenge. 1. Use a flag file that gets created after the postsyncscript that will skip over the install if it exists on refresh. Cons: Can't think of one at the moment but its been a LOOOONNGGG Day . 2. Set pool to delete on logoff and configure pool to not re-use computer names (Note that this is explained well in pool config, the computer account must be present in the target OU for it to skip. Which means you may have to setup a post logoff script that adds said computer account to ensure it is not reused.) Cons: Fairly convoluted, eventual Computer Account cleanup, and extra I/O for recompose vs refresh. Good Luck!

The client and agent will still establish an SSL connection through PCOIP. This is not the way to approach your challenge. Riverbed should have documentation on Horizon View and I would work with their support. You may need to get VMware involved as they likely have an approved list of WAN accelerators.