NilsK

Moin, nein, die Abfrage von $env:USERNAME führt hier nicht zum Ziel. Die gibt den Namen des Users zurück, der das Skript ausführt. Damit lässt sich aber nicht prüfen, ob jemand angemeldet ist. Die Frage, ob jemand lokal (oder überhaupt) angemeldet ist, ist nicht trivial. Die Abfrage per "query session" wurde schon genannt, aber auch das hat seine Tücken: [spaß mit der Konsolen-Session | faq-o-matic.net] http://www.faq-o-matic.net/2013/03/25/spa-mit-der-konsolen-session/ [Monitoring: Ist der Admin an die Konsole angemeldet? | faq-o-matic.net] http://www.faq-o-matic.net/2012/04/30/monitoring-ist-der-admin-an-die-konsole-angemeldet/ Gruß, Nils

Moin, naja, da hast du doch den Fehler. Wenn du dem AD sagst, dass die Außenstellen direkt miteinander verbunden sind, dann nutzt es das auch. Dass dies gar nicht zutrifft, kann das AD ja nicht wissen. Nimm also die Verbindung zwischen den Außenstellen raus, wenn die gar nicht existiert. Gruß, Nils

Moin, Ergänzung: Bei Windows 2012 und R2 sind die "physischen" CPUs relevant, nicht die Cores. Gruß, Nils

Moin, deine gpresult-Abfrage gibt nur die Benutzereinstellungen zurück (jedenfalls laut Screenshot), aber nicht die des Computers. Schau dir mal die Schalter von gpresult an. Gruß, Nils

Moin, fein, aber nächstes Mal beachtest du bitte die Warnung, lässt uralte Threads (sieben Jahre!) in Ruhe und eröffnest einen neuen Thread. Gruß, Nils

Moin, du hast gpupdate /target:computer ausgeführt oder den Client neu gestartet? Gruß, Nils

Moin, nein, du überprüfst noch mal deine Einstellungen: Sites und Sitelinks sind richtig? Subnets sind korrekt zugeordnet? IP-Adressen der DCs passen zu den Sites und Subnets? Automatic Bridging ist aus? Wenn das korrekt ist, sollte der KCC natürlich keine Verbindung zwischen den Außenstellen erzeugen. Gruß, Nils

Moin, wenn es nur bei dieser Anforderung bleibt, ist PowerShell sicher die beste Wahl. Wenn es künftig noch mehr Abgleiche geben kann oder soll, könnte man sich den Microsoft Identity Manager ansehen. Gruß, Nils

Moin, nein, musst du nicht. Aber sind die DCs auch logisch den passenden Standorten zugeordnet? Gruß, Nils

Moin, aha - also fehlten wohl doch noch Angaben, entgegen deinen etwas aggressiven Angaben in Post #3. Nächstes Mal dann vielleicht etwas weniger forsch. Gruß, Nils

Moin, naja, "showrepl" zeigt nur, ob die Replikationsversuche erfolgreich waren. Es bewertet nicht die Topologie. Welche Verbindung zeigt denn der DC in der Außenstelle? Gar keine? Gruß, Nils

Moin, kannst du es mal mit einem lokalen Laufwerk versuchen, z.B. einer USB-Platte? Tritt dann auch so ein Fehler auf? Falls nicht, dürfte das Problem beim Netzwerkzugriff liegen. Falls ja, ist lokal irgendwas im Busch. Produktionssystem? Dann würde ich, wenn das Problem lokal liegt, den MS-Support einbinden. Gruß, Nils

Moin, hm, eigentlich sollte das "einfach so" funktionieren. Und wenn die VM läuft, sollte dort auch "online" stehen, nicht "offline". Ist der Host auf aktuellem Patchlevel? Wohin soll gesichert werden? Ist in den Einstellungen der VM der Dienst für die VSS-Datensicherung aktiviert? Wurde der Host nach dem Auftreten des Fehlers schon neu gestartet? Steht etwas Verwertbares im Eventlog (System, Anwendungen, Anwendungs- und Dienstprotokolle/Microsoft/Windows/Backup/Betriebsbereit)? Gruß, Nils

Moin, Routing richtig konfigurieren, Site Links passend setzen, Bridging aus, manuelle Replikationsverbindungen löschen, abwarten. Dann sollte es sich korrekt einschwingen. Gruß, Nils

