Wolke2k4

In der Terminaldienstekonfiguration kann man für das RDP Protokoll Sitzungstimeouts (unter anderem auch für Leerlaufsitzungen) festlegen, hat der Admin der Fremdfirma das auch geprüft?

Zu dem Szenario habe ich auch ein paar Fragen. Wenn ich es richtig verstehe ist es problemlos möglich einen SBS als zweiten DC in eine Domain zu integrieren, die von einem W2K3 Standard Server gehostet wird? Die Replika und der ganze andere Schnulli funktionieren so als ob man zwei W2K3 Standard DCs aufsetzt? Es geht mir vor allem um die technische Kompatibilität zwischen SBS und Standard. Manchmal kann man ja garnicht so dumm denken als das MS da auch was beschneidet oder lizenztechnisch irgendetwas anders ist. Wobei wir dann schon beim nächsten Punkt wären, den Lizenzen. Wenn ich eine SBS Domain mit einem DC hochziehe muss ich für die Clients ja SBS CALs kaufen. Wenn ich nun als zweiten DC einen W2K3 Standard hinzufügen möchte kann/muss/darf ich dann normale CALs nutzen/kaufen? Was ist, wenn ich zuerst einen W2K3 Standard DC hochziehe und danach einen SBS als zweiten DC installiere, wie wird dann lizenziert? Gruß und Danke für die Antworten

Tritt der Timeout während des arbeitens in der RDP Verbindung auf? Wie schaut es bei unterschiedlichen IE Versionen aus?

Aber "wir" sprechen schon noch von einem zusätzlichen Server, der Terminal Server sein soll und nicht von der selben Maschine? Falls nicht sei nur nebenbei erwähnt, dass der SBS keine Terminal Dienste bereitstellt...

Aber die Backup Exec Dienste starten schon noch alle?

Hast du mal versucht sie auszuschneiden und sie dann zu löschen?

Wir haben schon des öfteren erlebt, dass RDP Verbindungen sowas wie ein "Eigenleben" haben und sich schon mal gern aufhängen und somit kein connect mehr möglich ist. VNC ist dann oftmals eine brauchbare Alternative.

Also für den Terminal Server dann doch nur eine Lizenz? Office wird ja schliesslich nur einmal installiert... :)

NAT würde dann auch ohne Internet funktionieren, wenn der Zugriff von beiden Netzwerken auf eine überschaubare Zahl von zentralen Ressourcen geschehen soll. Oder man nutzt halt das DMZ Prinzip... Alternativ fällt mir gerade ein, dass es auch möglich wäre die entsprechenden Hosts mit jeweiles einer zweiten IP und somit natürlich auch einem zweiten IP Adressbereich auszustatten. Das würde also bedeuten, dass entweder der Kunde oder Ihr an allen betreffenden Hosts jeweils eine zusätzliche IP Adresse vergebt/einstellt. Wenn die Geschichte sauber laufen soll sollte man in der Beziehung sicher auch das DNS mit einbeziehen, je nachdem was man machen will.

Viel Spass bei der Suche. Die Regeln des Routing und die Standards, die fest in der Hardware implementiert sind, wirst auch Du nicht umgehen können. Am Ende ist es nicht nur die Theorie sondern die Praxis die Dir zeigen wird, dass es ebend nicht geht... Du kannst ja mal versuchen zwei gleiche DNS Einträge bei DynDNS oder einem W2K/W2K3 Server zu erstellen, dann wirst Du sehen was geht und was nicht. Ich hatte vor ein paar Wochen bspw. den Fall, dass ein Kunde eine Verbindung via VPN zu einem ASP Server herstellen wollte. Der Kunde und die SAP Leutchens haben sich gewundert warum die VPN Verbindung zwar aufgebaut wird aber keine Verbindung zum Server hergestellt werden kann. Ein Blick mittels ipconfig/all verriet, dass für das VPN der selbe IP Adressbereich verwendet wurde wie im lokalen Netz (192.168.10.0/24). Und obwohl im lokalen Netz die IP Adresse des ASP Servers nicht vergeben war konnte die Verbindung zu selbigem nicht hergestellt werden. Es war gleich klar, dass eine Änderung des IP Netzes notwendig war... und siehe da, die Verbindung war auf einmal möglich. Im übrigen kann man sich das Szenario mit den selben IP Netzen auch ganz einfach selber nachbasteln... und spätestens beim erstellen der statischen Routen oder beim konfigurieren der Routing Protokolle wird Dir klar werden warum es nicht geht.

