Christoph35

@mailkilla: nadinsche hat das in der Default Domain Policy gesetzt, die sollte auf jeden Fall übernommen werden... @nadinsche: Probier doch mal, was passiert, wenn Du die User, die Clients in die Domain aufnehmen können sollen, in eine OU verschiebst, ggf. Sub-OU, damit andere Settings wirksam bleiben, und auf diese neue OU eine Delegierung dieses Rechts durchführst. Klappt es dann? Christoph

Hallo, und willkommen an Board! :) Das ist korrekt. Hast Du auch mal ein gpupdate /force ausgeführt, damit die neue Einstellung auch wirksam wird? Zusatzfrage: um was für Clients handelt es sich? XP, 2000 Pro? Christoph

Alternativ gibts Neverfail oder DoubleTake. Wir setzen Double Take ein. Ist auch nicht billig, funktioniert aber gut. Christoph

Ja, du musst NTDSUtil benutzen, aber "seize" darf nur dann verwendet werden, wenn der fehlerhafte DC FRISCH installiert oder gar nicht wieder ans Netz geht. Das geht aber ja nicht. Es sei denn, du machst den Exchange/DC zum Memberserver mit Exchange und installierst neue Hardware oder eine VM für den 1. DC, der dann auch nur 1. DC wäre. Kann aber ja sein, dass das aus Budget Gründen nicht in Frage kommt. Getestet habe ich eine solche Vorgehensweise noch nicht. Ansonsten versuche es mit dem transfer Kommando in NTDSUtil. Und tu dir einen Gefallen: spiel keine Images von DCs zurück. Du siehst ja, wohin das führt ;) Christoph

Hi, am besten fährst du den nicht richtig funktionierenden 1. DC zunächst mal herunter. Dann löschst Du ihn aus dem AD und gibst dabei an, dass er permanent offline ist. Danach kontrollierst Du die FSMO-Rollen. Falls nötig, kannst Du sie mit NTDSUtil auf den 2. DC übertragen, am besten mit Seize. Am besten schaust Du auch mit NTDSUtil ob noch irgendwo der gelöschte DC auftaucht. Falls ja: löschen. Dann installierst Du Windows auf dem 1. DC komplett neu und machst ihn zu einem zusätzlichen DC deiner Domain und überträgst die FSMO Rollen zurück auf den 1. DC (diesmal mit den AD-Verwaltungstools). Zum Umgang mit dem NTDSUtil Tool guckst Du hier. /edit: Du kannst natürlich, wie Velius zurecht schreibt, zunächst mal versuchen mit DCPromo das AD von dem 1. DC zu entfernen. Wenn das fehlschlägt, kannst Du immer noch mit NTDSUtil arbeiten. Christoph

Wäre ne Alternative, funktioniert aber vernünftig nur mit den 2003er Versionen von Exchange, SPS und Office. Wir haben mal die WSS mit Office 2000 angetestet und das ziemlich schnell wieder eingemottet. Mit Office 2003 wäre das um Längen besser (mal in ner VM Testumgebung probiert). Aber bei uns wird jetzt Office wohl erst in der 12er Version neu ausgerollt. Christoph

Ja klar werden wir das hier reinstellen. Ist ja auch ein ziemlich mysteriöses Verhalten, das so nicht allzu oft auftreten dürfte. Wie unsere Internet Recherechen belegen... Christoph /edit: war der Kollege doch glatt schneller als ich :D

Tja, ich weiß nicht, ich habe auch seit einiger Zeit das Gefühl, dass irgendwas bei der Migration nicht 110% so gelaufen sein könnte, wie es sein sollte. Obwohl mir da auf Anhieb nix einfällt, denn wie Sascha schon schrieb: eigentlich war s easy going... Im Prinzip müsste man die ganzen Steps, die wir damals mit den NT Domains gemacht haben, noch mal per VMs nachbauen und schauen, wie sich eine solche Testumgebung verhält... :eek: Unsere Lab Tests zu diesem Problem sind ja immer in AD-Domains gelaufen, die von Grund auf AD-Domains waren. Das könnte aber ganz schön aufwändig werden... und 2-3 Rechner nur für VMs beanspruchen :shock: Falls MS keine Lösung in absehbarer Zeit liefert, kommen wir da vllt. nicht drum rum. Aber jetzt warten wir erst mal auf MS ;) Christoph

