NilsK

Moin,

du verstehst da ziemlich vieles nicht. Das ist auch nicht weiter schlimm, nur solltest du entweder dich einarbeiten und das System so betreiben, wie es zu betreiben ist, oder zu einer anderen Plattform greifen.

Und ja, für den Zugriff auf einen Windows-Server benötigt man Clientlizenzen. Egal, ob das privat ist oder nicht. Wenn das nicht in euer Konzept passt, greift zu einer anderen Plattform. PHP läuft ja auch hervorragend auf Linux-Systemen ...

Gruß, Nils

Moin,

das klingt ganz so, als würde Windows den Abmeldeprozess nicht korrekt beenden. Schau mal ins Eventlog, ob das was hergibt.

Ändert sich der Zustand, wenn du nach dem Abmelden sehr lange wartest?

Gruß, Nils

Moin,

das ist ein Übersetzungsproblem. Beim "Übertragen" (= "transfer") stimmen sich alter und neuer Rolleninhaber ab. Beide können weiterarbeiten, weil sie sich einig sind. Beim "Übernehmen" (= "seize") stimmen sie sich nicht ab, der neue Inhaber übernimmt die Rolle einfach und kümmert sich nicht mehr um den alten. Der alte darf dann nie wieder in der Domäne aktiv werden. Gedacht ist das ausschließlich für Situationen, in denen der "alte" Rolleninhaber dauerhaft ausgefallen ist (z.B. irreparabler Hardwaredefekt).

Käme der alte Inhaber nach einem "Seize" wieder, könnten kritische Situationen entstehen (z.B. doppelte Vergabe von SIDs).

Gruß, Nils

Moin,

hust, hust - ihr glaubt ernsthaft, dass ihr mit so einem Verfahren ein sinnvolles Recovery hinbekommt?!

Was für Dienste laufen denn überhaupt in den VMs?

Gruß, Nils

Moin,

du brauchst nicht eine Karte pro VM, sondern eine pro Netzwerk.

Gruß, Nils

Moin,

nein, kann man nicht einstellen. Das ist aber auch keine Sache einer AD-Dokumentation, daher werde ich das nicht einbauen.

Gruß, Nils

Moin,

das habe ich verstanden, aber das meine ich nicht mit "Anforderung".

Welches Ziel steht dahinter? Technisch ist es schlicht nicht möglich, was du anfragst. Es gibt ja aber einen Grund für die Idee, und den kann man vielleicht anders lösen.

Gruß, Nils

Moin,

gern, danke für die Rückmeldung!

Gruß, Nils

Moin,

wenn du als Administrator angemeldet bist, wirst du immer auf die Datenbank zugreifen können, zumindest wirst du dir immer die Möglichkeit dazu verschaffen können. Ein Admin ist ein Admin ist ein Admin.

Was ist die genaue Anforderung?

Gruß, Nils

Moin,

gern, danke für die Rückmeldung!

Gruß, Nils

Moin

das Vorgehen ist so nicht sinnvoll.

Mehrere Netzwerkkarten führen nicht zu einem Failover. Auch mehrere Netzwerkkarten im selben IP-Segment führen zu Problemen. Zudem wird es nicht empfohlen, auf einem DC mehrere Netzwerkkarten zu betreiben.

Wenn übrhaupt, kannst du ein Failover erreichen, indem du ein Team über die Netzwerkkarten aufspannst. Dazu benötigst du spezielle Treiber vom Hersteller. Bei einem DC aber nicht empfohlen.

In einem Netzwerk mit mehr als ca. 10-20 Usern ist ein zweiter DC sehr empfehlenswert.

Gruß, Nils

Moin,

wenn du jetzt statt der rudimentären Stichwörter noch angibst, was du denn eigentlich erreichen möchtest und was für ein Werkzeug du dafür benötigst, kann man dir evtl. auch Tipps geben.

Gruß, Nils

Moin,

welche Berechtigungen sind auf der NTFS-Ebene gesetzt?

Gruß, Nils

Moin,

nein, das siehst du nicht richtig. InvokeSet gibt ja jetzt selbst einen Fehler zurück. Vermutlich kann es mit dem Datumsobjekt nichts anfangen.

Gruß, Nils

Moin,

ja, deine Annahmen sind falsch.

Bis einschließlich Exchange 2007 gibt es einen "Single Instance Store", d.h. wenn 20 User in derselben Datenbank z.B. dasselbe 20-MB-PPT erhalten, speichert Exchange es nur einmal. Löschst du von diesen 20 nun 10 Postfächer, dann gibt es immer noch 10 Links auf das PPT. Exchange kann es also nicht löschen, und die DB bleibt gleich groß.

Abgesehen davon: Selbst wenn die Inhalte aus der Datenbank verschwinden, verkleinert Exchange die Datei nicht. Es ist dann eben "Whitespace" innerhalb der Datei, den Exchange bei Bedarf wieder befüllt. Um die Datei physisch zu verkleinern, wäre eine Offline-Defrag nötig - aber das bedeutet 1. Downtime und 2. durchaus ein gewisses Risiko.

Gruß, Nils

Moin,

erstens ist Norbert zuzustimmen, zweitens kostet das Anfordern von Hotfixes kein Geld, um es deutlich zu sagen.

Gruß, Nils

Moin,

dann frage den Global Catalog ab.

Gruß, Nils

Moin,

wenn ich es spontan richtig sehe, solltest du InvokeSet auf dem Objekt $User aufrufen, nicht auf $ds, oder?

Gruß, Nils

Moin,

Leider gibt es dort für Exchange 2k keine Lösung. Nur für 2003.

du hast mal runtergescrollt?!

Gruß, Nils

Moin,

ausliest..

wenn ich die Unterdomäne im basedn festlege,

$base_dn = "DC=sub,DC=domain,DC=de";

dann bringt er mir keine fehler, aber zeigt auch keine user an..

wahrscheinlich hat das Konto keine Leserechte auf die Objekte. Dann gibt LDAP auch keine zurück.

Gruß, Nils

Moin,

jetzt gibst du uns bestimmt noch den Link zu dem Blog, damit wir mal schauen können, ob wir den Unterschied sehen, gelle?

Gruß, Nils

Moin,

zu PSOs noch folgender Tipp - ohne GUI ist das extrem unhandlich.

faq-o-matic.net Abgestufte Kennwortrichtlinien endlich komfortabel

Und José 3.0 kann die auch dokumentieren:

faq-o-matic.net José: Version 3.0 ist da

Gruß, Nils

Moin,

Es geht um Kennwortrichtlinien, aber das sollte jetzt ja eigentlich nicht wichtig sein.

doch, genau das ist wichtig, weil gerade die Kennwortrichtlinien auf diese Weise nicht steuerbar sind.

Kennwortrichtlinien

faq-o-matic.net Besonderheiten der AD-Kennwortrichtlinie

Gruß, Nils

Moin,

schmink dir bitte endlich die eigene Instanz ab. Die gibt dir ausschließlich Nachteile.

Alles, was ich dazu sagen kann, habe ich gesagt. Konkretere Empfehlungen werde ich in diesem Rahmen nicht aussprechen, das wäre unseriös.

Gruß, Nils

Moin,

du könntest die von Carsten gepostete Funktion abwandeln, sodass sie die Werte in eine temporäre Tabelle speichert. Dann fragst du die mit der Zieltabelle gejoined ab.

Gruß, Nils