Deleting user's roaming-mandatory profile at logoff not reliable

[Kam]

Hi,
We have public-access computers that log on with a mandatory roaming
profile, which we have set to 'self-delete' upon logoff--we use Group
Policies to put the local Users group into the Guest group. Microsoft's
default mechanism is to delete any Guest's profile at logoff. The 'master'
copy of the profile actually sits on the computer itself, C:\Profiles, so a
copy of it is made to C:\Documents and Settings\<username>. The profile is
..MAN.

The problem is that invariably the system fails to delete the profile, then
the auto-login kicks in and the user is logged back in with a duplicate
profile as the previous one becomes unusable/corrupted. Thus as the day goes
on, each user session invariably creates successive profiles, and some
computers end up with hundreds of 'dead' profiles that we need to manually
delete.

Does anyone have any advice on how to ensure that the cached profile is
deleted consistenly and reliably each time the user logs off and on? Thanks.

 

[Kam]

Just to add: I've tried UPHClean 1.6d--it doesn't help, and 2.x seems to have
ceased development! The failing profiles are not consistent, but highly
sporadic, which makes it hard to troubleshoot.

 

[Lanwench [MVP - Exchange]]

Hi,
We have public-access computers that log on with a mandatory roaming
profile, which we have set to 'self-delete' upon logoff--we use Group
Policies to put the local Users group into the Guest group.
Microsoft's default mechanism is to delete any Guest's profile at
logoff. The 'master' copy of the profile actually sits on the
computer itself, C:\Profiles, so a copy of it is made to C:\Documents
and Settings\<username>. The profile is .MAN.

The problem is that invariably the system fails to delete the
profile, then the auto-login kicks in and the user is logged back in
with a duplicate profile as the previous one becomes
unusable/corrupted. Thus as the day goes on, each user session
invariably creates successive profiles, and some computers end up
with hundreds of 'dead' profiles that we need to manually delete.

Does anyone have any advice on how to ensure that the cached profile
is deleted consistenly and reliably each time the user logs off and
on? Thanks.

How are you using roaming profiles if the "server" copy is actually local to
that computer? I have never seen this work unless you're using a domain
model (and the profile lives on the server). You say you've got group
policy, which is also a domain thing....otherwise it's a local policy. So
I'm a bit confused as to what you've got.

That said, you might check rsop.msc and your event logs for errors/clues.
However, since a mandatory profile cannot be changed, why are you concerned
with deleting it anyway? What's the harm in leaving it be?

 

[Kam]

Hi,
We have a typical Active Directory domain structure, and originally we had
the profiles on the DC. Our public computers have a 1-hour usage limit. Their
session is forcibly logged off on the hour, so we routinely have approx. 1500
computers logging off and auto-logging back on at the same time throughout
the day! Our bandwidth was being clobbered with the profiles downloading
approx. 9MB x 1500 computers each hour! So, we changed the roaming profile
path to point to a share on the local C: drive, and of course, had to deploy
a copy of the 'master' profiles to every workstation.

Why do we delete the profiles after each user's session? We were finding
that the mandatory settings remain unchanged, some temp internet files were
not being erased at logoff, even though that is the action specified in our
group policies. We have a strict privacy policy and have to safeguard the
public users from any temp files or historical data that might be used to
reveal their internet activity. We're a government organization who provides
free internet access to the public.

 

[Lanwench [MVP - Exchange]]

Hi,
We have a typical Active Directory domain structure, and originally
we had the profiles on the DC. Our public computers have a 1-hour
usage limit. Their session is forcibly logged off on the hour, so we
routinely have approx. 1500 computers logging off and auto-logging
back on at the same time throughout the day! Our bandwidth was being
clobbered with the profiles downloading approx. 9MB x 1500 computers
each hour!

Sure. Youch. Of course, the profile should be miniscule - folder redirection
(to a null folder?) etc.

So, we changed the roaming profile path to point to a
share on the local C: drive, and of course, had to deploy a copy of
the 'master' profiles to every workstation.

That sounds horrid to manage, honestly.

Why do we delete the profiles after each user's session? We were
finding that the mandatory settings remain unchanged

That's fine, right?

, some temp
internet files were not being erased at logoff, even though that is
the action specified in our group policies.

For that, I'd do a logoff script-

FOR /F %%A IN ('DIR/B "C:\Documents and Settings"') DO DEL/S/F/Q
"C:\Documents and Settings\%%A\Local Settings\Temporary Internet Files\*.*"
FOR /F %%A IN ('DIR/B "C:\Documents and Settings"') DO RD/S/Q "C:\Documents
and Settings\%%A\Local Settings\Temporary Internet Files\"

(this works best as a startup or shutdown script that doesn't run in the
user context, as it acts on all files in documents & settings\.... but will
work for a user in a logoff script.

We have a strict privacy
policy and have to safeguard the public users from any temp files or
historical data that might be used to reveal their internet activity.
We're a government organization who provides free internet access to
the public.

I'd look into something besides this config. Have you checked out any of the
kiosk-config stuff, such as Windows Steady State? Or the Doug Knox Security
console? Or, there are plenty of other options, some of which will go as far
as re-image the machines every night.

It isn't really clear why these users need to log into the domain,
either....is that truly necessary?

 

[Kam]

Thanks for your advice and suggestions, Lanwench, I appreciate your time! The
public users (all generic, fixed accounts, btw) need to log into the domain
so that we can apply group policies to them according to their various group
memberships. I'm assuming that's the prerequisite...

I will try your suggestion of a logoff script, where it would not require
elevated/admin privileges to execute. I've read a lot about Microsoft's
various forms of maintaining a computer in a shared public environment, but I
haven't heard of Doug Knox, so for sure I'll check that out. Thanks!

 

[Lanwench [MVP - Exchange]]

Thanks for your advice and suggestions, Lanwench, I appreciate your
time! The public users (all generic, fixed accounts, btw) need to log
into the domain so that we can apply group policies to them according
to their various group memberships. I'm assuming that's the
prerequisite...

Yes, but if you need different users to have different permissions/settings,
I'm sure you could do this via Windows Steady State. I'm presuming it's a
one-to-one relationship between a user account and a computer, based on your
description. Without knowing what the users need, it's hard to say.

I will try your suggestion of a logoff script, where it would not
require elevated/admin privileges to execute.

It won't, but it won't delete anything that the user doesn't have
permissions to (just their own temp inet files)

I've read a lot about
Microsoft's various forms of maintaining a computer in a shared
public environment,

Have you tried any of them to see what they do?

 

[Anteaus]

Just a thought, but might it be worth investigating a 'Live CD' alternative?
In that case, rebooting puts the computer back as it was, with 100%
certainty.

The other advantage is that it deals effectively with the problem of
malware, which a mandatory profile doesn't necessarily deal with.

The 'Live' OS can be on a hard-dsk if replacing 1500 CD's for each upgrade
is a problem.

 

[Kam]

While reading about LiveCD, I picked up an idea of redirecting the current
user's profile to a RAM disk, which gets flushed at logoff. Thanks for the
lead!