NilsK

Moin, der Ransomware-Schutz macht ja schon was anderes. Die Idee ist auch nicht schlecht. Vor allem ist die Marketing-Aussage ja, dass die Funktion mit sinnvollen Vorgabewerten arbeite. Das scheint so aber nicht zu stimmen. Gruß, Nils

Moin, OK, danke. Dann schalt ich das erst mal wieder aus. Gruß, Nils

Moin, ah, gut zu wissen. Danke für die Info. Bleiben also "nur" die anderen Anmerkungen. ;) Gruß, Nils

Moin, leider bist du insgesamt auf dem Holzweg ... erst mal in Kürze: Das OS des Host-Systems hat mit den darin laufenden VMs erst mal nichts zu tun. Die kannst du weitgehend unabhängig voneinander betrachten. Exchange 2010 ist mit DCs unter Windows Server 2016 nicht supported. Wenn du 2016-DCs nutzen willst, musst du zuerst das Exchange aktualisieren. Eine AD-Domäne kannst du nicht umbenennen, wenn Exchange dort läuft. In aller Regel ist das aber auch nicht nötig. Eine Umstellung der Hyper-V-Hosts von 2008 R2 auf 2016 ist nur durch Ex- und Import der VMs möglich, richtig. Insgesamt würde ich dir empfehlen, so eine Umstellung nicht nur mit Foren-Support zu machen, sondern einen erfahrenen Dienstleister dazuzuholen. Das ist auch kein Riesenaufwand, aber man kann eben gravierende Fehler machen. Gruß, Nils

Moin, aufgrund der Empfehlung in der letzten c't habe ich mal den Ransomware-Schutz des Windows Defender eingeschaltet. In dem Artikel hieß es, dass das praktikabel sei. Nun habe ich allerdings festgestellt, dass der Ransomware-Schutz offenbar gerade keine praktikablen Voreinstellungen hat. Er hindert praktisch alle Prozesse daran, etwa im Userprofil Änderungen vorzunehmen - darunter auch der Explorer, weswegen nach einem Neustart plötzlich meine Taskleiste leer war. Erst nach expliziter Freigabe der Applikationen funktioniert das. Es scheint mir aber nicht zielführend, jetzt -zig Ausnahmen für den Explorer, Office und alles Weitere vorzunehmen. Eigentlich bin ich deshalb kurz davor, das wieder abzuschalten. Hat da jemand schon nähere Erfahrungen? Gruß, Nils

Moin, bei früheren Windows-Versionen habe ich ab und an beobachtet, dass die Modifikator-Tasten - vor allem Alt und AltGr, aber bisweilen auch Strg - aktiv bleiben, wenn man sie losgelassen hat. Eine Lösung habe ich dafür leider nicht. Mit Windows 10 ist mir das noch nicht passiert. Gruß, Nils

Moin, nein, das wird nicht funktionieren. Es wäre eine separate Domäne, die trotz gleichen Namens mit der ursprünglichen nichts zu tun hätte und andere SIDs verwendete. Vor weiterem technischen Gebastel wäre jetzt notwendig die Frage zu klären, was denn genau in welcher Qualität archiviert werden muss. Das ist ggf. mit einem IT-Fachanwalt zu klären, "Forenwissen" reicht dazu nicht aus. Gruß, Nils

Moin, meines Wissens kann Hyper-V das, denn genau dafür wurde das entwickelt. Konkret umgesetzt habe ich es noch nicht. Um sicher zu gehen, solltest du die Frage also mit Citrix klären, denn die müssten das am Ende ja supporten. (Und ja, auch sowas klärt man vor der Beschaffung in einer frühen Designphase.) Gruß, Nils

Moin, aus meiner Sicht ist jetzt der Zeitpunkt gekommen, an dem du zwei Sorten von Fachleuten hinzuziehen solltest: jemanden, der mit dir bzw. der Geschäftsleitung genau herausarbeitet, was denn da genau archiviert werden muss jemanden, der dir die technischen Hintergründe einer AD-Domäne erläutert und dich dann ggf. dabei unterstützt, den Server wieder in den richtigen Zustand zu bringen Einstweilen ein paar Hinweise: Nur weil du dich an dem Server nicht anmelden kannst, heißt das noch lange nicht, dass man an die Daten nicht herankommt. Auf einem 2003-Server ist mit allergrößter Sicherheit keine Verschlüsselung eingerichtet. Die Festplatte lässt sich also mit ebenso großer Sicherheit auf einem anderen Rechner (bzw. durch Booten von CD oder so) lesen. Deiner Beschreibung nach war der Server evtl. früher ein Domänencontroller. Je nachdem, wie er dann heruntergestuft wurde, ist er nun evtl. nicht mehr Mitglied der Domäne, also kann man sich mit Domänenkonten auch nicht anmelden. Da ein DC überhaupt keine lokalen Anmeldekonten hat, gibt es nun vermutlich nur das lokale Administrator-Konto, dessen Kennwort sich wahrscheinlich von dem des Domänen-Admins unterscheidet. Wenn die Software, um die es geht, Domänenkonten braucht, wird sie nun also auch ohne Weiteres nicht starten. Wahrscheinlich lässt sich das aber umkonfigurieren. Gruß, Nils

