Archiv der Kategorie: Windows Server 2003

Drucker in RDP-Sitzung verwenden

2 Antworten

Drucker in RDP Sitzung verwenden

Problem: Ein „lokal“ installierte Drucker eines PCs soll ebenfalls in einer RDP-Sitzung verwenden werden. Das Wort „lokal“ bedeutet hier, dass der Drucker über USB, Netzwerk , LPT oder eine beliebige andere Schnittstelle bereits auf dem PC eingerichtet ist.

Lösung: Zuerst einmal ist es wichtig, dass der Druckertreiber des Druckers der in der RDP-Sitzung verwendet werden soll auf dem Ziel PC/Server installiert ist. Wenn kein Druckertreiber Vorhanden ist, dann lässt sich auch eine passende Fehlermeldung dazu im Eventlog System auf dem Ziel PC/Server finden. Bsp. Ihr habt einen HP Laserjet 200 Pro bei euch auf dem PC installiert und Ihr wollt diesen Drucker in einer RDP-Sitzung (Server01) verwenden. Also muss sichergestellt sein, dass der Druckertreiber HP Laserjet 200 Pro auf dem Server vorhanden ist. Als Nächstes müssen die lokalen Drucker/Ressourcen natürlich in der RDP-Einstellung freigegeben sein.

RDP_Drucker_Freigeben

RDP Einstellung Drucker und Zwischenablage freigeben.

RDP_Drucker_Ports

In den Erweiteren Einstellungen sollten noch die Ports freigegeben werden, damit auch alle Anschlüsse weitergereicht werden.

Sollte das Ganze noch nicht funktionieren, dann müsst Ihr gegebenenfalls noch einen Regestrierungseintrag vornehmen [1]. Führen Sie dazu folgende Schritte aus, und beenden Sie anschließend den Registrierungseditor:

Klicken Sie auf Start, klicken Sie auf Ausführen, geben Sie regedit ein, und klicken Sie anschließend auf OK. Suchen Sie den folgenden Schlüssel in der Registrierung, und klicken Sie darauf: HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default\AddIns\RDPDR Zeigen Sie im Menü Bearbeiten auf Neu , und klicken Sie anschließend auf DWORD-Wert . Geben Sie FilterQueueType ein, und drücken Sie anschließend die [EINGABETASTE]. Klicken Sie im Menü Bearbeiten auf Ändern. Geben Sie FFFFFFFF ein, und klicken Sie danach auf OK. Quelle: [1]

[1] http://support.microsoft.com/kb/302361

Windows 7 NewSID zerstört Installation

Schreibe eine Antwort
Hallo Leute,
ich hatte vor Kurzem ein etwas ernüchterndes Erlebnis. Ich war mit einem Problem beschäftig bei dem nicht alle Windows 7 Clients in der WSUS Verwaltung auftauchten. Nach etwas hin und her stellte sich raus, dass in der Umgebung wohl einige Clients geklont wurden. Schnell bin ich dem meinem alten Halbwissen gefolgt und habe mit das Tool NewSID aus dem Internet geladen und ausgeführt.
Der Client, auf dem ich das Tool ausgeführt habe, wurde vor etwa 6 Monaten installiert und ist seit dem im täglichen Gebrauch. Nach stolzen drei Tagen war das Programm auch so weit durch. Ein Neustart des PCs brachte dann eine Überraschung in Form eines Blue Screens mit dem Errorcode 0x000000f4 hervor. Jegliche Bemühungen in Form von Systemwiederherstellungspunkt oder Reparaturinstallationen scheiterten kläglich und brachten keine Besserung.
Eine kurze Suche im Internet brachte dann auch schnell zutage, dass ich nicht der Einzige war der das probiert hat. Daher an dieser Stelle: Es ist dringend von dem Tool NewSID abzuraten, wenn es um ein anderes Betriebssystem außer Windows XP geht.
An dieser Stelle möchte ich auf einen Artikel von Mark Russinovich hinweisen. In dem diesem beschreibt er was es mit der SID auf sich hat und wieso er die Entwicklung des Tools eingestellt hat. Ich bin damals schon mal auf den Artikel gestoßen habe diesen aber nicht wirklich aufmerksam gelesen.
Interessant finde ich auch einen der letzten Sätze in dem der Autor drauf aufmerksam macht, dass die Domain Controller unter Windows ebenfalls eine identische SID haben. Anhand eines kurzen Tests konnte ich das Selbst überprüfen. In einer Umgebung mit drei Domain Controllern ( 1x Server 2003, 2x Server 2012) hatten die drei DC´s dieselbe SID.
Zum Schluss noch der Hinweis, dass ich in einem weiteren Artikel beschreiben werde wie das Problem der fehlenden Clients in der WSUS Konsole zu lösen ist.