werwolf

ist diese seite selber geschrieben, oder von irgendwo her eine standard - seite? selber geschrieben: html, javascript, php? standard: IIS standard seite, content-management, etc.? wird java benötigt um diese seite aufzurufen? sind meine fragen völlig ins schilf hinaus gefragt? und ich verstehe dich nicht richtig? gruss aus mittelerde werwolf

moin, Schilderung des Szenario: Ist: 1. Server - Windows 2000, SP4 = DC, AD, Printserver, FSMO, TS 2. Server Windows 2003, SP1 = MemberSrvr, Exchange Server 2003 (SP1) 3. Server Windows 2003, SP1 = MemberSrvr, Fileserver Soll: 1. Server - Windows 2003, SP1 = auf neuer Hardware, DC, AD, FSMO, TS 2. Server - Windows 2003, SP1 = MemberSrvr, Exchange Server 2003 (SP1) 3. Server - Windows 2003, SP1 = MemberSrvr, Fileserver 4. Server - Windows 2000, SP4 = MemberSrvr, Fileserver, Printserver, Profile-Server (war ursprünglich der DC) Beim Studium all der guten posts, inkl. Link Angaben zur Microsoft Knowledgebase tauchen für mich zwei Fragen auf. Exchange Server Schema im Active-Directory? ---------------------------------------------------- Muss ich bei diesem Szenario, beim Umzug der Domänen-Geschichte auf irgendetwas spezielles achten, in Bezug auf das Exchange Schema? Ist das wirklich so, dass sich im oben beschriebenen Ist-Zustand das Exchange Schema (denn der Mail-Server ist Member-Server) ins Active Directory reingeschrieben hat? Diese Frage entsteht, weil ich im 325379 der MS Knowledgebase nur Hinweise finde, die sich auf Exchange 2000 beziehen. Backup nach Aktualisierung des W2K-DC, vor ADPREP ------------------------------------------------------------- Darf ich mich sicher fühlen, wenn ich die Komplett-Sicherung mit dem Built-In NT-Backup mache? Hat da wer Erfahrung, musste schon mal jemand einen Domänen Umzug abbrechen, und den alten DC wiederherstellen? Ich werde den DC und den Exchange Server komplett sichern. Besten Dank für Euren Antworten Gruss aus Mittelerde

hallöchen, falls dieses problem noch vorhanden ist, sollte die lösung auf dieses problem relativ einfach sein. Im Registry der Notebooks einen bestimmten Eintrag erstellen. HKEY_CURRENT_USER\Software\Microsoft\Terminal ServerClient\Default\AddIns\RDPDR Hier ein neues D-WORD erstellen "FilterQueueType" (ohne") mit dem HexWert: FFFFFFFF gruss aus mittelerde P.S: der link dazu: http://support.microsoft.com/?kbid=302361 meine vermutung zu den notebooks: dass die drucker weder seriell noch parallel angeschlossen sind, sondern via usb. wenn nicht, dann musst du schlicht und ergreifend mit mehr input kommen. hint: auf TS und RDP-Client muss die gleiche Druckertreiber Version installiert sein (Ein Muss!)

sie haben auf dem alten link eine weiterleitung eingerichtet....

meine zusätzliche frage an kohn wäre noch.... in der domäne laufen im moment 3 server: srv1 w2k sp4 -> DC srv2 w2k3 sp1 -> memberserver u. exchange server srv3 w2k3 sp1 -> memberserver u fileserver nach dem upgrade wärs: srv1 w2k3 sp1 -> DC (der neue) srv2 w2k3 sp1 -> membersrv u. exchange srv srv3 wk23 sp1 -> membersrv u. file srv srv4 w2k sp4 -> printserver (ehemals dc) meine frage: wie siehts hier aus mit dem exchange schema auf dem DC? kann ich trotzdem deinen upgrade weg verwenden? gruss aus mittelerde

Norman Virus Control... Während des Setups auf dem Verteil-Server hast Du sogar ein Flag, das gesetzt werden kann, ob mit oder ohne Terminal-Server Gruss aus Mittelerde

Ich möchte mich dem post von Hirgelzwift anschliessen... sowas hatte ich auch schon mal, bei einem 2000er DC. Da es damals für mich ein bytheway-könntest-du-noch-schnell-hier-Problem war, hab ich die Grösse dann einfach angepasst, seitdem ist Ruhe. :rolleyes: Gruss aus Mittelerde

ein bisschen mehr aussage sollte da schon noch in deiner msg drin sein. falls du es so gelöst hast (dies ist meine interpretation), dass du den usern administratoren rechte gegeben hast, dann wär das der falsche weg. ich habs so gelöst: Falls diese Gruppe auf dem DC noch nicht existiert: Erstelle eine Gruppe namens Remotedesktopbenutzer (Eigentlich sollte diese bereits existieren, wenn nicht, hast du einen Win2000 DC, wenn ja, dann ists ein W2K3 DC. Diese Gruppe in der Richtlinie lokale Sicherheitseinstellungen im folgenden Abschnitt definierenderweise einfügen: Sicherheitseinstellungen/lokale Richtlinien/Zuweisen von Benutzerrechten Da findest Du irgendwo (ein bisschen suchen sollst auch Du :-) ) Anmelden über Terminaldienste zulassen und genau hier kommt diese oben erwähnte Gruppe rein. Falls es immer noch nicht geht... Gehst Du wiederum auf dem Terminalserver in die "Terminaldienstekonfiguration" Abschnitt Verbindungen, hast Du rechts eine vordefinierte RDP-TCP Verbindung. Diese mit der rechten Maustaste anklicken, ins Register "Berechtigungen" klicken und dort gleich auf die Schaltfläche "Erweitert" anklicken. Dort wiederum die Schaltfläche "Hinzufügen" anklicken und unsere Gruppe einfügen... und Du wirst staunen, was man da so alles anhakerln kann. :-)) Nach diesem Wege sollte es den Usern nun nicht mehr möglich sein, den Server Herunterzufahren. Und sonst, einfach das nächste mal ein bisschen mehr Infos posten. Dann hat man mehr "Fleisch am Knochen" Gruss aus Mittelerde

