NilsK

Moin, um das Schema zu aktualisieren, muss man Mitglied der Gruppe Schema-Admins sein. Ob der betreffende Account in der Root Domain oder in einer Subdomain beheimatet ist, ist dabei egal. Kann das Schema-Update wegen mangelnder Berechtigungen nicht stattfinden, wird einen die AD-Installation darüber informieren. Auch wenn es technisch möglich ist, eine Subdomain vor der Root Domain zu aktualisieren, ist es gerade wegen solcher Zusammenhänge i.d.R. nicht sinnvoll. Gruß, Nils

Moin, könnte man denken. In der Cloud habe ich eine abgeschaltete VM, falls ich die noch nicht gelöscht habe. Und meine Frau hat ihre Mailbox bei einem Cloud-Provider. Die fünf Webseiten, die ich betreue, laufen als Shared Hosting mit Ökostrom. Das war's im Wesentlichen. Zugegeben: Wäre ich Freiberufler, nutzte ich vielleicht ein wenig mehr, aber auch dann bräuchte ich es nur punktuell. Ich will hier auch niemanden angreifen, aber ich finde die Tendenz der Diskussion gerade etwas ... ergänzungsbedürftig. Gruß, Nils

Moin, hm. Und wofür braucht ihr das? Steht dem ein reeller Nutzen entgegen? Mein 4-Personen-Haushalt wird vom Energieversorger schon seit Jahren als weit unterdurchschnittlich eingestuft (trotz zwei Teenie-Töchtern - aber Smartphones brauchen für Insta und Youtube halt nicht viel Strom). Ich brauche einfach privat keine IT, schon gar keine, die durchlaufen würde. Geek hin oder her, aber irgendwann ist es ja auch eine Frage der Verantwortung. Gruß, Nils

Moin, JEA wäre durchaus geeignet, denn man könnte, wie in dem Beispiel zutreffend angegeben, passende Filter definieren und so einschränken, welche Mitglieder in die Gruppe dürfen. Aber: das hat einen Preis, nämlich erheblichen Aufwand für Entwicklung und Test. Da die Diskussion allerdings in eine seltsame Richtung geht, mache ich hier Schluss. Gruß, Nils

Moin magheinz, danke für deinen wertvollen Beitrag. Richtig wäre "Klugschei*ß*modus". Und falls die spitzen Klammern an SGML-Tags erinnern sollen, sind sie falsch gesetzt, weil ohne Abschluss. Gruß, Nils

Moin, das entspricht vom Prinzip her dem Ansatz 1. Ist auch ungefähr so aufwändig. Gruß, Nils

Moin, das AD sieht es nicht vor, per Berechtigung nur selektiv Mitglieder zu einer Gruppe hinzuzufügen. Wenn das wirklich erforderlich ist, müsste man also mit einem Workaround arbeiten. Aus Erfahrung stelle ich aber in Frage, ob das Erfordernis wirklich so wichtig ist. Zwei mögliche Ansätze sind schon genannt worden: ein Frontend bzw. ein anderes Tool, das nur die erlaubten Objekte auswählbar macht. Das allein reicht aber nicht - das Tool müsste, wenn es Sinn haben soll, über einen separaten (Service-) Account auf das AD zugreifen und der User dürfte gar keine Schreibrechte auf die Zielgruppen haben. Effektiv würde man also ein separates Berechtigungssystem bauen. Die auswähbaren Objekte selbst per AD-Berechtigungen einschränken. Das ist denkbar - wäre aber zum einen ein erheblicher Eingriff in die AD-Berechtigungen (und könnte dazu führen, dass Microsoft es nicht mehr supportet) und würde zum anderen bedeuten. dass der betreffenden User die versteckten Objekte überhaupt nicht mehr sehen und benutzen kann. Da das AD für so ein Szenario nicht gebaut wurde, würde ich, wie gesagt, genau prüfen, ob das wirklich erforderlich ist. Gruß, Nils

Moin, da es um MS SQL geht, sind hier natürlich auch SQL-CALs erforderlich. Auch hier geht es um tatsächlich zugreifende "Menschen", nicht um den verwendeten Account. Gruß, Nils

Moin, Und: adprep ist obsolet. Das macht die AD-Installation automatisch. Es gibt ja auch kein dcpromo mehr. Gruß, Nils

Moin, Nein, du kannst das einfach löschen, sofern die User ihre Rechner weiter nutzen. Sie verwenden dann das vorhandene Profil weiter. Gruß, Nils PS. Ihr wollt einen zweiten DC installieren.

Moin, ja, fast. Deshalb fragte ich ja, was du eigentlich erreichen willst. Was soll mit der Ausgabe geschehen? Bei "Beschreibung" geht es um das Feld "description" aus dem Gruppenobjekt? Und dann nur einen Teil davon? Wie habt ihr mehrere Zeilen dort reinbekommen? Gruß, Nils

Moin, mir ist unklar, wovon du redest. Kannst du bitte die Anforderung und die Situation noch mal genau beschreiben? Wichtig dabei: Gib an, was du eigentlich erreichen willst, nicht was die Probleme deines bisherigen Weges sind. Gruß, Nils

Moin, vermutlich liest er gern "ja". Ja. Gruß, Nils

Moin, korrekt, aber bei den Kunden, mit denen man sowas diskutieren muss, gibt es auch keine weiteren Hosts ... Gruß, Niös

