zeus-cu

Hallo Leute, ich würde gerne in einer Testumgebung eine Domänenstruktur wiederherstellen. Diese sieht wie folgt aus: Ein Forest mit dom1.com und dom2.com. Unter dom2.com existiert dann noch sub1.dom2.com und sub2.dom2.com. In dom1.com gibt es zwei Domänencontroller: server1.dom1.com (Schemamaster, Domänenmaster), server2.dom1.com (PDC, RID, Infrastruktur) In dom2 und den Subdomains gibt es jeweils nur einen Domänencontroller. Alle Domänencontroller sind auch GC Wie gehe ich beim Restore jetzt vor: server1.dom1.com -> autorisierende Wiederherstellung server2.dom2.com -> nicht autorisierend Server1.dom2.com ->autorisierende Wiederherstellung Server1.sub1.dom2.com ->autorisierende Wiederherstellung Server2.sub2.dom2.com ->autorisierende Wiederherstellung Ist das so richtig? Danke für Antworten. Viele Grüße

Hallo, wir verwenden an jedem Standort einen HTTP Proxy mit Namen wwwproxy (wwwproxy.sub.domain.de). Wenn nun ein Mitarbeiter mit einem Laptop, welches in die Hauptdomaine gehört (domain.de), in einen Standort fährt, erhält er vom dortigen DHCP Server einen verbindungsspezifischen DNS Suffix (sub.domain.de) Wenn das Laptop jetzt versucht sich mit dem Rechner wwwproxy zu Verbinden, wird leider immer zu erst wwwproxy.domain.de vom Client angefragt. (dieser läßt sich auch auflösen) Ich möchte aber, dass der Laptop zuerst den verbindungsspezifischen DNS Suffix verwendet, also den DNS Server nach wwwproxy.sub.domain.de befragt. Kann man das irgendwo einstellen? Also die DNSabfrage soll in folgender Reihenfolge ablaufen: 1. verbindungsspezifischen DNS Suffix (sub.domain.de) 2. primärer DNS Suffix. (domain.de) Danke für Antworten. Gruß Klaus

Super jetzt funktioniert die Default Domain Policy. Die Versionsnummern im Sysvol und AD sind nun identisch und wenn ich etwas über die Gruppenrichtlinienverwaltung in der Default Domain Policy ändere wird dies schön repliziert. Wie dieser schiefstand auf den beiden DCs entstehen konnte ist mir allerdings nicht klar. Danke für eure Hilfe. Gruß Klaus

So ich glaube ich komme dem Fehler näher. Auf unseren beiden DCs wird angezeigt, dass die Versionsnummer der Default-Domain Policy im Sysvol von der Versionsnummer im AD abweicht: UserVersion : AD Version: 8, SysVol Version: 8 ComputerVersion : AD Version: 144, SysVol Version: 143 Dazu kommt dann noch, wenn ich mir die Default Domain Policy auf den beiden DC im sysvol ansehe, steht auf dem einen DC das maximale Passwortalter von 42 Tagen, auf dem Anderen 365 Tage (so wie es sein soll) Allerdings hat die Default Domain Policy im Sysvol der beiden DC die gleiche Versionsnummer aber mit offensichtlich unterschiedlichen Inhalten. Darf man das von Hand beheben, also die GPO von einem DC aus dem sysvol auf den anderen kopieren und dann noch die Versionsnummer mit dem im AD anpassen? Also mit Notpad in der GPT.ini rumfummeln? Gruß Klaus

Aus irgendwelchen unerfindlichen Gründen hatte wir in den vergangenen ca. 4 Wochen die Passwortpolicy, welche auf der Default Domain Policy eingestellt war. Diese hatte sich irgendwie auf einmal doch aktiviert. Ich dachte alles wäre somit in Ordnung. Heute ist die Policy aber wieder auf 42 Tage zurückgesetzt. Weiß der Teufel wo das herkommt. Ich bin ratlos. Ich habe gerade auf einem unserer Domaincontroller mit Set-ADDefaultDomainPasswordPolicy die Policy wieder geändert, dies hält allerdings nur ca. 5 Minuten, dann steht wieder der alte Schrott drin. Woher könnte das kommen? Wie kann ich das debuggen? Gruß Klaus

