Jump to content

zeus-cu

Members
  • Gesamte Inhalte

    39
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von zeus-cu

Enthusiast

Enthusiast (6/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. zeus-cu

    Desaster Recovery

    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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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?
  7. okay... Und wie mach ich das mit der Richtlinie für lokale Konten?
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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.
  14. 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.
  15. 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:
×
×
  • Neu erstellen...