[Win 2k3] Cache van windows profiles

[Verwijderd]

We werken hier met een systeem van terminal servers waarbij het windows profiel (C:\Documents and Settings\profiel) bij het inloggen steeds via een script wordt geladen van de fileserver naar de terminal server waar de gebruiker op inlogt.

Wanneer ik bijvoorbeeld een policy aanpas dan wordt die enkel doorgevoerd bij nieuwe gebruikers, of bij gebruikers waarbij ik het profiel op de fileserver verwijderd hebt zodat ze eigenlijk van scratch beginnen en al de nieuwste policies geladen krijgen.

Dit is uiteraard geen efficiënte oplossing, daarom vroeg ik me af of die policies gecached worden in één bepaalde file of files in dat profiel waardoor ik niet telkens dat hele profiel moet verwijderen?

Een gpupdate /force op de terminal servers doet niets uit aangezien die profielen steeds geladen worden van op de fileserver.

[Verwijderd]

Na nog wat zoekwerk heb ik de volgende zaken ontdekt:

We hadden nog enkele testgebruikers staan en daarvan heb ik de paswoorden gereset (niemand kende ze nog) en daarmee ingelogd. Toen ik hiermee inlogde werden de nieuwe policies geladen en functioneerde de account zoals het hoort.

Nu weet ik echter niet of het resetten van het wachtwoord hier iets mee te maken kan hebben?

EDIT: Heb het bij een gebruiker getest en het werkt niet, dit kan ik dus al uitsluiten.

[ Voor 10% gewijzigd door Verwijderd op 11-02-2010 13:30 ]

[elevator]

Werkt dit systeem met .cab files, het klinkt een beetje alsof je het over FlexProfile's hebt of iets in die richting, misschien dat je daar wat meer mee kan.

[Verwijderd]

We werken met local profiles die via een script van de fileserver naar de desbetreffende terminal server worden gekopieerd. Ze hebben hiervoor gekozen in plaats van voor roaming profiles, het had iets te maken met bandbreedte ofzo.

[elevator]

Mjah maar wordt daar eens wat duidelijker in, want afhankelijk van welke tools je gebruikt en hoe het werkt moet je bv. 'gewoon' het mandatory profiel aanpassen oid ?

[Verwijderd]

Wel wanneer we in de active directory een gebruiker aanmaken en die de eerste maal aanmeldt wordt er op de fileserver onder de map tsprofiles een windows profiel aangemaakt die gebruiker.

Ook wordt dit profiel via een script automatisch gekopieerd naar de terminal server waar die gebruiker op aan het werken is. Daar kunnen er dan allerhande zaken in het profiel worden aangepast en opgeslagen zoals bv de Outlook settings, afbeeldingen, favorieten etc...

Wanneer de gebruiker terug afmeldt van de terminal server wordt via een script dit profiel terug op de fileserver geplaatst. We werken met verschillende terminal servers dus het profiel reist eigenlijk van de ene terminal server naar de andere met de fileserver als thuisbasis.

Nu zaten we met een probleem van een website die wegens te strenge cookie-instellingen niet werkte. Hiervoor heb ik dus een group policy aangepast die hiervoor verantwoordelijk was en heb ik gpupdate /force gedaan op al onze terminal servers. Wanneer een gebruiker terug aanmeldt kan hij echter nog steeds niet op die website ook al is die policy goed ingesteld.

Wanneer ik echt een nieuwe gebruiker aanmaak (waarvoor dus een nieuw profiel moet worden aangemaakt op de fileserver) dan kan die wel op die website, dit geldt ook voor een gebruiker waarbij ik het profiel op de fileserver heb verwijderd en er dus een nieuw wordt aangemaakt als hij terug inlogt.

Dus blijkbaar zijn er toch bepaalde zaken die gecached worden in dat profiel waardoor de nieuwe security settings mbt die cookies niet doorgevoerd worden?

[alt-92]

