aba

Also aktuell ist die 70-218 noch als "Elective-Exam" bei MS für den MCSE 2000 aufgelistet. (Stand 16.06.04/12:55)

MCSE on Microsoft Windows 2000 Certification Requirements

Ich würde erst von W2k auf W2k3 umstellen. Dann ein paar Tage so laufen lassen, um sicher zu gehen, dass auch wirklich alles funktioniert. Anschließend das Exchange-Update auf E2k3.

Ich habe das bisher nur einmal in einer Testumgebung gemacht ... hat auch geklappt.

Original geschrieben von marcel-stein

wie kann ich den fehler vernachlässigen?

Einfach nicht hingucken!!! :)

Original geschrieben von marcel-stein

ist das backup trotzdem o.k.?

es fehlen an die 50 MB

...

Steht doch bei MS in dem KB-Beitrag:

Microsoft Knowledge Base Article - 822132

.......

This error does not jeopardize the integrity of the backup.

.......

-> Der Fehler beeinträchtigt nicht die Integrität des Backups

Ich weiß ja nicht aus welcher "Rubrik" Du kommst (Privatanwender, MS-Partner, Großkunde, Mittelständler, ....)

Aber hier gibt es unterschiedliche Support-Rubriken, da kannst Du Dir ja das passende aussuchen. Ist auch in deutsch ;)

Microsoft Supportangebote im Überblick

Nur was das kostet, das mußt Du da selber erfragen.

Genau. Bei MS anrufen, das Problem ist bekannt bei denen, sie stellen einen Fix zur Verfügung. Der Fix ist allerdings noch nicht hinreichend getestet.

Workaround: Ignorier den Fehler ;) (Der Fehler beeinträchtigt nicht die Integrität des Backups)

Original geschrieben von HiQDevil

....

Wenn ich mit Browstat status abfrage, bekomme ich einen LINUX-Rechner als Masterbrowser angezeigt

...

Ich würde ja mal behaupten, dass da ein Samba auf dem Linux-Rechner läuft. Und dem würde ich es austreiben, im "Browser-Geschäft" mitzumischen ;)

Schau mal in der smb.conf, was da bei folgenden Parametern eingetragen ist:

- domain master = xxx

- local master = xxx

- preferred master = xxx

.... am besten Alles auf "no" setzen.

Ich würde 2 Server (Marken-Server, reduntantes Netzteil, SCSI-Raid-5 + Support) empfehlen. Passend dimensoniert (also auch ein bischen an die Zukunft denken und Leistungs- als auch Platzzuwachs berücksichtigen) sollte das für 30 Clienst in Ordnung gehen.

4 Server sind imho nur erforderlich, wenn das Thema Redundanz wirklich sehr wichtig ist.

Ich kann mich dem Statement von banshi und phoenixcp nur anschliessen und hoffe, dass die Jungs richtig "eins auf die Mütze bekommen".

;)

Die SRV-Einträge der Domänencontroller werden von den DCs dynamisch auf dem DNS-Server eingetragen, wenn die ZonenDatei die dynamische Aktualisierung erlaubt. Verantwortlich für das Erstellen und Aktualisieren der SRV-Einträge der Domänencontroller auf dem DNS ist der Anmeldedienst (Netlogon) der einzelnen Domänencontroller.

Die MX-Einträge für die SMTP-Server müssen imho "von Hand" also manuell im DNS eingetragen werden ... und da auch nicht in den Containern der SRV-Einträgen, sondern direkt in der Zone (wo auch z.B. die A-Einträge gespeichert sind).

Nein, bisher ist das so nicht vorgesehen imho.

Die SRV-Einträge funktionieren nur, wenn die Server (Domänencontroller, die ihre Services an den DNS melden und eintragen lassen) und die Clients (die den DNS nach diesen Einträgen befragen) "zusammenspielen".

Meines wissens gibt es da bisher für andere Dienste (SQl, SMTP, ...) weder auf den Servern noch auf den Clients das Feature: "Meld mal deine Datenbanken an den DNS" bzw. "Frag mal den DNS nach einer DB" ....

Die SRV-Einträge dienen dazu, die einzelnen "Dienste" der Active Directory und die entsprechenden Domänencontroller, die diese zur verfügung stellen "zu finden":

Kerberos, LDAP, GC (Gobaler Katalog-Server) und PDC (PDC-Emulator).

Das ganze einmal "pauschal" für die komplette Domäne, und zusätzlich noch mal aufgeteilt nach den eingerichteten Standorten (im Untercontainer _Sites).

Wenn sich ein Benutzer an einem Client anmelden möchte, kontaktiert der Client den DNS-Server, um eine Liste der Domänencontroller zu bekommen, die die benötigten Dienste ausführen. Wenn Standorte implementiert sind, enthält die Ergebnisliste, die der DNS-Server zurückgibt nur die Domänencontroller (und deren IP-Adressen), die zum entsprechenden Standort des Clients gehören.

Der Punkt in der GPO heißt nun mal "Lokale Richtlinien" ;) (Hat Microsoft so "benannt")

Die Einstellung wirkt sich schon "global" aus, wenn Du sie in der GPO veränderst.

