none
Server 2012R2 - RDS Farm mit User Profil Disk - Sporadische TEMP Profile RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo liebe Community,

    ich habe im März eine RDS Farm auf Basis Server 2012R bei einem Kunden in Betrieb genommen und nutze hierfür auch die User Profil Disks (UPD).
    Leider kommt es täglich vor, das einige User ein TEMP Profil erhalten. Workaround bisher ist, dass die User sich wieder abmelden, nochmal anmelden und zu 95% funktioniert es dann, da sie auf den anderen RDS Host geschmissen werden.

    Erstmal zur Konfiguration:

    • Alles virtuelle Maschinen auf Basis 2012 HyperV in einem Cluster
    • 2x HyperV Host per redundantem FC 8 GBit an Enterprise Storage mit SAS Platten
    • Netzwerk zwischen den HyperV und dem Backbone Switch ist 10Gbit
    • RDS Farm: 2x Host 2012R2, 1x 2012R2 als Broker, TS Lizenzserver, RDWeb, RDGateway und Freigabe UPD
    • Die Farm ist nach Anleitung angelegt und benutzt DNS Round Robin zur Verteilung der User (bzw. technologisch macht es eh der Broker, egal welchen Host der Client anspricht mit dem Farmnamen)
    • RD Clients sind heterogen, sprich von XP bis Win 8.1 alles
    • ca. 100 User
    • Programme: Office 2013, IE, FF, paar Forschungsprogramme
    • DNS Redundanz über 2 DC's

    Ich habe im Netz schon Stunden verbracht dazu, keine Lösung. O-Ton (nicht offiziell von Microsoft): Bug ist Microsoft bekannt, jedoch keine Lösung. Das möchte ich so nicht glauben.

    Was ich bisher probiert habe:

    • Wenn ich einen Host in der Sammlung deaktiviere für den Zugriff, und somit alle User vom Broker auf einen einzigen Server geschmissen werden, tritt der Fehler nicht auf o_O
      Sobald ich den zweiten Server wieder dazu schalte, geht es wieder los.
    • Die TEMP Profile landen in der Registry der Hosts als .bak Profile. Diese lösche ich regelmäßig, bzw. mittlerweile habe ich ein PS Script, welches dies erledigt. Das reicht auch, dass User, welche auf diesem Host mal ein TEMP hatten, beim nächsten mal eventuell wieder ihr normales Profil erhalten.
    • Die Sammlung habe ich mittlerweile so konfiguriert, dass die User nach 8 Stunden Trennung abgemeldet werden, so dass die UPDs nicht ewig offen gehalten werden müssen.
    • Ich habe schon geprüft, ob eventuell die UPDs der betroffenen User noch vom anderen Host gehalten werden, bzw. nicht sauber geschlossen wurden. Das kann ich nicht bestätigen. Bis auf einen einzigen Fall in der Vergangenheit, wurden und werden die UPDs sauber vom Host getrennt, wenn der User sich abmeldet.
    • Die Freigabeberechtigungen und NTFS Berechtigungen auf dem UPD-Share und den UPDs passen definitiv.
    • User-seitig ist kein bestimmtes Muster zu erkennen, es betrifft beide Hosts. Manche User trifft es öfter, manche hat es bisher nur einmal getroffen, andere wiederum gar nicht. Es spielt auch keine Rolle, ob der Client XP oder Win7 hat.

    Beispiel Eventeintrag, wenn es ein TEMP Profil gibt:

    Anfrage User athiele über den DNS Namen "Farm" --> An Host 1:

    • Protokollname: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
      Quelle:        Microsoft-Windows-TerminalServices-LocalSessionManager
      Datum:         18.05.2015 11:57:08
      Ereignis-ID:   41
      Aufgabenkategorie:Keine
      Ebene:         Informationen
      Schlüsselwörter:
      Benutzer:      SYSTEM
      Computer:      Host1.*****.de
      Beschreibung:
      Sitzungsvermittlung starten:
      Benutzer: *****\athiele
      Sitzungs-ID: 54
    • Protokollname: Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin
      Quelle:        Microsoft-Windows-TerminalServices-RemoteConnectionManager
      Datum:         18.05.2015 11:57:08
      Ereignis-ID:   20499
      Aufgabenkategorie:Keine
      Ebene:         Warnung
      Schlüsselwörter:
      Benutzer:      Netzwerkdienst
      Computer:      Host1.*****.de
      Beschreibung:
      Das Laden der Benutzerkonfiguration von Server "\\DC02.*****.de" für Benutzer "athiele" durch die Remotedesktopdienste hat zu lange gedauert.
    • Protokollname: Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational
      Quelle:        Microsoft-Windows-TerminalServices-SessionBroker-Client
      Datum:         18.05.2015 11:57:08
      Ereignis-ID:   1301
      Aufgabenkategorie:Vom Remotedesktop-Verbindungsbrokerclient wird eine Anforderung eines Benutzers verarbeitet.
      Ebene:         Ausführlich
      Schlüsselwörter:
      Benutzer:      Netzwerkdienst
      Computer:      Host1.*****.de
      Beschreibung:
      Vom Remotedesktop-Verbindungsbrokerclient wurde eine Umleitungsanforderung empfangen.
      Benutzer: *****\athiele
      RDP-Clientversion: 4

    Übergabe an Host2:

    • Protokollname: Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational
      Quelle:        Microsoft-Windows-TerminalServices-SessionBroker-Client
      Datum:         18.05.2015 11:57:09
      Ereignis-ID:   1307
      Aufgabenkategorie:Vom Remotedesktop-Verbindungsbrokerclient wird eine Anforderung eines Benutzers verarbeitet.
      Ebene:         Ausführlich
      Schlüsselwörter:
      Benutzer:      Netzwerkdienst
      Computer:      Host1.*****.de
      Beschreibung:
      Der Benutzer *****\athiele wurde vom Remotedesktop-Verbindungsbrokerclient zum folgenden Endpunkt umgeleitet: Host2.*****.de.
      IP-Adresse des Endpunkts = 172.20.0.15.
    • Protokollname: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
      Quelle:        Microsoft-Windows-TerminalServices-LocalSessionManager
      Datum:         18.05.2015 11:57:09
      Ereignis-ID:   42
      Aufgabenkategorie:Keine
      Ebene:         Informationen
      Schlüsselwörter:
      Benutzer:      SYSTEM
      Computer:      Host1.*****.de
      Beschreibung:
      Sitzungsvermittlung beenden:
      Benutzer: *****\athiele
      Sitzungs-ID: 54
    • Protokollname: Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
      Quelle:        Microsoft-Windows-TerminalServices-RemoteConnectionManager
      Datum:         18.05.2015 11:57:09
      Ereignis-ID:   1152
      Aufgabenkategorie:Keine
      Ebene:         Fehler
      Schlüsselwörter:
      Benutzer:      SYSTEM
      Computer:      Host1.*****.de
      Beschreibung:
      Fehler beim Erstellen der KVP-Sitzungszeichenfolge. Fehlercode "0x8007007A"
    • Protokollname: Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin
      Quelle:        Microsoft-Windows-TerminalServices-RemoteConnectionManager
      Datum:         18.05.2015 11:57:09
      Ereignis-ID:   20495
      Aufgabenkategorie:Keine
      Ebene:         Fehler
      Schlüsselwörter:
      Benutzer:      SYSTEM
      Computer:      Host1.*****.de
      Beschreibung:
      Die Remotedesktopdienste konnten einen Benutzerprofil-Datenträger für das Benutzerkonto mit der SID "S-1-5-21-682003330-1123561945-1801674531-4255" nicht einblenden. Fehlercode: 0x21.135
      [Anmerkung: Fehler wird auf Host1 generiert, obwohl die Sitzung schon an Host2 übergeben wurde. Liegt hier der Fehler???]
    • Protokollname: Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin
      Quelle:        Microsoft-Windows-TerminalServices-RemoteConnectionManager
      Datum:         18.05.2015 11:57:09
      Ereignis-ID:   20493
      Aufgabenkategorie:Keine
      Ebene:         Fehler
      Schlüsselwörter:
      Benutzer:      SYSTEM
      Computer:      Host1.*****.de
      Beschreibung:
      Die Remotedesktopdienste konnten keinen Benutzerdesktop für ein Benutzerkonto mit der SID "S-1-5-21-682003330-1123561945-1801674531-4255" anwenden. Für den Benutzer wurde ein temporäres Profil erzwungen. Überprüfen Sie die Benutzerprofil-Datenträgereinstellungen. Fehlercode: 0x21.135

    Auf dem Host2, wohin der User vom Host1 weitergeleitet wurde, sind für diesen Vorgang keine Fehlermeldungen im Log.
    Auf dem Broker gibt es dazu folgende Event Einträge:

    • Protokollname: Microsoft-Windows-TerminalServices-SessionBroker/Operational
      Quelle:        Microsoft-Windows-TerminalServices-SessionBroker
      Datum:         18.05.2015 11:57:10
      Ereignis-ID:   800
      Aufgabenkategorie:Die Verbindungsanforderung wird vom Remotedesktop-Verbindungsbroker verarbeitet.
      Ebene:         Ausführlich
      Schlüsselwörter:
      Benutzer:      Netzwerkdienst
      Computer:      Broker.*****.de
      Beschreibung:
      Der Remotedesktop-Verbindungsbroker hat eine Verbindungsanforderung für Benutzer *****\athiele empfangen.
      Hinweise in der RDP-Datei (TSV-URL) = tsv://MS Terminal Services Plugin.1.Farm
      Ursprüngliche Anwendung = NULL
      Der Aufruf stammt vom Umleitungsserver = Host1.*****.de
      Der Redirector ist konfiguriert als Farm member.
    • Protokollname: Microsoft-Windows-TerminalServices-SessionBroker/Operational
      Quelle:        Microsoft-Windows-TerminalServices-SessionBroker
      Datum:         18.05.2015 11:57:10
      Ereignis-ID:   801
      Aufgabenkategorie:Die Verbindungsanforderung wird vom Remotedesktop-Verbindungsbroker verarbeitet.
      Ebene:         Ausführlich
      Schlüsselwörter:
      Benutzer:      Netzwerkdienst
      Computer:      Broker.*****.de
      Beschreibung:
      Vom Remotedesktop-Verbindungsbroker wurde die Verbindungsanforderung für Benutzer *****\athiele erfolgreich verarbeitet. Umleitungsinformationen:
      Zielname = Host2
      Ziel-IP-Adresse = 172.20.0.15
      Ziel-NetBIOS-Adresse = Host2
      Ziel-FQDN = Host2.*****.de
      Getrennte Sitzung gefunden = 0x1.
    • Protokollname: Microsoft-Windows-TerminalServices-SessionBroker/Operational
      Quelle:        Microsoft-Windows-TerminalServices-SessionBroker
      Datum:         18.05.2015 11:57:11
      Ereignis-ID:   818
      Aufgabenkategorie:Die Verbindungsanforderung wird vom Remotedesktop-Verbindungsbroker verarbeitet.
      Ebene:         Ausführlich
      Schlüsselwörter:
      Benutzer:      Netzwerkdienst
      Computer:      Broker.*****.de
      Beschreibung:
      Die Verbindungsanforderung hat zu einer erfolgreichen Sitzungsanmeldung geführt (der Benutzer wurde erfolgreich am Endpunkt angemeldet). Der Remotedesktop-Verbindungsbroker beendet die Überwachung dieser Verbindungsanforderung.

    D.h. nun für den Broker läuft alles normal ab. Bei Host1 und Host2 klappt m.M.n. die Übergabe nicht sauber und es wird versucht die UPD des Users auf Host1 einzubinden, obwohl die Sitzung an Host2 übergeben wurde. Ziemlich strange....

    Ich bin mit meinem Latein am Ende. Wenn sich über die Community durch eine Anfrage wie diese nichts finden lässt, dann werde ich wohl einen Call bei MS aufmachen müssen.

    Mfg Patrick


    Montag, 18. Mai 2015 10:27
    |

