Jump to content

florian_ried

Members
  • Gesamte Inhalte

    49
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von florian_ried

  1. 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
     

    2018-07-11_12-07-38.png

     

     

    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....

  2. 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.

  3. 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.

  4. 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 

     

     

     

     

     

     

     

     

     

     

     

     

  5. Lizenzprobleme liegen auf keinen Servern vor

    es sind bisher lediglich virtuallisierte Server hiervon betroffen

    aktuelle VM-Ware Tools etc. installiert

     

    Problem tritt plötzlich sehr gehäuft auf

     

    unterschiedliche Betriebssysteme hiervon betroffen

    Windows Server 2012 R2

    Windows Server 2016 Standard

     

    Die Sitzungen verbinden sich in den aller meisten Fällen automatisch erneut.

    Nur ganz selten wird die Verbindung während eines Abbruchs nicht mehr hergestellt.

     

    Gestern alle betroffenen Server komplett gepatched und anschliessend neu gestartet

    Problem tritt weiterhin auf

  6. Hallo zusammen,

     

    wir haben die gleichen Probleme mit unseren Windows 2012 R2 Terminal-Servern.

    Mein Vorgänger hat nie was aufgeräumt so dass es bei uns einen großen Wildwuchs bezüglich Treibern, Druckerservern, Verteilungsmethoden usw. gibt.

    Ich werde die Vorschläge hier Schritt für Schritt abarbeiten und testen.

     

    Das schwierigste an den Problemen ist die Vermischung der Ursachen bzw. das die Sympthome sich sehr ähneln.

     

    Wenn man PDF-Dateien direkt aus einer E-Mail von Outlook per Doppelklick öffnet wurde sie bei uns oftmals nicht gedruck. Manchmal ohne jede Meldung und manchmal mit der Meldung : „Das Dokument konnte nicht gedruckt werden - Keine zum Drucken ausgewählten Seiten vorhanden“.

     

    Folgende Einstellung in Acrobat Reader DC haben bei uns eine Verbesserung gebracht:

    • Bearbeiten / "Voreinstellungen..." / "Sicherheit (erweitert)"
    • Die Hacken bei "Geschützten Modus beim Start aktivieren" und bei "Erweiterte Sicherheit aktivieren" entfernen.

    Mir ist klar, dass dadurch die Sicherheit verringert wird, aber ca. 30% unserer PDF-Druckprobleme können durch die beiden Optioenen behoben werden.

    Ich überlege schon die Reg-Keys zu ermitteln und per GPP für alle zu setzen.

    Ich hoffe das hilft Dir Florian. Aber Anwendung auf eigene Gefahr. ;)

     

    LG Kaltokri

     

    Nachtrag:

    Die Windows Foto und Faxanzeige zeigt auch gerne mal Drucker nicht an.

    Als Workaround öffnen wir TIF-Dateien jetzt mit IrfanView. Damit gab es diese Probleme nicht mehr.

    Aber es druckt teilweise deutlich langsamer.

    VIelen Dank für diesen Tipp!

     

    Solltest du die Reg-Keys gefunden haben, kannst du mir diese gerne noch hier mitteilen.

     

    Unsere Probleme wurden bereits größtenteils behoben.

     

    Wirklich geholfen hat folgendes:

     

    I wound up opening a ticket with Microsoft which resolve my issue. Apparently there are issues with 2012 R2 caching locally rendered network printers. Microsoft also recommended disabling local rendered printing via GPO. Resolution: We did the initial troubleshooting and performed the below mentioned steps : Remove entries (sub keys) from all below locations : 1.)HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\V4 Connections 2.)HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers (recreate) string value: DefaultSpoolDirectory C:\Windows\system32\spool\PRINTERS dword value: LANGIDOfLastDefaultDevmode 409 hex 3.) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\servers 4.) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider Download PSTOOLS or PSEXEC. http://technet.microsoft.com/en-us/sysinternals/bb897553 Open command prompt with admin priviledges Run the below command from the folder where you download PSEXEC to open registry and delete printenum entries using system account psexec -s -i regedit.exe -s Run the remote process in the System account. -i Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is specified the process runs in the console session. >> Deleted the corresponding entry from the following location :

    5.) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SWD\PRINTENUM 6.) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{0ecef634-6ef0-472a-8085-5ad023ecbccd} 7.) Open printers, hit F5 refesh . 8.) Restart the server.

  7. Was sollen die Sitzungshosts denn jetzt noch machen? Sitzungshost reicht doch ;)

     

     

    Auf den Connectionbroker-Servern oder eben auf dem Connectionbroker-Server?

    (Das ist aber auch so ein Punkt, über den man sich idealerweise vorher Gedanken macht.)

     

    Ich war damals beim Aufbau der Umgebung nicht dabei.

     

    Deswegen ist es leider nicht möglich gewesen dies von Anfang an zu planen.

     

    Einen eigenen Server für Connectionbroker gibt es nicht? Es sollte ja somit ausreichen, wenn ich den Verbindungsbroker auf einem Server installiere.

     

    Verstehe ich das richtig?

  8.  

    Das kommt ganz klar drauf an. Die Rollen sollten doch schon entsprechend da sein? Theoretisch musst du "nur" die Server aus der Farm nehmen und zu einer neuen Farm hinzufügen und ggfs. die Clients anpassen.

     

     

    Das kommt ebenfalls drauf an. Du kannst jedes AD Benutzer Objekt von Hand anpacken oder per Script oder per GPO. Vielleicht sind ja auch Profile-Disks was tolles..
     

     

    Nein.

     

    Auf allen Servern ist bisher nur der Remotedesktop Sitzungshost installiert.

     

    Auf welchem Server würdest du mir denn empfehlen den Verbindungsbroker zu installieren, wenn nicht auf dem DC?

  9.  

    Vielleicht hätte man das Design vorher mal hinterfragen sollen ;)

     

    Wo ist das Problem:

     

    • Test User anlegen
    • Mit Test User am Server anmelden
    • Ein paar Dateien aufm Desktop unter Dokumente anlegen, Favoriten im IE anlegen, eine Applikation einrichten
    • Test User am Server abmelden
    • Im AD Objekt des Test User ein Remotedesktopdienste-Profil eintragen
    • Mit Test User am Server anmelden
    • Prüfen ob die Daten und Einstellungen korrekt sind
    • Test User am Server abmelden
    • Test User an anderem Server anmelden
    • Prüfen ob die Daten und Einstellungen korrekt sind

     

    Vielen Dank für die Aufstellung!

     

    Der Test war erfolgreich.

     

    Jetzt stellt sich mir nur noch folgende Frage: Angenommen ich fange mit der Umstellung an. Wie gehe ich da am besten vor? Zuerst muss ich die Rollen alle installieren und die Server zu einer Farm hinzufügen. Anschließend erstelle ich dann die Benutzerprofilzuordnung.

     

    Wie findet dann der Umzug eines jeden einzelnen Profils statt? Muss ich dies manuell über das AD vornehmen oder wie ist hier der Ablauf....

     

    Vielen Dank im Voraus!

     

    Was meint ihr. Ist es in meiner Umgebung sinnvoll, den Domänencontroller als Verbindungsbroker festzulegen?

  10. Profilverwaltung? Terminaldiensteprofil?

     

    Dazu hatte ich (in einem anderen Thread) bereits geschrieben, dass MS dich wohl beschützen will. Mach einen Call bei MS auf und es wird Klarheit geben.

     

    Da dürfte der oben angesprochene Call bei MS die Klarheit bringen.

     

    Okay dann werde ich mich hier wohl an MS wenden müssen...

     

    Bzgl. Profilverwaltung und Terminaldiensteprofil

     

    Ist es möglich die bereits angelegten lokal gespeicherten Benutzerprofile auf den 5 Servern auf eine zentrale Netzwerkfreigabe umzuziehen?

    Somit könnte ich eine Sammlung erstellen und z.B. DNS-Roundrobin verwenden.

  11. Ich finde dieses Sammlungswirrwar, wie Dunkelmann, ebenfalls suboptimal.

    Warum willst du die User auf bestimmten Hosts festnageln? Grade wenn die Apps per RemoteApp kommen erschließt sich mir der Sinn nicht.

     

    Das du den Feed scheinbar nicht per GPO an die RDS verteilen kannst hast du doch schon gemerkt ;)

     

    Mit Citrix XenApp / XenDesktop ist das relativ simpel realisierbar.

     

    Ich bin gezwungen die User auf einen Host festzunageln, da die Server 2012 R2 bereits im Einsatz sind und die User ihr jeweiliges Profil bereits auf dem Server angelegt haben.

     

    Es kommen nicht alle Apps per RemoteApp. Standard-Software wie Office etc. ist auf jedem Server explizit installiert.

     

     

    Dass der Feed nicht per GPO an die RDS verteilt werden kann macht aber nach langer Sammlung von Informationen absolut keinen Sinn.

    Dies wird auf jeden Fall unterstützt von Microsoft und sollte möglich sein!

  12. Moin,

     

    ohne die Umgebung und die Anforderungen zu kennen, lässt sich schwer eine Empfehlung abgeben.

    Ich finde das beschriebene Design mit 5 Servern, Sicherheitsgruppen usw. eher suboptimal. Ich wäre zu faul so eine Umgebung pflegen zu wollen :cool:

     

    Vielleicht solltest Du mal das TLG für RDS nachbauen und Dich mit der Funktionsweise von Broker, WebAccess usw. vertraut machen. Das könnte eventuell auch die Unklarheiten im anderen Thread beseitigen.

    https://technet.microsoft.com/en-us/library/hh831610(v=ws.11).aspx

     Ich habe mir die letzten Tage Zeit genommen mich mit dem Thema RDS 2012 R2 vertraut zu machen.

     

    Ist folgende Überlegung umzusetzen....

     

    Umgebung:

    Domänencontroller: DC01, DC02

    S1-S5: Desktopbereitstellung (Alle Benutzer, die mit einem ThinClient arbeiten)

    RemoteApp: Application Server (Verteilung von Software auf S1-S5, sowie auf die vollwertigen Windows 10 Clients)

     

    Installation der Rollen:

    Domänencontroller: Verbindungsbroker

    S1-S5: Sitzungshost

    RemoteApp: Sitzungshost, WebAccess

     

    Konfiguration der Sammlungen:

    Sammlung Server 1                    Hostserver: S1                   Berechtigung: S1 Benutzer

    Sammlung Server 2                    Hostserver: S2                   Berechtigung: S2 Benutzer

    Sammlung Server 3                    Hostserver: S3                   Berechtigung: S3 Benutzer

    Sammlung Server 4                    Hostserver: S4                   Berechtigung: S4Benutzer

    Sammlung Server 5                    Hostserver: S5                   Berechtigung: S5 Benutzer

    Sammlung RemoteApp               Hostserver:RemoteApp      Berechtigung: Domänen Benutzer

    • auf die jeweiligen RemoteApp Programme können individuelle Berechtigungen gesetzt werden

     

    Ist dies so umzusetzen? Ist es vorallem so möglich, dass die veröffentlichten Programme auf dem Application Server via GPO (Standard-URL) an S1-S5 und Windows 10 Clients weitergegeben werden können??..

     

    Vielen Dank im Voraus!!

  13. Am IP Bereich wird es nicht grundsätzlich liegen. Außer natürlich, es steht eine Firewall dazwischen, die https blockiert.

     

    In den url ist nur der Hostname, nicht der FQDN, angegeben. Was passiert, wenn Du den FQDN nutzt?

    Grundsätzlich würde ich für alle veröffentlichten RDS Dienste den FQDN nutzen.

     

    Das Zertifikat für die RDS Dienste sollte natürlich auch zu den FQDN der Server passen.

    Auch mit dem FQDN hatte ich leider keinen Erfolg.

     

    Für mich ist es unerklärlich wieso es auf den physikalischen RDS nicht funktioniert. Auf der Test VM allerdings schon.

     

    Auf den physikalischen Servern erscheint weiterhin im Ereignislog für jeden Benutzer die Meldung:

     

    Die Installation der Standardverbindung wurde abgebrochen. Standardverbindungen können nicht auf Systemen verwendet werden, die Teil einer Bereitstellung mit Remotedesktopdiensten sind.

     

    Benutzer: Domäne\Benutzername

     

  14. Folgendes ist mir jetzt noch aufgefallen

     

    Die physikalischen Server befinden sich im Netz: 10.1.22.XY, 255.255.192.0

    Der virtualisierte Application Server ist im Netz: 10.1.82.XY, 255.255.255.192

     

     

    Ich habe zum Test eine VM erstellt im Netzbereich 10.1.82.XY, 255.255.255.192

    An diesem Server habe ich lokal in der GPO die Standard URL eingetragen.

    Nach einem Neustart wird diese URL auch korrekt gezogen.

     

    Kann es am IP-Bereich liegen, dass diese URL nicht gezogen wird an den physikalischen Servern??

    Dann würde sich allerdings die Frage stellen wieso das manuelle verknüpfen funktioniert.

     

    Es handel sich bei beiden um Win Server 2012 R2

  15. Ich habe mir das ganze jetzt nochmal angesehen.

     

    Mit einem Benutzer angemeldet auf einem Terminalserver 2012 R2. Manuell die URL eingetragen

     

    --> sieht die Registry wie folgt aus: https://abload.de/img/1suu7e.jpg

     

    Wie soll ich da jetzt am besten vorgehen?

     

    Es sind ja auch benutzerpsezifische Inhalte in den Werten. Wie gehe ich vor um per Registry an alle Benutzer die Standard URL zu verteilen.

     

     

    Ich habe es bereits auch schon per Anmeldescript versucht. Dies hat leider auch nicht funktioniert.

     

    Dieser Artikel beschreibt ziemlich gut mein Problem...

     

    https://rcmtech.wordpress.com/2013/10/07/remoteapp-default-connection-url-group-policy-not-working/

  16. Das macht je nachdem schon Sinn. Wäre b***d wenn am RDS und am Client PC die gleiche GPO den WebFeed einträgt und der User am RDS dann dauernd versucht seine eigene Session ggfs. zu Übernehmen.

    Evtl. möchte dich MS hier einfach nur schützen.

     

    Nicht das du dadurch den Unendlichen Unwahrscheinlichkeitsdrive startest ;)

     

    Okay das stimmt ;-)

     

    Leider habe ich in der Registry den betroffenen Eintrag nicht finden können...

     

    Falls wer hier bereits Erfahrungen gemacht hat wäre es nett wenn er mir dies mitteilen könnte.

  17. Hallo zusammen,

     

    wir verwenden bei uns aktuell 5 Terminalserver (WinServer 2012 R2).

     

    Auf diesen 5 Terminalservern arbeiten jeweils ca. 25.30 Benutzer.

     

    Es handel sich um physikalische Server mit hoher Leistung. Bisher ist auf den Terminalservern als Rolle lediglich der Remotedesktop-Sitzungshost installiert.

     

    Die Benutzerprofile liegen lokal auf den Servern.

     

    Es gibt für jeden Server Sicherheitsgruppen alias "Benutzer Server 1" usw.

     

    Somit ist gewährleistet, dass sich ein Benutzer nur auf dem für ihn zugewiesenen Server anmelden kann und das Profil nur einmal erstellt wird.

     

    Die Benutzer verbinden sich per freeRDP auf den jeweiligen Server.

     

    Ich sehe das ganze so, dass die 5 Terminalserver an sich noch nicht wirklich als Terminalserver konfiguriert sind.

     

    Würde es sich empfehlen die 5 Server in einer Farm als RDS zu konfigurieren? (Lizenzierung, Verbindungsbroker usw.)

    Was würden sich für Vorteile ergeben?

     

    Bisher kann lokal auf einem einzigen Server z.B. nur über den TaskManager Einsicht auf die angemeldeten Benutzer genommen werden..

  18. Hi,

     

    du hast Bereitstellung 1 mit einer Farm aus 5 RDS, wo der User eine Desktop Session bekommt?

    Dann hast du eine Bereitstellung 2 wo es eine Remote-App Sammlung gibt?

    Die App soll jetzt per Feed an die Bereitstellung 1?

     

    Ist das der gleiche Broker oder 2 unterschiedliche Broker?

    Kann der User den Feed von Hand einfügen?

     

    Zur Not setz den Feed per GPP Registry ;)

     

    Gruß

    Jan

     

    Genau wie von dir beschrieben ist es auch :)

     

    2 unterschiedliche Broker.

     

    Der User kann manuell die URL eintragen und auch auf die Apps zugreifen.

     

    Ich kann es gerne testen, die URL per Registry zu vergeben....

    Kannst du mir sagen wo in der Registry ich hier den Eintrag setzen muss?....

  19. Moin,

     

    mit der url wird den Clients, die die Remotedesktop Bereitstellung nutzen, das Webfeed mit den RemoteApps zugewiesen.

    Die RDS Server sind Bestandteil der Bereistellung und nicht Nutzer der Bereitstellung ;)

     

    Ich verstehe nicht ganz, was du mir hiermit sagen möchtest :confused: ;)

     

    Die 5 RDS Server sollen eben schon als Nutzer der Bereitstellung gesehen werden.

     

    Bestandteil der Bereitstellung für die Anwendungen ist der Application Server

  20. Okay, machen wir es kurz, Umgebung:

    • 5 Desktop (Office) Server auf Basis Windows Server 2012 R2 (physikalische Server)
    • 1 Application Server auf Basis Windows Server 2012 R2 (virtuelle Maschine - vmWare)
    • Applikationen vom Application Server auf den Desktop (Office-Server) freigeben

     

    Nun bietet sich dafür die (seit Windows 8 und 2012) vorhandene Option „URL für Standardverbindung angeben“ aus der GPO „Benutzerkonfiguration -> Richtlinien ->Administrative Vorlagen -> Windows-Komponenten -> Remotedesktopdienste-> RemoteApp- und Desktopverbindungen“ an.

     

    Die GPO sollte jetzt die URL automatisch auf dem Desktop konfigurieren. Doch was passiert?

     

    Ereignislog: „Die Installation der Standardverbindung wurde abgebrochen. Standardverbindungen können nicht auf Systemen verwendet werden, die Teil einer Bereitstellung mit Remotedesktopdiensten sind.

     

    Ist das euer Ernst? WARUM? Gerade das will man doch machen!

×
×
  • Neu erstellen...