NilsK

Moin, ich gehe weiter davon aus, dass das NAT das Problem ist. Gruß, Nils

Moin, dass du die Platte schrottest, ist ausgesprochen unwahrscheinlich. Entweder der Key passt - Zugriff auf die Platte. Oder er passt nicht - kein Zugriff. In jedem Fall würde ich dann vor weiteren Änderungen ein Backup der wichtigen Daten machen. @Norbert, kennst du das genaue Vorgehen in dem Fall? Das hatte ich so noch nicht: Verschlüsselte Platte an ein anderes TPM anhängen. Wenn ich dich richtig verstehe, sollte das gehen, aber wie genau? Gruß, Nils

Moin, ja, das ist natürlich korrekt. Sollten die auch nicht vorhanden sein, dann ist die Frage lizenzseitig ohnehin beantwortet, weil man ja nur noch 2016 bekommt. Gruß, Nils

Moin, ich vermute, dass das NAT zu dem Problem beiträgt. Das ist eine Konfiguration, die man lieber meidet. Zu den verschwindenden DNS-Einträgen: Ist das Windows Server 2008 R2? Dann hilft möglicherweise ein Hotfix. In 2008 R2 und Windows 7 gibt es einen Fehler, der nach IP-Konfigurationsänderungen die DNS-Records löscht. Gruß, Nils

Moin, technisch würde ich das als Geschmackssache bezeichnen - es hat sich tatsächlich nichts geändert, jedenfalls nichts Wesentliches. Beim Einsatz von W2016 ist zu beachten, dass man dann auch neue CALs braucht. Gruß, Nils

Moin, du übersiehst dabei, dass ein ordentliches Backup mit der VSS-Schnittstelle arbeitet, um innerhalb der VM die Daten konsistent zu halten. Ein Export tut das nicht. Damit eignet sich der Export nur für abgeschaltete VMs. Ob das wirklich ein sinnvolles Verfahren ist, nur um ein paar Minuten beim Recovery zu sparen, ist für mich fraglich. Gruß, Nils

Moin, das mit dem Export war bis 2012 so. Seit 2012 R2 ist das nciht mehr nötig, weil effektiv nichts anderes passiert als ein Kopieren. Ausnahme wäre ein Export im laufenden Betrieb, was ebenfalls seit 2012 R2 geht. Dabei wäre aber fraglich, ob das für Recovery-Zwecke wirklich geeignet ist. Auch sonst zweifle ich die Eignung eines Exports als Backup grundsätzlich an. Welchen Vorteil versprichst du dir davon? Das Event kann man natürlich auch per PowerShell abfragen und dann bei Bedarf darauf reagieren. Gruß, Nils

Moin, man braucht eine VM gar nicht zu exportieren, wenn man sie später importieren will. Simples Kopieren der abgeschalteten VM reicht aus. Einen wirklichen Export benötigt man nur in wenigen Ausnahmesituationen. Als Ersatz für ein Backup würde ich es nicht nutzen. Daher braucht man eigentlich auch keine Automatisierung. EIne Erfolgsprüfung ist im Prozess nicht vorgesehen. Wenn der Exportvorgang abbricht, bekommt man eine Fehlermeldung. Danach ist es wie bei jeder Kopie: Man müsste diese mit dem Original vergleichen oder importieren und starten. Kann man machen, ist aber die Frage nach dem Sinn des Ganzen. Gruß, Nils

Moin, meine Güte, sind wir uns wieder einig! :D Was war noch mal das Thema ...? :cool: Gruß, Nils

Moin, wovon auch immer du redest ... Gruß, Nils

