madison
Goto Top

RDS 2019 - Neuinstallation + Übernahme Userfiles alter RDS

Hallo,

mein RDS 2019 lief einige Monate stabil. Alles funktionierte prima. Da Windows Updates oder andere relevante Dinge einen Neustart erfordern, ging es dann los.
Der RDS startet als VM total langsam, erst nach ca. 8 Minuten kommt der Login. Loggt man sich ein, egal ob lokaler Admin oder AD Admin, soft Neustart der Kiste oder die VM schaltet sich aus.

Ich konnte die Kiste nur retten, indem ich mittels Powershell und der Server ISO per DISM die *.wim Datei wieder draufgebügelt habe.

DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:E:\Sources\install.wim:1 /LimitAccess

Das brauchte auch mehrere Versuche, bis es mal geklappt hat. Danach rennt die Kiste top, bis der nächste Neustart ansteht.
Auch haben viele User Probleme das ständig die Verbindung getrennt wird oder Apps sich schließen und der Fehler "Unbekannter Fehler aufgetreten. Porgramm wird geschlossen" oder so auftaucht.

Da ich diese Endlosschleife nun brechen möchte, soll der RDS 2019 neu aufgesetzt werden.

Mein Vorgehen:

- alten RDS aus AD nehmen
- neue VM
- SRV 2019 installieren
- Windows Updates installieren
- IP Einstellungen und Name vom alten RDS nehmen
- Aufnahme in Domäne
- RDS Dienste installieren
- Zertifikate installieren und Lizenzieren
- per change user /install alles benötigte an Software installieren
- Startlayout anpassen (ist schon als *.xml) vom alten Server vorliegend
- weitere Anpassungen

Nun mein Problem:

Ich möchte die lokalen Userprofile vom alten Server übernehmen. Diese wollte ich vom alten RDS per Robocopy auf den neuen kopieren.
Dazu die Registry Werte aus HKLM/SOFTWARE/Microsoft/Windows/NT/CurrentVersion/ProfileList exportieren und auf den neuem importieren.
Da meine User schon letztens gemeckert haben, das sie beim ersten Start von Outlook 3x auf weiter klicken müssen zum Einrichten + die Emailsignatur oder im EDGE mal die Startconfig durchklicken, möchte ich das mit dem kopieren der Userprofile gleich umgehen.

Funktioniert das so? Oder erst die Userfiles und REG-Werte auf dem neuen Server hauen und dann die Software installieren?

Eigene Dateien und Desktop werden vom Fileserver per GPO geholt. Das funktioniert.

Muss ich sonst noch was beachten?

Danke für Tipps und Ratschläge.

Gruß Madison

Content-ID: 1617513219

Url: https://administrator.de/forum/rds-2019-neuinstallation-uebernahme-userfiles-alter-rds-1617513219.html

Ausgedruckt am: 23.12.2024 um 04:12 Uhr

Doskias
Doskias 14.12.2021 um 08:23:48 Uhr
Goto Top
Moin Madison,

ich würde auf dem alten Server jetzt noch auf die User Profile Disks umstellen. Dabei wird das Userverzecihnis für jeden User in eine VHDX-Datei gespeichert und beim anmelden als Benutzerordner gemappt.

Richte es ein, lass es laufen bis sich jeder User angemeldet hat. Danach nimmst du den einen Terminalserver raus und aktivierst den anderen. Die User bekommen die gleiche VHDX gemappt und es ist alles so wie es auf dem alten Server war.

Bin mir allerdings grade nicht sicher ob es einen Automatismus beim Erstellen der UPDs gibt, wie bei Ordnerumleitungen.

Ansonsten:
Da meine User schon letztens gemeckert haben, das sie beim ersten Start von Outlook 3x auf weiter klicken müssen zum Einrichten
Ist halt so face-wink
+ die Emailsignatur
Gibt Tools die die Signatur automatisieren
oder im EDGE mal die Startconfig durchklicken, möchte ich das mit dem kopieren der Userprofile gleich umgehen.
Kannst du per GPO unterbinden.

