 |
 |
This is only marginally related but I believe
that the roaming profile logic is (or at least was) flawed in some respects
that can have an enormous impact on data survivability. I once wanted to
move the profiles from one drive to a larger one and so I did a backup and
restore to the new location. The files all retained the old timestamps
but the top level folders attained a new timestamp for some reason.
I would have expected that the roaming
profile system checked the datestamp of the files themselves before determining
which are the most recent. Unfortunately it appears to only look at the
datestamp of the user’s top level folder and in this case proceeded to
destroy user data when they arrived the next day. We were able to stop
the process in good time but quite a few users lost a lot of data. We do
not use roaming profiles now.
From: Mark Szymczak
[mailto:[log in to unmask]]
Sent: Thursday, December 21, 2006
9:26 AM
To:
Subject: [MSUNAG] Roaming Profile
Issue
Not sure how many are using roaming profiles, but
we’ve run into a problem and wanted to know if anyone might have any
advice. When a client workstation is not connected to the domain and a user
logs on to the workstation, providing they’ve logged on to that
workstation before, the user is logged on and has access to their profile. If a
user makes changes to a specific file while not connected to the domain, once
connected back, those changes are synchronized with the server profile and all
works well. The problem comes when a user either moves, deletes, or renames a
file or directory while not connected to the domain. When the user establishes
connection back to the domain, those changes are void and a copy of the
user’s profile is copied down from the server with settings the way they
were when last connected.
We’ve tried just about every possible scenario to isolate
the problem, but have not had any success. I should mention that this problem
only recently surfaced, though it’s possible the problem has been around
longer. Any help would be much appreciated.
Thanks.
Mark
__________ NOD32 1933 (20061221) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com