Oder versuch doch mal tracert 192.10.10.16. Dann siehst Du wenigstens schon mal die Route, die die Pakete nehmen.

Firewalls oder Portfilter sitzen nicht dazwischen?

Zur Sicherheit vielleicht noch mal auf den delegierten Container klicken. Dann müßte im rechten Fenster eigentlich ein Eintrag (NameServer-Eintrag) für den DNS-Server zu sehen sein, an den der Namensraum delegiert ist. Und wenn mich nicht alles täuscht, noch ein A-Eintrag (Hosteintrag) für die Auflösung des Namens zur IP für den DNS-Server, der die Delegierung bekommen hat.

Evtl. ist es ganz hilfreich, die jeweiligen DNS-Server mit einer sekundären Zone der anderen Domäne einzurichten/auszustatten.

Dadurch sollte dann eine fehlerfreie Namensauflösung der Rechner zwischen den beiden Namensräumen in "beiden Netzen" möglich sein.

Wenn Du eine Delegierung erstellt hast, mußt Du auf dem Server, der den delegierten Namensraum auflösen soll, auch eine primäre Zone für den delegierten Namensraum mitsamt aller enthaltenen Einträge erstellen (entweder manuell die Einträge reinbauen, oder eben per dynamischer Aktualisierung). Wie soll die Namensauflösung sonst funktionieren?

Wenn Du also auf dem DNS-Server1 die Zone square.washington.us auf/an den DNS-Server2 delegierst, dann mußt Du auf dem DNS-Server2 auch eine primäre Zone mit dem Namen square.washington.us einrichten und dort auch die Einträge (A-, CName, MX-, oder "whatever"-Einträge) in die Zonendatenbank bringen.

Und der administrative Aufwand zwischen Stub-Zone und delegierter Zone ist eben nicht identisch. In einer Stub-Zone werden die Einträge automatisch vom Master an die Stub-Zone weitergeleitet. Bei einer Delegierung sind alle Veränderungen an den DNS-Servern manuell einzutragen.

Schau doch mal bei http://www.eventid.net/ vorbei. Unter der EventID 61 und der Quelle "Print" ist da einiges an Tipps zu finden.

Als Memberserver sollte es keine Problem mit dem Terminal-Server-Dienst unter Windows Server 2003 in einer "2000er"-AD geben.

Original geschrieben von Fidi

...

hat jemand Erfahrungen mit den temp. TSCALS auf einem

W2K2 Terminal-Server.

....

Meines Wissens nach ist doch bei den Pro Versionen eine

Zugriffslizenz mit integriert?!

...

Wenn Du einen W2k3 Terminal-Server meinst: Da gibt es imho keine Client-Zugriffs-Lizenzen im Windows XP mehr.

Am besten alles in eine Batch ... Vielleicht vor dem Kopieren noch eine Abfrage des Errorlevels, ob das Verbinden des Netzlaufwerks geklappt hat.

mac2003: Schau doch mal bitte, wie große die Datei priv.edb im Dateisystem ist ;)

Darauf bezieht sich die Größenangabe von maximal 16GB bei der Standard-Edition.

Und ja, die einfache Addition der einzelnen Postfachgrößen weicht von der realen Größe der Datenbank ab. Das liegt daran, wie Exchange die Daten in der Datenbank verwaltet.

Delegieren von Zonen bedeutet eigentlich nur, dass man die Verwaltung eines Teiles der Zone an "Andere" abgibt (an andere Server, bzw. evtl. auch an andere Administratoren).

Delegieren funktioniert folgendermaßen: In der Zone, dessen "Teil" delegiert werden soll, wird die Verwaltung an einen anderen Server abgegeben. Auf diesem Server wird dann eine primäre Zone eingerichtet, der Administrator dieses Servers kann diese "delegierte" primäre Zone dann vollständig verwalten (mit allem drumm und dran, dynamischen Updates, manuellen Einträgen, weiteren sekundären Zonen, ....).

In der primären Zone, dessen Teil (Untermenge der Zonen-Datenbank) delegiert wurde, befindet sich ein Eintrag, der nur den Hinweis (NS-Eintrag) zum "neuen" zuständigen Server des delegierten Bereichs der Zone darstellt.

Etwas klarer geworden?

In der Computer-Konfiguration könnte man z.b. Skripte einhängen, die die Festplatte aufräumen (Temp-Ordner löschen oder so) ;)

Der Befehl unter W2k lautet:

secedit /refreshpolicy {machine_policy | user_policy}[/enforce]

Wenn das Script beim Anmelden ausgeführt werden soll, dann sollte das Script nicht in der Computerkonfiguration sondern in der Benutzerkonfiguration als Anmeldeskript eingetragen/hinterlegt werden.

Die Userkonten sollten sich dann natürlich auch in der entsprechenden OU befinden.

Etwas weniger Arbeit:

Alle Rechner, an die sich die "normalen" User nicht anmelden sollen in einer OU zusammenfassen.

GPO auf die OU legen.

Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinie -> Zuweisen von Benutzerrechten:

Entweder "Lokal anmelden zulassen" oder "Lokal anmelden" mit den entsprechenden Gruppen versehen ... fertich.