Moin, Grundregel: Nicht manuell eingreifen, sondern die Konfiguration so setzen, dass der KCC es automatisch richtig macht. Sobald du manuell eingreifst, musst du manuell weitermachen und hast die leistungsfähigen Mechanismen des KCC nicht mehr zur Verfügung, die selbstständig Redundanzen erzeugen, neue DCs oder Sites aufnehmen usw. Aus deiner Anfrage entnehme ich, dass die Standorte untereinander nicht kommunizieren können, weil z.B. die Firewall das nicht zulässt. Ist das richtig? In dem Fall musst du zum einen die Standorte und Standortverknüpfungen richtig konfigurieren. Zusätzlich musst du dem AD dann sagen, dass es keine Redundanzen zwischen den Standorten schaffen darf. Das erreichst du, indem du die Option "Bridge all site links" abschaltest. Hier ist das beschrieben: [bridge all site links] http://www.active-directory-faq.de/2012/12/active-directory-sites-and-services-%E2%80%93-bridge-all-site-links/ "Exotisch" ist die Konfiguration nicht, allerdings trifft man "hart" sternförmige Topologien in der Praxis tatsächlich eher selten an. Daher ist die Standardeinstellung meist schon sinnvoll. Gruß, Nils

Moin, liegen die VHD(X)-Dateien auf dem Host in einem Ordner, der komprimiert ist? Ist dort Dedup im Spiel? Falls nicht: Gilt eins oder mehrere für das Ziel des Backups? Gruß, Nils

Moin, da irrst du. Du kannst mit einer Standard-Lizenz den physischen Host betreiben und zwei VMs, wenn der physische Host nur Host ist. Sobald du dort auch nur eine Dateifreigabe oder einen anderen Dienst einrichtest, belegt der physische Host eine der Lizenzen, und du darfst nur noch eine VM betreiben. Das ist bei 2012, 2012 R2 und 2016 so. Zudem bin ich mir ziemlich sicher, dass du auf einem mit 2016 lizenzierten Host nicht parallel 2012-R2-Lizenzen zuweisen kannst (die Lizenzen gelten immer für die Hardware, nie für VMs). Gruß, Nils

Moin, Consultant, oder? :D Gruß, Nils

Moin, durchaus korrekt, aber "elegant" braucht manchmal einfach zu lang ... :D Gruß, Nils

Moin, du weißt doch - hier kann man nur gewinnen. :D Gruß, Nils

Moin, es wird empfohlen, einen DC unabhängig von der Virtualisierung zu halten, i.d.R. physisch. Aber dann separat, niemals direkt im Host-Betriebssystem. Da läuft nichts außer Hyper-V. Wenn du drei Netzwerkkarten im Server hast, dann nutz sie auch. Denkbar: Eine Karte für das Host-OS, zwei Karten zu einem Team zusammenfassen für die VMs (an das Team dann den vSwitch binden, das Host-OS bekommt hier keine Verbindung). So hast du alles sauber getrennt. Es wäre nicht zu erwarten, dass dann eine der VMs nicht kommunizieren kann. Was ist denn das für ein Heimnetz, dass du so viele Server und auch noch WDS brauchst? Klingt erst mal seltsam. Deine Lizenzierung passt jedenfalls hinten und vorne nicht. Meines Wissens darfst du verschiedene Lizenzversionen nicht auf derselben Hardware betreiben, bleiben also zwei Standard-Lizenzen oder vier VMs. Du sparst keine Lizenz, wenn du Dienste auf dem Host-OS betreibst - in dem Fall ist dort eine Lizenz belegt und nur noch eine "VM-Lizenz" frei. Wenn es also bei vier VMs bleiben soll, dann fasse die Dienste passend zusammen. Was sind das für Lizenzen? MSDN oder Dreamspark? Dann darfst du die nicht produktiv nutzen. Gruß, Nils

Moin, OK, verstehe. Hier steht der Dienst auf "manuell" und ist nicht gestartet, also dürfte es in dem betrachteten System wohl in der Tat irgendwas geben, was ihn braucht. Vielleicht wäre es ein Ansatz, den Dienst zu deaktivieren und dann zu schauen, welche Fehler auftreten. Ließe sich ja vielleicht mit einem Systemklon machen. Gruß, Nils

Moin, dann will ich aber auch. ;) Die Abfrage kann noch etwas einfacher sein, weil die Select-Anweisung für den Zweck nicht nötig ist. $UserSource = 'Alogie' $UserTarget = 'PAhner' $UserSourceObject = (Get-ADUser $UserSource -Properties memberOf) foreach ($Group in $UserSourceObject.MemberOf) { Add-ADGroupMember -Identity $Group -Members $UserTarget } Gruß, Nils

Moin, okay, danke. Die Erklärungen in dem Artikel sind zwar nicht korrekt, aber wenn die Maßnahme das Problem behebt (und keine erwartbaren negativen Nebenwirkungen hat, was hier der Fall ist), ist es ja OK. Gruß, Nils

Moin, ah, prima. Und, hast du auch eine Quelle dazu? Gruß, Nils PS. übrigens ein hübsches Beispiel für den unsinnigen Einsatz von "/force" ...