NilsK

Moin,
 
du findest im Web zahlreiche Quellen für Skripte, die alle DCs nach der letzten Anmeldung fragen und damit  das "echte" letzte Anmeldedatum herausfinden, eine Suche nach "active directory real last logon" oder so hilft.
 
Im Zeitalter des Ruhezustands sind aber Cached Credentials der übliche Anmeldeweg, sodass die Anmeldedaten am DC nur begrenzte Aussagekraft haben. Kommt also drauf an, was ihr da rausfinden wollt. Und: Selbstverständlich sind solche Auswertungen ein Thema für den Betriebsrat.
 
Gruß, Nils
 

Moin,
 
so eine richtig einfache Lösung scheint es nicht zu geben, wenn mehr als ein Dongle in Reichweite sein kann. Hier hat einer eine "schmutzige" Lösung gebaut, die im Action Center nach dem gesuchten Gerät per Bilderkennung sucht und dies dann auswählt. Scheint ein AutoHotKey-Skript zu sein.
 
https://stackoverflow.com/questions/35601005/autoconnect-to-ms-wireless-display-on-windows-10
 
Gruß, Nils
 
 

Moin,
 
die Suchmaschine deines Verrtrauens beantwortet dir auch dies:
https://www.microsoft.com/de-de/howtotell/cfr/report.aspx
 
Ob es was bringt und du das melden willst, musst du dir selbst überlegen.
 
Gruß, Nils
 

Moin,
 
ein Client, der eine Richtlinien-Einstellung aufgrund seiner Windows-Version nicht "versteht", wendet sie einfach nicht an. Es ist also fast nie wirklich nötig, GPOs nach Windows-Versionen zu unterscheiden. Dass dieselbe Einstellung unterschiedliche Reaktionen hervorruft, ist so gut wie nie der Fall.
 
(Genau betrachtet, ist es noch etwas anders: Der Client wendet die Einstellung an, schreibt den Wert also in seine Registry. Wenn aber das Betriebssystem diesen Registry-Wert gar nicht verwendet, dann bleibt er einfach ohne Funktion. Das Betriebssystem schaut an der Stelle einfach gar nicht nach und reagiert also auch nicht. Ein solcher Wert, der nicht verwendet wird, richtet aber auch keinen Schaden an.)
 
Gruß, Nils

Moin,
 
da gibt's doch was von Obipharm. 
 
[Hyper-V: Virtuelle Switches und die angebundenen VMs anzeigen | faq-o-matic.net]
https://www.faq-o-matic.net/2014/05/21/hyper-v-virtuelle-switches-und-die-angebundenen-vms-anzeigen/
 
[Get-HyperVNetworkReport: Hyper-V-Netzwerke übersichtlich anzeigen | faq-o-matic.net]
https://www.faq-o-matic.net/2015/03/16/get-hypervnetworkreport-hyper-v-netzwerke-bersichtlich-anzeigen/
 
Gruß, Nils
 

Moin,
 
passiert dasselbe in einem CMD-Fenster? Ich würde intuitiv nicht ausschließen, dass die PS da wegen irgendwas hustet.
 
Gruß, Nils
 

Moin,
 
ein "normaler" Server aktualisiert sich nicht laufend wie Windows 10. Das Server-OS hat den Charakter einer Longterm-Version und wird nur alle paar Jahre grundlegend erneuert. Das von dir beobachtete Verhalten ist also korrekt. Die auf deinen 2016-Server folgende Version wird Windows Server 2019 sein, sie ist neu zu lizenzieren, wenn man sie haben will.
 
Neu ist seit etwa einem Jahr eine völlig separate Serverversion, die ca. alle sechs Monate wie Windows 10 erneuert wird. Die ist aber nicht für "normale" Server gedacht, sondern im Wesentlichen für Container (also "Docker"). Dort führt man dann auch kein Upgrade durch, sondern wirft alle halbe Jahr die Container und ihr Basis-Image weg und macht sie automatisiert neu. Für diese separate Version ist die SA für die Lizenz erforderlich.
 
