user profile zoekt oude file server

[Verwijderd]

Beste lezers,

Dit weekend hebben we een migratie van de file servers gehad, nu is alleen het probleem dat er ergens in het user profile nog naar de oude file servers wordt gewezen.

In de GPO zijn alle locaties aangepast, maar wanneer iemand inlog en je in het regester kijkt zie je onder shell folders (in het register) nog steeds verwijzingen naar oude file servers staan.

Iemand enig idee waar dit vandaan komt?

Wanneer een user profile wordt verwijderd en inlog, gaat het overigens wel gewoon goed. Het zit hem dus niet (voor zover wij denken) in een policy.

Alvast bedankt!

[Archie_T]

Gebeurt het bij enkele users of allemaal?
Heb je in de policy aanpassing ook het vinkje gezet bij move the contents to the new location?
Wat zegt de gpresult? Of beter nog de GP result wizzard in GP management?
Wat zie je in de eventviewer mbt folder redirection?
Welk OS?

[hans_lenze]

Ik gok op Windows 7 of Windows Vista.

In het register staat een sleuteltje waarin verwezen wordt naar het profiel van de gebruiker. Deze klopt niet meer als je het profiel verhuisd.
HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList (even uit mijn hoofd). Hier staan een aantal UID's van gebruikers. Per domein gebruiker staat er een sleuteltje met de profiel lokatie.

Succes!

Mocht je een mooie manier vinden om deze sleutels te wissen of te vervangen, ik hoor het graag!

[Verwijderd]

Bedankt voor je reactie!

Dit komt bij alle users voor.

Het vinkje move the contents to the new location staat aan

Logboek:
Kan beleid niet toepassen en map RoaminAppData niet omleiden naar LOCATIE (is wel bereikbaar)
Omleidingsopties=0x1021
Deze fout is opgetreden: kan de lijst met normale onderliggende mappen onder \\OUDE LOCATIE niet samenstellen foutdetails kan het netwerkpad niet vinden. eventID 502

OUDE LOCATIE, dit is de oude data server, waar overigens niets meer van in de gpo te vinden is.

Na het maken van een gpresult zie ik oa de policy waarin de locaties voor het user profile worden vastgesteld staan als toegepaste groepsbeleidsobjecten.

Windows Server 2008R2

[Verwijderd]

heb hier net hetzelfde voorgehad na een migratie van mijn 2008 R1 fileserver naar 2008 R2. Ik had in alle policies de nieuwe servernaam ipv de oude gezet, maar dit werkte niet overal goed, ik vermoed omdat ik ten eerste nog wat gpo's was vergeten te aanpassen, en ten tweede omdat de vermelde folder locaties uit mijn GPO's net een onderdeel van het profiel zelf zijn en dan laadden de profielen niet 100% goed vooraleer de aanpassing in de group policies van toepassing was.

heb dit dan opgelost door via een bat file met (regedit /s *.reg) voor de clients de beide regkeys (shell folders én user shell folders) goed te zetten.

[ Voor 5% gewijzigd door Verwijderd op 13-03-2011 20:19 ]

[Verwijderd]

Thanks voor je reactie!

Je hebt handmatig dus de shell folders en user shell folders 1x goed gezet, export gemaakt en deze export aangepast met de username naar %username% en dan bijv. via een opstartscript bij iedereen laten uitvoeren tijdens het starten?

Ik hoor het graag!

[alt-92]

Verwijderd schreef op zondag 13 maart 2011 @ 18:43:
Wanneer een user profile wordt verwijderd en inlog, gaat het overigens wel gewoon goed. Het zit hem dus niet (voor zover wij denken) in een policy.

Dus wel

Maar daar heb je nu niet zoveel meer aan, denk dat je oude fileserver ook al uit staat?
Eventueel zet je die tijdelijk terug met RO permissies op de shares.

Je kan dit voorkomen door een meer gefaseerde aanpak - eerst de nieuwe doos in de lucht brengen, GPO's aanpassen met de extra doos, dan de profile folders aanpassen. Daarna haal je de oude machine uit de GPO maar laat je deze nog aanstaan - zo vang je eventuele stragglers aan users nog op.
Pas als je (bijna) geen file activity meer hebt op de machine decommission je 'm.

Kost iets meer tijd, maar user impact is verwaarloosbaar in tegenstelling tot zo'n big-bang. Dan ontkom je niet aan een zooi profile resets en daar worden je users weer niet echt blij van.

(en regedit hacks voor shellfolder items is nou niet bepaald de meest handige manier nog afgezien van het punt dat dat met Vista en hoger unsupported is)..

hans_lenze schreef op zondag 13 maart 2011 @ 18:59:

Mocht je een mooie manier vinden om deze sleutels te wissen of te vervangen, ik hoor het graag!

DelProf werkt nog steeds toch?

[ Voor 16% gewijzigd door alt-92 op 13-03-2011 22:56 ]

[Archie_T]

Om nog even op hierboven in te haken, ik zou dan de dns entry en de share van de oude server laten verwijzen naar de nieuwe, hoef je ook geen oude servers aan te laten en na een maand of twee ruim je alles op.

[alt-92]

Dat lukt je tegenwoordig alleen als je DFS hebt gebruikt, alternate netBIOS names is flaky at best.
En ik gok er zomaar op dat er geen FQDN als profileserver name is gebruikt

[Verwijderd]

Verwijderd schreef op zondag 13 maart 2011 @ 20:52:
Thanks voor je reactie!

Je hebt handmatig dus de shell folders en user shell folders 1x goed gezet, export gemaakt en deze export aangepast met de username naar %username% en dan bijv. via een opstartscript bij iedereen laten uitvoeren tijdens het starten?

Ik hoor het graag!

inderdaad, maar was wel op een zeer kleine omgeving.
Wat zeer belangrijk is in dit verband: onthoud dat C:\users\%username% =/= %userprofile% !
het pad kan verschillen, bvb. wanneer er voorheen al profielproblemen waren op een client (cf. user.domein.000 profielmap bvb.)

best dus met variabele userprofile werken, dan zou het script moeten lukken.

[Archie_T]

alt-92 schreef op maandag 14 maart 2011 @ 08:17:
Dat lukt je tegenwoordig alleen als je DFS hebt gebruikt, alternate netBIOS names is flaky at best.
En ik gok er zomaar op dat er geen FQDN als profileserver name is gebruikt

Grappig, bij ons werkte dat namelijk wel (geen FQDN gebruikt) nou was dat wel een migratie vanaf een 2003 file cluster naar een EMC Celerra, ik het het inderdaad nooit Windows -> Windows gedaan.