EFSAssistant Work Item Rss Feed

Commented Issue: EFSAssistant package does not install on Windows 7 [10732]

gillesh — Thu, 23 Sep 2010 11:41:35 GMT

The EFS Assistant package does not install on Windows 7. Also unclear if the ADM templates will work for Windows 7 .
Comments: ** Comment from web user: gillesh **

Hi All,

Is it plan to develop an EFS Assisant for Windows SEven Entreprise ?

Ths in advance

Created Issue: EFSAssistant package does not install on Windows 7 [10732]

brysow — Tue, 06 Oct 2009 15:49:15 GMT

The EFS Assistant package does not install on Windows 7. Also unclear if the ADM templates will work for Windows 7 .

Commented Issue: Encryption does not happen

venkat27 — Fri, 14 Aug 2009 17:53:00 GMT

I configured the group policy for EFSAssistant and deployed the package. Everything seems to work fine. I could see the configured folders from the EFS Results file marked for Encryption. But the folders/files are not encrypted.

Can someone let me know how to fix this? Thanks

I could not find the debug logs even though i configured.

Thanks
Venkat
Comments: ** Comment from web user: venkat27 **

the files and folders configured are classified as green and default/group policy. The folders are named test, test1 located in the Desktop folder and C:\TestEFS in the root.

Created Issue: Encryption does not happen

venkat27 — Fri, 14 Aug 2009 17:22:08 GMT

Created Issue: Wipe plaintext copy of newly encrypted file

brysow — Thu, 23 Jul 2009 14:43:45 GMT

Currently EFS itself will delete the plaintext temporary copy once the datastream is completely encrypted. However , it can still be possible to recover the original plaintext file in deallocated space using a number of utilities. It would be an enhancement to me to wipe the plaintext copy if EFSAsst encrypts a formerly unencrypted file. Regular use of cipher /w or sdelete or a number of other utilities can also provide the same capabilities but it might be good feature wise to make the call after encrypting a file assuming CPU utilization isnt greatly impacted or if it doesnt impact the completion timeline by 1000%, which is an important determining factor. Updating EFSAsst to add a policy setting for this feature might be easier than updating EFS itself.

Created Issue: After upgrade to Windows 7 from Vista, unable to uninstall Microsoft EFS Assistant

r2c1 — Fri, 26 Jun 2009 01:51:05 GMT

Uninstalling "Microsoft EFS Assistant" after upgrade to Windows 7 will result in
"Microsoft EFS Assistant can only be installed on Windows XP SP2 or Windows Vista."

Found workaround is to remove it manually.

1) Search under HKLM for "efs assistant" for a key under "CurrentVersion\Uninstall"-- path will be different depending if system is x86 or amd64. e.g. key:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{93C545C0-0E66-4813-BFF1-55B464580909}
2) "InstallSource" value might point to non-existant directory (with non-existant source MSI package). If so copy "UninstallString" value and modify it to also log and then run it, e.g.:
msiexec /uninstall {93C545C0-0E66-4813-BFF1-55B464580909} /lv* "%userprofile%\desktop\msi.log"
3) Open the log at "%userprofile%\desktop\msi.log" and look for line like:
MSI (s) (00:30) [17:10:30:297]: Original package ==> C:\Windows\Installer\203f6baa.msi
4) Open an elevated CMD prompt to clean-up:
IF application is running> kill EFSAssistant.exe
IF 64-bit Windows> rmdir /s /q "C:\Program Files (x86)\Microsoft EFS Assistant"
ELSE IF 32-bit Windows> rmdir /s /q "C:\Program Files\Microsoft EFS Assistant"
Delete the installer, e.g.> del C:\Windows\Installer\203f6baa.msi
Delete the Add/Remove Programs entry, e.g.> reg delete HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{93C545C0-0E66-4813-BFF1-55B464580909} /va

Created Issue: MSI Installer Error: Event 11708 with Windows Restricted Users

tekkid — Thu, 05 Feb 2009 14:40:48 GMT

I am reporting a bug with the EFS Assistant application when being run under a user that does not have appropriate access to the c:\windows temp directory. Each time EFS Assistant is run, it will produce event 11708 errors in the event log. Microsoft says that a major code change will be needed in either MSIINSTALLER or EFS ASSISTANT. FYI...

Subject: RE: Microsoft Support Incident: SRZ081124000449 - SA/Win2k3/Sec/Event ID 11708

Thank you for your patience. I am writing in to update you regarding the 11708 event issue you opened.

We have researched and tested with in local reproduced environment. We were not able to find an effective way to stop the events being generated as this may involve big code changing either to MsiInstaller or EFS Assistant the application. We do think instead of granting the permission to normal users, we would rather suggest ignoring the events. Here are the findings we would like to share with you:

Further Information
=================
1. We did a thorough check of MSI log and WMI logs. Based on our analysis, the actions recorded in MSI log in our case were all triggered by the following WMI query(from wbemcore.log):

Query Engine request: querying dyn provider with <select InstallLocation from Win32_Product>
Query Engine actual: querying dyn provider with <select __RELPATH, InstallLocation from Win32_Product>

2. We wrote a simple .vbs script with similar WMI script as above to do a software query. There are no real install/uninstall actions either like in our case. We ran it on our local repro machine as well as another machine with clean installed Windows XP SP3 (No EFS Assistant Tool Installed). As a result, we saw similar behavior in WMI log and MSI log.

The test above further confirms that query into WMI namespace MSI provider-> Win32_Product Class will trigger a check in the installation database, including the installation packages.

3. Then we did more researches in our internal database and found the explanation of this behavior:

Queries into Win32_Product loads msiprov.dll (the msi provider for wmi) and then msi.dll. It performs the actual task to query the MSI database on the machine for all the installed packages.

The process above also triggers a consistency check on packages installed, verifying and repairing the installation. When the MSI package has MST file in c:\windows\temp, if we run it under a normal user account, we might get the 11708 event message, as normal user normally doesn't have read permissions on temp folder.

Summary
=========
The behavior is by designed. There is no way to get around it except:

1. Change the behavior of MsiInstaller to not let it check the whole installation database based on the WMI query.
2. Change the behavior of EFS Assistant to not make the WMI query.

Either of the way will involve big code changes and probably lose the original purpose of doing the consistency check. So based on our analysis, since there is no real installation actions failed and no obvious business impact, I think we can safely ignore the events. (they are not even error/warning events)

Please let me know what do you think and let me know if you have any questions. Again, thank you for your time and patience.

COMMENTED ISSUE: XP Tablet PC Edition and Media Center Edition 2005

DaveMo — Tue, 04 Mar 2008 00:40:33 GMT

EFS Assistant seems to crash on Tablet PC Edition 2005. Has Microsoft tested it with SKUs other than XP Professional? Most laptops especially have these operating systems. The error msg is attached as a JPEG file.
Comments: ** Comment from web user: DaveMo **

Hello,

Although it was not officially tested on Tablet, I believe that the PM for the project was running Tablet and ran the software on that OS for the duration without any issue. Do you have the ability to run the EFSA on the tablet with Visual Studio installed so we can find out where the issue might be?

Dave

CREATED ISSUE: XP Tablet PC Edition and Media Center Edition 2005

tuxplorer — Sat, 01 Dec 2007 09:24:01 GMT

CREATED ISSUE: Leftover bugbug - additional exceptions in "if (_subStatus == EncryptionSubStatus.None)"

MikeSL — Wed, 15 Aug 2007 18:27:23 GMT

From Encryption.cs > EncryptFile()

if (_subStatus == EncryptionSubStatus.None)
{
try
{
//
// Preserve the original time stamp on the file
//
DateTime _lastWriteTimeUtc = File.GetLastWriteTimeUtc(fileName);
File.Encrypt(fileName);
File.SetLastWriteTimeUtc(fileName, _lastWriteTimeUtc);
_status = EncryptionStatus.Encrypted;
_subStatus = EncryptionSubStatus.NewlyEncrypted;

}
catch (Exception e)
{
Log.EFSAsstTrace("FailedToEncryptFile", fileName, e.Message);
// bugbug - there may be other reasons for a failure...
_subStatus = EncryptionSubStatus.AccessDenied;

CREATED ISSUE: .NET 1.1 compilation bug - FolderPathsToEncrypt() cannot use ExpandEnvironmentVariables()

MikeSL — Sat, 11 Aug 2007 15:55:43 GMT

From UtilityClass.FolderPathsToEncrypt source code:

// 1.1 bugbug - If this code is compiled in .NET 1.1 this will
// not work. EEV returns short path names and DirectoryInfo.FullName
// does not expand them in 1.1.
//
_path = Environment.ExpandEnvironmentVariables(_path);
_dirInfo = new DirectoryInfo(_path);
_path = _dirInfo.FullName;

COMMENTED ISSUE: CA2205 : UseManagedEquivalentsOfWin32Api in Win32API.cs - SHGetFolderPath()

MikeSL — Sun, 29 Jul 2007 23:44:57 GMT

Comments: ** Comment from web user: MikeSL **

Dave (and others), this bug is called straight out of FxCop.

Any non-standard implementations in a shared-source project are one heckuva lot easier to support, and preserve as an exception, with documentation or comments to clarify what issues such a non-standard implementation are meant to workaround.

If anyone knows what issues this would resurrect, their input would be MOST appreciated.

COMMENTED ISSUE: CA2205 : UseManagedEquivalentsOfWin32Api in Win32API.cs - SHGetFolderPath()

DaveMo — Sat, 28 Jul 2007 15:55:10 GMT

Comments: ** Comment from web user: DaveMo **

For any functionality where we had to use the unmanaged equivalent, it was because the managed version didn't function correctly. I don't know what the point of this issue is since if we revert to the managed equivalent something would stop working correctly.

COMMENTED FEATURE: Add FileSystem Watcher to encrypt new files

DaveMo — Sat, 28 Jul 2007 15:50:55 GMT

This is a feature I'm loath to try to implement, as I'm afraid of the potential downside in inserting something at the filesystem layer that will intercept all Writes. The Antivirus vendors had a helluva time trying to perform such things in Windows, such that they were disproportionately the cause of shell and/or OS instability and crashes. [I believe in the latest version(s) of Windows, they've implemented a shared function that removes the kernel hooks needed by each ISV, but it still gives me the willies.]

IF we were to try to implement such a feature, here's an incomplete list of requirements and processing workflow steps I believe we'd need to follow:

_BAD_
* it would have to ignore all files created or modified by any other user except the Current User
* it would have to wait to encrypt until after the file was closed, since all attempts to encrypt a file would require exclusive access
* unfortunately, it would have to run at all times, and (because I wouldn't want to rely on its stability) it would have to process encryption requests immediately - I wouldn't want to rely on a work item queue of files to be encrypted
* it would have to perform some very heavy-duty processing to determine whether the file should be encrypted or not (either based on some inference of folder path, or based on a hashtable of filetype - let alone the metadata or file contents proposals that are scary in their own right)
* it would have to have some heuristics to ensure it didn't spend inordinate cycles chasing ephemeral files (i.e. those temporary files that are created and then very rapidly deleted)
* it wouldn't really provide any value in preventing the creation of plaintext shreds on disk, since (unlike the EFS driver itself) it wouldn't create new files natively encrypted (cf. files created under an encrypted folder), but rather would only encrypt a copy of the plaintext file, and still leave behind the plaintext on disk on sectors allocated to the deleted plaintext file.

_GOOD_
* it could ignore all Read & Delete requests, focusing only on intercepting Write calls
* it should skip all files that were created in encrypted folders (i.e. those files that will be encrypted regardless)
* it *could* help with those files that are Moved not Copied, so that longstanding design flaw of NTFS could be beaten
Comments: ** Comment from web user: DaveMo **

It's not completely clear whether you are requesting a user-mode or kernel-mode solution. Since you describe FileSystemWatcher in your title, I think you are asking for a user mode solution. But a user mode solution (which I think is a reasonable first solution to the underlying issue) doesn't suffer most of the negative issues that you describe. The user-mode solution does not have any "kernel hooks" nor would there be any real chance of instability as you describe. I would not recommend a kernel-mode solution to solve the problem because of the stability risks and difficulty of implementation.

Using FileSystemWatcher, this is a relatively easy feature to add to EFSAssistant and one that I pushed for during development but was overruled due to the perceived risk of having a thread hanging around waiting for a file system event. IMHO, this kind of feature is low impact to the system and low risk.

I don't really understand your paragraph that starts with "heavy-duty processing". The straight-forward implementation is to run through the standard classification code since the rules for files that are just created should be the same as the rules for files that already exist. The current code takes way less then a second to process so I don't think there's any hidden issue we would need to address.

This is really only about 10 lines of code to implement but testing would take some cycles.

COMMENTED ISSUE: Document system folder exception in Quick Start Section

MikeSL — Mon, 23 Jul 2007 21:40:02 GMT

Because the tool will not scan into system folders, the tool will never include some default red folders on Vista machines in the WMI data. For example, the start menu folder will never show up in the WMI data because a folder above it is a system folder.

It is suggested that the documentation be updated to explicitly state that this will be the case. This will help evaluators who have not read the indepth discussion of how the tool works understand why these folders aren't appearing in the Results Viewer.
Comments: ** Comment from web user: MikeSL **

It looks like this was never included in the Microsoft release of the Data Encryption Toolkit. Our next-best option is to add this to the project's Wiki somewhere.

CREATED FEATURE: Add FileSystem Watcher to encrypt new files

MikeSL — Sat, 21 Jul 2007 00:20:39 GMT

This is a feature I'm loath to try to implement, as I'm afraid of the potential downside in inserting something at the filesystem layer that will intercept all Writes. The Antivirus vendors had a helluva time trying to perform such things in Windows, such that they were disproportionately the cause of shell and/or OS instability and crashes. [I believe in the latest version(s) of Windows, they've implemented a shared function that removes the kernel hooks needed by each ISV, but it still gives me the willies.]

IF we were to try to implement such a feature, here's an incomplete list of requirements and processing workflow steps I believe we'd need to follow:

*BAD*
* it would have to ignore all files created or modified by any other user except the Current User
* it would have to wait to encrypt until after the file was closed, since all attempts to encrypt a file would require exclusive access
* unfortunately, it would have to run at all times, and (because I wouldn't want to rely on its stability) it would have to process encryption requests immediately - I wouldn't want to rely on a work item queue of files to be encrypted
* it would have to perform some very heavy-duty processing to determine whether the file should be encrypted or not (either based on some inference of folder path, or based on a hashtable of filetype - let alone the metadata or file contents proposals that are scary in their own right)
* it would have to have some heuristics to ensure it didn't spend inordinate cycles chasing ephemeral files (i.e. those temporary files that are created and then very rapidly deleted)
* it wouldn't really provide any value in preventing the creation of plaintext shreds on disk, since (unlike the EFS driver itself) it wouldn't create new files natively encrypted (cf. files created under an encrypted folder), but rather would only encrypt a copy of the plaintext file, and still leave behind the plaintext on disk on sectors allocated to the deleted plaintext file.

*GOOD*
* it could ignore all Read & Delete requests, focusing only on intercepting Write calls
* it should skip all files that were created in encrypted folders (i.e. those files that will be encrypted regardless)
* it *could* help with those files that are Moved not Copied, so that longstanding design flaw of NTFS could be beaten

CREATED FEATURE: Re-enable support for Roaming User Profiles

MikeSL — Thu, 28 Jun 2007 00:17:55 GMT

Encryption of *any* folders in a case where the user's User Profile is a Roaming User Profile should still be valid. The known issue is that encrypting folders that Roam will cause Windows XP to fail in multiple ways during logoff. [This issue was resolved in Windows Vista.]

However, sometime during development of EFS Assistant, the application was changed so that it would exit if it detected the user's profile was a RUP:

"We don't support roaming user profiles since EFS encryption generally doesn't work in that scenario."

This was noted as addressing PS Bug #8194, but no record of what that bug was is available, and it's entirely possible that was an edge case for a single user.

Plan:
- remove the code that exits if the application detects a RUP
- add code that enumerates the currently-configured Roaming Folders
- add code that detects RUP, and performs the following conditional action:
- - if (OS = XP) and (Profile = RUP), then add current Roaming Folders to Red list

COMMENTED ISSUE: CA2000 : DisposeObjectsBeforeLosingScope in Log.cs - TextWriterTraceListener

MikeSL — Wed, 27 Jun 2007 23:52:11 GMT

Comments: ** Comment from web user: MikeSL **

There appears to be no Log.RemoveTraceListener() method available, so that the TraceListener will *NEVER* be disposed. While I don't know whether there is a specific instability case here, this is certainly a significant opportunity for resources to be poorly managed.

At minimum, a RemoveTraceListener() method should be added to the EFSAssistant.Log class, and this method should be called at the equivalent step to whatever this project has to a Form_Unload() event.

CREATED ISSUE: CA2205 : UseManagedEquivalentsOfWin32Api in Win32API.cs - SHGetFolderPath()

MikeSL — Mon, 25 Jun 2007 18:43:34 GMT

Comments:

Description: CA2205 : Microsoft.Usage : Remove the declaration for 'NativeMethods.SHGetFolderPath(IntPtr, Int32, IntPtr, Int32, StringBuilder):Int32'. Callers should use the following managed alternative: System.Environment.GetFolderPath
File: C:\Documents and Settings\msmithlo\My Documents\personal\VS2005 Projects\EFSAssistant\EFSAssistant\Win32API.cs
Line: 23
Project: EFSAssistant

CREATED ISSUE: CA2200 : RethrowToPreserveStackDetails in Log.cs - AddTraceListener() one more time

MikeSL — Mon, 25 Jun 2007 18:38:59 GMT

Comments:

Description: CA2200 : Microsoft.Usage : Log.AddTraceListener():Void rethrows a caught exception and specifies it explicitly as an argument. Use 'throw' without an argument instead, in order to preserve the stack location where the exception was initially raised.
File: C:\Documents and Settings\msmithlo\My Documents\personal\VS2005 Projects\EFSAssistant\EFSAssistant\Log.cs
Line: 134
Project: EFSAssistant