Gruß, Nils
 

Moin,
 
DFS-N = System, das einen virtuellen Verzeichnisbaum bereitstellt. Die Einträge des Verzeichnisbaums sind Shares, die auf beliebigen SMB-Dateiservern liegen können. Die Dateiserver brauchen nichts von DFS zu wissen. DFS-N ist nur auf dem Server bzw. den (wenigen) Servern installiert, die den Baum als Verteilpunkt anbieten, diese Server sind typischerweise selbst keine Dateiserver.
 
DFS-R = Replikationssystem, das Dateien zwischen mehreren Servern repliziert. Kann mit oder ohne DFS-N verwendet werden. Ohne DFS-N nutzt man sowas manchmal, um Dateien von mehreren Servern z.B. für ein zentrales Backup zu konsolidieren. DFS-R und DFS-N in Kombination kann dafür sorgen, dieselben Daten z.B. an mehreren Standorten für User bereitzustellen. Vorsicht, DFS-R steuert die Zugriffe nicht und ist in der Hinsicht "dumm", es besteht also das Risiko des Datenverlusts oder von Inkonsistenzen, wenn man es falsch konzipiert und einsetzt.
 
Gruß, Nils
 

Moin,
 
hm, dann war das in anderem Zusammenhang. Jedenfalls müsste das hier eigentlich helfen, konkret der untere Teil in dem Artikel.
 
https://mssqltrek.com/2012/06/28/how-to-add-a-new-diskdrive-to-sql-server-failover-cluster/
 
Gruß, Nils
 

Moin,
 
korrekt, Die Berechtigungsstruktur für Hyper-V gab es mal, aber die hat Microsoft entfernt, warum auch immer. Nicht, dass die gut zu nutzen gewesen wäre, aber jetzt gibt es wirklich gar nichts mehr. Aber selbst damit hätte sich das nur auf Hyper-V bezogen, nicht auf Cluster.
 
Hyper-V-Administratoren sind ggf. eine Alternative, wenn es wirklich nur um Hyper-V geht, nicht um den unterliegenden Host und nicht um den Cluster als solchen. Aber dann ist das eben auch nur "alles oder nichts".
 
Ergänzend noch zu JEA, das Microsoft als Ansatz positioniert, das aber sehr aufwändig ist:
 
[Just Enough Administration: Material von der CDC Germany 2017 | faq-o-matic.net]
https://www.faq-o-matic.net/2017/06/12/just-enough-administration-material-von-der-cdc-germany-2017/ 
 
Die Videos der CDC 2017 gibt es mittlerweile kostenlos, aber nur gegen Registrierung:
https://www.hyper-v-server.de/news/session-video-mitschnitte-der-cdc-germany-2017-jetzt-kostenlos-verfuegbar/
 
 
Gruß, Nils
 

Moin,
 
jein, leider ist es so leicht nicht.
 
Aus Sicherheitssicht sollte man WINS heute nicht mehr einsetzen, es wird seit Jahren nicht gepflegt und es gibt bekannte Sicherheitslücken, die Microsoft ausdrücklich nicht mehr schließen wird. Ob man WINS "braucht", ist leider nicht so einfach zu beantworten. Alles, was man "wirklich" braucht, geht schon seit Jahren über DNS. Es gibt aber Software - die durchaus nicht "uralt" sein muss -, die immer noch Mechanismen nutzt, die ohne WINS nicht oder nicht richtig funktionieren. Einfache Computerlisten (mit denen z.B. ein User den Server auswählt) sind so ein Beispiel - manche Developer nehmen da einfach das, was sie immer genutzt haben, und dann baut so eine Liste sich aus NetBIOS-Namen zusammen. Im eigenen Subnet geht das per Broadcast, sobald aber ein Router im Spiel ist, scheitert das. Da hülfe WINS, DNS aber nicht.
 
