Wolke2k4

Dann empfiehlt es sich natürlich eine eigene Farm anzulegen, die unabhängig von der bestehenden Farm ist. Grundlage von MetaFrame sind aber zunächst einmal die Terminaldienste von MS. Statt gleich mit MetaFrame anzufangen solltest Du Dich erst in die Materie Terminalserver und vor allem das Thema Lizenzierung reinarbeiten. Wie kritisch gerade die Lizenzierung ist sieht man an den häufigen Posts zu diesem Thema... Nachdem Du dann mit dem TS durch bist kannst Du Dich MetaFrame widmen. Kleine Tipp nebenbei. Zum Testen macht sich ein ordentliches Image Programm immer gut. So kann man schnell mal etwas rückgängig machen ohne den Server wieder komplett einzurichten...

Einen der Schuldigen habe ich erstmal gefunden und könnte ihn theoretisch mit einer ACL ausschalten, die wie folgt aussieht: access-list 102 deny ip 0.0.0.132 255.255.255.0 any access-list 102 deny udp any eq netbios-dgm any access-list 102 deny udp any eq netbios-ns any access-list 102 deny udp any eq netbios-ss any access-list 102 deny udp any range snmp snmptrap any access-list 102 deny udp any range bootps bootpc any access-list 102 deny tcp any eq 137 any access-list 102 deny tcp any eq 138 any access-list 102 deny tcp any eq 139 any access-list 102 permit ip any any Allerings habe ich jetzt noch ein weiteres Problem... wobei sich erst noch herausstellen muss ob es wirklich eines ist. Und zwar habe ich festgestellt, dass der Router in der Außenstelle (RouterB) sich trotzdem weiterhin einwählt. Die Sache scheint aber von ihm selber aus zu gehen zumindest denke ich, dass dies folgender Auszug von "sh caller full" aussagt: PPP: LCP Open, multilink Open, CHAP (<-->) Dialer: Connected to XXXXXXXX, outbound Type is ISDN, group Di1 Cause: snapshot <--- was um alles in der Welt ist das??? IP: Local 192.168.190.235 Bundle: Member of RouterA Counts: 63 packets input, 2537 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 63 packets output, 2747 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets Als Dialergrund wird also snapshot angegeben. Ich nehme an, dass dies etwas mit dem snapshot routing zu tun hat. Kann man die Geschichte optimieren, anpassen und/oder zeitlich begrenzen?

Das heisst, dass MS die Implementierung der per User Lizenzierung nicht bis zum final Release geschafft hat und die per User Lizenzierung momentan so wirksam ist wie die der normalen CALs. Aus technischer Sicht reicht derzeit das Vorhandensein eines Lizenzierungsservers im per User Mode. Lizenzrechtlich bleibt natürlich alles beim alten. siehe auch hier

Das werden sie auch weiterhin nicht, da bei der per User Lizenzierung der TS CALs derzeit keine Lizenzen ausgestellt werden...

Kann es sein, dass du per User lizenziert hast? Per User TS CALs werden derzeit vom Terminallizenzierungsserver nicht ausgestellt.

Funktioniert der Druck nur aus bestimmten Anwendungen nicht oder gibt es generell Probleme mit dem Drucken? Wie sind die Drucker auf dem MetaFrame Server installiert?

Hier die zweite Config RouterB = Außenstelle: version 12.3 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname RouterB ! boot-start-marker boot-end-marker ! enable password 7 xxxxxxxxxxxxxxx ! username RouterA password 7 xxxxxxxxxxxxxxx username RAS password 7 xxxxxxxxxxxxxxx no aaa new-model ip subnet-zero no ip domain lookup ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 description connected to LanB ip address 192.168.190.235 255.255.255.0 no keepalive ! interface BRI0 description connected to RouterA no ip address encapsulation ppp dialer rotary-group 1 dialer-group 1 isdn switch-type basic-net3 no cdp enable ! interface Dialer1 description connected to RouterA ip unnumbered Ethernet0 encapsulation ppp no ip split-horizon dialer in-band dialer idle-timeout 300 dialer map ip 124.0.0.132 name torge broadcast Vorwahl+Rufnummer dialer map snapshot 1 name torge broadcast Vorwahl+Rufnummer dialer hold-queue 10 dialer load-threshold 180 either dialer-group 1 snapshot client 15 360 suppress-statechange-update dialer no cdp enable ppp authentication chap ppp multilink ! interface Dialer2 description connected to RAS ip address 192.168.200.1 255.255.255.240 encapsulation ppp no ip split-horizon dialer in-band dialer idle-timeout 300 dialer hold-queue 10 dialer-group 1 peer default ip address pool RAS no cdp enable ppp authentication chap ! ip local pool RAS 192.168.200.2 192.168.200.14 ip classless ip route 0.0.0.0 0.0.0.0 192.168.190.254 2 ip route 124.0.0.0 255.0.0.0 124.0.0.132 ip route 124.0.0.132 255.255.255.255 Dialer1 no ip http server ! dialer-list 1 protocol ip permit ! line con 0 exec-timeout 0 0 password 7 xxxxxxxxxxxxxxx login transport preferred all transport output all stopbits 1 line vty 0 4 password 7 xxxxxxxxxxxxxxx login transport preferred all transport input all transport output all ! no rcapi server ! ! ! end Ich bin für jeden Tipp dankbar!

