Hello,First of all, I apologise if I have misplaced the topic since I am not sure where to put it..Now the problem - on our Windows Server 2003 R2 fileserver we have an encrypted folder for the executives containing hundreds to thousands documments. We need to move the encrypted folder to another server with minimum administrative effort as possible (manually moving files and then adding user certificates toeach individualfile manually is the last option..). Is there some tool to do this for us, or is it possible to use a script?So far I have tried adding user certificates using cipher.exe /ADDUSER /CERTFILE:<UNC path to .cer> <UNC path to files to encrypt> from my Vista machine, however the encrypted files are inaccessible to the users.Thanks,Michal Novk

this is some kind of a guidance for client computers which is applicable also for file servers:http://technet.microsoft.com/en-us/library/cc722147(WS.10).aspxthe problem are basically the user certificates which would require running cipher and scanstate (or other transfer method).you could try to move all the EFS user profiles (they are just normal profiles on the FS)from one FS to another by using the scanstate/loadstate between the FSs. (scanstate/loadstate can be used even without having the particalar user logged on).You could as well use Credentails Roaming feature, but this does not work for the certs on EFS file server over network. You would have to make all the users to log on interactively (local/ts) to the original FS, then to the new FS.I would prefer trying the scanstate.o.

Thanks for reply.I have not described the problem enough - so far our XPusers have had an EFS folder on Server1, where they have their EFS certificates and keys. Now, the EFS folder is going to be moved to Server2 and the users are going to have Vista and new EFS certificates and keys. So far I have enabled the server "Trusted for delegation" but I can't get the user profile of my test user created on the server, when I try encrypt or decrypt something using this user profile..To use the scanstate/loadstate method does USMT3 have to be installed on the serevr or is it possible to run it remotely from Vista? If I undestand correctly I have to >1. scanstate from server12. loadstate to server23. robocopy EFS folder from Server1 to Server2...is it correct?

a) what delegation did you use for the new server? "... to any service (kerberos only)" or the contrained delegation? The constrained delegation does not work for 2008 servers (or I was not able to make it work :-))b) you need to restart the FS after this settingc) you need to log off the users from their workstations before tryingd) you need the users to access the FS by using its name (isn't it a cluster?), not an IP address, not an A alias (CNAME is ok)e) if you have an already encrypted file on the Server2 (which is encrypted with a key present only on the original Server1), the user will NOT enroll for a new key for that file. f) check the EFS template you are using, because it may be marked with the setting "do not enroll for new if there is a valid certificate in AD" - because the EFS certs are by default published.g) on the Server2 you should better disable self-signing.---scanstate/loadstate can be started without installation from a network share of the remote installed folderexcept for this, your procedure is correct as what I would say.ondrej.

Okay, I have solved it.The problem was, that we are in the middle of the migration process to Windows Vista and therefore our users, who already have Vista have two roaming profiles - <username> for XP and <username.V2> for Vista. The EFS certificates were however issued to Vista and they are part of the <username.V2> profile. When EFS is enabled on the server which is trusted for delegation and a user accesses the EFS share, a local copy of his roaming profile from AD is created BUT it is the profile <username> from XP and there are no valid EFS certificates and therefore the user is unable to access the encrypted files from Windows Vista..Thekind of workaroundI have found is to backup and delete the <username> profile, create a copy of the <username.V2> profile and rename it to <username>. After this procedure, correct profile is being created on the EFS server and user can access his cryptoed files.It's not very systematic, so if anyone knows something more polished, I'll be glad to hear it :-)The whole migration process works for me like this:1. Starting point is a working server with EFS share (let's say EFS$), all users with valid EFS certificates can access, that we want to migrate (Server1)2. Set the newserver where EFS share should be migrated to (Server2) as Trusted for delegation3. On Server2 create a share (again EFS$) set the NTFS and share permissions and encrypt it 4. copy the encrypted data using robocopy \\Server1\EFS$ \\Server2\EFS$ /efsraw /copyall5. ensure, that when a user connects to share \\Server2\EFS$ and tries to open an encrypted file a copy of his roaming profile is created on the server and he can access the files.6. if needed, export user EFS certificates and addthem to encrypted files using cipher /ADDUSER /CERTFILE <path to exported certificate>.cer <path to file/s>Michal Novak

ok. the important point in you case which I didn't know was that you have theroaming profiles. in that case, you certainly do not need the scanstate/loadstate, because the private keys are roamed automatically throught the profiles.have a nice day.ondrej.

Hi,Thanks anyway for you guidance. By the way do you know if there is something I can do about the mess with ".V2" profiles.. "somehow" make the server to copy it instead of the old <username> profile?Thanks.Michal