Antworten

  • Question
    Anmelden
    2
    Anmelden

    Es ist schon eine Weile her, das ich so ein Setup mal durchgespielt habe.

    Ich glaube die Lösung lag darin, einen A Record oder Alias mit dem Farmnamen im DNS zu erstellen, der dann auf den Broker verweist.

    This posting is provided AS IS with no warranties.

    Dienstag, 19. Mai 2015 12:48
    |
  • Question
    Anmelden
    1
    Anmelden

    Unter 2012(R2) wird RR noch für einen hochverfügbaren Connection Broker genutzt.

    Man muss nicht unbedingt RDP Dateien zu Fuß verteilen. In einer kleinen Umgebung mit nur einer Sammlung, kann man auf dem Broker eine Standardumleitung definieren. Dann wird jede RDP Anfrage ohne explizite Angabe einer Sammlung, auf diese Sammlung umgeleitet. Als Admin muss man dann den /admin Switch verwenden, um sich direkt mit dem Broker zu verbinden.

    http://ryanmangansitblog.com/2013/03/11/connection-broker-redirection-rds-2012/

    Der Link bezieht sich zwar auf VDI, ist aber auch für klassische RDS geeignet - das ist ja das Gute am 2012'er, es braucht nur eine (hochverfügbare) Infrastruktur, an die sich fast alles klemmen lässt.

    Web Portal und Feed finde ich sehr elegant. Keine Verteilung von msi Paketen oder RDP Dateien mehr. Die Inhalte werden regelmäßig aktualisiert. Wenn man mag, hat man es auch als Kachel unter Windows 8.1

    Beim Gateway reicht i.d.R. die automatische Ermittlung. Ich hab's allerding nie gemeinsam auf einem System installiert - für mich ist der Gateway eine DMZ Rolle und hat nichts auf einem internen System zu suchen.

    This posting is provided AS IS with no warranties.

    Montag, 18. Mai 2015 16:31
    |