Gruß
Doskias
Madison
Madison 14.12.2021 um 08:40:26 Uhr
Goto Top
Hallo Doskias,

danke für deinen Tipp. Die Überlegung hatte ich auch schon. Leider hab einen Termin für die Umsetzung aufgedrückt bekommen. Das soll morgen geschehen. Nun sind aber mindestens 30% der User nicht im Dienst (Urlaub, Krank, etc.) und loggen sich demzufolge auch nicht ein, um die UPD zu erstellen.

Ich habe ein Script gefunden zum kopieren der lokalen Profile in eine UVHD:

$sourceServer = "RdServer"  
$localProfilePath = "\\$sourceServer\C$\Users"  
$updPath = "\\fileServer\updShare\"  
$forUseOnSourceServer = $true  #UPD being set up is for same server that local profile was on

$templateUpd = "$updPath\UVHD-template.vhdx"  
write-host " "  
write-host "   ╔════════════════════════════════════════════════════════╗ " -ForegroundColor Yellow  
write-host "   ║                                                        ║ " -ForegroundColor Yellow  
write-host "   ║        This script must be ran as Administrator        ║ " -ForegroundColor Yellow  
write-host "   ║                                                        ║ " -ForegroundColor Yellow  
write-host "   ╚════════════════════════════════════════════════════════╝ " -ForegroundColor Yellow  
write-host " "  
timeout.exe 15

#try to determine users from local profiles
$profileFolders = @(get-childitem -Path $localProfilePath -Directory | Out-GridView -Title "Select Profiles to copy to UPD" -PassThru)  