Schuldigung, wenn ich ein wenig Begriffstutzig bin. Mit einer Kennwortrichtlinie auf einer OU ändere ich die lokale Richtlinie auf dem Client die Domänen Richtline bleibt dann aber erhlaten? Ich möchte eigentlich, dass alle Benutzer in der Domäne die Kennwortrichtlinie mit komplexem Passwort erhalten. Lokale Benutzer sollen aber einfache Passwörter verwenden können. Vermutlich wird so was aber nicht gehen oder?

okay... Und wie mach ich das mit der Richtlinie für lokale Konten?

So habe jetzt in der Default Domain Policy die Kennwort Richtlinie gelöscht und eine weitere GPO auf die Domain gesetzt mit höherer Prio. Dann habe ich die GPO wieder gelöscht die Kennwortrichtline in der Default Domain Policy wieder eingetragen und jetzt wird sie beim Aufruf von net accounts /domain auch angezeigt. Very strange : net accounts /domain Die Anforderung wird auf einem Domänencontroller für Domäne xxxx.com verarbeitet. Abmelden erzwingen nach: Nie Minimales Kennwortalter (Tage): 0 Maximales Kennwortalter (Tage): 365 Minimale Kennwortlänge: 8 Länge der Kennwortchronik: 1 Sperrschwelle: Nie Sperrdauer (Minuten): 30 Sperrüberprüfungsfenster (Minuten): 30 Rolle des Computers: PRIMÄR Was mich jetzt allerdings sehr wurndert ist die Tatsache, das die lokale Kennwortrichtlinie (beim Aufruf von gpoedit.msc) jetzt ebenfalls dies Werte hat, die in der Default Domain Policy eingestellt sind. (s. Anlagen) D.h. ich kann jetzt keine lokalen User auf dem Client mit einem einfachen Passwort anlegen. Zudem ist die lokale Kennwortrichtlinie ausgegraut. Ich kann nichts an ihr ändern, auch nicht wenn ich mich nur lokal anmelde. Ist das so beabsichtigt? Gruß Klaus

Hallo Norbert, ich suche den Fehler bestimmt schon eine Woche. Die Vererbung wurde nicht unterbrochen. Zumindest sehe ich es nicht. Die Default-Domain-Policy ist bei uns auf der Domäne angewendet. Es existiert auf der Domäne auch keine weitere Policy mit einer höheren Priorität. Wenn ich mir mit gpresult /H den generierten Report anzeigen lasse, ist dort die Kennwortrichtlinie aus der Default-Domain-Policy aufgeführt. Es gibt in diesem Report keine weiteren Treffer was die Kennwortrichtlinie betrifft. Ich bin echt ratlos. Beim Aufruf von net accounts /domain wird folgendes angezeigt: Die Anforderung wird auf einem Domänencontroller für Domäne dohle.com verarbeitet. Abmelden erzwingen nach: Nie Minimales Kennwortalter (Tage): 0 Maximales Kennwortalter (Tage): 42 Minimale Kennwortlänge: 5 Länge der Kennwortchronik: 1 Sperrschwelle: Nie Sperrdauer (Minuten): 30 Sperrüberprüfungsfenster (Minuten): 30 Rolle des Computers: SICHERUNG Keine Ahnung wo das her kommt. Gruß Klaus

