I have setup a VPN connection on my Windows 7 Pro computer and can connect to it over VPN from another Windows 7 computer. I've setup a share on the VPN host and can access all of the shared files and folders from the remote computer. I can't however share encrypted files between the 2 as per http://windows.microsoft.com/en-US/windows-vista/Share-encrypted-files . I have followed this document to the letter but still can't share the files, open the files or copy the files between the 2 computers.

Hi, Before moving on, I would like to know the network environment of these two computer. If one of them is in a domain? If so, please check the policy on domain controller site first. Meanwhile, please be sure export and import the certification successfully.Kim Zhou TechNet Community Support

Neither is on a domain, they are both in separate workgroups. The certificates are imported and exported properly according to the document in my original post.

Hi, Have you encountered any error message during opening the encrypted file? In addition, stop and re-start Credential Manager service and EFS in Services.msc.Kim Zhou TechNet Community Support

I get 'Access is Denied'. I can however delete the file.

I know this is an old thread, but in case you are still trying to make this work, I thought I'd share my experience. I, too, had problems sharing encrypted files on XP. I've since upgrades all of my home systems to Win 7 Pro (and used the same cert for encryption that I used in XP) and it works flawlessly. Since it worked for you in Win2k, I'd say it was a bug introduced in XP that caused the problems. Cheers... - dennis

This IS on Windows 7, nothing to do with W2K.

Hi, Users can remotely encrypt or decrypt files, but this capability is not enabled by default. The following are requirements for successful remote EFS operations in a file share environment. -- The user must have Write or Modify permissions to encrypt or decrypt a file. -- The user must have either a local profile on the server where EFS operations will occur or a roaming profile. -- The remote server should be configured with "Trusted for delegation" so that it can impersonate the user to obtain access to the necessary public or private key from profile. More information. Using Encrypting File System: http://technet.microsoft.com/en-us/library/bb457116.aspx#EHAA Best regards, Jason Mei Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi, Any updates? please drop me a note. Best regards, Jason Mei Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Apologies; I misread the context. I've now run back into the same problem you are describing. It would seem, after further research, that: EFS encryption/decryption on file shares is supported only in domain cases; requires additional configuration to enable this as noted by Jason's post on May 7thEFS uses changing keys that are stored on the local computer in non-domain cases. Keys are changed on an elapsed-time basis. Because of #2, the keys can (and apparently do) fall out of sync on 2 non-domain computers. It is apparent that restoring the EFS key from a backup somehow recovers previous keys (otherwise, it would never be able to read older, encrypted files). In the network case, though, it seems to me that once the keys change, the ability of Computer A to encrypt/decrypt shared files on Computer B is lost to standard Win32 APIs. This is also likely the reason why SyncToy 2.1 claims to support encrypted files across the network only when the encrypted files are local, and the remote computer stores the files unencrypted (in that case, a flag in CopyFileEx takes care of making the decrypted copy). RoboCopy is able to manage this by using OpenEncryptedFile, ReadEncryptedFile and WriteEncryptedFile. I haven't gotten around to testing if those would work across the network in non-Domain cases (requires backup or admin privileges on the target server). Update 5/21/12: Just completed coding and testing these APIs. In my environment, the xxxxEncryptedFileRaw APIs work just fine across the network in the non-domain case when I have Admin credentials on the networked computers. All with Win 7 x64. Happy to share the C-code that does this if anyone would find that useful.

Apologies; I misread the context. I've now run back into the same problem you are describing. It would seem, after further research, that: EFS encryption/decryption on file shares is supported only in domain cases; requires additional configuration to enable this as noted by Jason's post on May 7thEFS uses changing keys that are stored on the local computer in non-domain cases. Keys are changed on an elapsed-time basis. Because of #2, the keys can (and apparently do) fall out of sync on 2 non-domain computers. It is apparent that restoring the EFS key from a backup somehow recovers previous keys (otherwise, it would never be able to read older, encrypted files). In the network case, though, it seems to me that once the keys change, the ability of Computer A to encrypt/decrypt shared files on Computer B is lost to standard Win32 APIs. This is also likely the reason why SyncToy 2.1 claims to support encrypted files across the network only when the encrypted files are local, and the remote computer stores the files unencrypted (in that case, a flag in CopyFileEx takes care of making the decrypted copy). RoboCopy is able to manage this by using OpenEncryptedFile, ReadEncryptedFile and WriteEncryptedFile. I haven't gotten around to testing if those would work across the network in non-Domain cases (requires backup or admin privileges on the target server). Update 5/12/12: Just completed coding and testing these APIs. In my environment, the xxxxEncryptedFileRaw APIs work just fine across the network in the non-domain case when I have Admin credentials on the networked computers. All with Win 7 x64.

Apologies; I misread the context. I've now run back into the same problem you are describing. It would seem, after further research, that: EFS encryption/decryption on file shares is supported only in domain cases; requires additional configuration to enable this as noted by Jason's post on May 7thEFS uses changing keys that are stored on the local computer in non-domain cases. Keys are changed on an elapsed-time basis. Because of #2, the keys can (and apparently do) fall out of sync on 2 non-domain computers. It is apparent that restoring the EFS key from a backup somehow recovers previous keys (otherwise, it would never be able to read older, encrypted files). In the network case, though, it seems to me that once the keys change, the ability of Computer A to encrypt/decrypt shared files on Computer B is lost to standard Win32 APIs. This is also likely the reason why SyncToy 2.1 claims to support encrypted files across the network only when the encrypted files are local, and the remote computer stores the files unencrypted (in that case, a flag in CopyFileEx takes care of making the decrypted copy). RoboCopy is able to manage this by using OpenEncryptedFile, ReadEncryptedFile and WriteEncryptedFile. I haven't gotten around to testing if those would work across the network in non-Domain cases (requires backup or admin privileges on the target server).