Fileserver migratie TSProfiles synchronisatie error

[H8M3CuzUaintM3]

Gisteravond een fileserver migratie gedaan en liep tegen 1 probleem aan, TSProfiles.

- Alle data was 1 op een 1 over van de oude fileserver naar de nieuwe zonder errors.
- Alle Citrix terminals waren disabled om op in te loggen.
- Alle oude DFS targets waren disabled.
- Alle nieuwe DFS targets waren enabled naar de nieuwe locatie.

Toen we op een gegeven moment de targets enabled hadden naar de nieuwe locatie hadden we een enkele RDS omgeving enabled om op in te loggen met een gebruikersaccount die altijd op de omgeving werkt. Het inloggen ging prima en alle data was benaderbaar.

Nu komt het probleem, bij het uitloggen komt de volgende foutmelding "Your roaming user profile was not completely synchronized. See the event log for details or contact administrator.".

In mijn ogen lijkt het een rechten issue, alleen het vreemde is de TSProfiles zijn 1 op 1 over gezet, de rechten inclusief. Dit heb ik ook gecontroleerd! Op een gegeven moment ervoor gekozen om de ownership op de TSProfiles te wijzigen en te testen met SYSTEM, Domain Admins, Domain Users, de gebruiker zelf en Administrator. Helaas blijft dezelfde melding terug komen bij het uitloggen.

Voor nu TSProfiles DFS Target terug gezet naar de oude fileserver om het te onderzoeken.

Wat zie ik over het hoofd?

[Hero of Time]

Wat staat er dan in de event viewer hierover? Lijkt mij toch wel redelijk basic om dat op z'n minst te melden en op te zoeken. Is ook het pad verandert bij het in gebruik nemen van de nieuwe file server? Is die verandering in AD doorgevoerd? Kan de gebruiker de locatie handmatig openen en alles in doen wat nodig is?

[H8M3CuzUaintM3]

Hero of Time schreef op donderdag 01 oktober 2015 @ 09:41:
Wat staat er dan in de event viewer hierover? Lijkt mij toch wel redelijk basic om dat op z'n minst te melden en op te zoeken. Is ook het pad verandert bij het in gebruik nemen van de nieuwe file server? Is die verandering in AD doorgevoerd? Kan de gebruiker de locatie handmatig openen en alles in doen wat nodig is?

Eventviewer gaf na het uitloggen 2 foutmeldingen aan:

Event ID 1060
The Terminal Services User Home Directory was not set because the path specified does not exist or not accessible. The default Home Directory Path was used instead. User Name: standaard Domain: X

Event 1112
The Group Policy Client Side Extension Group Policy Drive Maps was unable to apply one or more settings because the changes must be processed before system startup or user logon. The system will wait for Group Policy processing to finish completely before the next startup or logon for this user, and this may result in slow startup and boot performance.

Waar ik tegen aan loop is dat de TSProfiles 1 op 1 over zijn. Het DFS Target is gewijzigd naar de nieuwe lokatie en dan gaat het fout bij het uitloggen. De data is prima te benaderen daar ligt het niet aan... ik zie iets over het hoofd

[Hero of Time]

Je ziet idd iets over 't hoofd. De server heeft opgeslagen waar het profiel staat. Die locatie bestaat niet meer. Heb je dus de eigenschappen van de user aangepast om de nieuwe locatie actief te maken? Je kan het altijd verifiëren door de gebruiker in 't register op te zoeken. Je krijgt dan een hele lijst van UIDs van alle gebruikers die op het systeem zijn aangemeld geweest en de eigenschappen daarvan, inclusief profiel locaties.

[H8M3CuzUaintM3]

Hero of Time schreef op donderdag 01 oktober 2015 @ 10:12:
Je ziet idd iets over 't hoofd. De server heeft opgeslagen waar het profiel staat. Die locatie bestaat niet meer. Heb je dus de eigenschappen van de user aangepast om de nieuwe locatie actief te maken? Je kan het altijd verifiëren door de gebruiker in 't register op te zoeken. Je krijgt dan een hele lijst van UIDs van alle gebruikers die op het systeem zijn aangemeld geweest en de eigenschappen daarvan, inclusief profiel locaties.

Welke eigenschappen moet ik aanpassen van de user, zowel homedir als TSProfile worden via GPO weggeschreven naar de nieuwe fileserver. In Active Directory is het "Remote Desktop Services User Profile" tabblad leeg.

