Migration von Roaming Profiles zu FSLogix Containern

[phatair 39]

Hallo zusammen,

 

wir setzen bei uns aktuell noch 2012R2 RDP Hosts zusammen mit Roaming Profiles ein. 

Die "temporären" lokalen Profile werden nach einer Abmeldung vom RDP Host gelöscht (per GPO so gesetzt).

 

Nun stellen wir auf 2019 RDP Hosts um und wollen in diesem Zuge auch auf die FSLogix Container umstellen.

Soweit ist alle konfiguriert und beim testen ist nun folgendes aufgefallen.

Die Container lassen sich zwar per CLI und dem Befehl "frx.exe copy-profile -filename Profile_User.vhdx -username contoso\user -dynamic 1 -verbose" kopieren, aber dazu muss das lokale Profil auf dem RDP Server vorhanden und der User darf nicht angemeldet sein (Es wird wohl der Reg Key aus UserProfile gelesen/übernommen oder so was ähnliches).

Nun kann man mit dem Parameter -profile-path= noch den Pfad zum Profil angeben. Dort habe ich dann den UNC Pfad zum Roaming Profile angegeben, aber hier habe ich immer die Fehlermeldung 

 

Formatting volume: \\?\Volume{d763ba77-a660-47d9-8e2d-fe2eb0257308}\
Copying profile for user S-1-5-21-602162358-1844237615-839522115-5229 to volume \\?\Volume{d763ba77-a660-47d9-8e2d-fe2eb0257308}\
Error copying profile (0x00000001): Unzulõssige Funktion.

 

Wenn ich das Roaming Profile lokal in einem temporären Ordner kopiere und dann den Befehl ausführe erhalte ich den gleichen Fehler.

Hat hier noch jemand eine Idee? 

Die bestehenden RDP Hosts per GPO so zu konfigurieren, dass das Profil trotz Roaming Profile lokal beim abmelden erhalten bleibt ist erstmal keine Lösung. Da würde ich die Profile auf den neuen Hosts einfach neu anlegen lassen, da wir die wichtigen Ordner wie Desktop, Dokumente usw. sowieso auf das Home Laufwerk umleiten.

 

Danke und Gruß

[testperson 1.707]

Hi,

 

wenn du die Profile vorher umstellen möchtest, hatte ich bislang immer diese Scripte im Einsatz. Das waren aber überwiegend auch Citrix UPM Profile. Es sollte aber auch kein Hexenwerk sein, das "UPM Script" an die RUPs anzupassen.

• Convert Citrix UPM to FSLogix Profile Containers - Xenit
• Move on-premises Remote Desktop Services to Azure Virtual Desktop - Cloud Adoption Framework | Microsoft Docs

Als Alternative könntest du ggfs. noch bei der Anmeldung ein leeres FSLogix Profil erstellen und dann die nötig(st)en Daten bei der Anmeldung kopieren lassen.

 

Gruß

Jan

[phatair 39]

Danke Jan,

 

ich hab mir das Script mal angeschaut und es beinhaltet ja schon eine Vorgabe für Roaming Profiles.

Für den ersten Test habe ich mir mal ein Roaming Profile lokal kopiert und mit folgendem PS Befehl versucht das Profil zu migirieren

Convert-RoamingProfile -ProfilePath "C:\temp\Test FSLOGIX\test-rdp\" -Target "C:\temp\Test FSLOGIX\" -VHDMaxSizeGB 5 -LogPath 'C:\temp\Test FSLOGIX\log.txt'

Hier erhalte ich leider folgende Fehlermeldung im Log "Could not resolve to AD User. Cannot copy."

Ich habe mir das Script mal angeschaut, leider bin ich kein Programmierer und so richtig verstehe ich nicht wie er versucht aus dem Pfad/Ordner den AD User zu erkennen.

Kennst du vielleicht das Problem bzw. die Lösung?

Danke und Gruß,

Steffen

[testperson 1.707]

Hi,

 

die Funktion "New-MigrationObject" aus "\Helper Functions\New-MigrationObject.ps1" Zeile 74 bis 93 versucht den Usernamen aus dem Profilpfad anhand von SID oder Namen des Verzeichnisses auszulesen.

 

In deinem Fall wird es vermutlich keinen Benutzer "test-rdp" im AD geben? Sollten im Ordner "..\test-rdp\" die Profile liegen, müsste es vermutlich der Parameter ParentPath anstatt ProfilePath sein.

 

Gruß

Jan

[phatair 39]

Hi Jan,

 

"leider" gibt es einen AD User test-rdp und diesem gehört auch dieses Profil. Deshalb war ich so verwundert.

Es sind auch alle notwendigen Module installiert (AD, HyperV und Pester).

 

