Hallo liebe Microsofties,
in Systemadministrator in einem Unternehmen mit ca. 100 Mitarbeitern. Wir haben derzeit einen Windows Server 2008 R2 Terminal Server im produktiven Einsatz. Des Weiteren haben wir einen Windows Server 2012 R2 Terminal Server (Testserver) im Einsatz. Wir wollen nun den alten 2008 R2 Server ablösen und vollständig auf den neuen Server migrieren.
Wichtig ist noch zu wissen, dass wir Benutzerzertifikate aus der hauseigenen Enterprise Zertifizierungsstelle verwenden. Diese werden dabei auf Aladdin E-Token exportiert um diese mit einer Pin vor Missbrauch zu schützen. Die Active Directory Gesamtstruktur Funktionsebenen ist Windows Server 2008 R2. Die Domain Controller sind ebenfalls noch Windows Server 2008 R2.
Beim Windows Server 2012 R2, habe ich derzeit noch 3 Probleme die ich nicht gelöst bekomme, daher wende ich mich an euch.
Anmelden in der Konsole:
Wenn ich einen Windows Server 2012 R2 Terminal Server bereitstelle und auf diesem keine Anwendung zur Verfügung stelle, habe ich im RD Web die Konsolenverbindung (MSTSC) zur Verfügung. Füge ich eine beliebige Remote App (z.B. Outlook) hinzu verschwindet sofort die Konsolenverbindung (MSTSC) und ich kann diese nur mit einem Workaround wieder hinzufügen.
Ich habe mir geholfen in dem ich die C:\Windows\System32\MSTSC.exe mit dem Parameter /v Servername.FQDN als Remote App hinzugefügt habe. Diese Lösung ist jedoch sehr unsauber, da ich zunächst eine Remote Desktop Verbindung öffne um dann mit dem Parameter eine Remote Desktop Verbindung zu öffnen. Somit hat jeder Nutzer automatisch 2 aktive Sitzung und ich verschwende unnötig Ressourcen. Bei 20 aktiven User hätte ich somit aktive 40 Sitzungen, dieser Effekt ist sehr unschön.
Hat jemand einen Rat, wie ich dieses Problem sauberer lösen kann?
Es ist des Weiteren nicht mehr möglich, Programme welcher auf einem Netzlaufwerk liegen als Remote App zu veröffentlichen. Auch hier suche ich noch nach einer passenden Lösung. Der Server gibt lediglich die Fehlermeldung aus, dass ich einen UNC-Pfad verwenden soll.
Automatische Server Verbindung beim Hochfahren des Client Betriebssystems:
Ich finde es für den Nutzer sehr komfortabel, wenn dieser sich die Remote App und Desktopverbindung in der Systemsteuerung hinzufügen kann um diese dann bei jedem Start des Computers direkt zu verwenden.
Leider scheint diese Funktion ein Fehler zu haben, welchen ich auf unsere Zertifikat Authentifizierung zurückführen würde.
Ich gehe hierbei wie folgt vor, ich öffne die Systemsteuerung (klassische Ansicht Kleine Symbole) klicke auf Remote App und Desktopverbindungen und wähle die Option „neue Verbindung mit Remote App und Desktop Verbindung einrichten“. Im Anschluss konfigurierte ich dann mithilfe des Wizard‘s die Verbindung zu meinem Server.
Nun fordert mich das Server auf mich gegenüber dem Server zu authentifizieren und fügt mir die Remote Apps hinzu. Starte ich meinen Client nun neu kann er diese Verbindung nicht erneut herstellen und das Feature ist somit derzeit nutzlos da, sich meine Nutzer diese Verbindung nach jedem Neustart erneut einrichten müssten.
Es sieht für mich so aus, als ob der Server an der Zertifikatsauthentifizierung (Eingabe der Pin zum Lesen auf dem E-Token) scheitert.
Hat jemand eine Idee, wie ich diesen Fehler beheben kann? Es würde die Akzeptanz der Nutzer sehr stark erhöhen und den Zugriff zum Server wesentlich vereinfachen.
Des Weiteren bin ich auf der Suche, nach einem Weg diese Verbindung automatisch auf dem Client einzurichten. Hierbei wäre eine Batchdatei welche ich mit einigen anderen Installationen verknüpfte meine Wahl.
Verschlüsselte Remoteapps:
Unter Windows Server 2008 R2 hatte ich die Möglichkeit, die zur Verfügung gestellten Remote Apps verschlüsselt zu exportieren, damit ich diese meinen Nutzern zur Verfügung stellen kann um den Login in den Server zu vereinfachen.
So wie es aussieht hat Microsoft vergessen diese Funktion in Server 2012 R2 zu implementieren.
Hat irgendjemand ein Workaround um dieses Thema? Ich habe leider im Internet nichts passendes gefunden. Das tolle an der Funktion war das der Nutzer die zur Verfügung gestellten RDP Dateien nicht manipulieren konnte.
Grüße Fritz