Ik ga er vanuit dat je HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ bedoeld waar de "CentralProfile" in staat. Wordt deze niet automatisch aangepast nadat een gebruiker inlogd en opnieuw inlogd of moet ik hem handmatig aanpassen? Moet ik de SID hiervoor verwijderen dat hij opnieuw aangemaakt wordt ?

[Meekoh]

Waarom via GPO? Dit soort dingen zet je normaal gesproken in de properties van de user in AD.

[H8M3CuzUaintM3]

Meekoh schreef op donderdag 01 oktober 2015 @ 11:15:
Waarom via GPO? Dit soort dingen zet je normaal gesproken in de properties van de user in AD.

De roaming user profiles worden weggeschreven naar de fileserver d.m.v. de Group Policy:
Windows Components/Remote Desktop Services/Remote Desktop Session Host/Profilesshow

[Dennism]

Heb je ook even voor de migratie alle aanwezige profielen op de RDS servers even verwijderd zodat bij de eerste inlog na de migratie netjes alles even volledig opgehaald wordt vanaf de nieuwe locatie? Mogelijk dat hier nog ergens een verwijzing in zit die bokt bij het uitloggen.

[Hero of Time]

supra_indo schreef op donderdag 01 oktober 2015 @ 11:36:
[...]


De roaming user profiles worden weggeschreven naar de fileserver d.m.v. de Group Policy:
Windows Components/Remote Desktop Services/Remote Desktop Session Host/Profilesshow

Waarom heb je dat op die manier opgelost? In AD heb je juist de TS Profile tab om specifiek voor terminal servers een apart roaming profile toe te kennen. Als je die had ingevuld en naar de nieuwe locatie had laten wijzen, zou 't geen problemen hebben gegeven. Nu het echter via GPO gedaan wordt, zal de locatie niet direct aangepast worden, of zelfs helemaal niet als 't een initiële setting is.

[H8M3CuzUaintM3]

Hero of Time schreef op donderdag 01 oktober 2015 @ 13:10:
[...]

Waarom heb je dat op die manier opgelost? In AD heb je juist de TS Profile tab om specifiek voor terminal servers een apart roaming profile toe te kennen. Als je die had ingevuld en naar de nieuwe locatie had laten wijzen, zou 't geen problemen hebben gegeven. Nu het echter via GPO gedaan wordt, zal de locatie niet direct aangepast worden, of zelfs helemaal niet als 't een initiële setting is.

Ik heb de omgeving niet zo ingericht dus ik zal de migratie moeten afronden met de situatie die ze altijd hebben gehad, eventueel achteraf bespreken ter aanpassing is uiteraard mogelijk en ook heel scherp dat je hier duidelijk in bent, dank hiervoor!

Maar voor nu, de foutmelding bij het uitloggen moet weg!

Moet ik op alle RDS servers de registry keys (SIDs) verwijderen?

[Hero of Time]

Je moet de GPO aanpassen iig. Wil je 't 'fixen' voor users, dan kan je het register juist aanpassen. Gooi je de register entries weg, dan moet je ook de mappen in C:\Users weggooien, anders krijg je doodleuk mappen met gebruiker en gebruiker.domein. Dat wil je niet.

[H8M3CuzUaintM3]

Hero of Time schreef op donderdag 01 oktober 2015 @ 13:22:
Je moet de GPO aanpassen iig. Wil je 't 'fixen' voor users, dan kan je het register juist aanpassen. Gooi je de register entries weg, dan moet je ook de mappen in C:\Users weggooien, anders krijg je doodleuk mappen met gebruiker en gebruiker.domein. Dat wil je niet.

Dus inprincipe als ik het snel wil oplossen moet ik "CentralProfile" handmatig wijzigen door de oude locatie in het register te vervangen voor de nieuwe?

Had ik tevens nog een vraag m.b.t. de rechten, ik zit net de rechten te bekijken op TSProfile oude locatie en nieuwe locatie

Oud:
CREATOR OWNER
SYSTEM
Gebruiker zelf
Administrators
Oude fileserver\users

OWNER: Gebruiker zelf

Nieuw:
SYSTEM
Gebruiker zelf
Administrators

OWNER: Domain users

Hier niks fout aan?

[Hero of Time]

