Christoph35

Nein, ich meine schon den _msdcs-Ordner unterhalb der Domain. Das ist der 1. von mir im vorherigen Posting beschriebene Fall (_msdcs.domain.tld nur einmal sichtbar). Wie gesagt, musst (und kannst) Du hier nur die Eigenschaften von test.dom nutzen, um dyn. Updates und die Integration ins AD zu konfigurieren. Es kann aber auch so eingerichtet sein, was dann der 2. Fall wäre: http://img24.imageshack.us/img24/4115/dnsmgmt.jpg. (Advworks.com ist meine Test-Domain in einer VM). Christoph

Hi, das Zertifikat wird dann als vertrauenswürdig eingestuft, wenn das Zertifikat der ausstellenden CA (und ggf übergeordneter CAs bis zur Root-CA) als vertrauenswürdig eingestuft ist. Heißt für Dich, wenn Du eine eigene CA nutzen willst, oder eine CA, deren Zertifikat nicht in der Microsoft Liste der Trusted Root CAs enthalten ist, dass Du deren Zertifikat auf alle Client-Rechner ausrollen musst, und dort in den Speicher für "Trusted Root CAs" integrieren musst. Das ließe sich in einer Domain über eine Group Policy erreichen. Outlook Anywhere Access funktioniert auch nur mit einer vollständig vertrauenswürdigen Kette von Zertifikaten, da Outlook eine Zertifikatswarning nicht wie Du im Browser einfach ignorieren kann. Christoph

Wird der _msdcs-Ordner gelb oder grau dargestellt? Wenn gelb, dann ist es eine DNS-Sub-Domain von Test.dom, es wurde nicht mit einer Delegation gearbeitet und du kannst, wie Du schon festgestellt hast, keine Eigenschaften setzen. Dann musst du diese Konfigurationen nur auf der Test.Dom-Zone machen. Wenn der Ordner unterhalb von test.dom grau dargestellt ist, wurde eine Delegation erstellt, dann müsste es unterhalb von Forward-Lookup-Zones noch einen weiteren _msdcs.test.dom Eintrag geben, auf dem die Eigenschaften separat konfiguriert werden können. Christoph

Hi, ich kann Dir sagen, wie Du es bei einem englischen Standard-2003-Server machst, sollte auch auf einem SBS funktionieren. Also: DNSMGMT.MSC starten (start/ausführen/dnsmgmt.msc eingeben), dann Deine AD-Zone auflisten und gleich mal schauen,. ob die _msdcs.<ad-domain.tld>-Zone nicht doch schon vorhanden ist. Wenn nicht, rechtsklick auf die Zone und "new delegation" auswählen. Im Verlauf des Wizards _msdcs als Namen eingeben und danach den Server als Nameserver auswählen. In den Eigenschaften der Zone und der _msdcs-Zone kannst Du jeweils einstellen, dass nicht sichere Updates zugelassen werden. Zur Integration ins AD neben "Type" auf "Change" klicken und da das unterste Kontrollkästchen aktivieren. Danach kannst Du dann konfigurieren, dass sich nur Domänen-Mitglieder automatisch im DNS registrieren können. Christoph

Es kann in Zusammenhang mit Linux und .local auch Probleme geben, wenn MDNS (Multicast DNS) aktiviert ist. Ich hatte das mal in einer Testumgebung. .local-Namen konnten nicht aufgelöst werden, obwohl ich glaubte, DNS korrekt konfiguriert zu haben. Bin dann auf diesen Artikel gestoßen: Cool Solutions: Resolution problems with SUSE Linux in a .local domain Christoph

Hi, vielleicht hilft Dir dieser Thread: Re: Trust issue "The specified user already exists" Christoph

Hätte mir auch eine Teilnahme vorstellen können, wenn es denn eine Veranstaltung auch hier im Westen gäbe (z.B. Köln oder Düsseldorf). Naja, viel Spass und viel Erfolg, damit ihr vielleicht mal auch im Westen eine Veranstaltung anbieten könnt ;) Christoph

Für die, die Ex. 2007 einsetzen: Schneller als gewöhnlich hat MS ein neues Update Rollup für Ex. 2007 SP1fertiggestellt, das einige Bugfixes bringt: You Had Me At EHLO... : Update Roll-up 7 for Exchange Server 2007 Service Pack 1 has been released. Außerdem gibt es neue Doku zu Ex. 2007 SP1: Ankündigung hier: http://msexchangeteam.com/archive/2009/03/18/450860.aspx Christoph

Klare Antwort: Nein. Es geht nur über Verteilerlisten, öff. Ordner oder Resource Mailboxen, auf die der User Send-As-Berechtigungen erhält, so wie im oben verlinkten Artikel beschrieben. Christoph

Du könntest ja erstmal die Situation in VMs nachstellen und da üben, bevor Du es auf dem produktiven Server durchführst. VMware server 2.0 oder Virtual PC bzw. Virtual Server sind kostenlos erhältlich, aber Du brauchst natürlich einigermaßen gut ausgestattete Hardware. Wenn Du mal nachlesen möchtest, könntest Du z.B. hier anfangen: Deploying Domain Name System (DNS): Domain Name System(DNS) Christoph

