Wurzerl

Eingriffe ins AD sind immer mit der nötigen Sorgfalt vorzunehmen und manchmal nicht zu vermeiden. Wegen einem Benutzer, der sich gestört fühlt, weil sein Name nicht richtig geschrieben ist, sind solche Änderungen vielleicht übertrieben. :nene: Wenn jedoch seine Seligkeit davon abhängt, und er mit den eventuellen Folgen einverstanden ist (kann bis zum Löschen des Postfaches anschließender Neuanlage führen), dann ja. :D

Die fraglichen Netzlaufwerke nicht permanent über den Explorer verbinden, sondern mit einem Script im Autostart: net use N: \\Server\Freigabe /persistent:no Der Parameter persistent:no verbindet das Laufwerk nur für die aktuelle Sitzung. Dann kommt zwar auch die Meldung, doch nur im DOS-Fenster, das sich nach dem Scriptende schließt.

Bitte poste die Event-ID´s vom DHCP-Server und Client.

Aber nicht für eine Produktivumgebung!

Bei 2010 kann das Attribut problemlos geändert werden, ja es scheint sogar unbedingt erforderlich zu sein. Das sollte auch bei 2003 problemlos möglich sein.

Richtig, Variante 2, die Verteiler- und Sicherheitsgruppen zu trennen ist die sauberere Lösung. Das Verzahnen von Sicherheits- und Verteilergruppen war mit Exchange 2003 noch möglich und funktionell, mit Exchange 2007 ist es sehr empfehlenswert, diese zu trennen.

Wenn Verteilergruppen in einer Verschachtelung funktionieren sollen, muß jede Gruppe eine Verteilerguppe (Email aktivierte Gruppe) sein. Hat eine Gruppe in dieser Struktur kein Mailkonto, wird auch die Vererbung unterbrochen - damit auch die Mailverteilung.

Wenn Du den älteren DC nur herabstuftst, ist dieser trotzdem noch mit Namen in der Domäne vorhanden. Dieser muß zuerst entfernt werden. Das Beste wäre, danach einen neuen DC mit dem alten Namen zu installieren. Möglich wäre auch noch, den derzeiten 2008 R2 DC umzubenennen, habe ich in der Praxis noch nie gemacht und würde ich bei einem Livesystem weitestgehend vermeiden. Eine ebenso unerprobte Alternative auf einem DC wäre, auf dem 2008 R2 DC, zusätzliche Namen für den DC zu vergeben: HKLM\System\CurrentControlSet\Services\DNSCache\Parameters MULTI_SZ: AlternateComputerNames = NeuerName1.domäne.erw NeuerName2.domäne.erw HKLM\System\CurrentControlSet\Services\LanManServer\Parameters MULTI_SZ: AlternateComputerNames = NeuerName1 NeuerName2 DWORD: DisableStrictNameChecking = 1

Entweder wie von Norbert vorgeschlagen, den Namenscache einzeln im Outlook löschen (nur die Alten werden gelöscht, geht jedoch viel Zeit drauf), oder gleich die Autovervollständigenliste im Outlook leeren (Alle werden gelöscht, muß nur einmal pro Outlook und Benutzer durchgeführt werden. (Wäre meine Empfehlung)).

Sorry, hab ich überlesen, daß es sich um einen 2003 handelt. Jedoch scheint das Problem auf der gleichen Schiene zu liegen. Wurde hier auch ein Update oder Hotfix im Zeitraum von September bis Oktober 2012 ausgerollt? Oder ist das Problem dem User schon länger bekannt? Folgende Attribute sollten überprüft werden (falls vorhanden): DistinguishedName legacyExchangeDN proxyAddresses textEncodedORAddress

Seit der Installation des Update Rollup7 f. Exchange 2010 SP1 treten Probleme auf, die mit LegacyExchangeDN zusammenhängen. Ich habe das bei folgenden Szenarien beobachtet: Namensänderungen (Heirat, etc., betraf eine Dame, die vor 4 Jahren geheiratet hat, d. h. mit Exchange 2003 und 2010 vor RU7 hat es funktioniert!) Anlage doppelter Benutzer mit Kopie: Benutzer, Kopie wird erstellt mit Benutzer2 für verschiedene Aufgaben und daher auch mit einem zugeordneten Mailkonto versehen. Abhilfe ist hier mit der Karteikarte Attribut-Editor des AD möglich, aber hier nicht nur das Augenmerk auf "LegacyExchangeDN" legen, sondern auf alle Attribute, die den String beinhalten und ändern.

