NilsK

Moin,

man glaubt gar nicht, wie die alten Herren hier sich freuen, wenn sie Anlass zum Fachsimpeln bekommen. 

Gruß, Nils (alter Herr)

Moin,

und dann kommt kurz vor deinem letzten Arbeitstag jemand an und wirft dir JSON vor die Füße ...

Gruß, Nils

Moin,

En Screenshot ist schlechter als ein Text, wenn es auf den Text ankommt. Und ein PDF ist schlechter als ein Screenshot, wenn es auf den Screenshot ankommt.

Gruß, Nils

Moin,

könntest du nächstes Mal einfach direkt einen Screenshot einbinden statt eines PDF?

Die Meldung ist normal, wenn du ein Batch aufrufst, das mit UNC-Pfaden arbeitet. Würde ich einfach ignorieren. Das ist ja auch keine Fehlermeldung. 

Gruß, Nils

Moin,

Aber das Problem ist doch gelöst ...?

Gruß, Nils

Moin,

Für mich klingt das zuerst nach Konzeptfehler. Wenn man VMs jede Minute repliziert, hat man meist nicht verstanden, wozu VM-Replikation gedacht ist und unter welchen Grenzen und Bedingungen das steht.

Ich würde das Intervall hochsetzen, sehr wahrscheinlich verschwinden die Probleme dann. Wenn das höhere Intervall "zu hoch" ist, dann ist Replikation nicht die richtige Lösung.

Gruß, Nils

Moin,

naja, merkst du doch selbst oder? Relevant wäre jetzt, was "früher" war und was sich zwischen "früher" und "jetzt" geändert hat. Das gäbe zumindest Anhaltspunkte, wo das Problem zu suchen wäre.

Gruß, Nils

Moin,

die Änderung der Längenvorgabe greift erst, wenn der Anwender das Kennwort das nächste Mal ändert. Windows weiß nicht, wie lang das aktuelle Kennwort ist, weil es nur einen Hash davon gespeichert hat. 16 Zeichen funktionieren übrigens in der Richtlinie nicht:

https://www.gruppenrichtlinien.de/artikel/active-directory-security-breach-15-zeichen-kennwortrichtlinie-nicht-moeglich/

Den Kennwortablauf zu ändern (bzw. abzuschaffen), wird hingegen sofort wirksam.

Willst du erreichen, dass User auf jeden Fall ein längeres Kennwort setzen, dann schalte "Benutzer muss Kennwort bei der nächsten Anmeldung ändern" ein.

Gruß, Nils

Moin,

naja, dann - intensiv beobachten und prüfen. Ein Weg über die PowerShell wurde dir schon genannt, eine andere Variante wäre fciv, was du bei Microsoft herunterladen kannst.

Wie gesagt, einen Fehler in robocopy würde ich erst mal nicht vermuten, das wird so viel eingesetzt, dass man davon sicher gehört hätte. Ausschließen kann man aber erst mal nix. Deine Überlegungen bezüglich der Komprimierung sind vielleicht gar nicht abwegig, aber das müsste man sicher intensiv strukturiert durch Tests überprüfen.

Gruß, Nils

Moin,

ich halte es auch für unwahrscheinlich, dass das Problem nur bei bestimmten Dateitypen auftritt. Vermutlich bemerkt man es bei den anderen Dateitypen nur nicht.

Wenn solche Probleme allerdings auftreten, sollte man neben einer Methode zum Entdecken auch nach den Ursachen forschen. Da ist möglicherweise irgendwas im VPN nicht okay - oder an anderer Stelle. 

Gruß, Nils

Moin,

Computerkonfigurationen wirken nicht auf Benutzerkonten. Das GPO müsstest du also mit der OU verknüpfen, in der sich das Computerkonto befindet.

Gruß, Nils

Moin,

