NilsK

Moin, vielleicht gab es einfach in den letzten 24 Stunden keine Warnungen oder Fehler? Ist ja nun nicht ganz unüblich. Gruß, Nils

Moin, da es sich bei der Gruppe um eine lokale Gruppe der DCs handelt ("Builtin"), musst du den DC neu starten, damit der Effekt wirksam wird. In einer Umgebung mit mehreren DCs musst du alle neu starten. Zum Testen dann nicht das vordefinierte Administrator-Konto als Zielobjekt nehmen, das hat nämlich spezielle Berechtigungen. Gruß, Nils

Moin, daher habe ich ja auch empfohlen, mit vmconnect.exe auf die VMs zuzugreifen. Das Programm verbindet sich auf den Host und von da über die Integrationsdienste auf die VM. Gruß, Nils

Moin, Full Backup und Log-Backup sind prinzipiell unabhängig voneinander. Sobald man eine DB mit Full Recovery Model hat, muss man beides einrichten. Die einzige direkte Abhängigkeit: Damit das Log-Backup überhaupt geht, muss es mindestens ein Full Backup gegeben haben. http://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/ Gruß, Nils

Moin, generell sollte man den Aufbau von Multi-Domänen-Strukturen vermeiden. Die Nachteile solcher Aufbauten sind fast immer größer als der Nutzen. [Welches Domänenmodell ist das Beste für Active Directory? | faq-o-matic.net] http://www.faq-o-matic.net/2007/06/09/welches-domaenenmodell-ist-das-beste-fuer-active-directory/ Um einen Multi-Domänen-Forest aus der bestehenden Umgebung zu bauen, müsstest du alle Außenstellen-Domänen auflösen und als Subdomains neu installieren. Riesiger Aufwand, wenig Nutzen. Eine Absicherung gegenüber einer Einzeldomäne hättest du damit auch nicht, denn die Sicherheitsgrenze ist der Forest, nicht die Domäne. Über diese allgemeine Anmerkung hinaus solltest du dir aber einen kundigen Berater suchen und die Entscheider des Unternehmens dazuholen. So ein Design macht man nicht "mal eben". Gruß, Nils

Moin, hier ist die Gruppe "Prä-Windows 2000-kompatibler Zugriff" beschrieben: [Active Directory information exposed to users?] http://www.windowsecurity.com/articles-tutorials/misc_network_security/Active-Directory-information-exposed-users.html Diese Gruppe hat u.a. vollen Lesezugriff auf user-Objekte. In den meisten Umgebungen sind die "Authenticated Users" Mitglied in der Gruppe, wodurch effektiv jeder auch userAccountControl lesen kann. Für höhere Sicherheit wird empfohlen, die Gruppe zu leeren - dann können eben nicht mehr alle User das Attribut lesen. Das würde das in diesem Thread diskutierte Verhalten erklären. Gruß, Nils

Moin, also, ganz ehrlich, bevor ich auf einem produktiven System Mirroring oder Log Shipping einrichten würde (mit allem, was dranhängt), würde sogar ich eine "Nachtschicht" einlegen. Deinstallation und Neuinstallation von SQL Server dauert so lange ja nun auch nicht. Komplexe Techniken wie die genannten sollte man nicht "mal eben" ins Spiel bringen. Gruß, Nils

Moin, anscheinend läuft Logparser beim Zusammenstellen des Reports auf einen Fehler, das sagt ja deine Ausgabe. Erweitere doch mal bitte in der CreateErrorReport.bat den Logparser-Aufruf um "-e:1", dann sollten auf der Kommandozeile Details zu den Fehlern auftauchen. Den "sleep"-Aufruf kannst du ersetzen durch ping -n 5 127.0.0.1 > nul (die Zahl hinter -n ist die Zahl der zu wartenden Sekunden) Gruß, Nils

Moin, die Probleme, von denen du berichtest, entstehen aus einem unpassenden Design. Das wirst du nicht lösen mit einem Design, das sehr wahrscheinlich auch nicht passt. Und Multi-Domain passt eigentlich so gut wie nie. Offenkundig ist das "richtige" Design in der Umgebung auch nicht "mal eben" zu entwerfen. Hier wäre es also sinnvoll, sich mal in Ruhe mit jemandem zusammenzusetzen, der sich mit AD-Designs auskennt, und dann die Entscheider des Unternehmens hinzuzuholen. Sonst wird man Technik und organisatorische Anforderungen erfahrungsgemäß nicht in Abstimmung bringen können. Gruß, Nils

Upps, OK, das war mir nicht bekannt. Wobei dort leider kein Grund dabei steht - und ich weiß keinen (siehe oben). Möglicherweise hat Microsoft dort einfach eine harte Prüfung eingebaut, um mögliche Sicherheitsprobleme zu vermeiden, die aus bestimmten Zusatzfunktionen entstehen könnten. Die Windows-Benutzerverwaltung für SQL-Logins könnte auch ein Grund sein, denn auf DCs gibt es ja keine lokalen Konten. Gruß, Nils