Hallo mal wieder in diesem Theater... wir suchen immer noch nach der Ursache für unser Problem, auch MS hat das ganze jetzt in den Second Level Support eskaliert, nachdem der 1st Level mehr als eine Woche Logs analysiert hat und keine Ideen mehr hat. :eek: Ich denke, wir werden da mal auf Packet-Ebene (network sniffing) forschen müssen :shock: . Sobald wir was neues finden oder MS sich meldet, gibts wieder ein Update. In der Zwischenzeit: falls jemand Ideen hat, immer her damit.... :D :cool: Christoph

Hallo zusammen, mal wieder Zeit für ein Update des Threads ;) hier sind unsere neuesten Beobachtungen: In der Forest Root Domäne (a.firma.com): Benutzer aus B -> Universelle Gruppe in A -> Zugriff auf Ressource in A -> Access Denied Diese universelle Gruppe in A -> Domain Local Group in A -> Zugriff auf Ressource in A -> Access Denied Benutzer aus B -> Domain Local Group in A -> Zugriff auf Ressource -> Access OK! Benutzer aus B -> Universelle Gruppe in A -> Universelle Gruppe in B -> Zugriff auf Ressource in A -> Access OK! Die universellen Gruppen in A.firma.com verhalten sich "komisch" in der Domäne A, aber korrekt in den anderen Domänen. Wir haben jetzt noch mal mit NLTest /sc_verify und nltest /domain_trusts /alltrusts /v die Vertrauensstellungen und die Secure Channels von jeder Domain zu allen anderen Domains getestet. Ergebnis überall successful... Die Trusts dürften damit als Fehlerquelle ausscheiden, und das Problem scheint wohl nur die Forest-Root Domain A zu betreffen. So langsam gehen uns die Ideen aus... Christoph

Besser ist das ...

Hehe, dann kommts noch drauf an, wie sein Mailkonto und seine Anbindung zu Hause ausschauen, 800 MB Mails downloaden, wenn sie bei euch raus sind ... kann unter Umständen was länger dauern :shock: :D Christoph

Hi, wenn wir von Site To Site VPNs reden, muss u.a. ein entsprechendes Netz für die Remote Site definiert sein und es müssen Regeln definiert sein, die den Verkehr von der Remote Site zur lokalen Site steuern. Wenn wir von RAS via VPN reden, müssen diese Regeln definiert sein für VPN-Clients nach Internal und umgekehrt. Sehr gut beschrieben werden alle Voraussetzungen für VPN (Site to Site und RAS) in T. Shinders Bibel. Christoph

Hi, beim ISA 2004 sind auch Verbindungen via VPN den Firewall-Regeln unterworfen, im Gegensatz zu ISA2K. Daher muss es eine Regel geben, die PING aus dem Internen Netz in das andere Netz zulässt. Dass es vom ISA aus geht, liegt daran, dass es in der System-Policy eine entsprechende Regel gibt, die Ping vom ISA in andere Netze zulässt. Christoph

RUS=Empfängeraktualisierungsdienst (Recipient Update Service). Wir haben englische Servers, deshalb bringe ich hier schon mal die englischen Bezeichnungen an, sorry... Vielleicht habe ich auch deine Frage falsch verstanden: Wo steht das .local drin, in Mails, die raus gehen?! /edit: oder hast du das gleiche Problem, wie http://www.mcseboard.de/showthread.php?t=77027 ?! Christoph

Hi! Ändere in der Empfängerrichtlinie die Hauptadresse auf die .com-Adresse. Ggf. den RUS nochmal anstoßen (Update oder Rebuild). Christoph

