RDS 2016 Migrationskonzept

[florian_ried 0]

Guten Tag zusammen,

 

IST-Zustand:

 

5 physikalische Server

mit folgender Hardware

 

Intel Cottonwood Pass S2600CW2 S2011-3

Intel Remote Management Modul 4 Lite

2x Intel Xeon E5-2620v3 2,4 6/12 1866

8x8GB DDR4 FSB2133 288-pin 

2x 480 GB Samsung SM663 MX MLC 2,5" SATA3 (RAID1)

 

OS: Windows Server 2012 R2

 

Installierte Rollen:

• Remotedesktop-Sitzungshost

 

Auf allen 5 Servern ist lediglich der Remotedesktop-Sitzungshost installiert. Es gibt 5 Sicherheitsgruppen. 

 

Alle 5 Server wurden damals mit identischer Software aufgesetzt. Sind also von der Konfiguration komplett identisch.

 

An Software ist auf diesen 5 physikalischen Servern lediglich Standard-Software wie Office, Adobe Reader usw. installiert. 

 

Absolut keine Software, die hohe Performance oder Grafikspeicher benötigt.

 

Unser Warenwirtschaftssystem läuft auf eigenen Terminalservern, womit sich die Benutzer wieder per RDP von oben genannten Servern verbinden.

 

Beispiel: 

 

Server 1 --> Sicherheitsgruppe: Benutzer Server 1

Server 2 --> Sicherheitsgruppe: Benutzer Server 2

 

Den jeweiligen Benutzern ist eine Sicherheitsgruppe zugeordnet, sodass dieser sich lediglich nur mit einem Terminalserver verbinden kann.

 

Als Endgerät verwenden unsere Benutzer Thin Clients der Firma Rangee mit freeRDP. 

 

Die Verbindung von den Thin Clients auf den Windows Server 2012 R2 erfolgt über RDP. 

 

Der "Lastenausgleich" in diesem Moment wird also von uns manuell vorgenommen. 

 

Die Benutzerprofile liegen auf den jeweiligen physikalischen Terminalservern lokal.

 

Der Lizenzserver wurden den Servern per Gruppenrichtlinie verknüpft und ist ein Windows Server 2016, welcher die RDP CALS zur Verfügung stellt. 

 

Zukünftiges Konzept (Frage an euch  )

 

Zusätzlich zu den 5 oben genannten physikalischen Servern haben wir uns folgenden neu angeschafft:

 

Intel® Sawtooth Pass C624 S2600STB S3647
Intel® Remote Management Modul 4 Lite v2
2 x Intel® Xeon® 4110 2,1 8/16 2400
4 x 16GB DDR4 FSB2666 288-pin REG x4 1R
LSI 9361-4i 4Port 12Gb/s PCI-E x8 MD2
Cache Vault NAND Speicher LSI 9361/9380
2 x 480GB Intel SSD 6Gb/s SATA S4500 2,5" (RAID1)

 

OS: Windows Server 2016 Standard

 

Der Hintergrund ist, dass wir bereits einige Benutzer in die Cloud (Office 365) migriert haben. 

 

Auf den 5 physikalischen Terminalservern ist  Office 2013 installiert. 

 

Jetzt hatten wir natürlich den Fall, dass einige Benutzer auf einem Office-Server bereits migriert wurden, andere aber eben noch OnPrem sind. 

 

Alle Benutzer gleichzeitig können aus lizenztechnischen Gründen nicht in die Cloud migriert werden.

 

Aus diesem Grunde wurde auch der neue Terminalserver beschafft. Auf diesem soll Office 365 Click to Run installiert werden.

 

Alle Benutzer, die dann bereits in in die Cloud (Office 365) migriert wurden, werden auf den neu angeschafften RDS-Server umgezogen.

 

In naher Zukunft ist natürlich das Ziel, alle Benutzer in der Cloud (Office 365) zu haben.

 

Sobald einer der alten physikalischen Servern von allen Benutzern freigeräumt wurde, soll dieser ebenfalls als Windows Server 2016 aufgesetzt werden.

 

Ich weiß, dass es mit Windows Server 2016 in Hinsicht auf RDS wieder einige Änderungen gab. 

 

Welche Variante wäre für uns am einfachsten umzusetzen?

 

Sollten wir eine RDS-Farm anlegen? Leider ist das Wissen hierüber noch nicht so vorhanden. 

 

Über mögliche sinnvolle Szenarien, die vielleicht bereits jemand in der Praxis einsetzt wäre ich sehr dankbar.

 