Hallo Zusammen, folgendes Szenario: 2 x Cisco 801 (IOS 12.3) die für eine Lan2Lan und jeweils eine RAS Verbindung für Administrationszwecke eingerichtet wurden. Da die Config nicht wirklich optimal ist bauen die Router die Verbindungen auch nicht optimal ab. Dadurch entstehen natürlich auch höhere Verbindungskosten, was ich gern irgendwie verhindern würde. Momentan können beide Router (Router A = Hauptgeschäftsstelle und Router B = Außenstelle) sich gegenseitig anwählen. Reichen würde es jedoch, wenn nur Router B wählt. Weiterhin sind auf beiden Routern keine ACL gesetzt, die unnötigen Traffic filtern würden (netbios Anfragen usw.). Meine Fragen nun: 1. Würde es reichen für Router A die broadcast nummer auf eine entsprechend falsche Nummer umzustellen, damit dieser nicht mehr Router B anwählen kann? Oder gibt es eine bessere Alternative ihm das Wählen abzugewöhnen? 2. Ist es möglich den Routern zu sagen, dass sie incomming calls nur zu bestimmten Zeiten zulassen, also sowas wie ein Scheduler? So dass man sagt: Router A akzeptiert von Router B bzw. generell nur incomming calls von 07.00 Uhr bis 18.00 Uhr. Der Umgekehrte Weg wäre auch denkbar, sodass Router B nur von 07.00Uhr bis 18.00Uhr wählen darf... jenachdem was einfacher oder schneller ist. 3. Wie würde eine ACL aussehen, die verhindert, dass unnötiger Datenverkehr den Dialer aktiviert? Ich hänge die Configs mal unten an: Router A = Hauptgeschäftsstelle: version 12.3 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname RouterA ! boot-start-marker boot-end-marker ! enable password 7 xxxxxxxxxxxxxxx ! username RouterB password 7 xxxxxxxxxxxxxxx username RAS password 7 xxxxxxxxxxxxxxx no aaa new-model ip subnet-zero no ip domain lookup ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 description connected to LanA ip address 124.0.0.132 255.0.0.0 no keepalive ! interface BRI0 description connected to RouterB no ip address encapsulation ppp dialer rotary-group 1 dialer-group 1 isdn switch-type basic-net3 no cdp enable ! interface Dialer1 description connected to RouterB ip unnumbered Ethernet0 encapsulation ppp no ip split-horizon dialer in-band dialer idle-timeout 300 dialer map snapshot 1 name RouterB broadcast dialer map ip 192.168.190.235 name RouterB broadcast Vorwahl+Rufnummer dialer hold-queue 10 dialer load-threshold 180 either dialer-group 1 snapshot server 15 dialer no cdp enable ppp authentication chap ppp multilink ! interface Dialer2 description connected to RAS ip address 192.168.199.1 255.255.255.240 encapsulation ppp no ip split-horizon dialer in-band dialer idle-timeout 300 dialer hold-queue 10 dialer-group 1 peer default ip address pool RAS no cdp enable ppp authentication chap ! ip local pool RAS 192.168.199.2 192.168.199.14 ip classless ip route 192.168.190.0 255.255.255.0 192.168.190.235 ip route 192.168.190.235 255.255.255.255 Dialer1 no ip http server ! dialer-list 1 protocol ip permit ! line con 0 exec-timeout 0 0 password 7 xxxxxxxxxxxxxxx login transport preferred all transport output all stopbits 1 line vty 0 4 password 7 xxxxxxxxxxxxxxx login transport preferred all transport input all transport output all ! no rcapi server ! ! ! end

90 Tage, wenn der Terminallizenzierungsserver installiert wurde. siehe auch hier Mit der Deinstallation der Terminaldienste sollte es getan sein... Dann kannst Du in den Eigenschaften des Arbeitsplatz den Remotedesktop freigeben.