foreach($folder in $profileFolders)
{
    $name= $folder.name
    #try to find user account for the name
    write-host "__________________________________________________________________"  
    write-host "Profile folder $name" -ForegroundColor Cyan   
    
    $user = @(Get-ADUser $name -Properties objectSid)
    $sid = $user.objectSid
    if($sid)
    {
        $userUpd = "$updPath\UVHD-$sid.vhdx"  
        #see if UPD already exists
        if(test-path $userUpd)
        {
            #upd already exists
            Write-Host "Found UPD for $name - $sid" -ForegroundColor Cyan  
        }
        else {
            #UPD does not exist, copy template to new file
            Write-Host "Make UPD for $name - $sid" -ForegroundColor Cyan  
            Copy-Item -Path $templateUpd -Destination $userUpd
            timeout 5
        }
        #mount UPD for copying data
        write-host "Mount vhd for $name" -ForegroundColor Cyan  
        $disk = Mount-DiskImage -ImagePath $userUpd
        # create a new signature
        $randomSignature = [uint32](Get-Random -Maximum ([uint32]::MaxValue))
        $disk | Set-Disk -Signature $randomSignature
        #get drive letter
        $Drive = Get-Partition (Get-DiskImage -ImagePath $userUpd).Number | Get-Volume
        $drivePath = $Drive.DriveLetter + ":\"  
        Write-Host ("Drive path is " + $drivePath)  
        timeout 5
        #now run robocopy from old profile path to new UPD path
        write-host "Copy $($folder.fullname) to $drivePath"  
        timeout -seconds 5
        robocopy "$($folder.fullname)" $drivePath /copy:datso /r:0 /mt:64 /xj /xo /fft /xd "Application Data*" "Code Cache" /s /z  

        #dismount before continuing
        write-host "dismount vhd for $name " -ForegroundColor Cyan  
        Dismount-DiskImage -ImagePath $userUpd
        if($forUseOnSourceServer)
        {
            write-host "rename $($folder.fullname) folder " -ForegroundColor Cyan  
            Rename-Item -path $folder.fullname -newname ($folder.fullname + "-Copied")  
            #clear the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\{SID} key by renaming it
            write-host "rename ProfileList Registry Key " -ForegroundColor Cyan  
            Invoke-Command -ComputerName $sourceServer -ArgumentList $sid -ScriptBlock {  param($sid); Rename-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\$sid" -NewName ($sid + "-OLD") }  
        }
        timeout 5
    }
}

Wenn das funktionieren würde, hätte ich für jeden User schon mal UPD. Aber ob die dann in der Location von User Profile Disc auf dem RDS angenommen wird, hab ich keinen Ahnung.
ukulele-7
ukulele-7 14.12.2021 um 09:45:46 Uhr
Goto Top
Also erstmal UPD != VHD. Ich habe mit UPD keine Erfahrung wenn es um echte Profiledaten geht, nur mal getestet. Damals wurde davon abgeraten. Mit FSLogix habe ich gute Erfahrungen, vor allem bei sehr großen Profilen. Von wie vielen Daten reden wir überhaupt? Warum liegt das alles auf dem (einzigen?) RD-SH? Welche Art von Profil liegt da jetzt, local?

Auch verstehe ich nicht warum man sich hier mit einer Deadline bzw. einem festen Umsetzungszeitpunkt quält. Dadurch wirst du mit Sicherheit eine ganze Menge mehr Probleme bekommen als das der User 3 mal auf Weiter klickt um Outlook einzurichten. Warum wird nicht ein zweiter RD-SH parallel hin gestellt und erstmal ein Benutzer migriert?

Läuft der Broker und Lizenzserver auch auf dem RD-SH? Ist das eine virtuelle oder physische Maschine?
Madison
Madison 14.12.2021 um 10:07:35 Uhr
Goto Top
Zitat von @ukulele-7:

Also erstmal UPD != VHD. Ich habe mit UPD keine Erfahrung wenn es um echte Profiledaten geht, nur mal getestet. Damals wurde davon abgeraten. Mit FSLogix habe ich gute Erfahrungen, vor allem bei sehr großen Profilen. Von wie vielen Daten reden wir überhaupt? Warum liegt das alles auf dem (einzigen?) RD-SH? Welche Art von Profil liegt da jetzt, local?

- alle Files liegen unter C:\Users
- mehr als 100 Userprofile
- Eigene Dateien und Desktop liegen per GPO auf dem Fileserver
- es arbeiten meist ca. 30 - 40 User gleichzeitig
- alles lieht auf einem einzelnen Server - keine Ressourcen um Gateway Standalone und SH getrennt zu halten


Auch verstehe ich nicht warum man sich hier mit einer Deadline bzw. einem festen Umsetzungszeitpunkt quält. Dadurch wirst du mit Sicherheit eine ganze Menge mehr Probleme bekommen als das der User 3 mal auf Weiter klickt um Outlook einzurichten. Warum wird nicht ein zweiter RD-SH parallel hin gestellt und erstmal ein Benutzer migriert?


- ich wollte das zwischen den Feiertagen umsetzen, ist durch die Vorgesetzten nicht gewollt. habe morgen und Donnerstag aufs Auge gedrückt bekommen
- ja die User tun sich da schwer 3x zu klicken und die Signatur einrichten schafft auch nur 60% der User

Läuft der Broker und Lizenzserver auch auf dem RD-SH? Ist das eine virtuelle oder physische Maschine?

- Broker + Lizenzserver -> alles komplett (alle RDS Rollen auf einen Server) - Hyper-V VM
ukulele-7
ukulele-7 14.12.2021 um 10:28:51 Uhr
Goto Top
Zumindest hast du eine VM, du könntest also eine 2te VM (erstmal mit wenig Ressourcen) aufsetzen. Wenn auf dem RD-SH auch wieder Broker + Lizenzserver laufen sollen müsste das auch parallel gehen. Dann FSLogix auf beiden System gleich konfigurieren und die User nach einander migrieren.

Klar kann man auch alles in einer Hauruck Aktion machen, steht der Laden halt im Zweifelsfall.
Madison
Madison 14.12.2021 um 10:44:54 Uhr
Goto Top
Die User loggen sich morgens ein, arbeiten aber nur sporadisch daran. Mal Emails checken oder im Warensystem etwas eintragen oder in die Dokumentation. Die Ressourcen sollten reichen.

Wichtig ist das der RDS1 wieder IP und den Namen des alten Servers bekommt. Sonst verbinden einige ThinClients nicht mehr oder die User, die ihr RDP File gespeichert haben, wissen wieder nicht das der Name/IP sich geändert haben und mein Telefon steht nicht mehr still.

Hab auch schon überlegt ob ich das gleich anders mache:

RDS1 "Verbindungsbroker" + "Web-Access" + " Lizenzserver" (2 CPU, 8GB RAM)
RDS2 "RDS Sitzungshost" (4 CPU, 16GB RAM)
RDS3 "RDS Sitzungshost" (4 CPU, 16GB RAM)

Danach auf RDS2 + RDS3 die ganze Software parallel 1:1 installieren + FSLogix.

Zum Migrieren, müssen sich da die User anmelden oder kann ich das "Offline" machen?
Doskias
Doskias 14.12.2021 um 12:25:21 Uhr
Goto Top
Zitat von @Madison:
Hab auch schon überlegt ob ich das gleich anders mache:

RDS1 "Verbindungsbroker" + "Web-Access" + " Lizenzserver" (2 CPU, 8GB RAM)
RDS2 "RDS Sitzungshost" (4 CPU, 16GB RAM)
RDS3 "RDS Sitzungshost" (4 CPU, 16GB RAM)
Das klingt für mich nach einem guten Plan

Danach auf RDS2 + RDS3 die ganze Software parallel 1:1 installieren + FSLogix.
In der Konstellation hab ich allerdings wiederum keine Erfahrung mit FSLogix, sondern nur mit User Profile Disks

https://www.windowspro.de/wolfgang-sommergut/user-profile-disk-benutzerp ...

Daraus auch:
User Profile Disks lassen sich sowohl für Remotedesktop-Sessions als auch für nicht-persistente virtuelle Desktops (pooled Desktops) einsetzen. Die Funktions­weise ist dabei jeweils die gleiche: Der Administrator gibt ein Netzlaufwerk an, auf dem die Benutzerdaten in einer VHDX-Datei gespeichert werden. Der Session Host oder der virtuelle Desktop mounten die VHDX unterhalb des Verzeichnisses \users, so dass die Umleitung des Profils in eine virtuelle Harddisk für alle Anwendungen völlig transparent erfolgt.

Also erstmal UPD != VHD.
Würde ich so jetzt nichtpauschal sagen ;)

