no file system virtualization

[John Myers]

It seems my Vista Ultimate system does not perform any file system
virtualization, ever, despite the fact that I do have the corresponding group
policy setting enabled. When I try tests like the one suggested at
http://thelazyadmin.com/blogs/thelazyadmin/archive/2007/04/26/file-system-virtualization.aspx
I always get "Access denied" errors, no matter whether or not the
application (say, cmd.exe) is set as virtualized or not, and no matter what
system area I am trying to create a file in. If I try to write a file in
C:\Windows, C:\Windows\system32, C:\Program Files, I always get access denied
errors. However, there are no error messages in any of my event logs, either.
The system just acts as if I had file virtualization disabled, but I
haven't...

I wonder if anybody can shed some more light on this for me. My system has a
non-standard setup, which may or may not be related to this issue. Here is
some more information:

- For my system, C:\ProgramData and C:\Users are actually junctions (reparse
points) that target D:\ProgramData and D:\Users, which is where the files
reside physically.
- Likewise, C:\Program Files is a reparse point targeting E:\, so all of my
program files reside in the E: partition.
- I have Admin approval mode disabled for the built-in administrator, and
the built-in Administrator is the only account with adminsitrative privileges.

Thanks for any help!

 

[Jesper]

I wouldn't be at all surprised if the modifications you have made to the file
system layout broke virtualization. Many applications have broken over the
years because they did not traverse reparse points. Did you manually move the
files to the other drives?

What do you mean when you say that you have "admin approval mode disabled"
for the built-in Administrator account? The built-in Administrator account is
exempt from UAC restrictions, and is disabled, and should not be used. What
did you do with the other administrative account?

To troubleshoot this the actual UAC settings are needed. What values are set
in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System?

 

[John Myers]

I wouldn't be at all surprised if the modifications you have made to the
file

system layout broke virtualization. Many applications have broken over the
years because they did not traverse reparse points.

Since reparse points reside at the filesystem level, this is only possible
if the application is specifically coded to detect them, and handle them in a
special manner. A standard, reparse-point-agnostic application will never be
able to see the difference. Do you have examples of applications that have
trouble with reparse points?

I know that Vista's indexer does not cross reparse points, but that is
because it is coded to do that, for reasons of efficiency.

Did you manually move the files to the other drives?

No, that is not easily possible, not without a lot of non-trivial
script-juggling and ACL wizardry anyway. As you know there are some intricate
reparse point structures in some of these folders...

What I did instead is use a disk image of the original C:\ partition, in
order to make sure all of the filesystem and ACL structures are correct.

What do you mean when you say that you have "admin approval mode disabled"
for the built-in Administrator account? The built-in Administrator account is
exempt from UAC restrictions, and is disabled, and should not be used.

Actually, the built-in Administrator account is exempt from UAC restrictions
only because it has Admin approval mode disabled by default. You can enable
approval mode if you wish, by setting the corresponding Group Policy option.
Once that is done there is really no reason not to use the built-in Admin
account.

What did you do with the other administrative account?

There is no other one; all the other accounts are Standard Users.

To troubleshoot this the actual UAC settings are needed. What values are set
in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System?

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ConsentPromptBehaviorAdmin"=dword:00000002
"ConsentPromptBehaviorUser"=dword:00000001
"EnableInstallerDetection"=dword:00000001
"EnableLUA"=dword:00000001
"EnableSecureUIAPaths"=dword:00000001
"EnableVirtualization"=dword:00000001
"PromptOnSecureDesktop"=dword:00000001
"ValidateAdminCodeSignatures"=dword:00000000
"dontdisplaylastusername"=dword:00000000
"legalnoticecaption"=""
"legalnoticetext"=""
"scforceoption"=dword:00000000
"shutdownwithoutlogon"=dword:00000001
"undockwithoutlogon"=dword:00000001
"FilterAdministratorToken"=dword:00000000

Thanks very much for your input!

 

[Jesper]

Since reparse points reside at the filesystem level, this is only possible

if the application is specifically coded to detect them, and handle them in a
special manner. A standard, reparse-point-agnostic application will never be
able to see the difference. Do you have examples of applications that have
trouble with reparse points?

File replication. I once broke an entire domain by putting sysvol beneath a
reparse point. The replication services failed to traverse the reparse point.
The really interesting thing was that much of AD was apparently written not
to traverse reparse points either because you couldn't even demote the system
to a non-DC to fix the problem.

What I did instead is use a disk image of the original C:\ partition, in
order to make sure all of the filesystem and ACL structures are correct.

You went to a lot of trouble, didn't you?

Actually, the built-in Administrator account is exempt from UAC restrictions
only because it has Admin approval mode disabled by default. You can enable
approval mode if you wish, by setting the corresponding Group Policy option.
Once that is done there is really no reason not to use the built-in Admin
account.

Well, there are still reasons not to use that account, like the fact that
(a) it is disabled by default, (b) using it breaks all chances of auditing
who did what, (c) it is hidden from logon by default. Still, it is a
functional account and if you want to use it, you may.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]

"ConsentPromptBehaviorAdmin"=dword:00000002
"ConsentPromptBehaviorUser"=dword:00000001
"EnableInstallerDetection"=dword:00000001
"EnableLUA"=dword:00000001
"EnableSecureUIAPaths"=dword:00000001
"EnableVirtualization"=dword:00000001
"PromptOnSecureDesktop"=dword:00000001
"ValidateAdminCodeSignatures"=dword:00000000
"dontdisplaylastusername"=dword:00000000
"legalnoticecaption"=""
"legalnoticetext"=""
"scforceoption"=dword:00000000
"shutdownwithoutlogon"=dword:00000001
"undockwithoutlogon"=dword:00000001
"FilterAdministratorToken"=dword:00000000

