I’m presenting this week at the Boston VMware User Group (VMUG) conference on ‘What You Didn’t Know That You Needed To Know Before Implementing VMware View’.  If you are in the Boston area I hope to see you there!

My session abstract is as follows:

Don’t be caught unprepared when you make the move to virtual desktops!  This session will provide attendees with an overview of how VMware View integrates with your existing infrastructure, Windows images, applications, and processes.  Building on Clearpath’s experience in implementing VMware View for customers of many sizes in a variety of industries, we will look at many of the issues that can cause a View pilot or production implementation to get off track.  Prerequisites and best practices for the pieces of your environment that touch View will be reviewed, including Active Directory, Distributed File System (DFS), Group Policies, Load Balancers, ThinApp packaging, and base image optimization.  Finally, we’ll discuss how to integrate the several facets of your IT group that will have to be involved in your View roll-out: application, desktop/helpdesk, network, storage, and infrastructure teams.

I thought I would give a preview of one of the points in my presentation around placing VMware View Persona Management user profiles on Microsoft DFS.

A DFS share is a great place to store your VMware View Personas.  It offers a highly available, replication, and a unified path for accessing files.  However, there are some considerations before you actually implement Persona on DFS.

1. Upgrade your DFS to 2008 Mode before putting Persona on it.  This requires your Active Directory Domain to be at 2008 Functional Mode.
   1. There is no in-place upgrade path from a 2000/2003 mode DFS namespace to a 2008 mode namespace.  Downtime is required to migrate the DFS, and large DFS namespaces (like ones that hold a ton of user generated garbage in a View Persona) will take longer to migrate.
   2. 2008 Mode offers Access Based Enumeration of shares.  If you don’t have permissions to a share (the CEO’s profile, for example), it isn’t visible to an unpriviledged user when browsing the share.  This can help protect confidentiality of user names.
   3. Remote Differential Compression optimized replication, copying only the changed bits of files rather than copying the entire file.  This helps with bandwidth consumption and continuity of a user profile should the DFS referral change.
   4. More Scalable for branch offices with new replication topologies (Hub & Spoke and Full Mesh)
   5. Improved monitoring vis DFSDIAG, DFS Management Console Health Checks and scripting.
2. Carefully plan your replication topology and intervals depending on your user’s mobility and availability requirements.  If your users move between branch offices with different DFS referral priorities, faster than your topology can replicate they may lose data.
3. Not directly DFS related, but upgrade to View 5.1.1 to prevent Persona data loss when persona is stored on a DFS path under certain situations.  See my post on the Clearpath blog for more: https://blog.clearpathsg.com/blog/bid/209020/VMware-View-5-1-1-Update-Released-Addresses-Persona-Management-Problem

The Issue – Temp files in profile not replicated

Finally, watch out for files with the TEMP attribute in users profiles.  DFS does not replicate files with the TEMP attribute by design, and this behavior cannot be changed: https://blogs.technet.com/b/askds/archive/2008/11/11/dfsr-does-not-replicate-temporary-files.aspx

The TEMP attribute here should not be confused with temp files (%profile%temp, IE Temp, etc.) – those are redirected to a disposable disk in a View environment.  I’m talking here about valuable user files that pick up the TEMP attribute.  There are several reasons a file might pick up the TEMP attribute.  For example, some versions of Symantec Endpoint Protection tag Outlook attachments with the TEMP attribute (https://www.symantec.com/connect/forums/sep-1104-outlook-auto-protect-sets-temporary-attribute-attachments-files-dont-replicate-dfsr).  A user who opens an attachment in Outlook, modifies it, then saves the file in their Persona managed profile will end up with a file with the TEMP attribute.  This file will not be replicated, and will disappear from the user’s point of view when their DFS referral changes to another target.  This can have implications for data backup as well – if the DFS node that didn’t receive the file via DFS-R is the backup target, that file will never be backed up.  Let’s hope that file is not the CEO’s business plan for the next 5 years….

See the image to the right for an example of the TEMP attribute on a file – in this case a customer’s expense report where the user could see the file in their profile, but the administrative assistant who was processing expense reports could not see it because she had a DFS referral to the target server that did not receive the T-tagged file via DFS replication.

Files received via IM or Word auto-save versions of documents that have not been manually saved may also pick up the temp attribute.

Admins should add a review of DFS-R logs to their regularly scheduled tasks to make sure user files are not being saved with a TEMP attribute.  This article on TechNet has the commands to find and recursively remove the TEMP attribute from files in your Persona repository: https://blogs.technet.com/b/askds/archive/2008/11/11/dfsr-does-not-replicate-temporary-files.aspx.