Habe auch nix anderes erwartet, als dass es funktioniert :D Wo die Unterschiede sind?! Tja, das versuchen wir auch herauszufinden .... Wir kommen aber heute nicht mehr dazu, das zu testen. Wir haben das Problem erstmal umgangen und können von daher ohne Druck daran gehen, die Wurzel des Problems zu suchen. Wir haben die Zugriffsberechtigung direkt an den User aus Domain B gegeben, funzt..., ich weiß, ist nicht das Gelbe vom Ei, aber der User brauchte nun mal Zugang zu den Daten auf dem Share. Wenn wir aber den tieferen Grund gefunden haben, werden wir das natürlich entsprechend anpassen. Alle 3 Domains sind in-Place-migrierte Domains (NT4->AD). Wir haben damals jeweils eine VM pro Domain als temp. PDC installiert, den auf 2003 upgedatet und dann je 2 flammneue DCs hinzugefügt, alle FSMOs verschoben und dann die temp. DC aus den Domains entfernt. Ich bin mir ziemlich sicher, dass das sauber geschehen ist, bin aber gerne bereit, dass nochmal zu gegenzuchecken. Falls du irgendwelche GPO Settings wissen willst, stelle ich die gerne zur Verfügung. /edit: Kleine Ergänzung: habe auf dem Schema- und Dom.-Naming-Master, der auch PDC Emulator und RID-Master seiner Domain ist, mal dcdiag /v gemacht. Alle Tests: passed Christoph

Ja, ich glaub das ist irgendwas mit "FieldEngineering", weiß aber grad nicht, wo der gesetzt werden muss. /edit: hier stehts... http://support.microsoft.com/kb/314980 Christoph

Hi, ja, wir haben die Trusts noch mal überprüft: successfully validated.... Dennoch vermuten auch wir da das Problem, aber wir haben da mittlerweile mal einen Call bei MS laufen.. sollen die sich auch mal die Köpfe zerbrechen ;) Wie gesagt: wir haben eine VM-Umgebung mit 2 Domains gebastelt und da funzt das, auch funzt das ganze in der prod. Domain andersrum (Share in Domain B, univ. Gruppe in B, userkonto in A -> Zugriff möglich... Wir haben Replmon natürlich probiert: meldet keine Fehler... Replikation mittels Reghack loggen lassen? Kannst Du das mal erläutern? Schon mal danke für Deine Mühe :) Christoph

Hi, - definiere ein URL-Set, für das Zugriff erlaubt sein soll. - definiere 2 Regeln: eine für die Websites, auf die Zugriff erlaubt ist und eine, für die Zugriff verweigert wird. Bei der Regel, die den Zugriff erlaubt, stellst du als Target das URL-Set ein, bei der anderen gibst Du "External" an. Für die Deny-Regel öffne die Eigenschaften und aktiviere das Kontrollkästchen für die Umleitung und gib dort die URL für die anzuzeigende Site ein. Die Allow Regel muss vor der Deny Regel stehen! Das funktioniert! Christoph

Upss... hab ich wohl irgendwie übersehen :shock: Äh... in dem Fall solltest Du dann doch besser mal anrufen und sagen, du hättest wohl ein falsches Zertifikat bekommen. Christoph

Problem noch nicht gelöst :( Wir haben das ganze jetzt mal in einer VM Testumgebung gemacht, da gabs keine Probleme... Bin immer noch für Ideen offen... Christoph

Hi, nein, du bekommst nur das eine Welcome Kit. Wenn Du noch eine andere Wahlprüfung vor der 284 gemacht hättest (299 z.B.), hättest Du 2 Kits anfordern können. Einmal für MCSA und einmal für MCSA+M. Christoph

Hi, die 285 ist leichter, nicht so viel Text zu lesen, wie bei der 297. 6 Szenarios a 4-6 Fragen. Einiges zur Planung von Migrationen (5.5->2003, 2000->2003). Sollte für einen der die 284 gepackt hat, kein großes Problem darstellen. Falls Du noch was lesen willst, empfehle ich, in die Technical Library für Exchange 2003 reinzuschauen: http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/default.mspx Insbesondere das Whitepaper "Planning an Exchange 2003 Messaging System" dürfte gut sein zu kennen. Gruß Christoph

Update: wir haben das jetzt mal umgekehrt probiert. In Domain B.firma.com haben wir eine universelle Gruppe eingerichtet und Zugriff auf eine Freigabe auf einem Server in B.firma.com gegeben. Dieser Gruppe haben wir Mitglieder aus A.firma.com hinzugefügt. In dem Fall ist der Zugriff möglich :shock: Christoph