tolan

Hallo, danke schon mal für die Antwort. Von Trend Micro wird folgendes genutzt bzw. ist aktiv: Smart Scan, Echtzeitsuche, Web Reputation, URL-Filter. Ich könnte mir vorstellen, dass es an den letzten beiden Punkten hängt. Darüber wird denke ich auch schon die WSUS-Konsole kaputt gegangen sein. Die Firewall von Trend Micro ist aber nicht aktiv, nur die Windows Firewall. Aber da sind die Portfreigaben wie auf dem anderen Terminalserver gesetzt. mfg tolan

Guten Morgen, gestern viel mir aufgrund eines anderen Problems auf einem unserer Terminalserver auf, dass bei der Lizenzdiagnose angeblich keine Lizenzen zur Verfügung stehen und auch keine Details unserer zwei RDS-Lizenzserver angezeigt werden: Auf dem anderen Terminalserver wird alles korrekt angezeigt. Lizenziert wird pro Gerät. Die Umgebung: Terminalserver: 1 x Windows Server 2008R2 1 x Windows Server 2008R2 mit Trend Micro -> Problemserver RDS-Lizenzserver: 1 x Windows SBS 2011 (für Server 2008 RDS-CALs) 1 x Windows Server 2012 (nicht R2, für Server 2012 RDS-CALs) Auf dem Problemserver können sich die Clients ohne Probleme anmelden. Auf den Lizenzservern ist im RD-Lizenzierungsmanager auch ersichtlich, dass die Lizenzen korrekt vergeben werden. Als ich testweise die Lizenzserver aus der Konfiguration entfernt habe, kam nach neuer Anmeldung der Hinweis, dass die 120 Tage Grace Period abgelaufen ist und sich kein Client mehr anmelden kann. Danach habe ich die Lizenzserver wieder eingetragen und die Meldung bzgl. des Testzeitraums ist wieder weg und man kann sich normal anmelden. Es funktioniert also eigtl. wie gewünscht! Was ich sonst noch geprüft / versucht habe: - Lizenzserver über GPO festlegen - Lizenzserver über IP-Adressen angeben - Trend Micro deaktiviert - Firewalleinstellungen mit dem funktionierenden TS abgegelichen, keine Unterschiede - mit Network Monitor geschaut ob irgendwelche Pakete nicht durchgehen, aber das sieht nicht danach aus - EventLogs durchsucht, aber bzgl. Problemen bei der Lizenzierung steht da nichts drin Ich habe noch die Vermutung, dass es irgendwie mit Trend Micro zusammenhängen muss, weiß allerdings nicht, ob das früher vor der Installation auch schon so war. Ich habe die Serverumgebung dieses Jahr erst übernommen. Auf dem SBS war Trend Micro aber auch schon schuld daran, dass der WSUS bzw. dessen Konsole nicht funktionierte. Deshalb wäre das schon recht naheliegend. Hat vielleicht jemand noch eine Idee oder weiß vielleicht ob das an Trend Micro liegt? Ansonsten muss ich das wohl mal nachstellen, indem ich einen TS aufsetze, mit den Lizenzservern verbinde und danach Trend Micro installiere. Schon mal schöne Festtage :) mfg tolan

Hallo, wir haben nun einen 2012R2 als RDG aufgesetzt und diesmal mit der Domäne "verdrahtet". Dort dauert die Anmeldung nun nicht mehr so lange. Unsere vorherige Lösung ist wohl nicht so alltagstauglich. mfg tolan

Hallo zusammen, im Einsatz ist ein Remotedesktopgateway unter Windows Server 2008R2. Das Remotedesktopgateway befindet sich allerdings nicht in der Domäne, sondern nur in der abgekapselten DMZ. Wir melden uns also von außen nicht direkt über die Domäne an, sondern zuerst über einen lokalen Benutzeraccount auf dem Remotedesktopgateway und bauen danach die Verbindung zum Server im Intranet auf (Port 3389 vom RDGateway ist in unserer Firewall zum Server im Intranet freigegeben) und müssen dort dann die Domänen-Anmeldeinformationen angeben. Als Zertifikat nutzen wir noch ein Self-Signed-Zertifikat. Soweit funktioniert das alles gut. Das Problem ist nur, dass der Aufbau sehr zäh ist. Es kann schon über eine Minute dauern bis man auf dem Server im Intranet aufgeschaltet ist. Den häufig genannten Tipp auf dem Client den Haken für die Gatewayeinstellungen bei "Remotedesktop-Gatewayserver für lokale Adressen umgehen" rauszunehmen habe ich bereits von Anfang an so konfiguriert. Beim Mitloggen des Traffics über den Netzwerk Monitor fiel mir so nichts auffälliges auf, bis auf den mehrfach durchgeführten SSL-Handshake. Dafür werden aber nur ein paar Sekunden aufgewendet. Hat vllt. jmd. eine ähnliche Umgebung und das gleiche Problem und am besten noch einen Lösungsweg?

Ist weg!