Hi! Falls es auf dem 1. DC wider Erwarten noch keinen DNS Server Service gibt, kannst Du auch auf dem vorhandenen Server DNS installieren und solltest anschließend den DNS Client des DCs auf den DC selbst zeigen lassen. Dann legst Du eine Zone an, die so heißt, wie eure AD Domain. Lass vorläufig nicht sichere dynamische Updates zu. Danach konfigurierst Du eine Delegation der _msdcs.<ad.domain>-Zone (auch hier ggf. dyn. Updates zulassen). Ein Restart des NETLOGON-Dienstes sollte die SRV- und anderen DNS-Records dann registrieren; falls nicht, tut es auch ein NetDiag /fix oder als Ultima Ratio ein Reboot. NetDiag ist Teil der Windows Server 2003 Support Tools. Anschließend kannst Du die Zone ins AD integrieren und lässt nur noch sichere dynamische Updates zu. Zur Ausfallsicherheit installierst Du den 2. DC incl. DNS Service, gibst vor dem DCPromo zunächst den 1. DC als DNS-Server an und wartest ein wenig ab. Die Zone wird automatisch auf den 2. DC repliziert. Zur Auflösung der Internet-Domains konfigurierst Du auf den DNS Servern ein Forwarding für alle anderen Domains zum Router, oder gleich zu den T-Com DNS Servern. Christoph

Ja, aber das kann u.U. Stunden dauern, oder? Das ist Zeit, in denen die User dann im Extremfall untätig herumsitzen... Christoph

Da hat Frommi natürlich auch recht, hab ich übersehen :rolleyes: Christoph

Der Userprincipalname kann nicht gleich dem Vornamen sein, da der UPN nach dem Schema user@domain.tld aufgebaut ist. Versuch es stattdessen mit dem Attribut sAMAccountName. Der ADExplorer könnte Dir einen Einblick ins AD verschaffen: http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx Christoph

Hier noch mal ein Artikel, warum das von MS nicht unterstützt wird: Ask the Performance Team : Network Stored PST files ... don't do it! Christoph

Der Datenbankspeicher wird doch während der Online-Defragmentierung nächtens als frei markiert. Und der freie Platz wird ja von neuen Mails wieder belegt. Die offline-Defrag mit ESEUtil wird genutzt um die DB-Dateien zu verkleinern. Wenn Du also nicht akute Platzprobleme auf der HD hast, wo die Exchange-DBs liegen, würde ich das lassen. Du müsstest auch ohnehin die DBs offline nehmen und in der Zeit könnten die User nicht arbeiten. Christoph

Hi, wir nutzen dieses Tool zur Ermittlung inaktiver User Accounts: OldCmp Kommandozeile kann wie folgt lauten: OldCmp.exe -b <basedn> -users -nodc -llts -realage -age <x> -sort cn -unsafe -report -file \\<fileserver>\<share>\filename.htm x = Inaktivität in Tagen

So verstehe ich das auch. Aber der Doc wird das sicher noch bestätigen oder ggf. widerlegen. Christoph

Ja, aber wozu dann der SBS? :confused: Wie soll denn z.B. der Zugriff auf den Exchange gestaltet werden? Wenn die Clients nicht zur Domain gejoint werden, müssen die User bei Verwendung von Outlook jedesmal eine Extra-Anmeldung für den Exchangeserver durchführen. Christoph

Schau mal hier: https://www.mcseboard.de/microsoft-lizenzen-50/anzahl-cals-ermitteln-147076.html Christoph

Ähm, fast... Der SBS wird der primäre DNS Server im Netz. Das muss so sein, damit die Clients zur Domain gejoint werden können. Also musst Du den Clients den SBS als DNS Server angeben, nicht den Router! In den Eigenschaften des DNS Servers (SBS) richtest Du ein Forwarding für alle anderen Domains zum Router ein (der ja im Prinzip auch nur ein Forwarding auf den ihm angegebenen DNS Server des Providers macht). Christoph

Wie Norbert schon schrieb, gilt beim SBS das Highlander Motto: There can be only one (SBS). Weiterhin können die SBS Domains keinen Trust zu anderen Domains aufbauen, damit ists eben auch Essig mit ChildDomains. Du müsstest also die eine SBS Domain auflösen und die Ressourcen und Konten in der anderen Domain erstellen. Aber es hält Dich nichts davon ab, den Exchange des verbleibenden SBS für beide E-Mail Domains über Recipient policies zu nutzen. Christoph

Hallo, und willkommen an Board! Du solltest den Windows DNS Service nutzen, damit der SBS seine SRV-Records registrieren kann. Diese sind für Active Directory zwingend erforderlich. Für externe Namensauflösung kannst Du ja eine Weiterleitung auf den Router konfigurieren. Christoph

Mit Win 2003 SP2 kam Receive Side Scaling, das sollte auf einem ISA abgeschaltet werden, da es zu Problem führen kann. An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers Christoph

Ok, als PC-Spiele Redakteure sollten die Spiele installieren dürfen, sehe ich ein :D, dass das in VMs eher schlecht ist, auch... Leider ging das ja aus deinem Ursprungsposting nicht hervor. Nun, dass es so einfach nicht geht, hat ITHome ja schon geschrieben. Aber ein Computerstartscript wäre auch meine Idee gewesen. Sind das dann eigentlich separate Computer? Oder schreiben die auf dem gleichen Rechner auch ihre Testberichte und machen ihre sonstige tägliche Arbeit? Christoph