Das Profil liegt eben testweiter unter C:\temp auf meinem lokalen Notebook. Ich habe es aus dem UNC Pfad, wo die Profile normalerweise liegen, kopiert und extra die Endung .V4 gelöscht damit der Name sauber zugeordnet werden kann. 

 

Ich habe auch schon bei -Profilpath den abschließenden Backslash weggelassen. Ging trotzdem nicht.

auch habe ich es mit meinem eigenen Profil getestet, auch dort kann er das AD Objekt nicht finden.

[testperson 1.707]

vor 13 Minuten schrieb phatair:

Ich habe es aus dem UNC Pfad, wo die Profile normalerweise liegen, kopiert und extra die Endung .V4 gelöscht damit der Name sauber zugeordnet werden kann. 

Hast du es auch mal mit der Version im Ordner versucht? Also das ".V4" dran gelassen? Der RegEx

 

# Aus New-MigrationObject.ps1

# Zeile 65
$VersionRegex = "(?i)(\.V\d)"

# Zeile 74
(Split-Path "C:\temp\Test FSLOGIX\test-rdp\" -Leaf) -match $VersionRegex #false
(Split-Path "C:\temp\Test FSLOGIX\test-rdp.V4\" -Leaf) -match $VersionRegex #true

 

dürfte nur "True" ergeben, wenn am Profilordner eben das ".V<Zahl>" bzw. ".v<Zahl>" hängt.

 

[phatair 39]

also ich bin ratlos. ich habe jetzt auch das .V4 wieder angehängt. Trotzdem kommt der gleiche Fehler.

Wenn ich folgende Befehl ausführe, erkennt er den User und auch die Version aber die SID und GUID kann er nicht auslesen

 

New-MigrationObject -ProfilePath C:\temp\FSLOGIX\profiles\TEST-RDP.v4\ -Target C:\temp\FSLOGIX\

 

ProfilePath : C:\temp\FSLOGIX\profiles\TEST-RDP.v4\
Username    : TEST-RDP
Version     : v4
UserSID     : SID Not Found
UserGUID    : GUID Not Found
Target      : Cannot Copy

 

Es gibt aber dieses AD Objekt. Ich habe die PS Konsole auch extra mit einem User gestartet, der Schreibzugriff auf die OU hat in der das Objekt liegt. Auch das hat nichts geholfen. 

Falls du noch eine Idee hast wäre ich dankbar, ansonsten würde ich die User wohl informieren, dass die Profile neu erstellt werden. die wichtigen Ordner haben wir ja sowieso umgeleitet.

 

EDIT: Wenn ich Get-ADUser -identity test-rdp ausführe, dauert es etwas und dann erhalte ich die Meldung, dass der Server nicht verfügbar ist.

Führe ich den Befehl auf einem der DCs aus, erhalte ich sofort die Infos. Ich habe unsere FW im Verdacht.

 

EDIT2: also es lag tatsächlich an der FW. PS hatte den Port 9389 für die AD Abfrage genutzt und diesen hat unsere FW blockiert.

Danach wurde der User gefunden. Nun kommt aber gleich der nächste Fehler.

 

10/21/2021 20:38:49 - Could not create or mount Profile Disk
10/21/2021 20:38:49 - Mit den Hyper-V-Verwaltungstools war kein Zugriff auf eine erwartete WMI-Klasse auf Computer "NB350" möglich. Dies kann darauf hinweisen, dass die Hyper-V-Plattform nicht auf dem Computer installiert ist oder dass die Version der Hyper-V-Plattform mit diesen Verwaltungstools nicht kompatibel ist.

 

Ich habe auf meinem Win 10 20H2 einfach unter den "Windows Features aktivieren" die hyper-V-Verwaltungstools installiert. Muss ich hier noch weitere Module laden?

bearbeitet 21. Oktober 2021 von phatair

[phatair 39]

Ich antworte jetzt einfach auf mein Beitrag selber, da ich den Fehler gefunden habe.

Es musste tatsächlich die komplette Hyper-V Plattform installiert werden und nicht nur die Verwaltungstools (so wie es ja auch in der Fehlermeldung steht). ich bin allerdings davon ausgegangen, dass das Scrpt das prüft (stand zumindest so in der Readme).

 

Nach dem ich die hyper-v tools installiert habe, wurde auch das vhdx file erstellt. Nun muss ich morgen noch prüfen ob die Verwendung sauber funktioniert.

Danke Jan für die Hilfe bis hier her.

[phatair 39]

Hallo zusammen,

 

soweit klappt die Migration nun erstmal. Das Script läuft sauber durch und ich habe es so angepasst, dass der Ordner für das FSLogix Profil USERNAME_SID ist und nicht mehr SID_USERNAME.

Wenn ich mich dann allerdings am Test RDP Server anmelde, der für FSLogix konfiguriert ist, wird eine neue VHDX erstellt und meine migrierte in CORRUPTED_ umbenannt.

Im FSLogix Log steht folgendes

Creating new user profile disk (user's registry hive was missing) 

 

Laut Google ist das ein Problem mit der NTUser.dat, dass diese zum Beispiel nicht vorhanden ist oder wir noch eine andere Software/Lösung wie Roaming Profiles einsetzen die sich vorher die NTUser.dat geladen hat.

Beides ist aber nicht mehr der Fall. Roaming Profiles habe ich in der GPO entfernt und ich habe in der VHDX nachgeschaut, dort ist die NTUser.dat vorhanden.

 

Hat noch jemand eine Idee, woran das liegen kann? Kann bei der Migration innerhalb der VHDX die Berechtigung irgendwie zerschossen sein bzw. kann man das prüfen?

Wenn ich die migrierte VHDX per FSLogix mounte kann ich erstmal nicht auf das Profil zugreifen. Ich muss die "Sicherheit" bearbeiten und mich als Besitzer eintragen. erst dann kann ich in das Profil schauen - ist das normal oder deutet das auf ein Berechtigungsproblem hin?

 

EDIT: Gerade noch einen letzten Test gemacht

1. Neues sauberes FSLogix Profil durch FSLogix selber erstellen lassen. Diese VHDX mit dem FSLogix Tool gemounted. In das Profil kam ich erst rein, nach dem ich die typische Windows Meldung "sie benötigen Zugriff" bestätigt hatte. Damit war mein User zwar in der ACL Liste eingetragen aber das ist ja erstmal egal. Die Berechtigung war der eigentliche User, System und Admin

2. Das gleiche noch mal mit meinem migrierten FSLogix Container gemacht. Migrierte VHDX mit dem FSLogix Tool gemounted und versucht das Profil aufzurufen. Kam erstmal auch die typische Windows Meldung mit dem Zugriff. Die Meldung bestätigt und trotzdem kam ich nicht rein - es kam die Meldung, dass ich die Sicherheit bearbeiten muss. Also habe ich den Besitz übernommen und siehe da, es steht nichts in der ACL drin. Ich habe dann manuell SYSTEM mit Vollzugriff hinzugefügt und dann ging auch das anmelden mit diesem Container.

 

Die Frage ist nun, wie bzw. wo läuft im Script mit der Berechtigung was schief. Oder liegt es am Ursprünglichen Roaming Profile...?

 

bearbeitet 22. Oktober 2021 von phatair

[phatair 39]

Ich mache noch mal einen neuen Beitrag, einfach damit es etwas übersichtlicher ist. ich hoffe das ist OK und es hilft vielleicht dem ein oder anderen der auch von Roaming Profiles zu FSLogix wechseln möchte.

 

Ich habe den Fehler nun gefunden.

 

Das Problem war, dass ich das Script mit einem User ausgeführt habe der lokal Adminrechte hatte (um überhaupt das VHDX mounten zu können) und auch auf das Target Ziel schreiben durfte. Er war aber nicht auf das Roaming Profile selber berechtigt und damit konnte er die Berechtigungen im VHDX nicht setzen.

Das habe ich nun mal temporär angepasst und siehe da es läuft sauber durch.

Einzig im Script Convert-Roaming-Profiles.ps1 musste ich an der Stelle wo die Berechtigungen gesetzt werden "Administrators" durch "Administratoren" ersetzen, da wir eine Deutsche Umgebung haben.

 

 

[testperson 1.707]

Danke für die Rückmeldung(en)!

 

Du könntest die SID "S-1-5-32-544" nehmen, dann ist die Sprache egal:

icacls $Destination /grant *S-1-5-32-544`:`(OI`)`(CI`)F

 

[phatair 39]

Am 22.10.2021 um 15:44 schrieb testperson:

Du könntest die SID "S-1-5-32-544" nehmen, dann ist die Sprache egal:

Stimmt - gute Idee. Danke.

 

Eine Frage habe ich doch noch.

Ich würde gerne in den Profile Order, der in der VHDX enthalten ist, eine AD Sicherheitsgruppe in die ACL aufnehmen, damit die entsprechenden Admins beim mounten der VHDX im Problemfall auf das Profil zugreifen können.

Im dem von dir verlinkten Powershell Script ist da ja problemlos möglich, aber wie mache ich das bei neuen VHDX Containern, die dann nicht über das Script erstellt werden?

In den GPOs habe ich zwar die Richtlinie "Set access control for profile directory inside VHD" gefunden, aber meine Tests damit waren leider nicht erfolgreich.

Hast du dazu noch eine Idee?

 

Danke und Gruß