NilsK

Moin, das musst du auch nicht mit uns diskutieren, sondern mit jemandem, der das rechtlich beurteilen kann. Der Hinweis besagt nur, dass so ein Konstrukt Merkmale hat, die die Anwendbarkeit einschränken können. Gruß, Nils

Moin, schau dir die oben verlinkte Definition an. Die Mailbox ist 230 MB groß, und es gibt wiederherstellbare Elemente (das sind nicht die im Papierkorb, sondern die im Dumpster) im Umfang von 4 MB (nicht 4 GB, der Punkt steht im Amerikanischen für unser Komma). Gruß, Nils

Moin, da wäre zu klären, was du mit "GESAMT-Größe" meinst und warum du glaubst, dass TotalItemSize nicht korrekt sei. https://msdn.microsoft.com/en-us/library/gg576861(v=exchsrvcs.149).aspx#ExplanationOfValues Gruß, Nils

Moin, um alle ein- und ausgehenden Mails zu archivieren, brauchst du kein Mailbox- und kein In-Situ-Archiv, sondern eins, das sich an die Journaling-Schnittstelle anbindet. Soweit ich weiß, kann die dafür nötige Journaling-Mailbox selbst nicht in Office 365 liegen, sondern sie muss lokal sein, damit eine separate Archivlösung sie ausleeren kann. Gruß, Nils

Moin, dann könntest du mit einem Hilfsmittel wie z.B. LIZA mal vergleichen, wie die Berechtigungen neu erzeugter Objekte denn tatsächlich sind. Wer weiß, ob die "umsortierten" Strings nicht vielleich ungültig sind und das AD dann was anderes macht, als nominell dort steht ... http://ldapexplorer.com/en/liza.htm Gruß, Nils

Moin, um "revisionssicher" zu archivieren, musst du für deinen Fall (also dein Unternehmen, die Branche ...) erst mal definieren, was bei einer Revision denn für Kriterien gelten. "Revisionssicher" ist kein Kriterium an sich. Die Exchange-Archivierung ist zunächst eine Verdrängung, also Verlagerung von Daten in eine separate Mailbox, um die primäre Mailbox zu entlasten. Dazu dienen dann auch die Tags. Das In-Situ-Archiv hingegen verhindert im Wesentlichen, dass der Anwender Mails löscht. Das bezieht sich aber immer nur auf die einzelne Mailbox (aber nicht etwa auf "alle ein- und ausgehenden möglicherweise geschäftsrelevanten Mails") und gilt ab dem Zeitpunkt, zu dem die Funktion aktiviert wurde. Ob das für die Anforderungen reicht, lässt sich von außen nicht beurteilen. Gruß, Nils

Moin, äh - wie suchst du denn? :confused: Ich finde z.B. auf Anhieb dies hier: https://itconnect.uw.edu/wares/msinf/other-help/understanding-sddl-syntax/ Gruß, Nils

Moin, Mandatory Profiles will man nicht. Das ist Technik aus NT4-Zeiten und war damals schon schlimm. Quasi eine Garantie für Datenverluste. Gruß, Nils PS. abgesehen davon, war der Thread seit über fünf Monaten inaktiv.

Moin, also, ich finde haufenweise zu "Windows SDDL" ... wo genau ist das Problem? Gruß, Nils PS. wir sind uns hoffentlich einig, dass alle Manipulationen in einer isolierten Lab-Umgebung stattfinden ...?

Moin, du wirfst ein paar Dinge durcheinander. Noch zu 1: Nur die DefDomPol. [besonderheiten der AD-Kennwortrichtlinie | faq-o-matic.net] https://www.faq-o-matic.net/2010/06/24/besonderheiten-der-ad-kennwortrichtlinie/ Zu 2: "Kennwort läuft nie ab" betrifft nur den erzwungenen Kennwortwechsel. Wenn der User aus eigenem Antrieb das Kennwort wechselt, muss dieses natürlich den Regeln (Länge, Komplexität) genügen. Zu 3 und zu deiner Nachfrage: Die Kennwortrichtlinie gilt für alle Rechner der Domäne, dort dann für die lokalen Konten. SIe hat aber nichts damit zu tun, dass ein Kennwort geändert wird oder nicht. Du könntest lokale Konten ebenso mit "läuft nie ab" kennzeichnen, um den automatischen Ablauf zu vermeiden (vielleicht ist es auch das, was du meintest). Wenn du innerhalb einer Domäne für verschiedene User unterschiedliche Policies brauchst, kannst du das mit Fine Grained Password Policies erledigen, zu dem Begriff findest du im Web einiges. Gruß, Nils

Moin, ich dachte, du schreibst jetzt, dass das da ja schon steht. :D Gruß, Nils PS. danke!

Moin, um es noch mal im Zusammenhang darzustellen: Der DC mit der Rolle PDCe ist der Haupt-Zeitgeber für die Domäne. Dieser muss mit einer externen Zeitquelle synchronisiert werden. Alle anderen DCs der Domäne bekommen ihre Zeit von dem PDCe. Sie sind also anders konfiguriert als der PDCe, und zwar nach der Standard-Domänenhierarchie (NT5DS). Alle Clients (also Server, die nicht DC sind, und Client-PCs) bekommen ihre Zeit von "einem beliebigen" DC. Bei diesen Rechnern möchte man ja die Redundanz nutzen. Auch diese sind nach NT5DS konfiguriert. Genau diese Konfiguration stellt Windows selbst her, wenn man nicht eingreift. Da in vielen Umgebungen aber eben doch eingegriffen wird, beschreibt Norberts Artikel vollständig, wie man diese empfohlene Konfiguration per GPO wieder einrichtet und ab da sicherstellt. Dazu gibt es eben die beiden GPOs: Ein GPO, das nur (!) den PDCe konfiguriert. Durch den WMI-Filter ist es "ewig flexibel", weil es den PDCe auch nach einem Rollenwechsel findet. Ein GPO, das alle (!) anderen Rechner konfiguriert. Dass also die Rechner verschiedene DCs als Zeitquelle anzeigen, ist nicht nur normal, sondern auch erwünscht. Gruß, Nils