Bei unseren Kunden erleben wir regelmäßig, dass die LAN Verbindungen unter W2K/XP deaktiviert sind/werden. Das betrifft nicht immer die selben Nutzer sondern tritt immer mal im Abstand von mehreren Wochen/Monaten bei dem einen oder anderen Kunden auf und ist immer ein Einzelfall. Da wird dann rumgeheult von wegen "Ich habe kein Netz mehr." und "Ich habe nichts gemacht." Ein ipconfig oder ein Blick in die Netzwerk und DFÜ Verbindungen entlarvt recht schnell den Schuldigen: Die deaktivierte LAN Verbindung. Schon oft habe ich mich gefragt ob es wirklich die DAUs sind oder hier ein echter Bug hinter steckt. Ich selber habe es nämlich noch nie erlebt, dass sich eine LAN Verbindung unter W2K/XP einfach so deaktiviert.

Interessantes Szenario, was aber IHMO nicht funktionieren dürfte (zumindest unlizenziert). Nach dem Administrator ist jeder Nutzer, Nutzer ob er nun zur Gruppe der Administratoren gehört oder nicht. Ich habe es zwar selber noch nicht ausprobiert aber ich kann mir nicht vorstellen, dass außer dem Administrator ab der 2. concurrent Session noch weitere Sessions aufgebaut werden können. Außer das Geld für die TS CALs zu sparen fällt mir ehrlich gesagt auch kein logischer Grund für ein solches Szenario ein. Der einzige Grund wäre, wenn eine Anwendung nur mit dem Nutzer Administrator läuft, hatten wir auch schon. Nur hinterher hat sich bis jetzt immer herausgestellt, dass das Problem woanders lag und der Zugriff auf "einfachen" Nutzern ermöglicht werden konnte. Ansonsten kosten TS CALs für 5 Nutzer nun wirklich nicht die Welt... Du hast erwähnt, dass ein Lizenzserver bereits läuft. Wird der vom TS denn auch genutzt? Wenn der TS richtig lizenziert ist und in der Terminaldiensteverwaltung die entsprechende Option aktiviert ist kann sich der Administrator und auch andere Nutzer so oft am TS anmelden wie er/sie will/wollen. Für jede Session wird eine eigene SitzungsID erstellt. Problemlos wird die Sache bei mehrfacher Anmeldung aber bestimmt nicht ablaufen...

Meldest Du Dich als Administrator an? Was siehst Du, wenn Du auf dem Server in die Eigenschaften des Arbeitsplatzes gehst und den Karteireiter Remote auswählst? Wo sind die Haken gesetzt und wo nicht? Alternativ kann ich VNC zur Fernwartung empfehlen bis das RDP Problem gelöst ist...

Was meinst Du mit Prüfbits? Ein Routing zwischen den selben IP Adressbereichen ist nicht möglich! Aus diesem Grund darf weder im Internet noch in den nach RFC 1918 festgelegten IP Netzen eine IP doppelt vergeben werden. Und aus dem selben Grund werden die IP Netze nach RFC 1918 im Internet nicht geroutet. Das ist auch logisch, da der Router bzw. andere Endgeräte das Datenpaket nicht doppelt zuordnen/weiterleiten/routen können. Beispiel: PC AA (192.168.143.1) befindet sich in seinem lokalen Netz A (192.168.143.0/24) und will ein Datenpaket an PC BB (192.168.143.2) schicken, dass sich im entfernten Netz B befindet (192.168.143.0/24). Der Versand dürfte in der Regel schon dann scheitern, wenn die Entscheidung über die Weiterleitung des Famres auf Layer 2 getroffen wird. Spätestens wenn der Switch, der das entsprechende Datenpaket erhält in seine ARP Tabelle schaut wird er das Paket dort hin weiterleiten wo sich PC BA (192.168.143.2) befindet. Und das ist in der Regel sein lokales Netz A. Davon ab ist mir nicht bekannt, dass ein Switch ein und den selben ARP Eintrag mehreren IP Adressen zuordnen kann. Und selbst wenn er es könnte, wohin mit dem Paket. Es ist wie beim DNS und bei der Post. Es kann nur eine eindeutige Adresse geben. Die Alternative ist also den IP Adressbereich umzustellen oder Dienste, die für beide Netzwerke bereitgestellt werden sollen in eine DMZ zu packen. Hier jedoch muss man schon genau planen ung gucken. Ein absurder Gedanke der mir dabei noch kommt ist, was passiert, wenn man die Subnetmask bei einem der Netze ändert... Vielleicht könnte auch VLSM eine Möglichkeit bieten aber da stecke ich zu wenig in der Materie um eine brauchbare Antwort zu geben. Das mit den IP Adressen würde mich allerdings auch interessieren. Schreib mal bitte die Subnetzmasken auf... Ansonsten sieh's einfach so. Es könnte schlimmer sein, nach RFC 1918 sind die Netze wenigstens adressiert. :D