Da Standort A und B mit jeweils einem unterschiedlichen IP Netz (192.168.0.0/24 und 192.168.95.0/24) versehen sind müssen doch beide Server irgendwie in der Lage sein Clients vom jeweiligen Gegennetz aufzulösen. Aber mein kleiner Denkfehler ist mir, glaube ich, schon bewusst geworden. Für die Forward Lookupzone sollte sich ja nichts ändern, bis auf die Tatsache, das dort Clients aus beiden IP Netzen auftauchen. Somit sollte es lediglich nötig sein eine weitere Revers Lookupzone zu erstellen. Da das DNS von DC A AD integriert ist, sollte sich DC B den DNS Kram doch bei der Einrichtung des ADs rüberholen oder sehe ich das falsch? Änderungen am DNS werden auch mit repliziert?

Eine Frage die mir noch einfällt. Wie sieht es bezüglich DNS aus? Da DC A der erste DC wird und gleichzeitig natürlich DNS vorhält muss DC B ja auch irgendwie DNS am laufen haben. Nun ist es aber so, dass DC B sich ja in einem anderen logischen und physischen Netz befindet. Wird beim dcpromo auf dem DC B die Forward Lookup Zone für sein eigenes Netz automatisch im DNS erstellt oder muss ich vorher auf DC A jeweils eine Zone für das Netz von DC B erstellen?

Alles klar, Danke!

Jup sehe gerade, es würde wohl reichen, wenn man den DC im Standort B manuell zum GC macht, wenn der DC im Standort A mal ausfallen sollte... oder? Für die Replika ist es also nicht zwingend notwendig beide zum GC zu machen. Änderungen an DC B wie auch DC A werden aber trotzdem auf das jeweilige Gegenstück repliziert?

Laut http://www.wintotal-forum.de/index.php/topic,47686.0.html wäre es dann wohl aber doch besser beide Server zum GC zu machen...??

Der und kein anderer... ;)

Das ist schon soweit klar, anders hatte ich es auch nicht vor. Aber nochmal die Frage: Muss ich den DC im Standort B auch zum Golbal Catalog Server machen?

1. Die TS Lizenzierung kommt in der Regel IMMER auf den DC der Domain, es sei denn der DC ist ein W2K und der TS ein W2K3... es gibt natürlich noch weitere Ausnahmen. 2. Wie man den Terminallizenzierungsserver einem Terminalserver fest zuweist ist bereits mehrmals im Forum beschrieben worden, mit entsprechenden Links zu Microsoft, einfach mal suchen...

Beide Server sehen sich doch über die VPN Verbindung warum also den Server in der Außenstelle als GC einrichten? Das Replikationsintervall kann man wo einstellen?

Das ist in der Regel immer dann der Fall, wenn Backup Exec kein Medium zum sichern laden kann, es aber dennoch versucht (logisch oder... :)). Ist der automatische Abbruch nicht eingestellt läuft der Job natürlich durch... Wenn BE das Medium nicht laden kann liegt das entweder daran dass das Medium nicht im vorgesehenen Medienpool oder im Pool für temporäre Medien liegt... Im übrigen ist es empfehlenswert das SP1 für BE sowie den Rücksicherungspatch einzuspielen.

Da Du per VPN sowieso beide Netze miteinander verbindest kannst Du ODBC Verbindungen und den ganzen anderen Schnulli doch sowieso über eine Client - Server Verbindung laufen lassen. Es sei denn es werden regelmässig große Datenmengen übertragen, die den Upload des DSL Anschlusses dicht machen würden. Ein weiterer Knock Out der gegen eine direkte Client - Server Verbindung spricht ist, dass es Performance Probleme beim Zugriff auf Datenbanken oder Freigaben gibt. Ist dies nicht der Fall warum mehr Aufwand als nötig? Ich kenne den SBS nicht so gut aber sowas wie Webaccess über einen W2K3 Server wäre mir neu... Wozu auch, die Netzlaufwerke werden doch sowieso lokal dargestellt. Etwas anderes ist es natürlich wenn Du die Gelegenheit beim Schopfe packen willst und auf längere Sicht einen Terminal Server einsetzen möchtest. Vielleicht bekommst Du es ja beim Chef verkauft, wenn Du die entsprechenden Argumente vorbringst. ;) Und wenn die Umgebung erstmal ordentlich eingerichtet ist dann hat ein Terminalserver schon seine Vorteile. Wobei Citrix MetaFrame dann der "krönende" Abschluss wäre. Aber hier sind die Lizenz Kosten natürlich zu beachten. Übrigens gibt es für das scannen über RDP ein recht günstiges und vor allem gutes Produkt, nennt sich RemoteScan... aber das nur nebenbei. :) An Deiner Stelle würde ich mit der einfachsten und unkompliziertesten Lösung anfangen und das wäre erst mal die direkte Client - Server Verbindung. Sollte es Probleme geben kannst Du dann immer noch einen besseren PC zum TS machen und die Nutzer dann anbinden.

