locked
How to migrate an encrypted folder over network? RRS feed

  • Question

  • 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 to each individual file 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 Novák
    Tuesday, September 15, 2009 8:01 AM

Answers

  • 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).aspx

    the 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.
    • Marked as answer by Mervyn Zhang Thursday, September 17, 2009 10:51 AM
    Tuesday, September 15, 2009 11:36 AM
  • 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 setting
    c) you need to log off the users from their workstations before trying
    d) 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 folder
    except for this, your procedure is correct as what I would say.

    ondrej.


    • Marked as answer by Mervyn Zhang Thursday, September 17, 2009 10:51 AM
    Tuesday, September 15, 2009 1:13 PM
  • 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..

    The kind of workaround I 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 new server where EFS share should be migrated to (Server2) as Trusted for delegation
    3. 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 /copyall
    5. 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 add them to encrypted files using cipher /ADDUSER /CERTFILE <path to exported certificate>.cer <path to file/s>

    Michal Novak

    • Marked as answer by Mervyn Zhang Thursday, September 17, 2009 10:51 AM
    Thursday, September 17, 2009 9:01 AM

All replies

  • 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).aspx

    the 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.
    • Marked as answer by Mervyn Zhang Thursday, September 17, 2009 10:51 AM
    Tuesday, September 15, 2009 11:36 AM
  • Thanks for reply.

    I have not described the problem enough - so far our XP users 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 server1
    2. loadstate to server2
    3. robocopy EFS folder from Server1 to Server2
    ...

    is it correct?
    Tuesday, September 15, 2009 12:45 PM
  • 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 setting
    c) you need to log off the users from their workstations before trying
    d) 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 folder
    except for this, your procedure is correct as what I would say.

    ondrej.


    • Marked as answer by Mervyn Zhang Thursday, September 17, 2009 10:51 AM
    Tuesday, September 15, 2009 1:13 PM
  • 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..

    The kind of workaround I 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 new server where EFS share should be migrated to (Server2) as Trusted for delegation
    3. 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 /copyall
    5. 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 add them to encrypted files using cipher /ADDUSER /CERTFILE <path to exported certificate>.cer <path to file/s>

    Michal Novak

    • Marked as answer by Mervyn Zhang Thursday, September 17, 2009 10:51 AM
    Thursday, September 17, 2009 9:01 AM
  • ok. the important point in you case which I didn't know was that you have the roaming 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.

    Thursday, September 17, 2009 9:33 AM
  • 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

    Thursday, September 17, 2009 10:20 AM