Hallo Norbert, die Kennwortrichtlinie in der Default-Domain-Policy zieht definitiv nicht, weil weder die Kennwortkompläxität, Länge noch Haltbarkeit stimmen. Die Benutzer werden nach wie vor nach 42 Tagen aufgefordert ihr Passwort zu ändern. Mit "net user xxxx /domain" auf der Shell für meinen Benutzer wird folgendes ausgegeben: Letztes Setzen des Kennworts 11.12.2013 13:24:21 Kennwort läuft ab 22.01.2014 13:24:21 Kennwort änderbar 11.12.2013 13:24:21 Kennwort erforderlich Ja Benutzer kann Kennwort ändern Ja Dies entspricht genau dessen, was im lokalen gpedit.msc angezeigt wird. Bestimmt findet man die Einstellungen der Default-Domän-Policy irgendwo in der lokalen Registry. Weiß Du wo ich da nachsehen kann? Hab noch ein Screenshot von gpresult /H beigefügt. Da sieht alles gut aus. Gruß Klaus

Hallo Forum, obwohl wir in der Default-Domain Policy eine Kennwortrichtline (s. Domain-Policy.png) festgelegt haben, greift diese einfach nicht. Bei einem Aufruf von gpresult auf einem beliebigen Client wird aber angezeigt, dass die Default Domain Policy geladen wurde. Ich hatte auch schon den Verdacht, dass die Policy von einer Anderen überschrieben wird, habe allerdings nichts finden können. Beim Domain-Admin zieht nur die Default-Policy. Wenn ich mich am Domain-Controller als Administrator anmelde und dann den lokalen gpedit.msc aufrufe, sehe ich nicht die eingestellte Kennwortrichtlinie. (s. Lokale-Einstellung.png) Hat einer noch eine Idee an was das liegen könnte? Die Kennwortrichtline, die momentan eingestellt ist, stammt noch aus Zeiten wo unsere Domäne auf NT4 lief. Mittlerweile ist sie allerdings auf 2008. Gruß Klaus

Hallo Forum, ich habe hier folgendes Szenario: Ein AD-Forest mit 4 Domänen, wobei 2 Domänen Subdomains sind. Also: bsp1.de (Domäne BSP) bsp2.com (Domäne BSP2) aaa.bsp2.com (Domäne BSP2-A) bbb.bsp2.com (Domäne BSP2-B) Alle Domänen verfügen über Windows 2003 Domänencontroller und laufen in Windows 2000 einheitlich. Nun sollen die Domänencontroller der Domain BSP auf Windows 2008 migriert werden. Kann der Modus der Domänen weiterhin Windows 2000 einheitlich bleiben? Ist eine Migration auf Windows 2008 Domänencontroller ohne Probleme möglich? Ist eine spätere Heraufstufung der Domänenfunktion der Domäne BSP auf 2008 möglich ohne etwas in den anderen Domänen zu ändern (d.h diese sollen weiter Windows 2000 einheitlich bleiben). Wie gesagt es handelt sich hierbei um nur einen Forest. Fragen über Fragen. Hoffentlich kann mich jemand erleuchten. Danke für Hilfe. Gruß Klaus

Danke dafür, dass wir mein Problem hier so ausführlich behandelt haben. Als Resultat habe ich für mich dabei herausgezogen, dass ich Outlook per GPO auf ein festes Encoding Western ISO umstellen werde. Hab mir noch nie selber ne GPO gebaut, aber ich denke das sollte ich hinbekommen. Wir werden dieses Jahr von auf Windows 7, Office 2010 und Exchange 2010 wechseln. Tja aber leider ist es so, dass wenn Du Outlook auf UTF-8 einstellst und der HUB-Transport Server (läuft auf einem Windows 2003 R2) die Signatur anhängt, stimmt das Encoding auch wieder nicht, weil die Signatur in ISO-8859-1 vom HUB-Transport Server angehangen wird. Vermutlich ist es auf eine Windows 2008 Server anders. Da wird in utf-8 codiert. Danke nochmal für die konstruktive Disskusion.