Moin, DDA ist dafür ziemlich sicher der falsche Weg, denn darüber weist du die Hardware exklusiv der Kontrolle durch eine VM zu. So ziemlich das Gegenteil von dem, was du willst. Wie Dukel schon sagt, geht es hier um vGPUs innerhalb von RemoteFX: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-remotefx-vgpu Und auch mit seinem Hinweis hat Dukel Recht, das ist im Detail nicht trivial. Man sollte für sowas die Hardware immer erst nach dem Nachweis der Funktion beschaffen. Gruß, Nils

Moin, wenn es wichtig ist und nicht nur eine Testumgebung oder eine Kleinst-Domäne, mach einen Case bei Microsoft auf. Der Fehler ist exotisch und vermutlich "nur mit Internet" nicht mit ausreichender Erfolgsaussicht zu lösen. Gleichzeitig kann er für eine Produktionsumgebung kritisch sein. Gruß, Nils

Moin, mir scheint das ganze auch eher auf Hörensagen und Vermutungen zu beruhen. Warum etwa glaubst du, dedizierte Terminalserver zu brauchen? Vielleicht wäre hier etwas Beratung beim Design der Umgebung sinnvoll, wir sehen es allzu oft, dass aus Basis falscher Annahmen Beschaffungen durchgeführt werden. Gruß, Nils

Moin, wenn du den kostenlosen Hypervisor einsetzt, ist der ja kostenlos. Nähmest du die "Vollversion", so benötigtest du 2016-er Lizenzen in ausreichender Zahl. Die VMs selbst haben keine Lizenzen, lizenziert wird immer der Host (auch im Fall von VMware, KVM usw.). Auch in deinem Szenario lizenzierst du aber nicht die VMs, sondern musst die Windows-Lizenzen dem Host zuweisen. Hier also die 2008-Lizenzen. Ob die schon das Kumulieren von Lizenzen zulassen, weiß ich aus dem Kopf nicht mehr. Was soll denn das werden, eine Produktionsumgebung? Gruß, Nils

Moin, hier geht es anscheinend um Benutzerkonten, nicht um Profile. In der Tat gibt es die Auswahl nur für lokale Konten, wobei das weniger Sicherheitsgründe hat, sondern hauptsächlich darauf zurückzuführen ist, dass es in einer Domäne ja eine Vielzahl von Konten geben kann. Was ist denn die Anforderung hinter der Frage? Gruß, Nils

Moin, im Wesentlichen immer noch aktuell: [Hyper-V und Netzwerke | faq-o-matic.net] https://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Gruß, Nils

Moin, da fehlen doch von vorn bis hinten die Anforderungen. Was sollen denn "seine Daten" sein? In den wenigsten Situationen sind darunter Daten zu verstehen, die in einem Benutzerprofil liegen. Dann ist völlig unklar, warum von verschiedenen Standorten auf "die" Daten zugegriffen werden soll. Ebenso fehlen Aussagen, ob mit "den" Daten dann immer nur ein User arbeitet oder verschiedene - und wo diese sich dann befinden. Das musst du hier jetzt nicht alles offenbaren, aber genau solche Fragen musst du beantworten, wenn du ein passendes Konzept entwickeln willst. Zuerst ist dabei nämlich zu klären, wozu es denn passen soll. Gruß, Nils

