Kam <(E-Mail Removed)> wrote:
> 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?
> but I haven't heard of Doug Knox, so for sure
> I'll check that out. Thanks!
>
> "Lanwench [MVP - Exchange]" wrote:
>
>> Kam <(E-Mail Removed)> wrote:
>>> 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?
>>
>>
>>>
>>> "Lanwench [MVP - Exchange]" wrote:
>>>
>>>> Kam <(E-Mail Removed)> wrote:
>>>>> 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?
|