was steht denn in "...Anmeldung_Optimierung" drin? Meist ist in solchen Fällen das Missverständnis, dass ein GPO Computereinstellungen enthält, aber auf ein Benutzerkonto angewendet werden soll. Das kann dann nicht klappen.

Gruß, Nils

Moin,

vermutlich schon. Da die SIDs aus unterschiedlichen Domänen stammen, wäre aber auch eine temporäre Verbindungsstörung zu diesen Domänen denkbar, daher kann man das von hier aus nicht genauer sagen.

Ihr solltet das auch mal zum Anlass nehmen, eure IT-Security und eure Prozesse kritisch zu betrachten. Ich wüsste etwa gerade nicht, warum auf einem DC Dienste mit Anmeldekonten aus sieben verschiedenen Domänen laufen sollten.

Gruß, Nils

Moin,

das ist ziemlich typisch für Umgebungen, wo der Admin die Bedeutung der Gruppen missverstanden hat. Es gibt tausende Umgebungen, in denen User sich per RDP an den DCs anmelden dürfen, aber nicht an den Terminalservern. 

Wenn du also schon dabei bist - werte auch noch mal die Gruppen unter "Builtin" aus.

[AD-Standardgruppen auswerten | faq-o-matic.net]
https://www.faq-o-matic.net/2014/09/01/ad-standardgruppen-auswerten/

[Windows-Gruppen richtig nutzen | faq-o-matic.net]
https://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/

Hier sind die Standardeinstellungen aus der Default Domain Controllers Policy:

Hm, das sollte eigentlich eine Tabelle sein. Naja, lass ich jetzt so.

Hier noch ein Screenshot der lokalen Default-Einstellung, da die DDCP gar nicht alles enthält:

Gruß, Nils

Moin,

ich verstehe, was du meinst. Und genau daher der Hinweis: Teams ist kein IT-Thema. Es ist ein Organisationsthema. Wir beraten das oft für Kunden, die im ersten Ansatz bei der Einführung gescheitert sind und dann einen neuen Aufschlag suchen. Wenn man es mit der nötigen Einbettung angeht, funktioniert "Teams" viel besser. 

Gruß, Nils

PS. dieses Video illustriert, was ich meine: https://www.youtube.com/watch?v=vWqUp3IyUkY

Moin,

typischerweise wird dafür heute "Self-Service" empfohlen. Das lässt sich dann über Office 365 Groups und über Teams lösen. (Wobei man Teams nicht wegen sowas einführen würde, das ist ein Organisationsprojekt.)

Ist nicht dasselbe, aber ist die typische Antwort. 

DDL werden allgemein skeptisch gesehen, weil bei der Dymamik eben auch viel Unerwünschtes geschehen kann. Manche Kunden bauen sich selbst eine Lösung, indem sie "herkömmliche" Gruppen per Skript pflegen und dabei selbst die Logik festlegen.

Gruß, Nils

Moin,

am Ende heißt der sinnvolle Weg dafür: Nutzungskonzept entwickeln und den Anwendern vermitteln. Das ist vermutlich nicht das, was du hören willst, aber Teams ist nun mal keine Software, sondern ein Organisationswerkzeug.

Gruß, Nils

Moin,

vielleicht solltest du dich mit den Grundlagen des Themas erst mal in Ruhe befassen - nichts für ungut. Deine Fragen deuten darauf hin, dass dir das grundlegende Verständnis fehlt.

Eine Access-Datei ist eine Datenbankdatei. Diese ist darauf ausgerichtet, dass man sie ständig verändert. Es wäre daher sinnlos, eine solche Datei zu signieren, denn die Signatur ist in dem Moment ungültig, wo sich auch nur ein Bit der Datei ändert. Das passt schlicht nicht zu einer Datenbank.

Gruß, Nils

Moin,

vor 8 Stunden schrieb BOfH_666:

Ich bin eher in Umgebungen unterwegs, wo die Anwender sowieso mit "Fat-Clients" unterwegs sind und eine gut funktionierende Softwareverteilung existiert und das Arbeiten vom "Nicht-Firmen-Client" sowieso nicht erlaubt wäre. Deshalb packt die ganze RDS-Geschichte meiner Meinung nach eine riesen Schippe Komplexität oben drauf, die ich für eher nicht erstrebenswert halte. 

dann arbeitest du in einer Umgebung, von der es in der freien Wildbahn nicht viele gibt. Tatsächlich ist es in vielen Umgebungen genau umgekehrt: durch den Einsatz von RDS (mit oder ohne Citrix oben drüber) reduziert man die Komplexität.

Weder das eine noch das andere fällt aber in die Kategorie "one size fits all".

Gruß, Nils

Moin,

willkommen an Board.

Wenn du keinen anderen User hast, mit dem du dich mit ausreichenden Rechten anmelden kannst, dann gibt es keine Möglichkeit. Das ist ja der Sinn so eines Aufbaus. Du müsstest dann also den Server aus einem Backup wiederherstellen.

Der Vollständigkeit halber verweise ich auf die Boardregel Nr. 8, dass wir Angriffe auf Systeme und "vergessene Kennwörter" hier nicht unterstützen und nicht diskutieren.

Gruß, Nils

Moin,

ah, jetzt dämmert's. Du meinst die Standard-Einstellungen im Hyper-V-Manger?

Mit dem Speicherort für Virtuelle Maschinen meint Microsoft den Ort, wo die Konfigurationsdateien der VMs liegen. Das sind wenige Kilobytes und ist für Platz und Performance völlig egal. Relevant sind die VHDX-Dateien - eigentlich ausschließlich diese. Sogar der Speicherort des Host-Betriebssystems ist ziemlich egal, weil auf diese Dateien eher selten zugegriffen wird.

Als Best Practice gilt, dass man alle Dateien einer VM in denselben Ordner speichert. Man legt also, vereinfacht gesagt, auf dem Volume, das die VMs beherbergt, einem Ordner "VM" an und dort einen Ordner pro VM. In diesen kommen alle Dateien, die zu der VM gehören. Das passt für die allermeisten Zwecke.

Gruß, Nils

Moin,

Du verwendest anscheinend die Begriffe nicht korrekt. Leider lässt sich nicht verstehen, was deine Frage ist.

Gruß, Nils

Moin,

Möglicherweise hattest du auch noch nicht bedacht, dass du für einen 2019-Server auch 2019-CALs brauchst. Wenn du jetzt feststellst, dass es auch mit 2012 R2 geht, dann hättest du ja vielleicht eine Menge Geld umsonst ausgegeben.

Gruß, Nils

PS: in einem RZ installiert man selbstverständlich neu. Dort packt man aber auch nicht mehrere Funktionen auf denselben Server.

Moin,

ich würde sowas auch nie per Cloning machen. Neuinstallation ist schnell und risikolos. Die wenigen Parameter, die man in Hyper-V dann noch setzen muss, kann man vorher dokumentieren - mit diesem Skript eine Sache von Minuten.

https://gallery.technet.microsoft.com/Get-HyperVInventory-Create-2c368c50

Gruß, Nils

Moin,

ob du die CA noch brauchst, kannst du recht einfach feststellen, indem du dir ansiehst, ob sie Zertifikate ausgestellt hat, die noch gültig sind. Wenn ja, schaust du dir die Systeme an, auf denen diese verwendet werden.

Solltest du feststellen, dass du noch eine CA brauchst, musst du die alte aber auch nicht migrieren. In den meisten Fällen ist dann der bessere Weg, eine neue PKI ordentlich (!) aufzusetzen und die verwendeten Zertifikate gegen neue von der neuen CA auszutauschen. Oft wird nur migriert, weil man es kann, und dann hat man eine unnötig schlecht eingerichtete PKI.

Gruß, Nils