Gruß, Nils
 

Moin,
 
konkretisieren wir das: Sobald auf einen 2016 (VM oder physisch) durch Anwender oder Endgeräte zugegriffen wird, sind für diese Zugriffe CALs erforderlich. Wie viele das sind, richtet sich nach den konkret zugreifenden Einheiten. Je nach Dienst, der auf dem 2016 läuft, kann es erforderlich sein, alle CALs auf 2016 zu aktualisieren: Ein DC unter 2016 kann von allen Usern und Endgeräten angesprochen werden, einige andere Dienste ebenso - das lässt sich faktisch nicht einschränken. In diesen (und ähnlichen) Fällen müssen 2016-CALs also flächendeckend vorliegen.
 
Eine Ausnahme ist Hyper-V: Wenn ein 2016-Server ausschließlich als Host verwendet wird und keine anderen Dienste anbietet, aber sonst keine 2016-Server in Betrieb sind, dann sind keine 2016-CALs erforderlich. Meines Wissens hat sich dieses Prinzip nicht geändert.
 
Gruß, Nils
 

Moin,
 
naja, in Ordnung wäre sie eben nicht. Das Konstrukt mit den beiden Netzwerkkarten ist - kurz gesagt - falsch. Ob du dafür erst noch eine Testumgebung bauen willst, spielt auf einer anderen Ebene. Zum Aufbauen von Know-how ist das sicher eine gute Idee. Es gibt ja auch gute Literatur zum Thema.
 
Gruß, Nils
 

Moin,
 
ach so ... das war wirklich missverständlich formuliert. Ich hatte gedacht, es gehe um AD-Accounts pro System, die lokal berechtigt sind.
Genau das wäre auch der Schlüssel zur Lösung: Erzeuge je System einen Admin-Account im AD, der lokaler Admin wird. Dann kannst du solche Berechtigungen gut verteilen. Die lokalen Konten entfernst du von den Systemen. Lokale Konten haben halt nur lokale Rechte und können im Netzwerk nichts.
 
Gruß, Nils
 

Moin,
 
als erstes korrigierst du die Zeitserver-Einstellungen:
 
https://www.gruppenrichtlinien.de/de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/
 
Dann etwas abwarten und den Report neu erzeugen. Dann weitersehen.
 
Gruß, Nils
 

Moin,
 
näherungsweise kannst du dir das in etwa so vorstellen. Für die genauen Abläufe müsste ich  jetzt erst mal länger bei Microsoft suchen, das bekommst du bei Bedarf sicher auch  hin.
 
Der KDC läuft normalerweise "immer" und prüft, wenn meine Erinnerung nicht trügt, alle 15 Minuten, ob der die Topologie neu berechnen muss.
 
Gruß, Nils
 

Moin,
 
so in etwa. Beim Server unterscheidet Microsoft mittlerweile auch zwei Linien, die "herkömmliche" mit einem Vollprodukt alle paar Jahre (aktueller Name dafür ist LTSC) und eine weitere mit Aktualisierung zweimal jährlich. Letztere erfordert die Software Assurance und ist ausdrücklich kein Vollprodukt, sondern in erster Linie als Basis für Container gedacht.
 
Gruß, Nils

Moin,
 
bei Microsoft gibt es unabhängig vom Produkt mehrere Supportmöglichkeiten. Im Wesentlichen ist das Per-incident Support, d.h. du öffnest bei Bedarf einen Case zum Pauschalpreis, der einzeln abgerechnet wird. Oder du schließt einen Support Contract, den es auch in mehreren Ausprägungen gibt.
 
https://support.microsoft.com/de-de/gp/contactus81?forceorigin=esmc&Audience=Commercial
 
Gruß, Nils
 

Moin,
 
grundsätzlich sollte man in die KCC-Verbindungen nicht manuell eingreifen, sondern dem KCC Hinweise geben, wie man es haben will. Heißt: Im Normalfall keine manuellen Replikationsverbindungen. Sobald man diese baut, ist man dafür verantwortlich und schränkt die Mittel des KCC zur Korrektur bei Änderungen an der Infrastruktur ein.
 
