faq-o-matic.net » Terminal Server

Microsoft Office 2010 Standard auf Remotedesktopserver Windows 2008 R2 aktivieren

Bent Schrader — Wed, 20 Apr 2011 04:53:00 +0000

Dieser Beitrag erschien zuerst auf Bents Blog.

Für einen Kunden musste ich kürzlich einen neuen Remotedesktopserver (ehemals Terminalserver) unter Windows Server 2008 R2 aufsetzen. Normalerweise stellt die Installation von Microsoft Office Produkten kein Problem dar, typischerweise werden Anwendungen auf einem Terminalserver immer über den Punkt “Anwendung auf dem Remotedesktopserver installieren” in der Systemsteuerung eingerichtet.

Für die Microsoft Office 2010 Standard Version verwendete ich das ISO Abbild aus Microsoft Volume Licensing Service Center mit der Bezeichnung OPEN_Office_2010_W32_German_MLF_X16-51947.iso. Zu meiner Verwunderung fragte aber der Installationsassistent von Office 2010 nicht nach dem Produktschlüssel, nach der Bestätigung des Licence Agreements ließ sich Office sofort ohne Problem installieren.

Natürlich musste die Software noch aktiviert werden. Eine sehr gute Anleitung fand ich im Office Deployment Support Team Blog in folgendem Artikel. Mit dem Aufruf der beiden Kommandos

cscript “%ProgramFiles%\Microsoft Office\Office14\ospp.vbs” /inpkey:

gefolgt von

cscript “%ProgramFiles%\Microsoft Office\Office14\ospp.vbs” /act

konnte ich das Produkt erfolgreich aktivieren:

Da ich nicht täglich Microsoft Office auf einem Terminalserver installiere, war das Verfahren für mich neu, weswegen ich das Vorgehen hier dokumentieren wollte. Dank des guten Artikels des Office Deployment Support Team Blogs kostete mich die Prozedur jedoch nur wenige Minuten.

Troubleshooting für lange Anmeldezeiten auf Terminalservern

Kurt Rode — Wed, 12 Jan 2011 07:28:00 +0000

In einem Schulnetz läuft eine Terminalserver-Farm unter Windows Server 2003 R2 64bit. Dort kam es immer wieder zu stark verzögerten Anmeldungen, die schwer zu fassen waren.

Das Anmeldeverhalten ist im Vergleich zu einer „normalen“ Firma durchaus speziell: Zu jeder Schulstunde melden sich X Schüler an und am Ende wieder ab. Dabei konnte es vorkommen, dass die Anmeldung bei einem Schüler mehrere Minuten dauert (Ausreißer bis zu zehn Minuten), während das in Zeiten ohne Last bzw. mit wenig Last auch in 30-40 Sekunden vonstatten geht.

Netzwerk, CPU und Arbeitsspeicher auf den Terminalserver sind ausreichend dimensioniert und zeigen während der Lastzeiten keine beängstigenden Peaks. Der Fileserver wurde in Richtung maximal gleichzeitiger SMB-Verbindungen optimiert und die entsprechenden Einträge auf den Terminalservern gesetzt (MaxWorkItems, MaxMpxCt, MaxCmds).