Moin, ja, sobald man an den AD-Berechtigungen herumspielt, bewegt man sich schnell im nicht-supporteten Bereich. Daher sollte man auch nie die Standardberechtigungen ändern und alle Änderungen nur selektiv auf eigene Objektcontainer vergeben. Solange die Berechtigungsvorlage im Schema nicht manipuliert wurden, kann man alle Objekte oder Container mit dsacls.exe wieder auf die Vorgabe zurücksetzen, es gibt dort einen eigenen Schalter dazu. Die Standardberechtigung ist für jede Objektklasse (Schema-Object vom Typ classSchema) im Attribut defaultSecurityDescriptor gespeichert. Ein Vergleich dieser Attributwerte von dem Kunden-AD mit einem frisch aufgesetzten Referenz-AD sollte schnell Klarheit geben, ob da was manipuliert wurde. Für alle Reparaturen oder Änderungen empfehle ich dringend, jemanden hinzuzuziehen, der mit solchen Sachen Erfahrungen hat. Wie gesagt - man ist dort schnell in einem Bereich, den Microsoft nicht mehr supportet. Gruß, Nils

Moin, du meinst die Zugriffsberechtigungen auf das AD-Objekt? Die sind in der AD-Konfiguration bzw. im Schema vorgegeben. https://technet.microsoft.com/en-us/library/cc961748.aspx Was genau hast du denn vor? Gruß, Nils

Moin, warum? Gruß, Nils

Moin, die Anleitung von gruppenrichtlinien.de erfordert kein manuelles Eingreifen. Wenn sie richtig umgesetzt ist, aber es nicht funktioniert, ist was anderes im Busch. Du bist dir sicher, dass du alles richtig umgesetzt hast? Es sind zwei GPOs an den passenden Stellen zu definieren. Gruß, Nils

Moin, Was sagt denn netdom /query fsmo ? Gruß, Nils

Moin, Lies noch Mal die Frage. Gruß, Nils

Moin, So in etwa. Gruß, Nils

Moin, ich könnte mir gut vorstellen, dass der ODBC-Treiber von Access 2003 (!) auf WIndows 2012 R2 einfach nicht mehr richtig unterstützt wird. Vermutlich wäre es an der Zeit, auf ein ordentliches Datenbank-Backend umzusteigen. Ohne zusätzliche Lizenzkosten könnte das etwa ein SQL Server Express sein. Gruß, Nils

Moin, wie immer, sollte man für das Restore komplexer Applikationen verstehen, wie diese funktionieren und wie die sinnvollen Verfahrensweisen für verschiedene Szenarien aussehen. Jan hat völlig Recht, dass du für ein Forest Recovery "aus dem Nichts" typischerweise nur eine Instanz des AD aus dem Backup wiederherstellst. Weitere DCs kommen dann nicht aus dem Backup, sondern werden neu installiert, sobald das AD als solches wieder funktioniert. Das gilt um so mehr, wenn man Image-basierte Verfahren für das Backup einsetzt. Dass Veeam sagt, ein DC-Backup sei problemlos möglich, ist aus deren Sicht völlig korrekt. Damit sagen sie aber noch lange nicht, dass man damit dann jedes beliebige Restore-Verfahren umsetzen kann. Das AD ist nun mal eine Ecke komplexer als ein Dateiserver. Ähnliches wirst du auch feststellen, wenn es um Exchange oder SQL Server geht. Da das Restore die Kunst ist und nicht das Backup, solltest du dir, wie du nun merkst, genaue Verfahrensweisen aufbauen. Gruß, Nils

Moin, Äh - auch in kleinen Umgebungen installiert man natürlich nichts direkt auf dem Host. Das ist für Hyper-V nicht anders als für vSphere. Dass es in vSphere gar nicht erst geht, macht dabei keinen Unterschied. Gruß, Nils PS. Eigentlich ging es hier gar nicht um einen Vergleich von Hyper-V und vSphere. Bleiben wir doch besser beim Thema.

Moin, hm, ja, du könntest Recht haben. Der zugreifende Client wäre in dem Fall ja der Webserver. Da hatte ich eins zu viel um die Ecke gedacht. Gruß, Nils

Moin, dieses Vorurteil wird durch häufige Wiederholung auch nicht richtiger. :D Gruß, Nils

Moin, das dürfte daran liegen, dass DFS im Wesentlichen eine SMB-Umleitung für den Client ist. Sobald der Client ein Verzeichnis des DFS-N-Servers ausgewählt hat, bekommt er von diesem den SMB-Link (also den UNC-Pfad) und baut dorthin dann eine direkte SMB-Verbindung auf. Anders als viele vermuten, erzeugt DFS keine eigene Ordnerstruktur und stellt selbst keine Daten bereit. Die Verbindung zm tatsächlichen Speicherort ist Sache des Clients. Daher wird das (ziemlich sicher) nicht direkt per WebDAV gehen. Vielleicht gibt es spezielle WebDAV-Clients, die das DFS-Clientverhalten nachbilden, aber der bordeigene tut es nicht. Gruß, Nils