Moin, die Datenbanken vorab zu sichern, ist auf jeden Fall eine gute Idee. Ansonsten sehe ich aber nicht, warum SQL Server in so einem Fall ein Problem haben sollte. Da der Server ja Mitglied der Domäne bleibt, werden sowohl das Dienstkonto als auch die Berechtigungen hinterher weiter funktionieren. Sollte der SQL-Dienst wider Erwarten nicht neu starten, so dürfte es ausreichen, das Dienstkonto neu zu definieren. Etwas mehr Aufwand könnten höchstens Funktionen die DBMail (oder wie das heißt) machen, wenn man das Dienstkonto ändert. Aber auch das wäre reparierbar. Eine Neuinstallation von SQL Server dürfte unnötig sein. Es gibt dort keine Abhängigkeiten zum AD in der Art, wie man sie von Exchange kennt. Gruß, Nils

Moin, lies mal den verlinkten Artikel. Nur aus solchen optischen (und evtl. logischen) Gründen mehrere Domains zu bauen, ist Overkill. Du bist u.U. gerade dabei, einen großen Designfehler zu machen. Gruß, Nils

Moin, ja, natürlich braucht jede Domäne eigene Domänencontroller, und zwar redundant. Normalerweise vermeidet man es, in solchen Fällen Multi-Domain-Forests zu bauen. Was ist bei dir der Grund dafür? [Welches Domänenmodell ist das Beste für Active Directory? | faq-o-matic.net] http://www.faq-o-matic.net/2007/06/09/welches-domaenenmodell-ist-das-beste-fuer-active-directory/ Gruß, Nils

Moin, die drei Fehler im unteren Output entstehen wahrscheinlich, weil es die Protokolle "Diorectory Service", "File Replication Service" und "DNS Server" auf dem System nicht gibt. Die ersten beiden Protokolle ("System" und "Application") liest Logparser ja offenbar korrekt aus. Kommentiere also in der eventcollector.bat die letzten drei Aufrufe mal aus (REM davorschrieben) und schau noch mal. Was passiert nun? Gruß, Nils

Moin, Schema-Admin brauchst du auf keinen Fall dafür. Und Enterprise-Admin hat hier auch nur eine Änderung des Verhaltens ergeben, weil die auch Domänen-Admins sind. Wäre noch die Frage nach dem Grund. Ist bei euch die "Prä-Windows 2000"-Gruppe leer? Ich halte das eher für unwahrscheinlich. Ich tippe auf die Prä-Windows-2000-Gruppe. Gruß, Nils

Moin, das steuert ja auch nur die Anzeige im Attribut-Editor (bzw. in ADSI Edit, wo der Editor herkommt). Das ist keine Funktion, sondern ein Anzeigefilter (der sich auf die Schema-Definition der Attribute bezieht: sind sie "verbindlich", müssen also beim Objekt vorhanden sein, oder sind sie "optional", können also leer bleiben). Gruß, Nils

Moin, eieiei. Man wird alt. Gruß, Nils

Moin, gut, das ist schon mal konsistent. Ich kann mir nicht recht erklären, warum die PowerShell und die anderen Tools das nicht ausgeben. Sind in eurem AD evtl. die Zugriffsberechtigungen angepasst? Normalerweise sind die genannten Attribute ganz normal für Authentifizierte Benutzer lesbar, wenn ich nicht irre. Vielleicht liegt es aber auch an "Prä-Windows 2000-kompatibler Zugriff", das kann ich gerade nicht nachverfolgen. Wer ist denn in deinem AD in dieser Gruppe Mitglied? Gruß, Nils

Moin, wow, nein, das kannte ich bislang nicht. Seit wann gibt es das? Gruß, Nils

Moin, das ist ja spannend. Kannst du bei den Usern, wo die Ausgabe fehlt, per ADSI Edit auf das Attribut userAccountControl zugreifen? Wenn ja, was steht da drin? Gruß, Nils

Moin, es gibt kein Attribut "enabled" und auch kein Attribut "password never expires". Diese Eigenschaften sind in dem Attribut userAccountControl binär kodiert. Die PowerShell nutzt Pseudo-Attribute, um den Umgang damit zu erleichtern. Mein Doku-Tool José wertet diese Eigenschaften aus, einige andere tun das auch. http://www.faq-o-matic.net/jose/ Gruß, Nils

Moin, was sagt denn whoami /groups in einem CMD-Fenster? Am besten umleiten, dann liest sich das Ergebnis leichter: whoami /groups > %userprofile%\MeineGruppen.txt Gruß, Nils

Moin, auch wenn die dynamischen VHDX-Dateien kaum noch Performance-Nachteile haben mögen, es bleibt das Problem der Überprovisionierung. Ohne gutes Monitoring auf Storage- bzw. Host-Ebene sollte man das nie einsetzen. Außerdem bleibt natürlich das Problem der Fragmentierung, wodurch dann durchaus wieder Performance-Auswirkungen entstehen können, wenn das Host-System stark belastet ist. Gruß, Nils

Moin, das nächste Mal wäre es vielleicht besser, wenn du gleich vollständig angibst, was du erreichen willst. Dein Skript hat ja eine ganz andere Logik als nur das Kommando, das du angefragt hast. Gruß, Nils

Moin, Dukels Hinweis ist völlig richtig. Abgesehen davon, ist für so häufige Sicherungen das Transaktionsprotokoll-Backup meist der bessere Weg, weil er viel weniger Performance braucht. Das Restore ist dabei dann aber etwas aufwändiger. Holt euch - abgesehen von der Rücksprache mit dem CRM-Hersteller - am besten einen kundigen Berater ins Haus, mit dem ihr eure Anforderungen und die möglichen Wege dazu diskutieren könnt. Gruß, Nils