Was sonst ausser Veritas? :)

Was'n Zufall... ich durfte mich vorhin gerade mit einem DSL-I10 rumschlagen. Auch da lief die CAPI instabil! Teilweise war es sogar so, dass bei Anwahl von Rufnummern mit der CAPI die Firmware auf dem Router umgestellt wurde... ich und der Lancom Mitarbeiter waren sehr erstaunt. Auf anraten von Lancom habe ich dann die aktuellste Firmware eingespielt und siehe da... Also FW downloaden, Config sichern und neue Firmware einspielen...

Generell gilt, was auf dem Windows Terminal Server läuft läuft auch auf dem Presentation Server von Citrix (kenne bisher nur eine Anwendung wo es Probleme gab)... Ansonsten muss man von Fall zu Fall schauen. Am besten ist es, wenn man die Hersteller der Software, die über den TS/Citrix Presentation Server bereitgestellt werden sollen fragt, wie es mit der TS Tauglichkeit der Software aussieht.

Wichtig ist bei der Dimensionierung an die Zukunft zu denken bzw. die Maschine so auszubauen, dass später noch ein bissel RAM nachgesteckt werden kann. 1 - 2 GB reichen für 10 Nutzer locker.

Installiere den Lizenzierungsserver einfach in der W2K3 Domain. Den Lizenzierungsserver in der NT Domain lässt Du zunächst da wo er ist. Steht der Lizenzierungsserver in der W2K3 Domain, weisst Du deinem TS den neuen Lizenzserver manuall via Registry Eintrag zu (einfach mal im Forum suchen). Danach verbindest Du dich mit ein paar Clients auf den TS und schaust wie und ob die Sache korrekt abläuft (also ob der W2K3 Lizenzierungsserver TS CALs ausstellt). Wenn es läuft gibt es keinen Grund mehr den Lizenzierungsdienst in der NT Domain laufen zu lassen...

hehe der war gut... :D Wie dem auch sei, für die Relevanz dieses Threads kommt nur die Terminaldienstelizenzierung in Frage. Ob und wie der Rest mit "Papierlizenzen" korrekt eingekauft wurde ist wohl eher unbedeutend...

Hast Du mal drüber nachgedacht das Ganze mit Gruppenrichtlinien zu lösen?

Ich habe bis jetzt zwar noch nie was mit TSWEB zu tun gehabt aber IMHO muss der Port 3389 ebenfalls erreichbar sein. Und wenn ich das Script richtig interpretiere wird derzeit nur der 443 geforwarded... ?

Lokal am Client existiert der Drucker aber schon noch? Wie schaut es mit anderen Druckern aus? Werden diese ebenfalls nicht erstellt?

Bei der Installation des Lizenzierungsservers gibt es eigentlich nicht viel zu beachten. CD rein, Lizenzierungsserver installieren, fertig. Die Komponenten installiert er ja automatisch. Nachdem der Lizenzierungsserver installiert ist solltest Du von jedem PC/Server über die oben genannte URL auf den Lizenzierungserver zugreifen können...

Ich weiss ja nicht was Du für Terminal Server verwendest aber die von Microsoft kennen nur jeweils eine Lizenzierungsmethode (entweder, oder). Davon ab gibt es per User TS CALs erst seit W2K3 Um mal auf den Ausgangspost zurückzukommen. Die TS CALs kann man sich mit dem Terminalserverlizenzierungs Snap In licmgr.exe anzeigen lassen. Wo ist der TS Lizenzierungsserver überhaupt installiert?