eeg3's Posts

This function does not currently exist in the View PowerCLI cmdlets or within the Orchestrator functionality; however, check out: Setting VMware View Desktop State Remotely. You'll basically be m... See more...
This function does not currently exist in the View PowerCLI cmdlets or within the Orchestrator functionality; however, check out: Setting VMware View Desktop State Remotely. You'll basically be modifying the ADAM database. If you go this route, be careful. Tinkering with the ADAM database has potential to cause damage to the environment if incorrectly done.
If you choose to implement DFS with Persona Management, please be sure to check if the strategy you're going with is supported: Microsoft's Support Statement Around Replicated User Profile Data. ... See more...
If you choose to implement DFS with Persona Management, please be sure to check if the strategy you're going with is supported: Microsoft's Support Statement Around Replicated User Profile Data. Your mileage may vary around VMware trying to support one of the unsupported scenarios, but I suspect it will be similar to Microsoft's support statements around DFS replication with profiles.
You should use PCoIP in 99.999999999% of scenarios. You can tune it to use less bandwidth if needed via GPO (Disable Build-to-Lossless, set bandwidth/quality/etc caps).
Take a look at Liquidware Labs' Stratusphere UX.
Modify the image to remove the user profiles from it: Computer Properties -> Advanced System Settings -> Advanced Tab -> User Profiles -> Settings -> Select users' profiles -> Delete. Delete t... See more...
Modify the image to remove the user profiles from it: Computer Properties -> Advanced System Settings -> Advanced Tab -> User Profiles -> Settings -> Select users' profiles -> Delete. Delete the user's existing desktop, recompose the pool to the fixed image, then have the user try.
Do the affected users already have a profile on the base image? If so, that will cause problems.
You can use tagging on the pools and connection servers to separate them out and keep them in the same overall environment.
Check the services and other checks in this document: View Transfer Server Remains in Pending State. Also, the View Transfer Server / Local Mode will be removed in View 6.0. You may want to ta... See more...
Check the services and other checks in this document: View Transfer Server Remains in Pending State. Also, the View Transfer Server / Local Mode will be removed in View 6.0. You may want to take that into account if just now starting to implement it.
Did the datastores already have near the same amount of free space? A rebalance may not move desktops around if the free space is not substantially different.
What Gaurav_Baghla posted along with changing the "Automatically logoff after disconnect" to a time period that fits your needs should do the trick.
It will depend on the app if the install to the D:\ will behave gracefully, so the only way you'll know for sure is to test it out. If the apps licensing allows it, can you just install it on ... See more...
It will depend on the app if the install to the D:\ will behave gracefully, so the only way you'll know for sure is to test it out. If the apps licensing allows it, can you just install it on the image and let the other users ignore it? Is ThinApp an option for those apps? Can you just create another image and keep them in a dedicated linked-clone setup so your management of the desktops is the same across both pools? If you go the full clone desktop route, you're going to have to change the way you manage that desktop's updates and modifications... mimicking how you'd manage physical PCs.
I have not seen the formal release notes, but screenshots floating around show usage of Windows 2012.
There's no way built in to View that will accomplish this. You can set a global session timeout and logoff on disconnect, but not disconnect or logoff on idle time. You can try the below to achie... See more...
There's no way built in to View that will accomplish this. You can set a global session timeout and logoff on disconnect, but not disconnect or logoff on idle time. You can try the below to achieve it, though. Virtual Kilts: Disconnect Idle Users in View
250ms is the maximum supported latency.
Are you just using folder redirection or actually the entirety of View Persona Management (Deployment Guide)? The latter would be recommended.
Optionally you could use thinreg.exe to load them via a login script, or leverage something like LiquidwareLabs ProfileUnity to do that easier.
I've had good success by trying to break out most of the update process to outside of the image itself. For example, moving most image updates to be pushed through software deployment tools for b... See more...
I've had good success by trying to break out most of the update process to outside of the image itself. For example, moving most image updates to be pushed through software deployment tools for both updates and new software. We also try to leverage environment management solutions (e.g. AppSense Environment Manager/Application Manager, if available in the environment) to keep the golden image as barebones as possible. That way, we can power up the golden image, push everything through our ESD console, and then have to do very little to the image itself manually, thus reducing manual errors and making the re-build (if necessary) fairly painless. Also, keeping the golden image count down as low as possible is always a goal worth striving for, as you hinted at.
I've seen similar behavior before, but cannot remember the KB I used to resolve; however, the recommended solution was a reboot of connection servers and vCenter.  Not sure this is the same issue... See more...
I've seen similar behavior before, but cannot remember the KB I used to resolve; however, the recommended solution was a reboot of connection servers and vCenter.  Not sure this is the same issue and I noticed you mentioned you rebooted vCenter and bounced services, but wasn't sure if you rebooted your connection servers.
I don't have a P25 in front of me, but if you want to duplicate displays then I believe you need to do that through the settings on the zero client instead of Windows.
You can either shut it down or leave it running. It's up to how you want to do it. I personally power them off. Do not delete the snapshot unless it is no longer in use or needed. Existing des... See more...
You can either shut it down or leave it running. It's up to how you want to do it. I personally power them off. Do not delete the snapshot unless it is no longer in use or needed. Existing desktops will continue to run, though; they are based on the replica VM that has already been copied off of the snapshot itself. Rebalances to new datastores and creations of new pools will fail if the snapshot is removed.