Wir haben noch Outlook 2002. (Wir müssen sparen). Da gehts mit einer Änderung in der Registry. In den GPOs finde ich nichts passendes. Lasse mich aber gerne belehren. Ich will mich auch nicht mit euch Experten streiten :p . Das ist nicht mein Anliegen. Aber je weniger Daten über das Internet versendet werden, desto schneller ist es und das meine ich in Summe. Nicht nur lokal auf unseren Exchange begrenzt. Ist mir klar das das Encoding lokal vernachlässigt werden kann. Ist für mich einfach nur eine schlechte Einstellung: ****** auf die Datenmenge. Machen doch alle so. Die default-Einstellung von Outlook 2002 ist, das Encoding selber zu bestimmen. Halte ich für sehr sinnvoll. Nun hängt der HUB-Transport Server eine Signatur mit Umlauten an und überprüft nicht das Encoding?! Ist doch auch ein Prdukt von MS.

Mit ner GPO gehts nicht. 7 KB hier und 7kb da. Das läppert sich. Ich will ja jetzt nicht als der Messias des Internets auftreten, aber ich glaube wenn jeder seine Mails in utf-8 über das Internet verschicken würde, wäre das Datenaufkommen, dass über die Leitungen geht um ein vielfaches höher. Weiß nicht ob das im Sinne der Erfinder des Internets ist. Aber bei uns gibt es auch jede Menge Nutzer die denken warum kann ich nicht 500 MB als E-Mail verschicken. :wink2:

Wo steht das? Ich denke eher, dass es laut Gesetzgeber zur Pflicht geworden ist: Signatur (E-Mails im Geschäftsverkehr)

Weil es über 300 Clients sind und weil ich denke der Exchange sollte so clever sein das selber festzustellen. Outlook ist bei uns so eingestellt, das Encoding selbständig festzustellen. Und wenn eben eine Mail versendet wird, die keine Umlute enthält, wird das Encoding auf us-ascii eingestellt. Ist ja auch sinnvoll. Warum sollte man einen Text in UTF-8 oder ISO-8859-1 codieren, wenn es nicht nötig ist. Die Codierung eines solchen Textes erhöht in einem solchen Fall nur die Datenmenge.

Hallo Forum, folgendes Problem: Wir hängen mit einer Transportregel eine Verzichtserklärung (Disclaimer) an unsere Mails. Der Text der Verzichtserklärung enthält Umlaute. Wenn jetzt mit Outlook eine Mail im Textformat versendet wird und in dieser Mail sind keine Umlaute enthalten, stellt Outlook (weil so konfiguriert) das Encoding der Mail auf us-ascii ein. Wenn jetzt der Disclaimer von Exchange angehangen wird, ändert sich das Encoding leider nicht !!! Dies hat zur Folge, dass die Umlaute beim Empfänger der Mail nicht korrekt angezeigt werden. Ist dies ein Bug im Exchange ? (Exchange 2007 SP1 Updaterollup 9) Ich möchte ungern Outlook auf ein festes Encoding (Western ISO) umstellen. Danke für Antworten. Gruß Klaus

Wie peinlich. Habe das Postfach nun finden können. Das ist das Postfach einer weiteren Domäne die bei uns in der Organisation liegt. Ich habe das Postfach nun auf den ExchangeServer dieser Domäne verschieben können. Danke für eure Hilfe

Ich kann nur annehmen, dass es sich bei dem noch zu löschenden Postfach um dieses Admin Postfach handelt. Mit dem VBS Script AD-SQL-Suche MSEX-Homesrv.vbs wurden mir für unseren Exchange 2000 noch zwei Postfacher angezeigt. Diese lauteten SystemMailbox... Diese habe ich jetzt auch gelöscht und mit dem Cleanup-Agent entfernt. Die Deeinstallation funktioniert aber trotzdem nicht. Jetzt gibt es nur noch in jedem Postfachspeicher ein SMTP Postfach. Es existiert weiterhin noch ein Systemaufsicht Postfach und dieses besagte Administrator Postfach, welches ich aber im AD nicht finden kann. Die manuelle Entfernung von Exchange 2000 würde ich nur ungern durchführen. Am liebsten wäre es mir über Systemseterung -> Software.