Lösung: Es lag bei uns daran, dass zur gleichen Zeit ein weiterer Backupjob eines anderen Servers angestoßen wird. Anscheinend gibt es dann wohl ein Problem beim Logfile-Schreiben bzw. Robocopy ignoriert dann wohl ein kurzes Timeout und die Log-Infos aus diesem Zeitraum gehen verloren. Das Log wird jetzt halt erst lokal erstellt und am Ende ans Ziel transferiert.

Hallo, aufgrund von Zeitmangel habe ich einen Voucher-Code, den ich vergünstigt in der Berufsschule bekommen habe, günstig abzugeben. Der Voucher ist gültig bis zum 7/2/2013 11:59:00 PM und müsste auch für einen zweiten Versuch bei Nichtbestehen gültig sein (wurde so zumindest gesagt). Er gilt für die Prüfung 70-640 (Konfigurieren von Windows Server 2008-Active Directory). Bei Interesse bitte melden. mfg tolan

Update: Anscheinend funktioniert das Logging ab und an. Heute z.B. ist es auch für den betroffenen Ordner korrekt mitgeloggt worden. Hat jemand eine Idee woran es noch liegen könnte? Auch wenn das Logging nicht geklappt hat wurden die Dateien kopiert, somit gehe ich davon aus dass der Abbruch des Loggings sich nicht negativ auf das Kopieren auswirkt. Kann es problematisch sein, dass das Log-File im Zielordner des Kopiervorgangs abgelegt wird? (Zugriffsprobleme etc.) mfg Tolan

Hallo zusammen, verschiedene Ordner (diese beinhalten VM's, die zuvor heruntergefahren werden) werden von uns in einem PS-Skript in einer foreach-Schleife mit folgendem Robocopy-Befehl gesichert: robocopy $Source $Destination /MIR /LOG+:$Log /NP /NJH; Das Kopieren funktioniert soweit und auch das Logfile wird, mit Ausnahme eines zu kopierenden Ordners, problemlos erweitert. Für den entsprechenden Ordner sieht es im Logfile folgender Maßen aus: An dieser Stelle wird nicht weiter geloggt und es fängt dort später das Logging für den nächsten Ordner an: Ich habe das ganze nun auch mit einem vollständigen Log probiert, also so dass quasi jede 0,1% Kopierfortschritt dort verzeichnet werden. Aber das Log endet genau an der gleichen Stelle. Manuell funktioniert das auch nicht. Der betroffene Ordner wird, soweit ich das testen konnte, aber trotzdem vollständig kopiert. Die virtuelle Maschine ließ sich starten, sodass mit den Daten wohl alles in Ordnung ist. Kann es an der Größe der Datei liegen? (Knapp 100 GByte) Eventuell hat ja jemand schon einmal so etwas beim Logging mit Robocopy erlebt. Danke schon mal.

Hallo, danke für den Hinweis, der IE ist auf dem gleichen Patchlevel. Die RDP-Versionen scheinen warum auch immer unterschiedlich zu sein. Ich werde in der Richtung mal weiter sehen und testen.

Hallo, danke erst einmal für die Antwort. Das hatte ich versucht. Ich habe das Zertifikat sogar manuell über MMC unter dem Computerkonto hinzugefügt. Was mich nur stark wundert ist, dass es auf einem Klon dieses Computers (wurde vor längerem erstellt, aber an den Einstellungen hat sich nichts geändert) ohne irgendein manuelles Eingreifen einfach so funktioniert. mfg tolan

Hallo zusammen, ich versuche mal mein Problem möglichst kurz zu fassen. Hier die Ausgangssituation: Unser Terminalserver (Windows Server 2008R2) wird genutzt um von dort aus Verbindungen auf Kunden-Server herzustellen (per VPN, PPTP etc.). Nun muss für einige Kunden über einen im Internet zugänglichen Web-Access (den im Windows Server 2008R2 integrierten) eines Kunden eine Remote-App (eine RDP-Verbindung auf einen Server des Kunden) ausgeführt werden. Das Problem: Beim Versuch die Remote-App zu starten kommt folgende Fehlermeldung: Was ich versucht bzw. rausgefunden habe: - Sicherheitskonfiguration des IE wurde angepasst, die Seite ist den "Vertrauenswürdigen Seiten" hinzugefügt. - Die Sperrliste (den Link dahin kann man ja unter „Zertifikat anzeigen“ einsehen) konnte manuell problemlos heruntergeladen werden. - Das Zertifikat und die Sperrliste wurden testweise sowohl unter dem Benutzer- wie auch unter dem Computerkonto manuell importiert (unter MMC > Zertifikate). - Auf einem identischen System (Klon des betroffenen Computers) funktioniert die Verbindung ohne Probleme und ohne einen manuellen Eingriff in die Zertifikatseinstellungen. Eine Auswertung in Procmon bzw. ein Mitsniffen des Netzwerktraffics haben keine Unterschiede auf den beiden Maschinen gezeigt. Wenn jemand das gleiche Problem hatte und es gelöst hat oder eine Idee hat wäre ich für einen Lösungsansatz dankbar. mfg tolan