Nothing here really rings a bell. I have replicated all these settings, but
not your complicated file system structure, and the test at
http://thelazyadmin.com/blogs/thelazyadmin/archive/2007/04/26/file-system-virtualization.aspx
works just fine for me as a standard user and as RID 500. I really think the
reparse points have something do with it. I wouldn't be surprised at all if
the virtualization bits do not traverse reparse points. The virtualization
location is now beyond a reparse point so that would explain it.

 

[John Myers]

File replication. I once broke an entire domain by putting sysvol beneath a

reparse point. The replication services failed to traverse the reparse point.
The really interesting thing was that much of AD was apparently written not
to traverse reparse points either because you couldn't even demote the system
to a non-DC to fix the problem.

Ah, yes, that is something to beware of. Worse, I know that there are file
synchronization packages out there (SureSync comes to mind) that are touted
as being "Vista compliant", yet are unaware of reparse points. Now imagine
you are doing a two-way synchronization where some folders on the source have
multiple references to them because of the existence of reparse points. On
the first synch, the software will simply copy the files twice. No damage
done yet, but you have duplicated files and folders now. Next, some user(s)
edit some of the duplicated files, this way, unaware, creating distinct
versions of what before was just one file. Now try to synch back: Hard to
tell what exactly will happen, but it ain't gonna be pretty...

You went to a lot of trouble, didn't you?

Oh yes, you can say that. The advantage is that system restores become more
straightforward, and there is very little fragmentation on my system volume,
and in C:\Program Files which hardly ever get written to, other than for
software installations. I should say that this is for a scenario where a
fixed set of software packages are installed once, and then the system is
essentailly left alone (except for security updates and bug fixes) for months
at a time.

Well, there are still reasons not to use that account, like the fact that
(a) it is disabled by default, (b) using it breaks all chances of auditing
who did what, (c) it is hidden from logon by default. Still, it is a
functional account and if you want to use it, you may.

Valid points, each of them. However, in my specific scenario, I am the only
one who ever gets to log in as the Admin, so point b) does not apply. I fully
agree that in a different setting, using the built-in account may not be a
good idea.

Nothing here really rings a bell. I have replicated all these settings, but
not your complicated file system structure, and the test at
http://thelazyadmin.com/blogs/thelazyadmin/archive/2007/04/26/file-system-virtualization.aspx
works just fine for me as a standard user and as RID 500. I really think the
reparse points have something do with it. I wouldn't be surprised at all if
the virtualization bits do not traverse reparse points. The virtualization
location is now beyond a reparse point so that would explain it.

Yeah, I am almost certain that that is the issue. I would just like to know
if there is someone who knows for sure, or of there is some documentation
somewhere that specifically addresses the question. I have seen a statement
somewhere, saying that "file system virtualization is not enabled for reparse
points", but it is not entirely clear what that means. Since in my case,
virtualization also does not work if I try to create files in C:\Windows
(which is not behind a reparse point), I assume it means that the users'
VirtualStore cannot be behind a reparse point, but I am not sure; and I don't
want to spend the time trying to test my theory...

In any case, I can even see why disallowing virtualization involving reparse
points should not be allowed: There can be serious security problems
otherwise. For example, files created behind a reparse point will inherit the
security settings of their original folder, not the one of the reparse point,
which can lead to unpleasant surprises if one is not careful. As an aside, I
think this is something that should be addressed: Some warning from the UI
(Windows Explorer) may be appropriate if the ACLs of the reparse point and
the target don't match. Ideally there would even be an offer to synch the
ACLs so they are identical. Do you know where I should send that suggestion?

Thanks again!

 

[Jesper]

Yeah, I am almost certain that that is the issue. I would just like to know

if there is someone who knows for sure, or of there is some documentation
somewhere that specifically addresses the question.

I can't find any documentation from MS on it, but I did find one statement at
http://programming.reddit.com/info/12jzr/comments that sounds like what you
said. I think what that means is that you can't virtualize something
underneath a reparse point.

I have seen a statement
somewhere, saying that "file system virtualization is not enabled for reparse
points", but it is not entirely clear what that means. Since in my case,
virtualization also does not work if I try to create files in C:\Windows
(which is not behind a reparse point), I assume it means that the users'
VirtualStore cannot be behind a reparse point, but I am not sure; and I don't
want to spend the time trying to test my theory...

I bet that you just discovered a second issue here, in that the virtual
store can't be behind a reparse point. That's new, but since I am pretty sure
what Microsoft's answer is going to be if you ask them for support on a
system with the user profile behind a reparse point, I don't think they would
spend much time troubleshooting it either.

In any case, I can even see why disallowing virtualization involving reparse
points should not be allowed: There can be serious security problems
otherwise. For example, files created behind a reparse point will inherit the
security settings of their original folder, not the one of the reparse point,
which can lead to unpleasant surprises if one is not careful. As an aside, I
think this is something that should be addressed: Some warning from the UI
(Windows Explorer) may be appropriate if the ACLs of the reparse point and
the target don't match. Ideally there would even be an offer to synch the
ACLs so they are identical. Do you know where I should send that suggestion?

The right place to send it is the Windows Early Feedback program if you are
a beta tester and member of that. If you are not, you can write up a concise
description, complete with steps, and forward to me and I will submit it.
Another option is to post it in this newsgroup as a suggestion to Microsoft.
They do actually tend to read both of those.