NilsK

Moin, naja ... aber so unpraktikabel auch nicht. In eurem Szenario ist es sogar sehr simpel: Niemand hat eine Enterprise CAL, also darf niemand die Enterprise-Features nutzen. Unterscheidet sich jetzt nicht wesentlich von den Betrachtungen bei anderen Lizenzen - irgendwann ist es halt einfach sinnvoller, "alle" zu lizenzieren, wenn man bestimmte Funktionen einsetzt. Gruß, Nils

Moin, ihr seid ja so nett wie mein Kardiologe. Bei dem gehe ich auch als "sehr junger Mann" durch. Letzte Woche beim Blond-Konzert war ich sehr deutlich der Älteste, dabei hatten einige sogar ihre Eltern mit (ich hingegen habe niemanden begleitet). "Alter Herr" war eigentlich auch im universitären* Sinne gemeint, aber nach den sehr erfrischenden Reaktionen hier werde ich das wohl öfter mal kontextfremd einstreuen. Gruß, Ni"Jungbrunnen"ls PS. * "universitär" ist mir wichtig, ich meine das ausdrücklich nicht "burschenschaftlich"

Moin, ja, robocopy ist das Tool der Wahl für sowas. Das von Dukel beschriebene Verfahren kriegt man damit sehr gut hin. Außerdem kann robocopy (als eins von wenigen Tools) auch Daten kopieren, auf die der Admin eigentlich gar keine Rechte hat (Schalter /B). Und es hat auch eine Bandbreitensteuerung, ist für das VPN-Szenario also auch gut geeignet. Gruß, Nils

Moin, Das ist ja recherchierbar. Ich stelle das hier mal als Rätsel ein. Gruß, Nils

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, 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