Okay, wie ich gerade gelesen habe, wird es nicht ausreichen den Postfachspeicher einfach zu löschen, da das Setupprogramm nach Einträgen im Active Directory sucht. Da ich das alte Admin-Postfach über Outlook ja noch finde, frage ich mich, wo ich diesen Eintrag im Active Directory finde damit ich den Löschen kann. Beim Hinzufügen eines Exchangepostfachs wird folgendes angezeigt: E-Mail: /o=ORGANISATION/ou=Erste administrative Gruppe/cn=Recipients/cn=Administrator15138324 Das muss weg denke ich. Mit adsiedit.msc und ldp.exe finde ich nichts, außer der Systemaufsicht, was noch auf dem Exchange 2000 liegt ???

Vielen Dank für den Hinweis. Diesen Artikel habe ich auch bereits gelesen. Leider hat der nicht weitergeholfen :-( Wie gesagt, wenn ich das AD nach Postfächern durchsuche die auf dem Exchange 2000 liegen, wird nur die Systemaufsicht gefunden. Das Adminpostfach, welches sich verwenden läßt und welches mit dem Administrator Benutzer verbunden ist liegt bereits auf dem Exchange 2007. Gibt es eventuell eine Möglichkeit, einen Postfachspeicher gewaltsam zu löschen?

Hallo, nachdem wir Exchange 2007 installiert haben, möchten wir nun unseren alten Exchange 2000 deinstallieren. Alle Postfächer und öffentlichen Ordener haben wir verschoben. Alle Routinggruppenconnectoren wurden entfernt. Der RUS Dienst wurde gelöscht und der OAB Prozess auf Exchange 2007 verschoben. Beim Deinstallieren von Exchange 2000 wird nun allerdings behauptet, dass noch Postfächer auf dem Exchange 2000 vorhanden sind. Und tatsächlich, da liegt noch das Administrator Postfach. Wir haben demzufolge zwei Adminpostfächer, eins auf dem Ex2007 und eins auf dem Ex2000 (s. Bilder). Wenn ich unsere AD nach Postfächern auf dem Ex2000 durchsuche, finde ich nur Systemaufsicht. Auch der Postfachspeicher auf dem Ex2000 wo das Admin-Postfach noch liegt läßt sich nicht löschen. Meine Frage ist nun, wie bekomme ich das Admin Postfach auf dem Exchange 2000 weg. Den Cleanup Agent habe ich beriets auch laufen lassen. Mit Eseutil habe ich auch schon den Postfachspeicher untersucht. Keine Fehler. Hat einer eine Idee? Danke für Antowrten

Hallo Forum, gibt es eine einfache Methode dem Domänen-Admin oder einem anderen Benutzer für alle Postfächer auf einem Echange 2007 das Recht "Senden als" und "Empfangen als" global zu vergeben? Hintergurnd: Ich muss für eine MailArchiv Lösung alle vorhandenen E-Mails der Benutzer exportieren und dafür brauche ich diese Rechte. Jedesmal die Rechte manuell in der Verwaltungskonsole zu vergeben ist sehr mühselig. Danke für Hilfe und Infos. Gruß Klaus

Hi, da die Replikation der ÖO auch nichts weiter ist als Mails zu senden, vermute ich, dass Dein Problem da liegt da Deine Benutzer auch auch nicht wircklich mailen können. Ist bei der Installation der RoutinggruppenConnector zwschen dem Ex2003 und dem Ex2007 angelegt worden? Zur Not lösche den nochmal im ESM vom Exchange 2003 und lege Ihn neu an. Dabei darauf auchten, das er auch in der neuen Exchange 2007 Struktur angelegt wird. Funktioniert das interne Mailing im Exchange 2007 denn venünftig. D.h. können Deine Benutzer nur nicht ins Internet mailen? Gruß Klaus