Disclaimer: All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
An interesting EFS case cropped up the other day, the problem description was this:
We have just installed a new W2k8 file server cluster and are moving users over to it. Now, whenever we attempt to encrypt files on it the user gets the error ‘0x80074005’ returned regardless of whether they do this from an XP or a Vista client.
However, this only happens for users with a Roaming Profile…users with a Local Profile can encrypt on the new file server without problems!
After some head-scratching, we determined the following was happening:
When an EFS-encryption operation is performed against a remote file server, the file server creates a mini-profile under %systemroot%\%userprofilepath%.
If the user has a RUP defined and doesn't already have a V2 (Vista/W2k compatible) profile a new V2 profile is also created in the same location as the existing profile (suffixed with a .v2 name).
As the operation is being done by a Windows 2008 OS it doesn’t matter if the client is an XP machine, the W2k8 system essentially logs the user on locally on the remote file server and it therefore needs to have a V2 profile for the user.
During this operation, the file server impersonates the user so the creation of the folder is done in the security context of the user.
In this case the permissions on the Roaming Profile share of the users did not allow them to create a top-level folder.
The same operation is performed when encrypting files on a W2k3 file server cluster but in that case the impersonation is done by the W2k3 OS which doesn’t create a new .v2 profile for the user (even if the user is logged on to a Vista client) so it isn’t affected by the inability to create top-level folders in the profile share.
The options for resolving this are 2:
a) Pre-create the .v2 profile folders in the profile share so that the W2k8 system will not have to create them in the users’ context when the EFS operation is attempted. This can either be done by creating a script that creates folders with a .v2 extension based on the existing profile names and assigns ownership to the correct user or disabling the check for Ownership of the profiles using a GPO setting and simply creating a new .v2 profile folder for all existing users.
b) Grant the users the permission to create top-level folders in the profile share so they can create the new .v2 profile folder. By default the creating user and System will have be the only security principals with permissions to access those folders (Full Control for both) but the policy ‘Add the Administrators security group to roaming user profiles’ can be set on the file server to also grant the built-in Administrators group permissions on it so the admins can administer it (if required).
Managing Roaming User Data Deployment Guide
Enable a remote server for file encryption