Falls noch möglich, eine authoritative Wiederherstellung auf dem virtualisiertem DC durchführen. Wenn diese erfolglos bleibt, die FSMO-Rollen auf dem "aktiven" DC übernehmen. Den nicht mehr replizierenden Server demoten (siehe hier), danach wieder dcpromo.

Verhindert man das Löschen von Dateien, kann der Benutzer diese auch nicht mehr ändern. Zum Ändern von Dateien muß ein Löschrecht gesetzt werden, da die zu ändernde Datei nicht überschrieben, sondern gelöscht und wieder neu angelegt wird.

Steuere gleich meine ersten Erfahrungen mit Hyper-V 2012 bei: Installation recht flott, nimmt jede Hardware, solange ein 64-Biter darin werkelt. So, das war´s auch schon, das Positivum. Verwaltung nur mit Windows Server 2012 Server oder Windows 8 remote möglich, mit 2008 R2 oder Windows 7 sieht´s derzeit ziemlich traurig aus. Es fehlt schlicht ein Client zur Verwaltung, und sei es ein Dürftiger wie jeder von Xen (XenCenter). Daher mein Urteil: bemüht, Potential vorhanden, aber bis dato nicht genutzt.

Weil VMware und deren Verwaltung erprobt und getestet sind. Sicherung, Wiederherstellung, Abläufe, Verwaltung etc. Natürlich werde ich den Hyper-V 2012 testen, genauso wie den Vorgänger und XenServer. In der Grundversion sind alle Hypervisoren kostenlos. Erst bei den Verwaltungstools muß man mit der Kohle rausrücken, da machen alle Hersteller keine Geschenke.

Weise die Objektverwaltung auf dem 2008 R2 DC dem Benutzer neu zu. OT: Wenn keine 2003 Domäne mehr zu verwalten ist, dann ist ein Update der DC auf 2008 R2 empfehlenswert.

Ist der Exchangeserver am gleichen Standort? Outlook-Verbindung über LAN oder HTTPS? Exchange-Cache eingeschalten?

Die IP vom DC2 muß geändert werden: am DC2. am DHCP (als DNS-Server) und eventuelle DNS-Einträge auf Geräten, die keine Leases vom DHCP beziehen (z.B.: Router, Firewall) Sollt´s dann gewesen sein.

Clientseitige Zwischenspeicherung aktivieren. U.a. hier beschrieben.

Den Ordner b mit "Eigenschaften - Sicherheit -Erweitert" erweiterten Sicherheitseinstellungen konfigurieren, daß der Benutzer nur die Änderungsrechte auf "Nur Unterordner und Dateien" oder "Nur Dateien", je nachdem wie´s gewünscht ist, hat.

Reverse DNS-Lookup aktivieren. Siehe hier.

Für die Servervirtualisierung würde ich derzeit noch VMware 5.1 vorziehen. Die Arbeitsstationen mit einer Terminalserverlösung bedienen, da wäre die erste Wahl Citrix XenApp oder auch einzelne Arbeitsplätze mit XenDesktop, da muß aber das Storage und die Serverausstattung dahinter stimmen.

In so einem Falle würde ich so vorgehen: Sicherstellen, daß alle FSMO-Rollen und GC auf Server1 sind. Daten des Servers2 aus AD löschen. Siehe hier und hier. Server2 neu aufsetzen und als DC wieder ins AD bringen. Wenn es dann immer noch Fehler gibt, FSMO-Rollen und GC auf Server2 verschieben, Server1 demoten, neu aufsetzen, promoten. Und beim Kunden eine entsprechende USV und Backupserver installieren.

Dürfen die Postfächer Nachrichten von allen Absendern annehmen (Nachrichtenübermittlungseinstellungen)?

Sind´s immer die gleichen Clients, handelt´s sich um Laptops, Workstations, funktioniert OWA (falls eingerichtet) nach dem Trennen?