Die Lösung des Problemchens war: Regedit auf dem Client: [HKEY_CURRENT_USER\Software\Microsoft\Terminal Server\Client\Default\AddIns\RDPDR] neues DWORD erstellen, mit dem HexWert: "FilterQueueType"=FFFFFFFF und simsalabimmm Ich konnte drucken. Und hat mir noch gleich die Einstellungen des Windows Clients übernommen, welches der Default Printer ist, und welcher nicht. Ich danke Euch wieder einmal, für alle Eure Inputs, die für mich einerseits lehrreich sind und wertvollen Input liefern. Gruss aus Mittelerde

ok. begriffen... aber wie geschieht dann das anschnallen des TSPORTS? automatisch oder mache ich die drucker-definition von hand?

Hallo Hirgelzwift und Operator... Besten Dank für Euren Input. Der Hint für mich war: Druckertreiber auf dem Server installieren. Der eine der beiden Druckertreiber ist bereits installiert. Ich bin davon ausgegangen, dass sich ein TS-Druckerport wie z.b.: TS001 alles selber macht. Hab ich wohl dem ****** wohl mal wieder zuviel zugemutet. :) Ich konnte bis jetzt noch nicht ausprobieren, obs mit Druckertreiber auf Port zuweisen nun klappt, da der User sehr weit weg ist. Meine Folgefrage: Wenn ich nun in einer solchen TS-Verbindung einen Druckertreiber auf sagen wir TS001 (PC01:PRN2) anschnalle, bedeutet dies, dass dieser virtuelle Druckerport besetzt ist? Ich somit diesen Port für einen anderen TS-Benutzer und allenfalls einen anderen Drucker nicht mehr einsetzen kann? Besten Dank wie immer und Gruss aus Mittelerde der Werwolf

Hallo miteinander Ich habe da ein Phänomen/Problem wo ich einfach nicht rauskriege... Situation: Windows 2003 Small Business Server -> DC Windows 2003 Server Stand. Edition -> Terminal Server (mit TS-CALS) Windows XP, SP2 -> Client, der via Remotedesktopverbindung im TS einloggt -> 2 Drucker angehängt. 1. Drucker via USB, 2. Drucker via ADSLRouter/Hub mit fixer TCP/IP Adresse an PC "gemapped". Ich verbinde mich also mit dem Win XP Client am TerminalServer und kriege wunder- barstens eine Verbindung. Wenn ich den Explorer im Client öffne, sehe ich unter Arbeitsplatz auch schön brav die automatisch angehängen Freigaben des Clients (Drive C, Drive D, Drive E). Nur die Drucker sind nicht sichtbar? Ich habe die Einstellung des BuiltIn Tools Remotedesktopverbindung auf dem Client bereits überprüft, und sichergestellt, dass der Haken unter lokale Ressourcen fürs Drucken drin ist. Ich hab ebenfalls nachgeschaut, ob im TSDienste-Konfiguration Register "Berechtigung" das Flag "virtuelle Kanäle" im erweiterten Berechtigungsmodus für die Remotedesktopbenutzer-Gruppe gesetzt ist. Ebenfalls beim Register "Clienteinstellungen" überprüft, dass das Flag gesetzt ist bei "Bei Anmeldung Verbindung zu Clientdruckern herstellen". Ergebnis: nada, nix, nö, keine Drucker... Hat mir jemand einen Input an was es sonst noch liegen könnte? Ich danke schon mal bestens im voraus für jeden Input. Gruss aus Mittelerde der Werwolf