Wenn es mit FSLogix laufen soll gibt es auch dafür einen artikel
https://www.windowspro.de/wolfgang-sommergut/fslogix-alternative-zu-roam ...

Gruß
Doskias
ukulele-7
ukulele-7 14.12.2021 um 12:31:55 Uhr
Goto Top
Ich meine für FSLogix auch mal PowerShell gesehen zu haben mit der eine Profile Disk erzeugt werden kann (wie bei einer Useranmeldung wenn die Parameter richtig gesetzt sind), aber das finde ich grade nicht.

Das mit der IP ist natürlich unschön. Zeigen die ThinClients auf den NetBIOS Namen, den FQDN oder die IP?
DerWoWusste
DerWoWusste 14.12.2021 um 13:02:28 Uhr
Goto Top
Ich würde nicht neu installieren, sondern ein inplace-Upgrade machen. Das repariert alles.
Madison
Madison 14.12.2021 um 13:12:15 Uhr
Goto Top
Zitat von @ukulele-7:

Ich meine für FSLogix auch mal PowerShell gesehen zu haben mit der eine Profile Disk erzeugt werden kann (wie bei einer Useranmeldung wenn die Parameter richtig gesetzt sind), aber das finde ich grade nicht.

Das mit der IP ist natürlich unschön. Zeigen die ThinClients auf den NetBIOS Namen, den FQDN oder die IP?