Moin, mehrere deiner Punkte liegen nicht an EFS, sondern sind dem Prinzip der Verschlüsselung immanent oder liegen in der Arbeitsweise der Anwendungen begründet. Was du mit den Zertifikaten und den Profilen aussagen willst, ist mir absolut schleierhaft. Es gibt Alternativen am Markt, aber nicht viele. Da hat EFS schon seine Vorteile, weil es Teil des Betriebssystems ist. Nachteile haben die anderen auch - ich habe schon mehrere Evaluationen für Kunden gemacht, aber tatsächlich hat keine der anderen Lösungen die (teils unrealistischen) Vorstellungen der Kunden getroffen. Daher keine Produktempfehlung von mir, sondern eben nur der Hinweis darauf, dass es bei jeder Lösung Nachteile gibt. Empfehlung: Überlegt euch, welches Nutzungsszenario für euch wirklich wichtig ist und sucht euch genau dafür eine Speziallösung. Ein Produkt, das "alles" kann, gibt es nicht. Gruß, Nils

Moin, prima, danke für die Rückmeldung! Gruß, Nils

Moin, interessant wäre ja eher, was dich denn stört an EFS. Sonst würde ich zu EFS raten. :D Gruß, Nils

Moin, es ist angekündigt, dass es in einer der nächsten Versionen abgeschaltet sein wird. Microsoft richtet sich auch schon auf den Sturm der Entrüstung ein, der dann kommen wird. ... und ... Mir ist bekannt, dass es solche Haltungen bzw. Vorgaben gibt. Die beruhen aber eben praktisch nie auf belastbaren Hintergründen sondern fast immer nur auf Vorurteilen. Dass es tatsächlich Ausschlüsse gibt, weil bestimmte Systeme mit bestimmten Updates nicht laufen würden, sind sehr wenige Einzelfälle. Man würde ja aber nicht darauf verzichten, am Wochenende Brötchen zu kaufen, bloß weil man die Sorte mit Kümmel nicht mag. Gruß, Nils

Moin, MSP RMM von Solarwinds (ehemals GFI Max) zielt auf genau dein Szenario. Gruß, Nils

Moin, wenn du mit "Partition" eine separate VHDX meinst, bin ich einverstanden. :D Gruß, Nils

Moin, das wird immer wieder behauptet, trifft aber nur in seltenen Einzelfällen zu. Gruß, Nils

Moin, ... und bei der Gelegenheit verschiebst du die Logs auf ein anderes Laufwerk und hast künftig das Problem nicht mehr. Besser an der richtigen Stelle ansetzen, statt halbgare Workarounds zu probieren. Gruß, Nils

Moin, das ist Verlaufsform II. Gruß, Nils

Moin, Konjunktiv III, der "IT-Irrealis": Sollte man machen. Müsste funktionieren. Normalerweise geht das. Gruß, Nils

Moin, was steuerst du denn da per GPO? Vielleicht liegt da der Knackpunkt. Gruß, Nils

Moin, ich glaube, das mit SMB 2.0 ist ein Missverständnis. Die Verbreitung im Netzwerk geht, soweit ich es verstanden habe, über Lücken in SMB 1.0. Deshalb hacken ja alle so darauf rum, dass die Verbreitung vor allem auf Nachlässigkeiten zurückzuführen ist. Über den initialen Einfallsweg hat man wohl noch keine Klarheit und vermutet, dass es klassisch E-Mail ist. Gruß, Nils

Moin, okay. Du sprichst also anscheinend von der Windows Integrated Authentication für interne Webseiten. Die funktioniert bei mir unter 1703 genauso wie vorher. Mit Edge, IE, Chrome und Firefox. Was hat sich auf dem Rechner noch geändert? Gruß, Nils

Moin, "ohne gültiges Zertifikat" sollte hoffentlich gar keine Anmeldung möglich sein. Erklärst du bitte noch mal genauer, worum es geht? Gruß, Nils

Moin, vermutlich wird die Unklarheit auch noch dadurch verstärkt, dass das Ding sich so schnell verbreitet hat. Dadurch entpuppen sich manche Aussagen dann als Schnellschüsse, die so nicht zutreffen. Gestern Abend etwa erhielt ich von einem unserer Security-Herstellerpartner eine Marketingmail zum Thema, die die Ursache bei "bekannten Lücken in SMBv2" verortete ... Gruß, Nils