Schön, dass wir da alle einer Meinung sind. :) Die VPN Endgeräte haben wir schon, verschlüsselt wird mit IPSec und das Routing ist auch klar. Von daher sollten wir keine Probleme haben. Einzige offene Frage ist jetzt noch, ob es Probleme geben kann, wenn der Server für Standort B sich nicht gleich regelmässig mit A abgleicht. Wir werden Server A und B zunächst zwar gleichzeitig aufsetzen Server B jedoch erst eine Woche später in Standort B aufstellen, da erst dann die VPN Verbindung stehen wird. Aber eigentlich sollte sich Server B nicht schwer tun, wenn er mit B mal ein paar Tage nicht spricht oder? Wie schaut es eigentlich mit dem Traffic zwischen den beiden DCs aus? Gibt es Aussagen, wie oft und mit wieviel Traffic sich beide Server miteinander abgleichen? Vielen Danke erstmal für die Antworten!

Der SBS hat leider keine Terminalservices, somit entfällt diese Variante, es sei denn Du möchtest Deine Nutzer im Verwaltungsmodus auf den Servern arbeiten lassen, was natürlich "nicht so hübsch" ist. Für die Verbindung der Standorte solltest Du in jedem Fall über ein VPN nachdenken, da die Daten sicher nicht unverschlüsselt über das Internet huschen sollen. Von der Bandbreite reichst Du mit DSL bei 2 Nutzern dicke. Wir haben Anbindungen von Außenstellen mit Citrix MetaFrame über eine ISDN Wählverbindung (mit 64KBit und dynamischer Kanalbündelung) für bis zu 15 Nutzer realisiert. Wobei man natürlich sagen muss, dass nicht alle Nutzer gleichzeitig arbeiten... Da man bei MetaFrame die Druckerbandbreite begrenzen kann ist auch hier das Drucken (wenn es vernünftig eingerichtet ist) kein Problem. Aber auch bei den reinen Terminaldiensten hast du mit 2 Nutzern kein Problem. Um die Kosten für die Wählverbindung niedrig zu halten haben wir unseren Kunden den enjoy Tarif der Telekom empfohlen (12Cent/Stunde). Die Frage ist, ob sich die Terminaldienste in Deinem Fall lohnen oder nicht doch eine reine VPN Verbindung ausreichend ist...

Moin Zusammen, wir haben vor, das gute alte Novell durch eine Windows Server 2003 Domain abzulösen. Dazu folgende Vorraussetzungen: Standort A (IP Netz: 192.168.0.0/24) mit Novell Server (wird durch einen neuen Server mit W2K3 ersetzt) Standort B (IP Netz: 192.168.95.0/24) bekommt den alten Server (die Hardware) von Standort A ebenfalls mit W2K3 Da die Standorte zukünftig per VPN miteinander verbunden werden war unsere Überlegung gleich nur eine Domain aus dem Boden zu stampfen. Somit würden wir zunächst den neuen Server in Standort A als ersten DC installieren, danach den Novell Server platt machen, ebenfalls mit W2K3 bestücken und als zweiten DC für Standort B einrichten. Meine Fragen nun: Macht das Szenario Sinn, empfiehlt es sich doch zwei getrennte Domains einzurichten (IHMO nicht...) und gibt es Probleme, wenn man den DC von Standort B zunächst im IP Netz von Standort A installiert und dann später die IP ändert (entsprechend dem Standort B)? Eventuell hatte ich daran gedacht einen Router aufzusetzen um die Server schon in den entsprechenden Netzen zu installieren. Ich bin für jede Anregungen dankbar!

1. Ja der TS Lizenzierungsserver muss der DC sein. Es gibt Ausnahmen aber Dein Szenario gehört nicht dazu. 2. Die W2K TS Lizenzierung wird deinstalliert und auf dem W2K3 DC installiert. Der W2K3 TS Lizenzierungsserver stellt auch für W2K TS TS CALs aus. 3. Wenn es irgendwie geht nimm die per User Lizenzierung, die macht momentan am wenigsten Probleme... Sollte der TS seinen Lizenzierungsserver nicht finden kannst Du ihn fest zuweisen: http://support.microsoft.com/kb/279561/EN-US/

Wie sieht es sonst im Netzwerk aus? Gibt es Stabilitätsprobleme? Kommt der Client mit einer direkten Verbindung zum Server besser klar (bspw. über einen kleinen Switch oder ein Crossoverkabel)? Hat der Server mehrere NICs? Was sagt das Eventlog?