Velius

wenn du meinst :rolleyes:

Na dann viel Spass beim Suchen, mir ist kein solches Produkt bekannt.

Schnall ich nicht deine Fage. Du sagst, du willst OWA in eurem Firmenweb integrieren, und die Linux Login-Information automatisch an OWA weitergeben, also eine art Single Sign on. Versteh ich das richtig?

BTW: NT 4.0 kennt keine SID-History, lediglich die SID. Nur W2K/W2K3 Domänen im native Mode kennen SID-Histories.

Siehe hier: http://www.mcseboard.de/showthread.php?t=44386&highlight=script

Ist im Normalfall auch nicht nötig, aber super wenn's klappt :thumb1:

Na welcher dein Logon Server ist? Hast du ein "Set" ausgeführt oder wie kommst du darauf, dass die anderen Controller schneller reagieren. Du musst ja zugeben, das was nicht stimmt, denn die Funktion musst du im AD nicht aktivieren, die wurde so Entworfen. Irgendwas an deiner Implementierung ist krumm....

Wieso ich so reagiere? Weil sich ein haufen Leute mühe geben dir zu helfen, und du offenbar die Posts nicht richtig liest. Wenn alles so konfiguriert ist, wie es sollte, dann hättest du das Problem nicht. Ausserdem, wie stellst du das überhaupt fest? Schon mal daran gedacht, dass der DC am Standort selbst ne Macke hat?

@Data Wieso soll er denn einen löschen? Wenn in den Sites alles richtig konfiguriert ist, ist das nicht nötig. Ach was red ich, löschen von SRV Records ist das aller letzte, was man im AD tun sollte, um was zum laufen zu bringen, aber wenn ihr unbedingt rumpfuschen wollt, meinen Segen habt ihr. P.S.: Überflüssige SRV Records löschen kann man schon, nur sollte man Ahnung haben davon.....

Sorry, mein's nicht bös, aber weisst du wie AD funktioniert? Clients können nicht in Sites angelegt werden, jedoch können Sie aufgrund der IP ermitteln, bei welchem DC Sie sich authenifizieren sollen. Dafür müssen aber diese DC's in der richtigen Site im AD Sites and Services mit dem dazugehörigen Subnetz definiert werden. Ausserdem müssen die SRV Records im DNS stimmen. Da wird auch eine für jede Site angelegt. Normalerweise macht ein DC das selbständig, wenn er in eine Site verschoben wird, oder so wie Data sagte, den Netlogon Service starten und stoppen, was aber seit W2K3 glaube ich nicht mehr geht. Den Server neu starten oder Netdiag /fix verwenden hat einen ähnlichen Effekt. Alles andere bezüglich GC oder nicht GC kannst du ja haufenweise im Thread nachlesen. Viel Glück Velius

Von hand solltest du das nicht machen, sondern mit netdiag /fix auf dem betroffenen DC.

@phoefliger Am besten nach folgendem Artikel: http://support.microsoft.com/default.aspx?scid=kb;en-us;241505 Gruss Velius

Hallo Josh16 Da es sich um eine nicht verwaltete NG FP3 geht, würde ich dir raten von beiden Firewalls die Zertifikate zu exportieren und gegenseitig auszutauschen. Ist viel unkomplizierter. Gruss Velius

Können wir den Thread nicht langsam in frieden ruhen lassen, oder sollen wir einen Support-Call bei MS eröffnen :p

Wartet nur bis ich auch auf den Geschmack komme und einen Test Multi-Domain Forest baue.... :rolleyes: :p

Das brauchst du mir nicht erklären, denn die ganze Thematik habe ich mit Ghost auf unterschiedlicher Hardware von Forne nach Hinten durchgekaut. Die Frage ist nicht, ob man Hand anlegen muss, sondern der Aufwand und die Zeit, die dabei draufgeht, bis das SYstem wieder steht. Wir habe hier bei uns sehr höhe Ansätze. ASR scheint allen unseren Ansätzen bestens zu genügen; IDR wäre noch eine Option, da wir aber eine Lösung haben und IDR mehr kostet besteht soweit kein Grund.

Ich rede vom Harddisk Controller. Der ist das Herzstück der Geschichte. Ohne etwas an deinem Backup/Image zu ändern wirst du beim Aufspielen auf einem Rechner mit anderem Harddisk Controller 100%-ig einen Bluescreen bekommen, und das können die wenigsten gebrauchen. IDR kenne ich nicht besonders, sollte aber im Prinzip wie ASR funktionieren. Da wird die Hardware Konfiguration von Windows neu geschrieben. Darum auch der Vorteil und meine Frage. P.S.: Stell dir vor, dein Rechner fackelt in drei Jahren im wörtlichsten Sinne ab, und der Controller ist nicht mehr verfügbar....tolle Disaster-Recovery. :wink2:

@BuzzeR Rein aus Neugier, aber klappt das auch auf andere Hardware, weil das macht es ja erst interessant. Clone Software und Konfigurations-Orgien bei nicht baugleicher Hardware gibt's ja wie tonnenweise...

Hab ich gelesen.....

Hi Verwendest du RRAS auf dem SBS? RAS reserviert automatisch 10 Adressen aus dem DHCP Pool (wenn konfiguriert), und fordert weitere 10 an, wenn diese erschöpft sind. Gruss Velius

Vielleicht hilft ja das hier: How to Optimize the Location of a Domain Controller or Global Catalog That Resides Outside of a Client's Site Global Catalog Server Requirement for User and Computer Logon Im grossen und ganzen wird nur das bereits gepostete wiederholt. Deswegen: - DNS SRV Records checken. - AD Sites und Services checken. - Eventlogs können auch nicht schaden. Gruss Velius P.S.: Kann auch nicht schaden, diese mal gelesen zu haben. Domain controller is not functioning correctly How Domain Controllers Are Located in Windows XP

Vertrau mir, check die Logs. Nur weil die Verbindung nicht aufgebaut wird, heisst das noch lange nicht dass der Client nicht mit der Firewall komuniziert hat. Ich hatte auch schon Fälle, wo Teile der Negotiation erfolgreich waren. Darum ja auch mein Tipp; mit den Logs erfährst du mehr darüber.

Hi Ich habe mal in der SecureKnowledge gesucht, konnte aber nichts in diesem Zusammenhang finden. Hast du schon andere Konstelationen versucht (andere Router)? Verwendest du den SecureRemote oder den SecureClient? Beim SecureClient wäre auch ein Problem mit der Desktop Security (lokale Firewall) vorstellbar. Ausserdem solltest du die logs auf der Firewall prüfen (lassen?). Gruss Velius

....dafür gratis. Für mich klang die patrikbolts Antwort, als gäbe es keine Alternativen, oder es wären keine genannt worden in diesem Thread. Ich spreche keine Empfehlung aus, er muss es selbst enscheiden, ich betone lediglich, dass es Alternativen gibt. Gruss Velius

Hi Fraggix Willkommen im Board. Ich kann dir nur diesen Thread an's Herz legen: http://www.mcseboard.de/showthread.php?t=33524 Bei W2K3 Server hat sich was am NTLDR verändert. Deine Hall.dll ist sehr wahrscheinlich i.O. nur der NTLDR des neu installierten XP kommt damit nicht klar. Versuch's mal, bei mir hat's geklappt. ;) Gruss Velius P.S.: Der neue NTLDR kommt mit XP und W2K3 klar; ist ja auch abwärtskompatibel :p