NilsK

Moin, daher ja meine Empfehlung, das mit einem lokal ablaufenden Skript zu erledigen. In der Hinsicht muss ich mich auch korrigieren: Für lokalen Lesezugriff reichen i.d.R. normale Userrechte aus, das würde die Anforderung also sehr wahrscheinlich erfüllen. Gruß, Nils

Moin, unterschiedliche Druckertreiber oder unterschiedliche Einstellungen in den Treibern? Das kann bei Word sowas hervorrufen. Gruß, Nils

Moin, wie auch die Quellen in den anderen Threads bestätigen, dürfte das Zuweisen von maßgeschneiderten WMI-Berechtigungen einen sehr hohen Aufwand erzeugen. Wenn es um eine Lizenzprüfung geht, dann ist das ja normalerweise eine einmalige Sache. Da wäre es vermutlich am effizientesten, die Abfrage über ein Tool oder über ein WMI-Skript zu erledigen, das z.B. per Startskript mit Systemrechten läuft oder das per Taskplaner lokal mit Adminrechten ausgeführt wird und die Daten an zentraler Stelle sammelt. Gruß, Nils EDIT: Irrtum korrigiert - bei lokaler Ausführung sind wahrscheinlich keine Admin- oder Systemrechte nötig.

Hallo Rolf, Entschuldige bitte meine Ungeduld. Gruß, Nils

Moin, grummel ... ja, das geht aus deiner Frage hervor. Und welches eigentliche Ziel verbirgt sich dahinter? Leute, lasst euch doch nicht immer alles aus der Nase ziehen! Wie soll man euch da helfen? Gruß, Nils

Moin, ich habe gemeckert? :confused: Wann? Wo? Wie? Dass ich bei Detailfragen dieser Art immer nach dem Zusammenhang frage, liegt einfach daran, dass man viele Fragen viel besser und zielgerichteter beantworten kann, wenn man den Hintergrund kennt. Und wenn du dich auf einen anderen Thread beziehst, dann gib das doch einfach selbst an. Wir haben hier ja schließlich nicht das Board auswendig im Kopf. Vielleicht solltest du deine Haltung mal überdenken. Das ist ein ehrenamtliches Board, an das man keine Ansprüche stellt. Inhaltlich stimme ich den anderen zu: Ein VLAN-Konzept wird weniger fehleranfällig sein als eine Hintenrum-Lösung, nach der du fragst. Und ganz bestimmt: So groß ist der Aufwand nicht, gerade in Relation zu dem Aufwand, den eine reine DHCP-Lösung schnell in der Praxis bedeutet. Gruß, Nils

Moin, ich löse "das" gar nicht, weil ich den Sinn dahinter nicht verstehe. Was willst du denn am Ende erreichen? Gruß, Nils

Moin, und noch dazu würde es nichts nützen ... Gruß, Nils

Moin, und wieder meine Lieblingsfrage: Was willst du denn erreichen? Gruß, Nils

Moin, ergänzend darf ich korrigieren: Ein In-place-Upgrade auf Windows Server 2016 geht maximal von Windows Server 2012, aber nicht von 2008 R2 (die übliche Regel "n minus 2"). https://technet.microsoft.com/en-us/windows-server-docs/get-started/supported-upgrade-paths Außerdem dürfte SQL Server 2008 R2 auf Windows Server 2016 überhaupt nicht supported sein, wenn es übrrhaupt läuft. Soweit ich es auf die Schnelle sehe, ist schon 2012 R2 nicht untertstützt. Also: Plan begraben. Gruß, Nils

Moin, ich stimme Norbert zu. Das Risiko steht in keinem günstigen Verhältnis zum Nutzen. Wobei mir der Nutzen des Ansatzes völlig unklar ist - welches Ziel verfolgt ihr mit dem "doppelten" In-place-Plan? Gruß, Nils

Moin, von wievielen Usern reden wir denn? Ich glaube nicht, dass Office 365 wirklich teurer kommt. Es muss ja nicht die Volllizenz sein, für die Anbindung von Mailboxen reicht auch ein einfaches Abo. Business Essentials beispielsweise gibt es ab etwa 5 Euro pro User und Monat, und soweit ich sehe, kann man das auch bekommen, ohne Geschäftskunde zu sein. Das hat mir der Support-Chat auch grad so bestätigt. Also, ich würde gar nicht erst über einen eigenen Server nachdenken, aber dass muss man für sich selbst entscheiden. Gruß, Nils

