Jump to content

Wolke2k4

Members
  • Gesamte Inhalte

    2.224
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Wolke2k4

  1. Da gibt es nicht viel zu erzählen. Router 1 in Außenstelle Router 2 in Hauptstandort Entfernung ca. 20 - 30km Die Einwahl soll nur von der Außenstelle erfolgen, da diese via RDP auf den Terminalserver zugreift. Idle Timeout = 5 min und natürlich BoD also dynamic channel bundling (ich hoffe der 801 kann das auch)... Und ganz WICHTIG: RAS Einwahl auf beiden Routern!!! Danke erstmal für die Links!
  2. Moin zusammen, nachdem ich mein CCNA vor knapp 1 1/2 Jahren gemacht habe wird es nun "ernst". Ich muss demnächst eine LAN2LAN Kopplung mit zwei Cisco 801 realisieren. Dazu muss, logischerweise, irgendeine Config für beide Router her. Meine Frage: Gibt es ein Withepaper für die Einrichtung einer Config für eine LAN2LAN Kopplung auf einem 801 (idealerweise auch mit RAS Einwahl)? Was ist mit dem Config Maker??? Ich habe schon einen kleinen Blick auf die Cisco Seiten geworfen aber so richtig fündig wurde ich noch. Theoretisch sollte aber diese Doku auf den 801 anwendbar sein???? Ein paar Befehle werde ich sicher noch hinbekommen aber für das Einrichten einer Router-Router ISDN Wählverbindung wird es nicht ganz reichen...
  3. Wolke2k4

    Vpn

    Also funtkioniert die Verbindung doch nicht???? Wie schaut es mit einem Ping in das andere Netz aus??? können sich beide Netze sehen???
  4. Propiers mal mit einer Softwarefirewall, die entsprechende Routingfunktionen mitbringt (bspw. Winroute) Mit einem route add wirst du imho eine temporäre Route erstellen, die nach dem Rechnerneustart wieder futsch ist. Selbst mit einem Anmeldescript ist sowas nur eine Notlösung, wenn überhaupt. Eine entsprechende Softwarefirewall oder Routing Lösung macht sich hier besser!
  5. Eine statische Route sollte reichen und könnte etwa so aussehen: 10.250.0.0 Subnetmask 255.255.248.0 via 10.250.4.253 Dieses Routing müsste dann auf dem Router RO eingerichtet werden, der natürlich eine physische und logische Verbindung zu beiden Netzen haben muss...
  6. Jaein, hab mich wohl ein wenig umständlich ausgedrückt. Aus lizenzrechtlicher Sicht müssen die Lizenzen natürlich gekauft werden! Technisch gibt es derzeit jedoch keinen Mechanismus, der das vorhanden sein von per User Lizenzen prüft und ggf. den Zugriff auf den Terminalserver verweigert (wobei wir dann wieder beim Bezug zu diesem Thread wären). Mit dem SP1 für W2K3 soll sich das jedoch wieder ändern...
  7. In den Optionen für den Remotedesktopclient unter lokale Ressourcen --> lokale Geräte kann man den entsprechenden Haken setzen PDA Synchronisation via USB wird es erst mit MetaFrame PS 4.0 geben, der allerdings erst Mitte nächsten Jahres auf den Markt kommt jedoch als Feature für die PDA synch. wohl etwas teuer sein dürfte....
  8. Abhängig davon, wie lange der TS schon steht, was aus dem Posting nicht eindeutig hervorgeht... Gezählt wird nicht ab Start des Terminalservers sondern ab Tag der Clientverbindung, weil die TS CAL bei per Device Lizenzierung am Client festgemacht wird. Wunderbar zu sehen in der Terminalserverlizenzierungskonsole. Bei der per User Lizenzierung (erst ab W2K3) reicht lediglich das vorhanden sein eines Lizenzierungsservers...
  9. Wolke2k4

    Remote Desktop HELP

    Mal ne dumme Frage, welchen RDP Client nutzt du (Version)???
  10. Das Einrichten einer entsprechenden Gruppenrichtlinie empfiehlt sich für dieses Szenario...
  11. Temp Lizenzen stellt nur der TS Lizenzierungsserver aus, installiert werden diese nicht... Wie schaut die Lizenzierung genau aus? Ich nehme an, dass du per Device lizenziert hast? Habe ich das richtig verstanden, dass der TS neu aufgesetzt wurde????
  12. Ich kann Dir nur raten eine Testumgebung aufzubauen und erstmal dort zu probieren. In der MS KB gibt es entsprechende Artikel zur Installation von Office auf TS. Wenn es nichts mit der Testumgebung wird und du, aus welchen Gründen auch immer, am produktiven System rumschrauben musst/willst dann such dir am besten vorher ein entsprechendes Imageprogramm!!! Gerade bei Terminal Servern ist ein Image oft der Retter in der Not und die "Garantie" für ein fortbestehen deines Arbeitsvertrages... In der Regel kann man mit Deploy Center und/oder Acronis True Image Server immer ein Image ziehen. Wenn das eine Programm nicht funktioniert dann springt das andere ein.
  13. Was sagen denn die MetaFrame Lizenzen??? Wird David als published Applikation an die User verteilt? Was ist mit anderen Anwendungen, wie schaut es mit dem Desktop via ICA aus?
  14. Aber in der Regel doch sowas wie eine interne Sicherheitsrichtline, in der festgelegt ist, wer wo welche Rechte hat....
  15. Und das idealerweise nicht im Installations Modus... :shock: :)
  16. Hast du es mal mit ein paar öffentlichen DNS Servern probiert?
  17. Ich kann leider nur sagen wie es bei SSL ausschaut, vielleicht gibt es dir ja einen Denkanstoß... ;) Bei einer private CA muss auf dem Server, der SSL verschlüsselten Inhalte zur Verfügung stellt sowohl das CA Root Cert wie auch das Serverzertifikat installiert werden. Den Clients die auf die SSL Inhalte zugreifen wollen mussen in diesem Fall die private CA bekannt gemacht werden. Somit muss auch auf den Clients das CA Root Cert installiert werden. Bei deinem Szenario wird es (wahrscheinlich) so sein, dass jeder Client, wie bei SSL auch, ein eigenes Zertifikat bekommt und sich dementsprechend über dieses Zertifikat beim Server authentifiziert. Nichtsdestotrotz wird auch hier wieder das CA Root Cert auf den Clients und dem Server notwendig sein.
  18. Ansonsten könnte David V8 eine Alternative sein...
  19. Es wird dir zwar nicht weiterhelfen aber für die Zukunft gilt: Installiere nie kritische Anwendungen/Software oder Patches/Update auf einem MetaFrame Server ohne vorher ein Image gezogen zu haben! Ansonsten gibt es zu der Event ID noch folgende Infos
  20. ggfs. reicht der 1494, 1604 und 80 beim PS 3.0 nicht aus... siehe hier Welcher Parameter war es denn??
  21. Hallo schroeder, vielen Dank für Deine Mühe. ADMT hatten wir ja schon kurz am Wickel, leider wussten wir nicht einmal ob wir das Tool testweise auf dem NT PDC oder dem W2K3 DC installieren sollten. Wie Du siehst, ist es mit unserem Wissen in Bezug auf Migration von Domain nicht weit her. .. Wir wären Dir sehr dankbar, wenn Du uns einen kleinen Exkurs zur Nutzung von ADMT schreiben könntest oder eine brauchbare Quelle zur Nutzung von ADMT kennst. Wir hatten ADMT auf dem W2K3 DC installiert, haben mit einem Rechtsklick auf den obersten Eintrag den Eintrag "Report Wizard" ausgewählt, wobei wir nicht einmal wussten, was der Report Wizard tut. Als nächstes mussten wir Quell und Zieldomain angeben, wobei ADMT bereits die NT und W2K3 Domain erkannte. Beim Klick auf "weiter" erschien auch schon gleich der erste "Fehler 5 Zugriff verweigert" entgegen. Ich nehme mal an, dass dies etwas mit der Vertrauensstellung der Domains untereinander zu tun hat... Die Readmedatei von ADMT hilft uns nicht wirklich weiter. Nach dem besagten Rechtsklick auf den obersten Eintrag in ADMT finden sich viele Einträge z.B. "User Migration", "Report Wizard" usw. Müssen diese Punkte nacheinander abgearbeitet werden und fertig ist die Migration???? Wir fühlen uns bei dieser Problematik nicht besonders wohl :shock: , brauchen aber unbedingt fachmännische Hilfe!! ;) Wenigstens sind wir ehrlich... P.S. Die Problematik mit dem native Modus in Bezug auf Exchange hätte sich mit ADMT dann theoretisch aufgelöst, da die W2K3 Domain gleich als native installiert werden kann???
  22. Mir wäre es auch lieber die Geschichte ausführlich zu testen aber das ist leider einfach nicht drin. Wir haben unsere Köpfe noch mal rauchen lassen und sind unter anderem auf einen interessanten Lösungsansatz gestoßen . Im Grunde könnte man daraus folgende Vorgehensweise für unser Szenario ableiten: 1. Installation eines temporären NT4 PDCs mit Migration nach W2K3. Wobei sich die Frage stellt, was mit dem vorhandenen PDC passiert, sobald der temp PDC in das Netz gebracht wird. 2. Installation des (eigentlichen) W2K3 auf der neuen Serverhardware mit Übernahme der Betriebmaster Funktionen des temporären AD DC. Einrichtung der entsprechenden Dienste (DHCP und DNS) 3. Entfernen des temp AD DC aus der Domain. 4. Gegebenenfalls herabstufen der alten BDCs. Die Frage ist, ob das Herabstufen der BDCs Sinn macht bzw. überhaupt notwendig ist, wenn diese sowieso mit dem neuen W2K3 DC kommunizieren können. Ziel ist ein W2K3 DC mit drei BDCs und davon ein BDC mit Exchange 5.5 am laufen zu haben. Was passiert, wenn der W2K3 DC aktiv wird, wird dieser dann für die BDCs sowas wie ein "PDC"? Theoretisch müssten durch die Migration sämtliche Computerkonten übernommen werden (was ja auch Sinn der Migration ist) und somit die Einrichtung der Server und Clients in die W2K3 Domain entfallen (sprich die Aufnahme der Computerkonten in die W2K3 Domain). Über diesen Weg müsste dann, theoretisch, sichergestellt sein, dass weiterhin jeder Nutzer auf die ihm in der alten NT4 Domain zugewiesenen Ressourcen und Dienste zugreifen kann (egal ob W2K3 oder NT)???? Welche Rolle spielt jetzt noch der "native" Mode, auch im Zusammenhang mit Exchange? Laut dem Link oben gibt es lediglich die zwei folgenden Möglichkeiten: http://www.admins-tipps.net/software/microsoft/migration_nt4_w2k3/upgrade_pdc_to_w2k3/11.jpg wobei "Windows 2003 interim" für unser Szenario richtig wäre....
×
×
  • Neu erstellen...