es gibt den lösungsansatz der lokalen gruppenrichtlinie der clients: auf "netzwerkverbindungen warten" aktivieren. damit die netzlaufwerke sauber angeschnallt werden, da xp ja auf geschwindigkeit getrimmt wurde. auch wenn es nicht direkt mit dem lösungsansatz von den von dir angegebenen kbs hat, vielleicht hilfts was. das andere zu wissende wäre: wenn ein switch zwischen server und clients liegt, ob die nics der compis und die ports des switches alle auf auto-connection oder explizit alle auf z.b. half oder full duplex gesetzt sind.

.....

hab was ähnliches von einem bekannten diese woche gehört, der verwendet auch antivir. wenn es der antivir.de ist, nimm mal ein anderes antivir tool. vielleicht liegts an dem. ausprobiert hab ich es aber nicht.

Lieber IThome Ich danke Dir für Deinen Hint. :cool: Das Geheimnis ist zuTage getreten. Und ich bedanke mich ebenfalls bei allen anderen, die mir ebenfalls mit Tips und Hints zur Seite standen. Lösung: Im Terminaldienstekonfiguration gibts einen Ast namens Verbindungen, dort ist eine vordefinierte Microsoft RDP drin. klickt man mit der rechten Maustaste drauf, öffnet sich eine kleine Welt ;). Dort konnte ich dann meine selberdefinierte "Remotedesktopbenutzer" hinzufügen. Seltsam bleibt allerdings, dass die Gruppe "Remotedesktop User" nicht angezeigt wird. Meine Vermutung, da der DC ein SBS Server ist, und dort das RDP nur den Administratoren vorbehalten ist, muss an dieser Gruppe irgendwas rumgeschraubt worden sein. Ansonsten funktioniert zumindest das Login und ein paar Test-Starts von Applikationen fein säuberlich. Vielen Dank und Gruss aus Mittelerde

Das Flag "Allow Logon Terminalserver" ist bereits bei allen Domain-Usern, die sich via Terminal-Server anmelden dürfen, gesetzt. Ich habe ebenfalls schon versucht, mit einer von Hand erfassten Gruppe zu arbeiten: "Remotedesktopbenutzer", welche ich übrigens im "Built-in" Container platzierte. Ein anderer Versuch war, die Richtlinie auf dem Terminalserver von Hand zu ändern und die Gruppen "Remotedesktop User" und "Remotedesktop" (ich halte mich hier übrigens explizit an die Schreibweise von Microsoft) hinzugefügt. Ging auch nicht. Weiss irgendwer, was sich denn genau hinter dieser Security-Gruppe verbirgt? Oder weiss jemand was konkretes über die SID? Könnte es sein, dass die SID der deutschen Sprache und der englischen Sprache dieser Gruppe ein und dieselbe sind und sich somit irgendwo in den Annalen der Domänen-Welt beissen? Gruss aus Mittelerde

Hi zusammen... Erst mal zur Situation: - Windows 2003 Small Business Server (OS-Sprache: english) <- DC - Windows 2003 Standard Edition Server (OS-Sprache: deutsch) <- Member Server auf diesem Server ist der TerminalServer installiert, inkl. gültiger CALs (!) Ich habe also diesen TS installiert und aktiviert und kann mich mittlerweile auch wunderbar mit dem Administrator einloggen. Sobald ich aber mit einem Domänen-Benutzer einloggen will, kommt die Meldung der Verweigerung. Ich habe diesen Benutzer natürlich schön brav in die Gruppe "Remotedesktop User" eingefügt, und diese Gruppe über die Gruppenrichtlinie des Domänen Controllers im "Anmeldung auf dem Terminalserver zulassen" hinzugefügt. Wenn ich den Domänen Benutzer in die Administratoren-Gruppe des Terminal Servers hinzufüge, dann kann ich mich anmelden. Ist er dort entfernt, dann funktionierts nicht mehr. Kann mir da jemand Hilfe bieten? Gruss aus Mittelerde