Verwijderd schreef op vrijdag 12 februari 2010 @ 10:54:
Wel wanneer we in de active directory een gebruiker aanmaken en die de eerste maal aanmeldt wordt er op de fileserver onder de map tsprofiles een windows profiel aangemaakt die gebruiker.

Ook wordt dit profiel via een script automatisch gekopieerd naar de terminal server waar die gebruiker op aan het werken is. Daar kunnen er dan allerhande zaken in het profiel worden aangepast en opgeslagen zoals bv de Outlook settings, afbeeldingen, favorieten etc...

Wanneer de gebruiker terug afmeldt van de terminal server wordt via een script dit profiel terug op de fileserver geplaatst. We werken met verschillende terminal servers dus het profiel reist eigenlijk van de ene terminal server naar de andere met de fileserver als thuisbasis.

Tot zover niks bijzonders, en eigenlijk ook niks wat niet met de al aanwezige standaard profile roaming od redirection niet opgelost zou worden.

Waarom maken jullie eigenlijk gebruik van 'scripts' ? Het klinkt dusdanig vaag dat ik onderhand het idee krijg dat je eerder daarin eens de oorzaak moet gaan zoeken.
Als je profile maar één keer wordt overgezet door dat script dinges toestand geval en daarna niet meer meegesynced wordt voldoet dat wel aan het scenario wat je beschrijft.

[Verwijderd]

alt-92 schreef op vrijdag 12 februari 2010 @ 11:19:
[...]


Tot zover niks bijzonders, en eigenlijk ook niks wat niet met de al aanwezige standaard profile roaming od redirection niet opgelost zou worden.

Waarom maken jullie eigenlijk gebruik van 'scripts' ? Het klinkt dusdanig vaag dat ik onderhand het idee krijg dat je eerder daarin eens de oorzaak moet gaan zoeken.
Als je profile maar één keer wordt overgezet door dat script dinges toestand geval en daarna niet meer meegesynced wordt voldoet dat wel aan het scenario wat je beschrijft.

Ik ben hier slechts 6 maanden in diest en de hele infrastructuur met die scripts was reeds opgesteld door een outsourcingbedrijf dus ik heb daar niets in te zeggen gehad.

En je profiel wordt niet maar één keer overgezet:

even een schets:

1) Gebruiker logt aan op de farm en komt op terminal server 1
2) Via een script wordt zijn profiel van op de fileserver gekopieerd naar terminal server 1
3) De gebruiker meldt af op terminal server 1
4) Zijn profiel wordt terug naar de fileserver gekopieerd
5) Gebruiker logt terug aan op de farm en komt deze keer op terminal server 3 terecht
6) Zijn profiel wordt van op de fileserver naar terminal server 3 gekopieerd

[alt-92]

Ja, maar dat doet Windows zelf al standaard. Zonder scripts.

[Verwijderd]

Ja dat weet ik, maar om de één of andere reden is dat hier zo opgezet geweest. Dat hele systeem omgooien is geen optie want we zitten met 11000 bedienden en dergelijke zaken moet goedgekeurd worden.

[alt-92]

Dat snap ik
however, ik denk toch dat je in de scriptlogging misschien meer houvast terug vindt

[elevator]

Ik vermoed dat hij een combinatie van mandatory profiles (voor een basis profiel) gebruikt en daarin de persoonlijke settings laad die komen uit een cab file, bijvoorbeeld zoals http://www.loginconsultan..._details&gid=1&Itemid=149 werkt.

Wat je kan proberen is om eens op zoek te gaan naar welke registry key jouw policy nu heeft gewijzigd, meestal is dat vrij simpel te vinden door bv. de ADM file te bekijken.

Als je nu die key weer opzoekt in je 'al bestaande' profiel kan je controleren of die registry key gezet wordt in de policies key zodat je iig zeker weet dat je policy applied wordt en of de key niet toevallig overruled wordt door jouw script dat de settings terug inleest. Vind de je key niet terug met de door jou ingestelde waarde, en je past hem handmatig aan en het blijft dan in orde, is het waarschijnlijk je script dat de mist in gaat