Nachdem wir an einigen Stellen gesucht, optimiert und analysiert haben, haben wir uns sehr intensiv mit dem eigentlichen Anmeldevorgang beschäftigt. Dazu haben wir das User-Debug Logging eingeschaltet (http://support.microsoft.com/kb/221833/en-us), um da auch was sehen zu können. Mit dem netten Freeware-Tool Policy Reporter (http://www.sysprosoft.com/policyreporter.shtml) wird das Log-File dann auch grafisch schön aufbereitet.

Zuerst ist uns aufgefallen, dass ca. 20 Sekunden beim Login draufgehen für Einstellungen am Internet Explorer. Nach einer kurzer Recherche haben wir dann ein passenden Hotfix gefunden: http://support.microsoft.com/kb/941158/en-us Dieses haben wir nun also runtergeladen und den entsprechenden RegKey gesetzt. Das hat zwar eine einzelne Useranmeldung beschleunigt, unser Grundproblem bestand aber immer noch.

Ein paar Analysen und Versuche später sind wir dann noch über eine Stelle im Log gestoßen, die im ersten Moment „nur“ 2,5 Sekunden dauerte. Der Eintrag lautete: „Successfully logged registry Rsop data“. Nachdem ich mich schlau gemacht hatte was da passiert und mal danach gegoogelt hatte fand ich eine Seite, auf der jemand nur kurz beschrieben hat, dass die Erzeugung des RSOP die Anmeldung verlangsamen kann.

Daraufhin war es ziemlich einfach zu finden wo man dem System abgewöhnen kann dies zu tun. Das geht über GPO und man findet es unter:

Computerkonfiguration -> Windows Einstellungen -> Administrative Vorlagen -> System -> Gruppenrichtlinien -> Protokollierung des Richtlinienergebnissatzes deaktivieren –> Aktivieren

Nach einem Update der GPO auf unserem Testsystem verbesserte sich die Anmeldezeit nun derart, dass 20 gleichzeitige Useranmeldungen nun 20-40 Sekunden dauern und keine 5 Minuten mehr. Eine einzelne Useranmeldung liegt nun bei ca. 5-10 Sekunden.

Mandatory Profiles – Standardmäßig unsicher?

Helge Klein — Mon, 13 Dec 2010 12:41:59 +0000

Mandatory ("verpflichtende") Profiles gelten gemeinhin als schnell und sicher. Schnell, weil sie aufgrund ihrer geringen Größe die Anmeldung nur minimal verzögern, und sicher, weil die Benutzer mangels Schreibrechten das Mandatory Profile nicht verändern können. Das ist zwar beides richtig, doch zu tatsächlicher Sicherheit gehört mehr.

Lesen Sie in meinem aktuellen, zuerst im Windows Server 2008 R2 Remote Desktop Services Resource Kit erschienenen Blog-Artikel, wie durch das Setzen von Vollzugriff für Jedermann in der Registrierung standardmäßig vorhandene Schutzmechanismen ausgehebelt und auf Terminalservern Lauschangriffe oder Denial-of-Service-Attacken möglich werden:

Mandatory Profiles – Insecure by Default?

Terminalserver: Den Protected Mode des Adobe Reader X abschalten

Nils Kaczenski — Tue, 23 Nov 2010 06:19:00 +0000

Adobe hat vor einigen Tagen die neue Version 10 seines Adobe Reader veröffentlicht (Marketingname: Adobe Reader X). Eine der wichtigsten Neuerungen ist der “Protected Mode” (“Geschützter Modus”), der eine Art Sandbox um verdächtige Dokumente bildet. Ähnlich wie die geschützte Ansicht in Office 2010 verhindert dieser Modus den Übergriff von möglichen Schadfunktionen in PDF-Dokumenten auf das Computersystem des Benutzers. Eine sehr sinnvolle Funktion also.

Nur leider hat das ein paar Haken: Der Protected Mode funktioniert nämlich in einer ganzen Reihe von Situationen nicht. Dazu gehört dummerweise auch der Einsatz auf Terminal Servern mit Citrix – und anscheinend auch mit dem bordeigenen RemoteApp. Ruft man dort den Adobe Reader X auf, so meldet er beim Start:

Update 24. März 2011: Bent Schrader hat herausgefunden, dass in Version 10.0.1 der beschriebene Workaround nicht mehr notwendig ist.

[Adobe Acrobat Reader X auf einem Terminalserver - Bent's Blog]
http://bent-blog.de/windows/terminalserver/adobe-acrobat-reader-x-auf-einem-terminalserver/

Adobe dokumentiert diese Einschränkungen auch auf seiner Webseite. Dort sind allerdings die Remote Desktop Services (früher: Terminal Services) von Windows 2003 bis 2008 ausdrücklich als kompatibel angegeben. Zumindest im Zusammenhang mit RemoteApp tritt der Fehler allerdings auch auf, nicht nur mit Citrix.

[Protected Mode Troubleshooting | Adobe Reader]
http://kb2.adobe.com/cps/860/cpsid_86063.html

In seiner FAQ gibt Adobe lapidar an, man könne den Protected Mode auch über die Registry abschalten – welchen Key man dafür verwenden muss, darf der geneigte Admin dann selbst rausfinden. Auch sonst sind diese FAQ leider eher ein Eingeständnis, dass man den neuen Modus nicht so richtig toll implementiert hat.

[Protected Mode FAQ - Security and Information Assurance - Adobe Learning Resources]
http://learn.adobe.com/wiki/display/security/Protected+Mode+FAQ

Den Protected Mode zentral abschalten – GPP-Methode

Dabei ist es gar nicht so schwer, den Protected Mode zentral abzuschalten. Da es sich grundsätzlich aber um eine sinnvolle Funktion handelt, empfehle ich das folgende Vorgehen nur für Umgebungen, in denen der neue Modus ein Problem darstellt – eben beispielsweise RemoteApp-Umgebungen.

Der zu ändernde Key in der Registry ist folgender:

[HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\10.0\Privileged]
"bProtectedMode"=dword:00000000

Dieser Wert muss auf 0 (null) stehen, damit der Protected Mode abgeschaltet ist. Nun helfen die GPP (Group Policy Preferences) dabei, diese Einstellung auf alle RemoteApp-User auszurollen. Man suche sich also eine Gruppenrichtlinie (GPO) heraus, die für die betreffenden Benutzerkonten gilt (bzw. man erzeuge eine neue). Dort öffnet man die Benutzerkonfiguration/ Einstellungen/ Windows-Einstellungen/ Registrierung. Hier fügt man ein neues Element hinzu und trägt dort Folgendes ein:

Speichern, GPO schließen, fertig. Eventuelle getrennte Benutzersitzungen auf dem RemoteApp-Server muss man nun einmal zurücksetzen, damit die User sich tatsächlich neu anmelden. Danach sollte die GPP-Einstellung greifen und der Reader ohne Protected Mode starten.

Prüfen kann der Benutzer dies über die Einstellungen (im Menü “Bearbeiten”). Dort ist auch die Stelle, wo er die Einstellung manuell ändern kann.

Den Protected Mode zentral abschalten – ADM-Methode

Norbert Fehlauer hat folgende ADM-Datei geschrieben. Damit lässt sich der Vorgang auch über “klassische” Gruppenrichtlinien ausführen.

Update 9.12.2010: Christoph Langer hat uns auf einen Fehler in der ursprünglichen ADM-Version hingewiesen. Die unten stehende Fassung ist korrigiert.

; ADM Template Author: Norbert Fehlauer

Class User
    CATEGORY !!CAT_AdobeReaderX

        POLICY !!Pol_ProtectedModedeaktivieren
            #IF VERSION >= 4
                SUPPORTED !!Supportedon_AdobaReaderX
            #ENDIF

            EXPLAIN !!Expl_AdobeProtectedMode
            KEYNAME "Software\Adobe\Acrobat Reader\10.0\Privileged"

            PART !!Part_ProtectedModedeaktivieren Checkbox
                VALUENAME "bProtectedMode"
                DEFCHECKED
                VALUEON NUMERIC 0

                VALUEOFF NUMERIC 1

            END PART

        END POLICY ;Pol_ProtectedModedeaktivieren

    END CATEGORY ;CAT_AdobeReaderX

[STRINGS]

CAT_AdobeReaderX="Adobe Acrobat X"
Expl_AdobeProtectedMode="Für weitere Informationen siehe: http://learn.adobe.com/wiki/display/security/Protected+Mode+FAQ"
Part_ProtectedModedeaktivieren="Protected Mode deaktivieren"
Pol_ProtectedModedeaktivieren="Protected Mode deaktivieren"
Supportedon_AdobaReaderX="mindestens Adobe Reader X"

RDP-Verbindungsmanager für Admins

Nils Kaczenski — Sun, 13 Jun 2010 08:34:00 +0000

Vor wenigen Tagen hat Microsoft ein internes Werkzeug öffentlich verfügbar gemacht. Es handelt sich um einen RDP-Verbindungsmanager für viele gleichzeitige Terminalsessions, der insbesondere für Admins sehr interessant ist, die größere Umgebungen verwalten. Viele Drittanbietertools dürften damit überflüssig sein.

Der “Remote Desktop Connection Manager” (aktuell in Version 2.2) erlaubt es, RDP-Verbindungsinformationen in einer übersichtlichen, selbst definierten Baumstruktur anzuordnen. Dabei kann man Server nach verschiedenen Kriterien gruppieren; die Gruppen können sogar verschachtelt sein. Für jede Gruppe lassen sich die Verbindungsdaten vorgeben, sodass sie nach unten vererbt werden. Wer also in einer Domäne mit einem einheitlichen Adminkonto arbeitet, braucht dies nur einmal vorzugeben und wird dann automatisch damit eingeloggt.

Dabei kann man Untergruppen oder einzelne Server auch gezielt mit anderen Anmeldeinformationen versorgen. Alternativ kann man auch ad hoc eine RDP-Verbindung mit einem anderen Anmeldekonto anfordern. Ganz nebenbei erlaubt der RDCM es auch, Sessions für eine ganze Servergruppe gleichzeitig zu öffnen. Offene Verbindungen innerhalb einer Gruppe zeigt das Werkzeug als Thumbnails an – natürlich mit Live-Preview. Ein Klick auf den Titel vergrößert das Fenster.

Damit noch lange nicht genug – die Featureliste des Programms ist beeindruckend (mehrere Monitore, Abmeldefunktion, Übersicht offener Verbindungen …). Der Download ist kostenlos; das Programm läuft auf Windows-Systemen von XP bis 7 bzw. Windows Server 2008 R2. Wer XP oder Windows 2003 einsetzt, muss allerdings den RDP-Client auf Version 6.1 aktualisieren. Die Funktionen der neuen Clientversion kann man auch nutzen, z.B. Sound- und Grafikoptimierungen.

[Download details: RDCMan]
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4603c621-6de7-4ccb-9f51-d53dc7e48047

Terminalserver-Profileinstellungen in AD: Die ungenutzte Neuerung

Nils Kaczenski — Wed, 13 Jan 2010 11:04:40 +0000

Mit Windows Server 2008 hat Microsoft einige neue Attribute in Active Directory eingeführt, die für Benutzerkonten die Umgebungseinstellungen für Terminalserver speichern sollen. Dazu gehören vor allem der Terminalserver-Profilpfad und das Terminalserver-Basisverzeichnis (neue Attribute: msTSProfilePath, msTSHomeDirectory und msTSHomeDrive). Vorher hatte Windows diese Daten zwar auch im AD abgelegt, allerdings in einem großen Binärfeld namens “userParameters”. Dort waren die Werte nicht direkt nutzbar, sondern man musste stets ein besonderes API für den Zugriff nutzen. Leider sind die Dinge aber mal wieder nicht so einfach, wie sie sein sollten …

Laut Dokumentation im MSDN sollten die neuen Attribute auch bereits in Verwendung sein:

[2.3 Directory Service Schema Elements Used by Terminal Services Terminal Server Runtime Interface]
http://msdn.microsoft.com/en-us/library/cc669440(PROT.10).aspx

Dort heißt es (Stand Anfang Januar 2010):

msTSHomeDirectory
This attribute specifies the home directory for the user. Each user on a terminal server has a unique home directory. This ensures that application information is stored separately for each user in a multi-user environment.

[…]

msTSProfilePath
This attribute specifies a roaming or mandatory profile path to use when the user logs on to the terminal server. The profile path is in the following network path format: \\servername\profiles folder name\username.

Wer nun aber versucht, diese neuen Attribute zu nutzen, stellt fest: Steht nix drin. Auch ein direkter Versuch klappt nicht: Ein TS-Profil beim User anlegen, dann mit ADSI Edit nachsehen: msTSProfilePath ist leer.

Der Grund ist einfach, aber ernüchternd: Zwar sind die neuen Attribute bereits definiert und dokumentiert – aber in Wirklichkeit nutzt Windows sie nicht, weder in Windows Server 2008 noch im R2. Derzeit gibt es auch noch keine Aussage, wann der Wechsel tatsächlich vollzogen wird. Es gibt nur die Vorbereitung dafür …

Einstweilen bleibt also nur der seit Windows Server 2003 nutzbare Weg über das “alte” API.

[faq-o-matic.net » Wie kann ich die Terminal-Server-Einstellungen im AD verändern?]
http://www.faq-o-matic.net/2003/11/17/wie-kann-ich-die-terminal-server-einstellungen-im-ad-veraendern/

[IADsTSUserEx Interface (Windows)]
http://msdn.microsoft.com/en-us/library/aa380823(VS.85).aspx

[IADsTSUserEx::TerminalServicesProfilePath Property (Windows)]
http://msdn.microsoft.com/en-us/library/dd919966(VS.85).aspx

(Im letzten Artikel findet sich der gängige Code-Aufbau für VBScript ganz unten.)

TS Web Access 2008 über ISA Server veröffentlichen

Wolfgang Bauer — Sat, 30 Aug 2008 07:38:23 +0000

Windows Server 2008 hat die Terminaldienste deutlich erweitert. Unter anderem lassen sich RDP-Verbindungen nun über https durchs Web tunneln. Dieses neue Feature heißt "TS Web Access".

Dieser Artikel im PDF-Format beschreibt eine konkrete Implementierung der Terminaldienste für den sicheren Zugriff durch Benutzer, die sich außerhalb des Unternehmensnetzwerks befinden.

Note: There is a file embedded within this post, please visit this post to download the file.

Terminal Server 2008 einrichten

Torben Schönfelder — Tue, 26 Aug 2008 09:50:35 +0000

Als Grundlage eines TS 2008 dient in diesem Beispiel ein Server 2008 Standard Edition. Hierbei ist zu beachten, dass zur Aktivierung des Servers unter Umständen ein KMS benötigt wird (Lizenzkey). Nach abgeschlossener Installation und Aktivierung werden die nötigen Rollen für die Terminal-Dienste installiert.

Voraussetzung für einen funktionierenden Terminalserver 2008 sind die Installationen vom IIS7 und dem Network Policies und Access Service. Zur Nutzung des TS Web sind Clients mit Windows XP SP3 oder Vista SP1 erforderlich. Der Webdesktop benötigt das letzte RDP6.0 Update bei XPSP2 und Server 2003. Dazu am Ende nochmal Hinweise. Ebenfalls ist in diesem Beispiel eine interne Zertifizierungsinstanz vorhanden, um Computer wie Webserverzertifikate automatisiert zur Verfügung zu stellen.

Die Screenshots sind teilweise nachträglich anonymisiert worden, da es sich um eine Produktivinstallation und deren Dokumentation handelt.

Installation IIS7

Bei der Installation des IIS ist nichts Besonderes zu beachten.

Installation Network Policies und Access Service

Die Installation einfach beenden. Wichtig ist, dass kein NAP aktiviert wird.

Installation Terminal Services

Im Servermanager die Rollen hinzufügen und mit "Weiter" bestätigen. Die Serverrollen lassen sich durchaus auf verschiedene Server verteilen, wir gehen hier von einem Server aus.

Für den TS 2008 werden folgende Services zur Installation mit angeboten.

Terminal Server ( Zwingend erforderlich)
TS Licensing (Einer pro Domäne erforderlich)
TS Session Broker (Zur Verwaltung von Sessions in Serverfarmen)
TS Gateway (Das Gateway, erforderlich 1 pro Farm)
TS Web Access (Erforderlich zur Bereitstellung von TS Applikationen via WEB Interface)

Für unseren TS 2008 haben wir uns entschieden, alle Dienste bis aus den Session Broker zu installieren. Alle vier Services anhaken und mit "Weiter" bestätigen.

Der nächste wichtige Punkt ist die Authentifizierungsmethode. Um auch älteren Systemen den Zugriff auf den TS zu ermöglichen wird kein NLA aktiviert.

Als Lizensierungsmethode wählen wir die Lizensierung per User, da es öfter vorkommt, dass User andere fremde Geräte benutzen und somit mehr Lizenzen per Device nötig werden würden.

Als nächstes wird nun festgelegt, welche User/Gruppen auf den TS zugreifen werden können. Diese werden der lokalen Remote-Desktop-Benutzergruppe hinzugefügt, dort kann man später auch User und Gruppen hinzufügen. Die Gruppe der Administratoren ist immer hinzugefügt und kann während der Installation nicht entfernt werden.

Nun muss der Bereich gewählt werden, der vom Lizenzdienst abgedeckt werden soll. Da der Server domänenweit gelten soll wird „diese Domäne“ gewählt. (Der Screenshot ist er in einer VHD nachgestellt worden und zeigt hier nur Workgroup als mögliche Option an.)

Zur Konfiguration öffnen wir den Server Manager und springen in die Rolle Terminal Services.

Beginnend werden wir das Zertifikat hinzufügen. Im TS RemoteApp Manager gibt es in der rechten Aktionsleiste den Punkt Digitale Signatur, diesen öffnen wir und fügen das gewünschte Zertifikat, welches ein Computerzertifikat sein muss, hinzu.

Im Reiter Terminal Server tragen wir nun den FQDN des Servers ein und aktivieren die Serverauthentifizierung und den RDP im TS Web Access.

Im Reiter TS Gateway aktivieren wir den Gateway und geben unsere auf dem ISA-Server eingerichteten Daten ein, um die Veröffentlichung auf dem ISA Server zu nutzen und den TS per Web zugänglich zu machen. Also etwa TS.FIRMA.DOMAIN

Nach der Konfiguration der Zertifikate und des Gateways kann man nun mit der Einrichtung der zur Verfügung gestellten Programme beginnen. In der rechten Aktionsleiste findet sich der Punkt RemoteApp hinzufügen. Dieser öffnet einen Assistenten, um auf dem Server installierte Software als Webapplikation zu nutzen. Die gewünschten Programme anhaken und dem Assistenten folgen.

Im Terminal Server Manager wird dann der Server mit und ohne Domainsuffix eingetragen, um DNS-Probleme zu vermeiden. Unter der Terminal Service Konfiguration findet man den Lizenz Dienst, bei dem noch die vorhandenen CALs eingerichtet werden müssen. Hierzu dem Assistenten folgen und die CALs aktivieren.

Anschließend sieht die Diagnose wie folgt aus.

Im Service Manager ist dann unser TS2008 zu finden und alle Verbindungen, die aktuell bestehen, werden mit Verbindungsart und User dargestellt. Mit Hilfe des Managers können wir auch Verbindungen trennen oder verbundenen Users Informationen zukommen lassen. Sind alle Einstellungen getroffen ist der Terminal Server 2008 bereit für die Inbetriebnahme und es empfiehlt sich lediglich noch die Administrator Gruppe aus der Remote User Group zu entfernen um die größtmögliche Sicherheit zu erreichen.

Die Nutzung der RemoteApp Webdienste Seite ist erst ab XP SP3, Vista SP1 und Server 2008 möglich. Das TS Web Access und das TS Gateway sind ab auch unter XP SP2 und Server 2003 SP2 mit dem letzten RDP Update (KB925876) möglich, da es dort bereits die Funktion des TS Gateways gibt.

RDP absichern – aber wie?

Frank Röder — Wed, 20 Aug 2008 18:44:46 +0000

Die Remotedesktopverwaltung ist jedem Administrator sicherlich ans Herz gewachsen. Dass durch das Aktivieren der Remotedesktopverbindungen auch User zumindest schon einmal bis zum Logonfenster des Servers kommen, ist hier aber ein kleines Ärgernis bzw. Sicherheitsrisiko. Zumindest wird der eine oder andere User versuchen, ob ihm eine erfolgreiche Anmeldung möglich ist. Man könnte natürlich den Zugriff auf RDP durch entsprechende Firewallregeln schützen. Das ist aber unter gewissen Umständen nicht so einfach möglich.

Ein nützliches Tool, was ich schon länger in meiner Werkzeugkiste habe, ist „2xSecureRDP4“. Mit diesem Tool hat man die Möglichkeit, seine RDP Zugänge besser abzusichern. Der Administrator kann hier die RDP Verbindungen auf Basis der IP-Adresse, der MAC Adresse, des Client Computernamens, der Clientversion oder auch der Tageszeit festmachen. Dadurch ist diese Lösung wesentlich flexibler als das Einrichten von Firewallregeln. Wer es möchte, kann dann auch noch für die einzelnen Filter eigene Popup Meldungen definieren, die dem User dann angezeigt werden, wenn er einen Verbindungsversuch startet, der auf einen Filter passt. Alles in allem ein sehr nützliches Tool, was zudem auch noch Freeware ist und unter Windows Server 2000 und Windows Server 2003 installiert werden kann. Heruntergeladen werden kann es z.B. unter http://www.download25.com/2x-securerdp-for-terminal-services-download.html.

Hotfixes über RDP einspielen: Nur per Konsole

Nils Kaczenski — Tue, 10 Jun 2008 07:25:22 +0000

Die Information ist nicht mehr ganz taufrisch, aber sie hat sich noch längst nicht rumgesprochen: Wer einen Windows-Rechner per RDP mit Updates versorgt, sollte dies immer über die RDP-Konsolensitzung tun. Anderenfalls kann es passieren, dass der Neustart der Maschine nicht funktioniert. Also: Die RDP-Sitzung zum Patchen mit "-console" (älterer RDP-Client) bzw. "-admin" (neuerer RDP-Client ab 6.1; mitgeliefert bei Vista und Windows Server 2008) aufrufen.

Warum das so ist, erläutern zwei Artikel sehr schön:

[TechNet Team Blog Austria : Hotfix Installationen, Remote Desktop, Reboot - und keine Verbindung mehr]
http://blogs.technet.com/austria/archive/2008/06/09/hotfix-installationen-remote-desktop-reboot-und-keine-verbindung-mehr.aspx

[Ask the Performance Team : Hotfix Installs, Remote Desktop and the Reboot that wasn't ...]
http://blogs.technet.com/askperf/archive/2008/03/18/hotfix-installs-remote-desktop-and-the-reboot-that-wasn-t.aspx

faq-o-matic.net » Terminal Server

Microsoft Office 2010 Standard auf Remotedesktopserver Windows 2008 R2 aktivieren

Verwandte Beiträge:

Troubleshooting für lange Anmeldezeiten auf Terminalservern

Verwandte Beiträge:

Mandatory Profiles – Standardmäßig unsicher?

Verwandte Beiträge:

Terminalserver: Den Protected Mode des Adobe Reader X abschalten

Den Protected Mode zentral abschalten – GPP-Methode

Den Protected Mode zentral abschalten – ADM-Methode

Verwandte Beiträge:

RDP-Verbindungsmanager für Admins

Verwandte Beiträge:

Terminalserver-Profileinstellungen in AD: Die ungenutzte Neuerung

Verwandte Beiträge:

TS Web Access 2008 über ISA Server veröffentlichen

Verwandte Beiträge:

Terminal Server 2008 einrichten

Verwandte Beiträge:

RDP absichern – aber wie?

Verwandte Beiträge:

Hotfixes über RDP einspielen: Nur per Konsole

Verwandte Beiträge: