View 5 Persona Issues

[Phoenycks]

I've been searching through the forums but haven't quite found what I'm seeking...

I'm weighing the pros and cons of various View configurations. It's been impressed upon me that Persona is the only way to go, but I'm doscovering that's just not always the case. I've come across several exceptions, and right now I'm in a situation where I'm starting to think that Persona might not even be a valid solution for my current client. I may end up going with persistent desktops...

Here's what I've come across so far:

In Persona, login times are excessive. I've come across a couple of articles suggesting this may be AV related, so I've uninstalled it (Trend Micro) from my base image and recomposed the pool. Will be testing that shortly.

With Persistent, this doesn't appear to be an issue.

Persona - I've completely tweaked the image with every optimization I can find. This includes disabling Indexing and Search, Disabling Offline Files and Outlook Cached mode, etc...

With Indexing disabled, users can't create any new libraries, something they've done in the past.

With Search disabled, searches are now against the Exchange server and therefore less robust (though they still seem to work OK - it just doesn't highlight the search terms in the results any more)

Without the Outlook offline cache, the Junk Mail folder is now useless.

In order to enable all of this, I would need to enable Indexing, Search, and Cached mode. These are a huge performance hit though - Indexing and Search hit the CPU, Memory and SAN. Cached mode KILLS Outlook opening time, since it can take 10 minutes for Persona to download the OST file - they can be several gigs in size. Even if I preload that file, you're just killing performance until it downloads.

If I go with a Persistent desktop, I can enable a lot of this without too much of a hit, but the back end suffers - SAN is hit pretty hard, and forget about saving drive space - even with Linked Clones, the persistent desktops are eating 40-50GB each, and the SAN just isn't big enough to handle that. Also, the persistent disks are constantly running out of space. I can potentially change that configuration, but I've never done that so I don't have any idea what the performance impact would be.

I've used View in several locations with a similar configuration, and by-and-large the Persona configuration works well. This client however has a rather robust desktop requirement, and I'm not sure Persona is up to the task. Either that, or I do not yet have it configured ideally.

Any thoughts or suggestions?

Thanks!

[Phoenycks]

Update - with Trend removed, login times are down from about 3 minutes to just under a minute. An improvement but still not as fast as a persistent desktop, which takes just 15-20 seconds to log in...

[mittim12]

In Persona, login times are excessive. I've come across a couple of articles suggesting this may be AV related, so I've uninstalled it (Trend Micro) from my base image and recomposed the pool. Will be testing that shortly.

With Persistent, this doesn't appear to be an issue.

Keep in mind that with persistent desktops the profile is likely local which is always going to be faster imo.

Persona - I've completely tweaked the image with every optimization I can find. This includes disabling Indexing and Search, Disabling Offline Files and Outlook Cached mode, etc...

With Indexing disabled, users can't create any new libraries, something they've done in the past.

With Search disabled, searches are now against the Exchange server and therefore less robust (though they still seem to work OK - it just doesn't highlight the search terms in the results any more)

Without the Outlook offline cache, the Junk Mail folder is now useless.

In order to enable all of this, I would need to enable Indexing, Search, and Cached mode. These are a huge performance hit though - Indexing and Search hit the CPU, Memory and SAN. Cached mode KILLS Outlook opening time, since it can take 10 minutes for Persona to download the OST file - they can be several gigs in size. Even if I preload that file, you're just killing performance until it downloads.

If I go with a Persistent desktop, I can enable a lot of this without too much of a hit, but the back end suffers - SAN is hit pretty hard, and forget about saving drive space - even with Linked Clones, the persistent desktops are eating 40-50GB each, and the SAN just isn't big enough to handle that. Also, the persistent disks are constantly running out of space. I can potentially change that configuration, but I've never done that so I don't have any idea what the performance impact would be.

I've used View in several locations with a similar configuration, and by-and-large the Persona configuration works well. This client however has a rather robust desktop requirement, and I'm not sure Persona is up to the task. Either that, or I do not yet have it configured ideally.

Any thoughts

or suggestions?

I think you are spot on with your OST comments.  If you enable them you lose storage savings, take a performance hit, and it really would be brutal in a floating pool scenario.   There was a good blog on this awhile back @ http://info.kraftkennedy.com/blog/bid/102030/Don-t-Fear-Outlook-in-VDI-Environments.   Also the indexing puts a strain on the backend storage infrastructure.     Persistent may be the way to go for the best user experience but still enabling these features is going to hurt performance on the SAN.   Is the SAN dedicated to VDI or will this have a effect on other applications/servers too?    If you have to increase the realability of the SAN by upgrading does that effect their willingness to move to a VDI solution?

[Phoenycks]

As far as the the Persistent desktops go, it is a local profile. Which is faster. However I have it configured for a persistent data drive for user profiles, and that can't possibly be the best way to do that. View seems to want to default that to 2GB. Many users have OST's that large or larger, nevermind the rest of the profile. I typically double that to 4GB, but even that's not always enough - a couple users have profiles in excess of 15GB. Where on earth am I coming up with that space? There must be a better way, I need to revisit the configuration.

That's on the persistent desktops of course, not the Persona floating pool where the OST is disabled.

However, another consideration is that not all of these users are only on virtual - some also have laptops. That makes it even more interesting. Offline Files, for example, is a computer configuration - no problem. Disable on the virtuals, enable for the laptops, all is well. But Disabling Cached mode in Outlook is a user configuration - it's all or nothing. So for these laptop users, their View machines need cached mode enabled no matter what I do. When they're traveling, connecting to Exchange is certainly not always practical, particularly when they are out of the country.

The SAN does everything - servers and VDI - though they are on separate LUNS. It's not a particularly robust solution though - I can't separate the drives out individually. All LUNS reside on a giant RAID5 of all the available disks. Not ideal in my opinion...

Also - the article is great, though it's essentially suggesting the exact configuration I'm testing now.

And one last note - they are all VDI here - no physical machines except the laptop users, of which there's only a handful. They've been on View since 4.0, and were originally configured with persistent desktops. What I'm trying to do now is increase performance and decrease disk space usage by moving to Persona. The SAN is about at capacity, but if I could get some space back I could delay an expansion...

Message was edited by: Phoenycks - spelling and grammar...

[mittim12]

Phoenycks wrote:

As far as the the Persistent desktops go, it is a local profile. Which is faster. However I have it configured for a persistent data drive for user profiles, and that can't possibly be the best way to do that. View seems to want to default that to 2GB. Many users have OST's that large or larger, nevermind the rest of the profile. I typically double that to 4GB, but even that's not always enough - a couple users have profiles in excess of 15GB. Where on earth am I coming up with that space? There must be a better way, I need to revisit the configuration.

That's on the persistent desktops of course, not the Persona floating pool where the OST is disabled.

it's definitley going to take up space and nothing you can do about that.   The persistent disk are thin provisioned to start and you can expand them if a user runs out of space.   At least it's flexible.

However, another consideration is that not all of these users are only on virtual - some also have laptops. That makes it even more interesting. Offline Files, for example, is a computer configuration - no problem. Disable on the virtuals, enable for the laptops, all is well. But Disabling Cached mode in Outlook is a user configuration - it's all or nothing. So for these laptop users, their View machines need cached mode enabled no matter what I do. When they're traveling, connecting to Exchange is certainly not always practical, particularly when they are out of the country.

Are you sure about that?   I thought cache mode was an Outlook client setting.  I can enable it on my physical desktop and it remains disabled in my VDI sessions. 

[Phoenycks]

Outlook Cached Mode is definitely a GPO user setting - that's how I have it configured now. It's under User Configuration -> Policies -> Administrative Templates -> Microsoft Outlook 2010 -> Account Settings -> Exchange. There also a Cached Exhange Mode subfolder there.

However, in the vein of your comment, while that policy disables Cached mode in new profiles, it probably doesn't prohibit me from configuring Cached mode on a laptop. I haven't tried that though. I do know that if you already have cached mode enabled, and disable with this GPO, it won't actually disable it on an existing profile - you still have to go manually disable it and delete the OST. It's rather a pain actually.

Being that as it may, I still have plenty of other issues with Persona. Several applications that are industry specific seem to crash in the floating pool, but run fine in the persistent pool. On the other hand, a couple of Office plug-ins that don't work correcly in the persistent, DO work correctly in the floating pool - notably the Acrobat Reader Preview in Outlook.

I'm really starting to pull my hair out (and I don't really have any to spare). With a nearly identical hardware configuration (Windows 7, 2 GB RAM, 2 vCPU's), performance is generally much better on the persistent pool. Screen refreshes are better, applications run a little faster... Yes, because of their software requirements, they need 2 vCPU's. I've tried several times with just 1, and performance is just terrible. And I know it's their application requirements - at other clients with a more basic configuration, 1 vCPU is plenty. It just isn't good enough here.

Now we are talking about a fairly small deployment - the whole virtual infrastructure is about 50 machines, including servers and VDI. But it's very noticable when I make a change...

[cunejake]

I know this is an old post but we're in a very similar situation.  To get around the Outlook Cached Mode user setting problem, we enabled loopback processing in our computer GPO for the view desktops.  This allows user settings to get applied to a computer.  It's a bit slower to process the GPO that way but worth it to apply lots of user settings to the view computers.  This allows people to jump between physical and virtual machines nicely.

Regarding TrendMicro we also noticed slow boot times on the first bootup after a refresh.  We decided to let them be semi-persistent meaning we have a floating pool but we don't refresh the desktop after each session.  We simply refresh the pools after each update cycle.  This causes the machines to grow a little because some profile stuff is still saved the the VM but as along as we don't go too long inbetween updates they don't get too big.

We continue to have complaints about slow performance especially inside Outlook 2010.  We're still running Exchange 2003 and are working on upgrading to 2010 in hopes that will help.  Did you get the performance issues worked out?  If so I'd love to know what you did.

Jake

[blakebevard]

We had some similar issues to what you have encountered and here was the solution that we came up with:

1. Instead of installing AV on each individual VM, install it on your Persona server and set it up for on access scanning.  This reduces user performance hits because it is not running against your VMs and you can boost specs on your Persona server if necessary to account for the extra load on the system, but it was not crushing in our instance (~40 users at each site).

2. Use a mix of persona management and roaming profiles to reduce the amount of data that needs to be transferred at any one time.  We allow persona management to keep session data, settings and other general windows items, but allow roaming profiles to store Outlook ost files, thinapp data and user folders.  A description of how we did that is here: http://communities.vmware.com/message/2072819#2072819.  By doing this you don't slow the user's login time and since the data is available at SAN speed to your VDI host it should load at an imperceptible different from a normal desktop to the user.

We have had the same issues that you did as far as instant search goes and honestly there wasn't much we could come up with to resolve this.  The Windows instant search service insists on having the index file located locally on the hard drive of the machine in question and I could not get it to relocate in a way that would actually make it work.  I tried logon/logoff scripts where the file was copied on and off the local machine and stored in the user's persona location along with registry hacks and changes to have the location remapped on the fly, but none of them worked on any type of consistent basis.

Floating pools are definitely the way to go in terms of space usage and storage management because you aren't keeping multiple copies of the base image around.  It also makes updates and changes to the base image simple and fast eliminating the need for a patch and software management system.   Just my 2 cents, but if you have any questions let me know and I can make myself available to go into more detail for you.