> 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/thelaz...alization.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!
Linear Mode