Wenn es zwischen DC3 und DC4 keine Verbindung gibt, musst du die Standortverknüpfungen entsprechend definieren und das Auto-Sitelink-Bridging abschalten.
http://www.active-directory-faq.de/2012/12/active-directory-sites-and-services-–-bridge-all-site-links/
 
Gruß, Nils
 

Moin,
 
nicht verifiziert, aber es scheint einen Registry-Key zu geben, der das für 1803 ermöglicht:
https://social.technet.microsoft.com/Forums/en-US/59183715-0c04-44f7-b5ea-bb37da4125a5/unable-to-join-domain-with-new-windows-10-computers-build-1803?forum=win10itpronetworking
 
Gruß, Nils

Moin,
 
Listen geraten sehr schnell an ihre Grenzen. Wenn ihr tatsächlich "Grund" reinbringen wollt, rate ich zu einer Spezialsoftware, die den Ist-Stand jederzeit dokumentieren und auflösen kann. Gerade wenn es sehr viele Einzelberechtigungen gibt, ist das hilfreich. Damit kann man nicht nur die Frage beantworten "wer hat auf den Vertriebsordner Zugriff?", sondern auch "wo hat Ulla überall Berechtigungen?". Sehr leistungsfähig ist hier tenfold, ähnlich arbeitet 8MAN (ist aber teurer und weniger leistungsfähig).
 
Gruß, Nils
 

Moin,
 
die kannst du erst dann löschen, wenn die zugehörigen Zertifikate nirgends mehr verwendet werden. Da man bei einer Sub die Verlängerung oft vor dem Ablauf des CA-Zertifikats macht, muss man den Ablauf des alten Zertifikats erst abwarten, bevor man die Sperrliste löscht. Es könnte ja bei einem Client noch in Benutzung sein, und der muss feststellen können, ob es noch gültig ist.
 
Gruß, Nils
 

Moin,
 
schon seit zehn Jahren reicht es aus, einen verwaisten DC im ADUC zu löschen. Danach noch im Standorte und Dienste sowie im DNS entfernen.
 
Gruß, Nils
 

Moin,
 
vielleicht können wir hier ja einfach mal das Missverständnis aufklären. Die lokalen Peer-to-Peer-Updates sind für Netzwerke gedacht, in denen es keinen WSUS gibt. Kleine Netze oder z.B. kleine Außenstellen. Da spart man Traffic und eben den Aufwand eines WSUS.
 
Wenn ein WSUS vorhanden und gut angebunden ist, ergeben die Peer-to-Peer-Updates keinen Sinn.
 
Gruß, Nils
 

Moin,
 
die Computerrichtlinien gelten immer nur für die lokalen Konten des jeweiligen Rechners. Möchte man die Einstellungen für die Konten des AD vornehmen, dann geht das nur in einem GPO, das auf der Domänenebene definiert ist - und nur dort. GPOs auf OU-Ebene wirken nicht auf die Kennworteinstellungen von AD-Konten, sondern würden sich nur auf die lokalen Konten der Computer auswirken, deren Konten in der betreffenden OU gespeichert sind.
 
Aufgrund diverser Effekte sollten die Kennworteinstellungen für das AD ausschließlich in der Default Domain Policy definiert werden, nicht in einem eigenen GPO auf Domänenebene.
 
Die Einstellung "Kennwort läuft nie ab" bei einem Useraccount übersteuert für diesen einen Account das maximale Kennwortalter, das per Policy gesetzt ist. Gedacht ist das vor allem für Dienstkonten, damit nicht urplötzlich der SQL Server wegen eines Anmeldefehlers stehenbleibt. Alle anderen Einstellungen der Policy gelten dann aber weiter. Dies betrifft sowohl lokale als auch AD-Konten.
 
Gruß, Nils