Alle Antworten

  • Question
    Anmelden
    2
    Anmelden

    Moin,

    Du hast das Problem mit der Sitzungsumleitung schon erkannt.

    Mit Server 2012 wurde RDS in großen Teilen überarbeitet. Der Weg mit DNS RR eine direkte Verbindung zu einem Session Host aufzubauen ist obsolet. Das Thema 'connect and redirect' funktioniert zwar noch, kann aber viele Vorteile und Features einer Windows 2012(R2) RDS Umgebung nicht nutzen.

    In einer 2012'er Umgebung geht die initiale Verbindung auf den Broker und der sorgt für die Weiterleitung an einen Session Host aus der Sammlung.

    Ryan hat eine ganze Reihe guter Artikel zum Thema RDS 2012. Die meisten Artikel sind 1:1 auf 2012 R2 anwendbar.

    http://ryanmangansitblog.com/

    Von MS gibt es die TLG (Test Lab Guides) zu RDS:

    https://technet.microsoft.com/en-us/library/hh831610.aspx

    This posting is provided AS IS with no warranties.

    Montag, 18. Mai 2015 11:55
    |
  • Question
    Anmelden
    1
    Anmelden

    Danke für die Hinweise.

    Ich habe schon einiges durch bei Ryan. Leider sehe ich den initialen Big Point noch nicht, da laut ihm das DNS RR trotzdem eingerichtet werden muss.

    Mein Gedanke ist: Momentan verteile ich eine selbstsignierte RDP File per GPO auf den Desktop der User. Dort steht als Ziel der RDS Farm FQDN drin (DNS RR). D.h. die Anfrage geht an einen RDSH, von da zum Broker und dann zum RDSH, welcher zugeteilt wurde. Nun, wie kann ich das ganze umstricken?

    --> Wieder eine RDP File bauen, wieder den RDS Farm FQDN als Verbindungsziel, abweichend vom Szenario oben aber noch auf dem letzten TAP das RD GW konfigurieren. Somit müsste sich die Abfrage dahingehend ändern: Anfrage an RD GW (gleichzeitig Broker) --> Authentifizierung --> veröffentlichter Collection Name --> Broker --> RDSH --> Authentifizierung --> Verbindung.

    Ich glaube alles andere als eine "fertige" RDP File kann ich den Usern nicht zumuten. Wenn ich denen sage, verbinde dich mal auf die Webfeed URL (oder alternativ DNS TXT konfigurieren um per Mail dran zu kommen), melde dich da an und wenn da ne Abfrage kommt, ob RDP Zeugs zugelassen wird (Feed) dann bestätige das... Danach hast du unter Start --> blabla eine Verbindungsdatei. Prinzipiell ist ja meine selbst erstellte RDP File mit dem Verweis auf das RD GW genau das, was im Webfeed dargestellt wird.

    Patrick

    Montag, 18. Mai 2015 13:55
    |
  • Question
    Anmelden
    1
    Anmelden

    Unter 2012(R2) wird RR noch für einen hochverfügbaren Connection Broker genutzt.

    Man muss nicht unbedingt RDP Dateien zu Fuß verteilen. In einer kleinen Umgebung mit nur einer Sammlung, kann man auf dem Broker eine Standardumleitung definieren. Dann wird jede RDP Anfrage ohne explizite Angabe einer Sammlung, auf diese Sammlung umgeleitet. Als Admin muss man dann den /admin Switch verwenden, um sich direkt mit dem Broker zu verbinden.

    http://ryanmangansitblog.com/2013/03/11/connection-broker-redirection-rds-2012/

    Der Link bezieht sich zwar auf VDI, ist aber auch für klassische RDS geeignet - das ist ja das Gute am 2012'er, es braucht nur eine (hochverfügbare) Infrastruktur, an die sich fast alles klemmen lässt.

    Web Portal und Feed finde ich sehr elegant. Keine Verteilung von msi Paketen oder RDP Dateien mehr. Die Inhalte werden regelmäßig aktualisiert. Wenn man mag, hat man es auch als Kachel unter Windows 8.1

    Beim Gateway reicht i.d.R. die automatische Ermittlung. Ich hab's allerding nie gemeinsam auf einem System installiert - für mich ist der Gateway eine DMZ Rolle und hat nichts auf einem internen System zu suchen.

    This posting is provided AS IS with no warranties.

    Montag, 18. Mai 2015 16:31
    |
  • Question
    Anmelden
    1
    Anmelden

    Ok.

    Ich habe den Regeintrag auf dem Broker gesetzt:

    tsv://VMResource.1.Farm

    Die Collection heißt "Farm". Ergebnis wenn ich mich mit einem normalen User auf dem Broker anmelde ist:

    "Im Pool sind keine Computer verfügbar. Stellen Sie die Verbindung erneut her, oder wenden Sie sich an den Netzwerkadministrator."

    Edit: Ok, das war wohl Käse... das muss weiterhin tsv://VMResource.1.Virtualpool1 heißen:

    Ergebnis hier dann:

    Für den Computer kann keine Verbindung mit dem Remotecomputer hergestellt werden, da die in der RDP Datei angegebenen Einstellungen nicht vom Verbindungsbroker überprüft werden können. Wenden Sie sich an..."

    Edit2: Weiterhin getestet: tsv://MS Terminal Services Plugin.1.Farm

    Hier meckert eine Fehlermeldung dann darüber, ich muss den Farmnamen (anstatt den Namen des Brokers) in der RDP Datei verwenden.

     

    Montag, 18. Mai 2015 17:05
    |
  • Question
    Anmelden
    1
    Anmelden

    Mit 'Edit2' sollte es funktionieren.

    Passen die Zertifikate?

    Gibt es auf dem Broker relevante Ereignisse während des Verbindungsaufbaus?

    This posting is provided AS IS with no warranties.

    Montag, 18. Mai 2015 17:59
    |
  • Question
    Anmelden
    1
    Anmelden

    Auf dem Broker sieht im Gegenteil alles Gut aus, sauberes Redirecting auf Host2 laut den Event Einträgen.

    Die Fehlermeldung ist die gleiche, als wenn ich statt auf den Farmnamen direkt auf einen RDSH verbinden will...

    Edit: Vollständiger halber die Meldung:

    Von Remotedesktopverbindung kann keine Verbindung mit dem Remotecomputer
    hergestellt werden.
    Vom Remotecomputer "broker.*****.de", mit dem Sie eine Verbindung herstellen
    möchten. werden Sie zum Remotecomputer "Host1.*****.de" umgeleitet. Es kann nicht
    überprüft werden, ob die beiden Remotecomputer zur gleichen Remotedesktop·Sitzungshostserverfarm gehören. Sie müssen den Farmnamen, nicht den
    Computernamen verwenden, wenn Sie eine Verbindung mit einer
    Remotedesktop-Sitzungshostserverfarm herstellen möchten.

    Montag, 18. Mai 2015 18:02
    |
  • Question
    Anmelden
    2
    Anmelden

    Es ist schon eine Weile her, das ich so ein Setup mal durchgespielt habe.

    Ich glaube die Lösung lag darin, einen A Record oder Alias mit dem Farmnamen im DNS zu erstellen, der dann auf den Broker verweist.

    This posting is provided AS IS with no warranties.

    Dienstag, 19. Mai 2015 12:48
    |
  • Question
    Anmelden
    1
    Anmelden

    Das war ein entscheidender Tip. Funktioniert nun so. Laut Eventlog auf dem Broker ist er nun eindeutig der Umleitungsserver und nicht mehr einer der RDSH. Nun werde ich sehen, ob die User keine .baks mehr mit UPDs bekommen.

    Das Beste, die per GPO verteilte RDP File kann weiterverwendet werden.

    Kleine Schönheitsfragen:

    1. Wenn ich mich auf das RDweb verbinde und die Farm auswähle, ist dort in der RDP File nicht der Farmname, sondern der FQDN des Brokers. Eine Verbindung schlägt dann fehl wegen Authentifizierungsfehler 607. Meine Recherchen ergaben bis jetzt, dass es wohl am Zertifikat liegt. Wenn es ein self-signed ist (ich verwende ein self-signed Wildcard, das hängt am Broker, RD GW, RD Web, und an den RDSH und an der selbst erstellten RDP File) dann scheitert dies zwecks revoke. Extern verstehe ich das ja, da ich meine interne CA auch kaum nach extern öffnen werde. Jedoch kommt intern der gleiche Fehler ?-/. Es spielt dabei keine Rolle, ob Domänen PC oder Nicht-Domänen PC.

    Wenn ich diese RDP File vom RDweb runterlade und dahingehend ändere, dass ich den Broker FQDN als Verbindungsziel ersetze durch den Farmnamen, dann klappt es wieder ohne Probleme, also von intern und extern.

    Kannst du das bestätigen, dass zwingend öffentliche Zertifikate verwendet werden müssen? Bzw. das es richtig ist, dass nicht der Farmname sondern der Broker Name im RDweb drin stehen?

    2. Da der in der Umgebung noch einige XP im Einsatz sind (ja ich weiß... doof, aber muss zwecks angeschlossener Geräte) hatte ich den Schönheitsfehler, dass der User sich 2 mal authentifizieren muss. Einmal wahrscheinlich am Broker und dann nochmal am Server, die Credentials werden da nicht weitergereicht bzw. die Abfrage passiert auf dem Server und nicht vorher. Das konnte ich mittlerweile lösen, der Vollständigkeit halber, falls noch jemand mitliest, hier die 2 "MS Updates" welche auf den XP Client müssen:

    RDP 7 Client: https://support.microsoft.com/en-us/kb/969084/de-de

    CreedSSP iFixit: https://support.microsoft.com/en-us/kb/951608 (Neustart erforderlich!)

    So, wenn das Redirection nun sauber funzt und das RDweb noch klappt, bin ich hoch zufrieden.

    Vielen Dank bis hierher für deine Hilfe. Ich werde auf jeden Fall noch eine Statusmeldung abgeben, ob die Temp Profile weg sind.

    Patrick

    Dienstag, 19. Mai 2015 20:14
    |
  • Question
    Anmelden
    1
    Anmelden

    Moin,

    in der RDP Datei aus dem RDWeb steht der Broker drin.

    Unter 'full address:s:[broker FQDN]', 'workspace id:s:[broker FQDN]' und 'alternate full address:s:[broker FQDN]'

    Die Sammlung ist unter 'loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.[Sammlung]' angegeben, also die gleiche Info, die auch bei der Standardumleitung auf dem Broker genutzt wird.

    Ich habe es ehrlich gesagt noch nicht mit selbstsignierten Zertifikaten versucht. Unsere Zertifikate kommen aus der internen PKI.

    Die CDP und AIA sind extern veröffentlicht. Das sind nur zwei Verzeichnisse eines Webservers. Mit einem Reverseproxy kein Problem. Da braucht es auch keinen Zugriff auf die eigentliche CA.

    Ein kommerzielles Zertifikat kostet auch nicht die Welt. Das muss man halt abwägen.

    This posting is provided AS IS with no warranties.

    Mittwoch, 20. Mai 2015 09:22
    |
  • Question
    Anmelden
    1
    Anmelden

    Ok, da habe ich mich missverständlich ausgedrückt. Ich nutze intern auch eine Zertifizierungsstelle. Dort kommt auch das Zert her. Das RootCert wird natürlich sauber verteilt.

    Die Tempprofile sind nun weg. Heute war ein sauberer Arbeitstag mit 100 Usern. Lediglich ein die XPs brauchen noch die CreedSSP Registryeinträge, so dass die Anmelddaten vor dem Broker eingegeben werden und zum Host durchgereicht werden. Momentan landen die User auf dem Broker und sehen den Admin als angemeldeten User, klicken dann auf "anderer User" und geben ihre Daten ein. Dann landen sie auf dem Host und müssen nochmal das Passwort eingeben. GPO mit WMI Filter setzt die Einträge, sollte morgen auch erledigt sein.

    Das RDweb funktioniert nun auch intern ohne Probleme, es bleibt also nur noch das RDweb von extern, was aber wohl am besagten fehlendem Prüfen der Sperrliste liegt.

    Vielen Dank nochmal für deine wertvollen Tipps. Ich werde das sicherlich nochmal alles zusammenfassen in einem kleinen How To und im Netz verteilen, da doch einige ungelöste Probleme mit der UPD in einer Farm haben.

    Patrick

    Mittwoch, 20. Mai 2015 20:55
    |