Het is wel de bedoeling hier dat je zelf gaat nadenken en niet wacht op mensen om een voorgekauwd antwoord te geven. Ga dus zelf na wat de eventuele implicaties zijn van het missen van bepaalde groepen. Je bent systeembeheerder, of zo kom je hier over, dit soort dingen zijn onderdeel van je functie. Je weet 't of je gaat het opzoeken, niet wachten totdat iemand zegt wat 't is.

[Question Mark]

Controleer de volgende GPO setting even op de RDS-servers:

Do not check for user ownership of Roaming Profile Folders

De default instelling is nl. dat een user of domain admins owner moeten zijn, voordat Windows het Roaming Profile als legitimite beschouwd. In jouw geval voldoe je daar dus niet aan.

[KillerAce_NL]

Ik neem toch aan dat je targetfolder nu net NIET veranderd is...Waarom heb je anders DFS....
Als je TS profiles paden aanpast dan krijg je soms rare shit omdat het pad ergens hard gecodeerd weggezet kan worden.
Zelf al eens ervaren bij het testen van het renamen van een share..


Via GPO iets anders verzinnen als de default (en geteste en recommended) manier is vragen om problemen.
Dat kun je nu in 1x rechttrekken

[H8M3CuzUaintM3]

KillerAce_NL schreef op donderdag 01 oktober 2015 @ 15:17:
Ik neem toch aan dat je targetfolder nu net NIET veranderd is...Waarom heb je anders DFS....
Als je TS profiles paden aanpast dan krijg je soms rare shit omdat het pad ergens hard gecodeerd weggezet kan worden.
Zelf al eens ervaren bij het testen van het renamen van een share..


Via GPO iets anders verzinnen als de default (en geteste en recommended) manier is vragen om problemen.
Dat kun je nu in 1x rechttrekken

Alles is over naar de nieuwe fileserver behalve TSProfiles deze DFS Target loopt nog via de oude fileserver i.v.m. de foutmelding. Ik ga de "CentralProfile" in de registry aanpassen naar de nieuwe locatie en het DFS target daarna naar de nieuwe fileserver verwijzen en opnieuw inloggen kijken of het dan wel werkt! Ik kan het helaas niet nu testen aangezien dit buiten kantoor uren moet...

Wordt vervolgd, iedereen iig bedankt voor de reacties!

[ Voor 3% gewijzigd door H8M3CuzUaintM3 op 01-10-2015 15:34 ]

[Hero of Time]

supra_indo schreef op donderdag 01 oktober 2015 @ 15:33:
[...]


Alles is over naar de nieuwe fileserver behalve TSProfiles deze DFS Target loopt nog via de oude fileserver i.v.m. de foutmelding. Ik ga de "CentralProfile" in de registry aanpassen naar de nieuwe locatie en het DFS target daarna naar de nieuwe fileserver verwijzen en opnieuw inloggen kijken of het dan wel werkt! Ik kan het helaas niet nu testen aangezien dit buiten kantoor uren moet...

Wordt vervolgd, iedereen iig bedankt voor de reacties!

Hoezo buiten kantoortijden? Je hebt een gebruiker, die trap je van de server af, past 't register ervan aan en meld opnieuw aan. Wat krijg je dan als resultaat?

Sowieso vraag ik mij af wat voor amateur die omgeving heeft opgezet. Sterker nog, wat is überhaupt je omgeving?

[Question Mark]

Kijk nog even naar mijn eerdere opmerking, ik heb daar wel vaker ellende mee beleefd.

Welke OS-en praten we eigenlijk over? Wat draait er op de RDS-server, en wat draait er op de oude en nieuwe DFS targets?

Zonder dat te weten is het lastig troubleshooten. Geef daarom ook een zo duidelijk mogelijk beeld van je omgeving.

Edit: ik krijg verder haast het idee dat op de nieuwe DFS target een filescreen filter actief is, die bepaalde files blocked.

Zet usenv logging eens aan, eens kijken welke info dat opleverd:

http://karthikkv.blogspot...-environment-logging.html

[ Voor 30% gewijzigd door Question Mark op 01-10-2015 18:56 ]

[nescafe]

Zijn de gewone share-rechten ook van toepassing op DFS? Zo ja, heb je die ook al vergeleken met de andere server?

[hans_lenze]

Ik lees nu al een paar keer "alles één op één over". Is dat wel echt zo?

Heb je DFS-R gebruikt voor het kopiëren? Welke tool met welke instellingen?