Sie zeigen auf den NetBIOS Namen oder auf die IP. Das wollte ich immer mal noch umstellen, bin aber zu selten in den Außenstellen und per Remote komm ich nicht drauf. Wollte auf den TC´s mal noch SSH aktivieren das ich aus der Ferne das was Einstellen kann.
Madison
Madison 14.12.2021 um 13:15:40 Uhr
Goto Top
Zitat von @DerWoWusste:

Ich würde nicht neu installieren, sondern ein inplace-Upgrade machen. Das repariert alles.

Naja. Macht das nicht das DISM mit dem install.wim? Da bügelt er doch auch alles drüber.

Die Idee hatte ich auch schon. Weiß eben nicht wo der Fehler genau sitzt. Weder NAGIOS noch die Ereignisanzeige bringen was zum Vorschein. Hab bissl bedenken, wenn ich das drüber Bügel, das der Grundfehler doch noch irgendwo sitzt.

Ich behalte mal die alte VM. Falls etwas schief läuft, hau ich das alte Serverobjekt wieder ins AD rein über Arcserve UDP und starte die alte Kiste wieder. Da kann ich dann zwischen den Feiertagen immer mal noch antasten ob es was bringt, nochmal das Setup drüber zu bügeln.
DerWoWusste
DerWoWusste 14.12.2021 um 13:45:52 Uhr
Goto Top
Naja. Macht das nicht das DISM mit dem install.wim? Da bügelt er doch auch alles drüber.
Nein, das inplace-Upgrade macht weitaus mehr, als nur Dateien gegen heile Versionen zu tauschen.
Madison
Madison 15.12.2021 um 07:43:50 Uhr
Goto Top
Zitat von @DerWoWusste:

Naja. Macht das nicht das DISM mit dem install.wim? Da bügelt er doch auch alles drüber.
Nein, das inplace-Upgrade macht weitaus mehr, als nur Dateien gegen heile Versionen zu tauschen.

So. Eben Probiert, bei 37% hing er fest und dann Neustart und Drisch, die Kiste hat wieder den schönen Fehler das er sofort nach Login abkackt und neu startet. Nicht mal die Installation ist komplett durchgelaufen...
DerWoWusste
DerWoWusste 15.12.2021 um 11:25:08 Uhr
Goto Top
Tja, meine Inplace Upgrades (hunderte, wenn nicht tausende) laufen immer.
Dann neu das Ganze.
Madison
Madison 16.12.2021 aktualisiert um 09:33:06 Uhr
Goto Top
So. Wie gesagt, da das Inplace Upgrade ja nicht funktioniert hat und der Server wieder neu gestartet ist und nicht wieder hoch kam, musste ich also den Weg über "Neuaufsetzen" gehen.

Die meiste Zeit hat das Kopieren der Users gebraucht. Da sind locker 8h ins Land gegangen. Zum Glück kam ich immer noch per Powershell drauf. Schade das ich nicht nochmal auf den Server per RDP kam, sonst hätte ich das vorher alles bereinigt.

Nach dem Aufsetzen der neuen VM und Windows 2019 Installation + Updates hab ich dann per Roboycopy die User zurück kopiert, dazu noch den gesicherten Registry-Wert "ProfileList" importiert. Serverneustart. RDP Dienste installiert und den ganzen Kram eingerichtet + Software installiert. Profile bereinigt. Feuer frei.

Übernahme hat 1a geklappt. Die Hütte rennt, paar Testuser testen jetzt 2h Stunden und dann ist Freigabe für alle.

Der alte Server brauchte zum Booten 8 bis 20 Minuten und dann war ja jedes Mal der Absturz sobald man sich einloggt. Der neue bootet in 39 Sekunden und zickt nicht rum.

Backup noch einrichten und dann sollte alles passen.

Vielen Dank an alle die hier Tipps hatten mich unterstützt haben.

Gruß Madison