Christoph35
-
Gesamte Inhalte
3.624 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Christoph35
-
-
Naja, man könnte natürlich mit NTBackup in der von Exchange mit gelieferten Version ein Backup in eine Datei machen, und diese Datei mit einem anderen System sichern.
Gruß
Christoph
-
Durch das Beenden etwaiger Dienste vor einer Sicherung könnte auf Agends wie SQL / Exchange verzichtet werden, da ja die Datenbanken dann nicht mehr offen sind.
Also DB und Exchange sind Anwendungen, die i.d. Regel 24x7 laufen sollen, da ist es mit dem Beenden der Dienste dann nicht weit her ;-). Damit braucht man dann aber auch wieder die Agents.
Besonders im Fall Exchange ist noch zu erwähnen, dass nur eine Online - Sicherung die Transaction-Logs löscht; wenn die (wie bei einer Offline-Sicherung) erhalten bleiben, läuft früher oder später die Platte mit den Logs voll, was für Exchange nicht besonders gesund ist... kein Platz für Logs heisst nämlich, dass sich die Exchange Dienste beenden und dann ist das Geschrei groß ... ;)
Gruß
Christoph
-
Hi,
das wichtigste:
Du solltest hier für Active Directory mehrere Standorte definieren und die Intersite-Replikationstopologie entsprechen konfigurieren, damit die Daten zwischen den Domain-Controllern zu den Zeiten übertragen werden, zu denen die Verbindung besteht.
Außerdem ist in dem Fall ganz wichtig, an jedem Standort mindestens einen Domain-Controller zum Global Catalog Server zu machen.
Da die Verbindung ja nicht immer besteht, kann es natürlich sein, dass sich ein Benutzer, der an Standort A angelegt wird, sich evtl. erst einen Tag später an Standort B anmelden kann.
Du solltest weiterhin an jedem Standort einen DNS-Server zur Verfügung stellen, damit die Clients ihren jeweiligen DC auch finden.
Gruß
Christoph35
-
Wie oben schon erwähnt wurde, sollte an jedem Standort auch ein DC zum Global Catalog Server gemacht werden (AD Standorte und Dienste, Eigenschaften von NTDS-Settings unterhalb des Servers).
Marco hat mit seinen Bemerkungen recht. Zu erwähnen wäre höchstens noch, dass der Replikationsverkehr, den die GC-Replikation verursacht, reduziert wird, wenn der Forest den Windows 2003 Native Functional Level hat (und damit auch alle Domains, ist hier wohl nur eine?!). Dann findet eine Delta-Replikation statt, d.h. nur Änderungen an den Gruppenmitgliedschaften werden repliziert, nicht mehr die kompletten Gruppenmitgliedschaften.
Gruß
Christoph
-
falls du mehrere usernamen geleichzeitig lesen willst, würde ich die anmeldenamen in eine text-datei speichern, diese mit dem fso (filesystem scripting object) auslesen und als eingabequelle für das script verwenden.
Christoph
-
Versuchs mal hiermit:
wscript.echo "Username: "
username=wscript.stdin.readline()
und dann die var. username im weiteren script verwenden
Gruß
Christoph
-
Seit wann bist Du MCSA?
Bis das Cert. kommt, dauert es so ca. 3-4 Wochen ab Anforderungsdatum.
Und Certs gibts nur pro Titel (MCP, MCSA, MCSE).
Gruß
Christoph35
-
Aha, danke für die Info!
Schade, wäre eigentlich sinnvoll... wenigstens scheint demnach Stufe 1 zu greifen.
-
Versuchs mal mit dem Windows Server 2003 Deployment Kit (auch online verfügbar). Da steht so einiges drin, ansonsten die Training Kits zum MCSE 2003. Nicht zu vergessen: Technet, Whitepapers und Webcasts. Die Bücher geben nicht über alles Auskunft.
Christoph
-
So ist es. GPOs auf OUs die tiefer in der Hierarchie liegen überschreiben oder ergänzen GPOs für übergeordnete OUs.
Da für OU2a kein GPO angegeben ist zieht hier die GPO für OU2. Bei OU2b hast du ein GPO eingebunden, das die OU2 GPO überschreibt oder ergänzt.
Gruß
Christoph
-
Kann ohne weiteres und sollte sogar, wie olaf schon geschrieben hat, um die Anmelde-Geschwindigkeit zu erhöhen.
Unter win 2003 gibt es noch die Alternative, die Daten des GCs lokal zu cachen (wird auch über AD Standorte und Dienste konfiguriert), aber einen GC vor Ort würde ich vorziehen.
Nicht beides: global catalog und caching sondern nur eins von beiden ;)
Christoph
-
GC = Global Catalog, da wird ein Teil der User-Attribute drin gespeichert (z.B. Gruppenmitgliedschaften bei universellen Gruppen).
Wenn ein GC vorhanden ist, läuft die Anmeldung schneller wie EDV-Olaf gesagt hat.
Ach ja, DNS auf dem 2. DC ist auch nicht verkehrt. DHCP auf einem Domain Controller? Kann gehen, aber unter Umständen soll das zu Sicherheitslücken führen können. Müsste ich aber noch mal nachlesen.
Wenn Du die DNS-Zone im AD speicherst (ohnehin angebracht, wg. Sicherheit), wird die automatisch zu allen DNS Servern oder DCs repliziert (kann man in den Eigenschaften der Zone einstellen).
Gruß
Christoph
-
Ach ja... weniger als 512 KBit / sec. sollte ich wohl genau sagen ;-)
Gruß
Christoph
-
Hallo,
am besten setzt Du einen neuen Computer als Domain-Controller auf und sagst bei der Installation von AD, dass es sich um einen zusätzlichen Domaincontroller handelt. Dann repliziert er die Daten des 1. DC.
2. Möglichkeit, wenn die Verbindung zwischen den Standorten langsam ist: Du machst ein Backup des System-State und brennst das auf eine CD. Dann rufst du auf dem neuen Server DCpromo mit /adv auf, was Dir die Möglichkeit gibt, die Daten von CD zu holen. Das geht ggf. schneller als über eine langsame WAN-Leitung.
Alle Clients können sich über den jeweils anderen DC anmelden, wenn einer von beiden ausfällt und die Standorte über eine WAN-Leitung miteinander verbunden sind. Wenn es sich um ein anderes IP-Netz handelt, solltest du in AD Standorte und Dienste beide IP-Netze dem Standort hinzufügen, oder du erstellst einen neuen Standort und fügst die IP-Netze ihrem jeweiligen Standort hinzu. (2. Möglichkeit ist empfehlenswert, wenn die WAN-Leitung weniger als 512 KB/sec. hat.)
Gruß
Christoph35
-
Auch von mir nen herzlichen Glückwunsch,
die 294 habe ich erst im 2. Anlauf bestanden, die hats auch wirklich in sich ...
Naja, bin jetzt mal auf die 284 gespannt, die ich in diesem Jahr noch durchziehen will.
Gruß
Christoph
-
Hat niemand ne Idee?
Gruß
Christoph
-
Ich habe grade mal auf unserem Fileserver gesucht,
für das Failover eines DC könnte ich Dir ein PDF zur Verfügung stellen.
Gruß
Christoph35
-
Also für einen DC sollte man das wohl besser nicht machen, da Multimaster.
lieber mit den AD Konsolen, die FSMO Rollen übertragen.
Aber probiert haben wir Doubletake auf einem DC nicht. Gibt doch bei Sunbelt oder Doubletake einige Whitepapers. Guck da mal rein.
Gruß
Christoph
-
Hi,
wir haben das mit gutem Erfolg in Einsatz. Sowohl für FileServer als auch für Exchange.
Bisher keine ernsthaften Probleme aufgetaucht.
Gruß
Christoph35
-
upss... so genau hab ich das ja gar nicht gelesen ;)
Grizzly hat natürlich recht, für die user im container users gelten in dem fall die Domainpolicies, an den Container users lässt sich keine gp binden.
-
Hier gelten, da erst die Standort-Richtlinien und dann die Domain-Richtlinien angewandt werden, die der Domäne.
Gruß
Christoph
-
Hallo,
mal ne Frage zu Exchange 5.5 MTA Queues:
Wir haben erfolgreich einen Exchange 2003 in eine Exchange 5.5 Organisation aufgenommen (gemäß E2K3 Deployment Tools).
Es sind 4 Exchange Server in 3 Domains in 1 Site.
Domain1: exch55server1 und ex2k3server1 (AD-Domain)
domain2: exch55server2 (AD-Domain)
domain3: exch55server3 (NT4-Domain)
Auf den Rechnern, auf denen der Exchange 2003 System Manager und das Exch.5.5 Admin.-Programm installiert sind, bekomme ich sinngemäß folgende Fehler-Meldung wenn ich mir die MTA-Queues ansehen will:
"Das Administrationsprogramm konnte sich nicht mit dem Server ex55server1 verbinden, stellen Sie sicher, dass der MTA-Dienst läuft"
Der MTA-Dienst läuft aber auf allen Exchange 5.5 servern (getestet mit Mail-Verkehr zwischen den Servern und nach extern).
Die Queues werden aber auf Rechnern angezeigt, auf den der E2K3-System Manager nicht installiert ist. :suspect:
Was muß ich tun, um auch dann im Exchange 5.5 Admin.-Programm die MTA-Queues sehen zu können, wenn der E2K3 System Manager installiert ist?
Hoffe, ihr könnt mir helfen.
Christoph
-
Glückwunsch auch von mir!
Falls Du (in einem halben Jahr oder so ;) ) wieder Lust aufs Lernen hast, kannst Du auch ja den MCSE+M (Messaging) machen, wie mein Vorredner vorschlug ...
Ich glaub Exchange Spezialisten werden gebraucht (Umstieg bei vielen Firmen von Exchange 5.5 nach Exchange 2003).
Gruß
Christoph
-
du könntest es mit tests von measureup versuchen, deinen Kenntnisstand zu checken.
Ansonsten kann ich nur empfehlen, dass ganze mit testlabs zu üben, wieder zu üben und dann nochmal von vorn....
Wenn man genügend ausgestattete rechner zur Verfügung stehen hat, empfehle ich den Einsatz von VMWare oder Virtual PC.
Was auch noch sinnvoll ist: Technet und Whitepapers und Webcasts.
Gruß
Christoph
Vernetzung mehrerer Standorte
in Windows Server Forum
Geschrieben
Kommt drauf an, wie groß die Zweigstellen sind (Anzahl user). Wenn es nur wenige User pro Filiale sind, kommst Du wahrscheinlich mit einer Domain gut hin, wenn die User gleichmäßig auf alle Filialen verteilt sind, kann man überlegen, ob man SubDomains einsetzt. Für weniger als 100 User pro Site würde ich jedenfalls keine eigenen Domains einsetzen. Für Ausfallsicherheit sollte man bei mehr Usern min. 2 DCs pro Standort und Domain nutzen, und das ist dann eine Kosten-/Nutzenfrage.
Christoph