Ist in unserem Fall ein Lastenausgleich überhaupt sinnvoll, wenn bisher das Profil lokal auf allen Servern abgelegt wurde.

 

Gibt es schnelle Möglichkeiten, um ein Benutzerprofil vom "alten, WIN 2012 R2" Server auf den Win 2016 Server umzuziehen?

 

 

Viele Grüße

Florian Ried 

 

 

 

 

 

 

 

 

 

 

 

 

[MurdocX 957]

Am 9.7.2018 um 17:34 schrieb florian_ried:

Gibt es schnelle Möglichkeiten, um ein Benutzerprofil vom "alten, WIN 2012 R2" Server auf den Win 2016 Server umzuziehen?

Meines Wissens werden die Profile mit der ersten Anmeldung am RDS autom. migriert.

 

Am 9.7.2018 um 17:34 schrieb florian_ried:

Sollten wir eine RDS-Farm anlegen?

Könnt Ihr machen. Aktuell benötigt Ihr dann aber die RDS-Cals für beide Server..

Ich habe auch gelesen: 

Zitat

Die Office Komponente in Office 365 ProPlus, Office 365 Enterprise E3 und Office 365 Enterprise E5 erlaubt es dem lizenzierten Nutzer das Office auf bis zu 15 Endgeräten (5 Smartphones, 5 Tablets und 5 PCs oder Macs) und zusätzlich auf beliebig vielen RDS Host im Unternehmensnetzwerk zu installieren und mit den Lizenzierten Nutzern darauf zuzugreifen.

 

Die Office 365 Business Varianten beinhalten nicht das Recht auf Office auf einem RDS Host zuzugreifen!

 

[florian_ried 0]

vor 4 Minuten schrieb MurdocX:

Meines Wissens werden die Profile mit der ersten Anmeldung am RDS autom. migriert.

Mir fehlt aktuell der Hintergedanke wie genau dies funktionieren soll. Ein Benutzer meldet sich am neu aufgesetzten Server an. Warum genau soll das Profil automatisch von einem der 5 vorherigen Terminalserver migriert werden?

 

vor 4 Minuten schrieb MurdocX:

Könnt Ihr machen. Aktuell benötigt Ihr dann aber die RDS-Cals für beide Server..

Ich habe auch gelesen: 

Die Office 365 Business Varianten beinhalten nicht das Recht auf Office auf einem RDS Host zuzugreifen!

Unsere Benutzer verwenden alle eine Office 365 Enterprise E3  Lizenz. Somit sollten wir hier keine Probleme haben.

[MurdocX 957]

Mit Roaming Profile funktioniert das. Dementsprechend gehe ich aus, dass Ihr das nicht im Einsatz habt.

[florian_ried 0]

vor 8 Minuten schrieb MurdocX:

Könnt Ihr machen. Aktuell benötigt Ihr dann aber die RDS-Cals für beide Server..

 

 

Die Frage für uns wäre ob es sich lohnt eine RDS-Farm zu bilden... Entstehen hieraus für uns Vorteile?

Der Profilpfad der Benutzer wird weiterhin der jeweilige lokale physikalische Server sein.

Genau aus diesem Grund ist mir nicht klar, ob wir dann überhaupt Vorteile hätten, wenn wir eine Farm erstellen.

 

Ich kenne von einem Windows Server 2008 den Remotedesktopdienste-Manager.

 

Mit diesem verknüpfe ich aktuell schon die WIN2012 Terminalserver um zum Beispiel an alle Benutzer gleichzeitig Nachrichten senden zu können.

 

Hätten wir bzgl. Verwaltungsaufwand einen Vorteil wenn wir eine Farm bilden. Und wenn ja, wie genau müssten wir diese Farm aufbauen, wenn wir weiterhin das Konzept fahren, den Latenausgleich selbständig weiterhin durch unsere AD-Gruppen vorzunehmen.

[Gadget 37]

Hi Florian,

 

Am 9.7.2018 um 17:34 schrieb florian_ried:

Sollten wir eine RDS-Farm anlegen? Leider ist das Wissen hierüber noch nicht so vorhanden. 

Gibt es schnelle Möglichkeiten, um ein Benutzerprofil vom "alten, WIN 2012 R2" Server auf den Win 2016 Server umzuziehen?

 

 

Da die Implementierung von RDS Farmen einer meiner Hauptaufgaben die letzten Jahre war...

kann ich dir nur wärmstens empfehlen die Konfiguration nach Microsoft Best Practice zu machen, du gewinnst damit Ausfallsicherheit und Performance!

 