Moin, laut Webseite unterstützen die "signing in via social networks" - dahinter wird sich vermutlich sowas wie SAML verbergen. Eine LDAP-Integration von einer fremdgehosteten Seite an euer internes AD wollt ihr jedenfalls nicht, das wäre sicherheitstechnisches Roulette. Gruß, Nils

Moin, was ist das für eine Webseite? Welche Technik steht dahinter? Dem Szenario nach könnte SAML bzw. ADFS passen: Anmelden bei einer externen Webseite mit internen Konten, ohne dass die internen Kontendaten das Netzwerk verlassen. Frag also den Hersteller der Web-Software, ob diese SAML unterstützt. Die Technik ist in der Einarbeitung nicht ganz ohne, aber für sowas gibt es ja Dienstleister. ;) Wenn es einmal eingerichtet ist, besteht i.d.R. kaum noch Pflegebedarf. Gruß, Nils

Moin, schön, danke für die Rückmeldung! Gruß, Nils

Moin, da deine DNS-Zonen AD-integriert sind, replizieren sie sich automatisch mit der Multi-Master-Replikation des AD. Wie Norbert ja nun schon zweimal gesagt hat. Kannst du prüfen, indem du auf dem zweiten DC die DNS-Konsole öffnest. Gruß, Nils

Moin, das ist ein Missverständnis. Die Delegation hat mit der Replikation nichts zu tun. Gruß, Nils

Moin, solche hatte ich nicht. Offenbar gibt es sehr unterschiedliche Fassungen der Prüfung. Gruß, Nils

Moin, die Subnet-Angabe im AD muss nicht exakt der im Netzwerk entsprechen. Das AD vergleicht die IP des Clients mit den Subnet-Angaben und entscheidet daran, wohin der Client gehört. Wenn es also mehrere "reale" Subnets zu einem "logischen" AD-Subnet gibt, ist das OK, solange diese zum selben Standort gehören. Nur echte Überschneidungen darf es nicht geben. Clients, deren IP-Adresse nicht zu einem definierten Subnet passt, suchen sich irgendeinen DC. Das würde zu dem beobachteten Phänomen passen. Die DCs führen ein Log über Clients, die sie nicht zuordnen können, Hinweise darauf gibt es im Eventlog. Gruß, Nils

Moin, GPO-Tests immer in einem Labor-AD. Gruß, Nils

Moin, "primäre" nicht, aber wie Jan schon richtig sagt, ist genau dafür das Standort-Konzept in Active Directory da: definiere Standorte weise die DCs den jeweiligen Standorten zu weise die Subnets den jeweiligen Standorten zu Im Prinzip ist das alles. Die DCs sollten ihrerseits auch aus dem jeweils passenden Subnet kommen, das ist aber nicht zwingend. Sofern die DCs nicht von vornherein am passenden Standort installiert wurden, kann es sein, dass sie sich im DNS falsch eingetragen haben. Das wäre also zu kontrollieren. Steht ein DC im DNS für den falschen Standort drin, dann löschst du den Eintrag dort und führst eine Neuregistrierung durch: net stop netlogon net start netlogon ipconfig /registerdns Wichtig ist natürlich auch, dass die Clients auch den passenden Subnets angehören, sonst suchen sie sich "irgendeinen" DC. Gruß, Nils

Moin, wobei mich jetzt der Ansatz etwas wundert ... normalerweise würde man doch erst (anhand des Bedarfs) rechnen und dann erst kaufen, oder? Sprich: "Ich will X virtuelle Maschinen auf dieser Hardware betreiben - was brauche ich dafür?" Aber gut, schön, dass es jetzt geklärt ist. Gruß, Nils

Moin, vielleicht hilft dies: Gruß, Nils

Moin, fragen wir so: Wozu sollte es die geben? ;) Eine VM mit einem AD zum Nachsehen ist in weniger als einer Stunde fertig ... Gruß, Nils

Moin, ich verstehe nicht ganz, was du vorhast. Wenn es lokal sein soll, warum dann nicht direkt über den Aufgabenplaner? Gruß, Nils