Moin, dass "Firmen" pauschal an bestimmten Zertifikaten interessiert seien, ist ein Mythos. Wenn überhaupt, ergibt sich das evtl. aus dem Profil einer bestimmten Stelle, die zu besetzen ist (selten). Oder bei IT-Dienstleistern aus den Anforderungen von Microsofts Partnerprogramm (auch selten). Es gibt aber praktisch nie den Fall, dass jemand "nur" oder "vor allem" wegen bestimmter Zertifikate eingestellt wird. Relevant sind immer Praxiskenntnisse und Persönlichkeit, und über die sagen die Zertifikate nichts aus. Aus meinem Nähkästchen: Den Teil mit den Zertifikaten schaue ich mir bei der Sichtung von Bewerbungen zunächst überhaupt nicht an, das kommt frühestens dann, wenn ich jemanden zum Gespräch einlade. In deinem Fall wäre es also sinnvoll, dass du dich an deinen eigenen Interessen sowie an den Erfordernissen deines Jobs orientierst. Gruß, Nils

Moin, die Frage, ob man mehr als einen DC haben sollte, ist recht identisch mit der Frage, ob es mehr als ca. 10 User in der Domäne gibt. (Es erstaunt mich immer wieder, dass man das heute noch diskutieren muss ...) Gruß, Nils

Moin, *lol* - ich stimme Norbert völlig zu. Gruß, Nils

Moin, eine gute Beratung hätte euch in dem Zusammenhang sicher auch über die üblichen Verfahren beim Code-Signing informiert ... aber geschenkt. Ihr müsst die PKI ja jetzt nicht einstampfen, das Verfahren mit dem Timestamp-Server ist nicht Windows-spezifisch. Ihr müsst halt eure Prozesse für das Code-Signing ändern. Das würde ich tun, bevor ich die bestehenden Probleme weiter bearbeite, weil die ja offenkundig auf den alten, ungünstigen Prozessen beruhen. Ich ergänze trotzdem einen Schuss ins Blaue: Ist auf dem Rechner, von dem aus du den Code signieren willst, der Private Key für das Zertifikat denn vorhanden und für den Useraccount zugänglich? Gruß, Nils PS. für eine Windows-PKI hätte ich dir jetzt ein gutes Buch empfohlen ... ob du für euer Produkt eins findest, weiß ich nicht.

Moin, eigentlich solltet ihr euch zuerst überlegen, was ihr haben wollt und dann eine Lösung dafür suchen. Ob 1, 2 oder 3 für euch geeignet sind, können wir ja gar nicht beurteilen. Am Ende ist ein "Home" ein Ordner wie jeder andere auch, Es liegen bestimmte Berechtigungen drauf, und im Fall eines Homes ist er normalerweise für den betreffenden User gemappt. Ob das Mapping direkt bei der Anmeldung über das AD-Attribut erfolgt oder separat per Skript oder GPO, ist meist egal. Der Vorteil des AD-Attributs ist, dass bei der Anmeldung auch gleich eine Systemvariable gesetzt wird, aber die wertet heute kaum noch jemand aus. Bleiben also die Berechtigungen. In der Praxis stellen viele fest, dass die Berechtigungen, die per ADUC (also über das GUI) automatisch gesetzt werden, so toll doch nicht sind. Es spricht also meist einiges dafür, die Ordner per Skript anzulegen und dabei genau die Berechtigungen zu setzen, die man haben will. Dafür leistet z.B. SetACL von Helge Klein gute Dienste. 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, irgendwie scheint mir immer noch die wesentliche Frage ungeklärt: Was sind denn eigentlich die Anforderungen? Ohne diese Information kann man schlicht keine Abwägung treffen. Gruß, Nils

Moin, damit man Code nicht jedes Mal beim Erneuern des Zertifikats neu signieren muss, setzt man beim Code Signing üblicherweise Timestamp-Server ein. Der Timestamp ist dann Teil der Signatur, damit ist bewiesen, dass die Signatur zum Zeitpunkt des Signierens gültig war, auch wenn das Zertifikat längst abgelaufen ist. Statt also über den Problemen eures (unvollständigen) Ansatzes weiter zu brüten, würde ich die Infrastruktur nach diesem Prinzip neu machen. Warum nutzt du nicht die in Windows integrierte CA? Gruß, Nils

Moin, der Fehlermeldung nach vermute ich, dass du den Verschiebevorgang von 2016 nach 2012 R2 von dem 2016-Server aus versuchst? Dann kann es sein, dass dessen Hyper-V-Manager den 2012 R2 nicht korrekt ansprechen kann. Geht es, wenn du den Vorgang von dem 2012 R2 aus anstößt? Ich bin mir gar nicht sicher, ob ich das mal selbst probiert habe. Grundsätzlich sollte es aber gehen. Weitere Möglichkeiten wären per PowerShell von der einen oder der anderen Seite. Gruß, Nils