1. Keine Roaming Profiles mehr verwenden - User Profile Disks bieten diverse Vorteile und sollten defintiv zum Einsatz kommen. (Fehleranfälligkeit, Performance etc.)
2. DNS Konfiguration sollte gut durchdacht werden Split-DNS Konfiguration beachten
   Bitte diesen Artikel: https://www.rdsgurus.com/windows-2012-r2-how-to-create-a-mostly-seamless-logon-experience-for-your-remote-desktop-services-environment/  "VOLLSTÄNDIG" durchlesen und verstehen!
   Gilt exakt so auch für 2016
3. Keine RDP Files verteilen bitte XML Feed Veröffentlichung verwenden
4. Für die ThinClients Kompatibilitätskonfiguration "DefaultTsvUrl" einrichten sodass ein Lastenausgleich über den Broker möglich ist (Siehe Bild-Anhang)
   https://blogs.technet.microsoft.com/askperf/2015/06/11/walkthrough-on-session-hint-tsvurl-on-windows-server-2012/
   
5. Weitergehende Literatur und Infos zur Fortbildung verwenden
   https://www.video2brain.com/de/videotraining/windows-server-2016-grundkurs-remotedesktopdienste
    

PS: Rückfrage am Rande warum in Hardware und nicht auf nem Hypervisor bzw. virtuell?

 

Gruß Gadget
 

[florian_ried 0]

Am 11.7.2018 um 12:12 schrieb Gadget:

Hi Florian,

 

 

Da die Implementierung von RDS Farmen einer meiner Hauptaufgaben die letzten Jahre war...

kann ich dir nur wärmstens empfehlen die Konfiguration nach Microsoft Best Practice zu machen, du gewinnst damit Ausfallsicherheit und Performance!

 

1. Keine Roaming Profiles mehr verwenden - User Profile Disks bieten diverse Vorteile und sollten defintiv zum Einsatz kommen. (Fehleranfälligkeit, Performance etc.)
2. DNS Konfiguration sollte gut durchdacht werden Split-DNS Konfiguration beachten
   Bitte diesen Artikel: https://www.rdsgurus.com/windows-2012-r2-how-to-create-a-mostly-seamless-logon-experience-for-your-remote-desktop-services-environment/  "VOLLSTÄNDIG" durchlesen und verstehen!
   Gilt exakt so auch für 2016
3. Keine RDP Files verteilen bitte XML Feed Veröffentlichung verwenden
4. Für die ThinClients Kompatibilitätskonfiguration "DefaultTsvUrl" einrichten sodass ein Lastenausgleich über den Broker möglich ist (Siehe Bild-Anhang)
   https://blogs.technet.microsoft.com/askperf/2015/06/11/walkthrough-on-session-hint-tsvurl-on-windows-server-2012/
5. Weitergehende Literatur und Infos zur Fortbildung verwenden
   https://www.video2brain.com/de/videotraining/windows-server-2016-grundkurs-remotedesktopdienste
    

PS: Rückfrage am Rande warum in Hardware und nicht auf nem Hypervisor bzw. virtuell?

 

Gruß Gadget
 

 

 

Hi Gadget, 

 

erstmal vielen Dank für deine Antwort. Echt hilfreich!!

 

Es ist ja mal wieder einige Zeit vergangen. Wir haben bereits 2 WinServer 2016 Terminalserver am laufen. 

Die Benutzerprofile wurden allerdings alle manuell migriert von den WinServer 2012. 

 

Die Profile sind lokal auf den schnellen physikalischen Platten gespeichert. Das möchten wir auch weiterhin so machen. 

 

Ich bin aktuell auf der Suche nach einer Lösung uns die manuelle Migration der Benutzerprofile von Win2012 to Win2016 zu ersparen. 

Während eines Seminares bin ich auf USMT gestoßen. Laut Referrent ist dies auch für Windows Server einsetzbar. 

Ich habe es ausprobiert. Allerdings spuckt die PowerShell leider nach dem .\scanstate aus, dass USMT auf Servern nicht verwendet werden kann.

 

Mir ist absolut klar, dass RDS viel effizienter verwendet werden kann. 

Unsere physikalischen Maschinen werden auf lange Sicht abgeschafft und durch Windows Virtual Desktop in der Azure Cloud ersetzt. 

 

Um die Zeit zu überbrücken möchten wir aber noch die Migration auf Windows Server 2016 durchführen, wo dann auch Office 365 Pro Plus verwendet wird. 

 

 Gibt es anderweitig nützliche Tools wo wir unser Vorhaben schnell umsetzen können und uns die manuelle Migration für die ausstehenden Server ersparen können....