Moin, die Frage stelle ich mir auch. Aus meiner Sicht spricht nahezu nichts gegen virtuelle DCs. Es spricht aber sehr wohl etwas dagegen, nur einen DC zu betreiben. Eine 30-User-Umgebung liegt aus meiner Sicht deutlich oberhalb der Grenze, bis zu der man einen einzelnen DC tolerieren könnte. Noch dazu bei den genannten Eigenschaften. Ein physischer DC muss in so einer Umgebung nicht mehr kosten als 1500 Euro inkl. Lizenz. Wenn das zu viel ist, um im Fall des Falles viel schneller wieder arbeitsfähig zu sein und gleichzeitig verschiedene Schadensszenarien ganz vermeiden zu können ... Gruß, Nils

Moin, ich glaube, in Nordhessen wäre noch Wasser übrig. Hier in Hanau ist es hingegen eher unverdächtig. Gruß, Nils

Moin, dies hier ist immer noch aktuell und ziemlich vollständig: [Darf man einen Domänencontroller virtualisieren? | faq-o-matic.net] https://www.faq-o-matic.net/2011/02/28/darf-man-einen-domnencontroller-virtualisieren/ Ich würde auch weiterhin nicht auf einen physischen DC verzichten. Es handelt sich um ein Unternehmen? Dann ist ein einzelner DC ziemlich sicher zu wenig. Gruß, Nils

Moin, ich glaube, du willst lieber das bestehende Problem lösen statt eine Reihe neuer Probleme zu erzeugen. Ihr wollt euren SQL Server nicht nach außen veröffentlichen. Gruß, Nils

Moin, deine Syntax ist von Grund auf falsch. Du kannst die Cmdlets nicht einfach so hintereinander schreiben. Auch kannst du nicht einfach aus einem Parameter einen Vergleich machen. Und schließlich funktioniert die Mehrfachverschachtelung und der Verweis auf Werte nicht so, wie du dir das denkst. Vielleicht solltest du erst mal einfachere Codebeispiele ausprobieren und damit in der PowerShell laufen lernen. Deine jetzige Anforderung ist schon sehr komplex, da sollte man die Basics draufhaben. Gruß, Nils

Moin, ja, die betreffende Partei hat meine Haltung gut erkannt. Gruß, Nils

Moin, hm, ich glaub, ich soll in diesem Leben immer nur dasselbe wählen. 92 Prozent Übereinstimmung ... Gruß, Nils

Moin, weitergehend wäre die Frage, ob solche Accounts überhaupt im produktiven AD richtig aufgehoben sind. Aus Sicherheitssicht wäre zu prüfen, ob man für diese Tests nicht ein separates AD einrichtet. Schließlich habt ihr offenbar eine ganze Reihe von Sessions, die unbeaufsichtigt laufen - und das dann künftig vielleicht auch noch mit Shared Accounts. Gruß, Nils

Moin, ich glaube, du solltest dir noch ein paar Grundlagen aneignen. Sonst wirst du auf Basis fehlender Kenntnisse herumstochern und möglicherweise schwere Fehler erzeugen. Ein AD läuft auf einem bestimmten Modus und hat ein bestimmtes AD-Schema. Beide werden von den vorhandenen DCs vorgegeben. Das Schema muss immer dann aktualisiert werden, wenn ein DC mit einem neueren Betriebssystem eingebunden werden soll, und zwar vorher. Das geschieht (in älteren Versionen) über das ForestPrep. Da noch weitere Anpassungen nötig sein können, gibt es auch noch das ADPrep. Erst dann kann man den "neueren" DC überhaupt als DC dazuinstallieren. Hast du also ein AD mit DCs unter 2003 R2 und willst einen DC mit 2008 dazuhaben - ist ForestPrep und ADPrep erforderlich. Seit Windows Server 2012 (meine ich) ist dieser Schritt direkt in die Installation integriert - er findet immer noch statt, aber nicht mehr separat. Der Modus hingegen gibt an, welche neueren Funktionen im AD aktiv sind. Der mögliche Modus wird vom "ältesten" DC vorgegeben. Solange du also noch 2003-DCs hast, kannst du nicht vom 2003-Modus weg. Wenn du den letzten 2003-DC entfernt hast, hebt sich der Modus aber nicht von selbst an, das muss man manuell tun. Normalerweise ist das auch problemlos, aber es kann "theoretisch" Applikationen geben, die vorher geprüft werden müssen. Exchange ist da der einzige "typische" Fall, weil ältere Exchange-Versionen meist mit den neueren AD-Modi nicht klarkommen. Beide Aspekte (Schema und Modus) haben technisch aber nichts miteinander zu tun. Die Probleme in deinem Lab werden nicht ursächlich damit zu tun haben, da stimmt etwas anderes nicht. Gruß, Nils

Moin, das klingt nicht gut. Dann ist sicher das Eventlog voller Details dazu. Ich wage mal zu vermuten, dass wir das in einem Forum nicht gelöst bekommen. Wenn es sich um eine Produktionsumgebung handelt, solltest du umgehend einen Case bei Microsoft eröffnen. Gruß, Nils

Moin, nur ergänzend dazu aufgrund deiner Anmerkung: Drucker gehören auch nicht auf einen DC, die sind auf einem dedizierten Druckserver genau richtig aufgehoben. Gruß, Nils