NilsK

Moin, aber auch zum Sichern von Dateien geht man nicht so vor. Einen Server herunterfahren, um ihn zu sichern - das habe ich in den Neunzigern das letzte Mal gesehen. Gruß, Nils

Moin, ich gehe davon aus. Innerhalb von Hyper-V hat er dann alle Rechte. Wobei ich das Szenario mit den Nicht-Domänen-VMs gerade nicht nachvollziehen kann. Dass man VMs, die nicht Teil der Domäne sind, nicht über die Integrationsdienste herunterfahren könne, wäre mir jetzt nicht bekannt (wobei ich aber auch nicht ausschließen kann, dass ich das bislang übersehen habe). Andere Ursachen für das Phänomen sind ausgeschlossen, z.B. abgeschaltete Integrationsdienste? Gruß, Nils

Moin, du suchst den Authorization Manager (AzMan). Der ist zwar seit Windows 2012 "deprecated", also "veraltet", aber in Wirklichkeit gibt es noch keinen Ersatz dafür. Sollte dein Host mit Windows 2012 R2 laufen, dann funktioniert dies allerdings nicht mehr - dann gibt es keinen einfachen Weg zu deinem Ziel. Der "Ersatz" wäre SCVMM, was aber in kleinen und mittleren Umgebungen nicht praktikabel ist. Sofern dein Admin innerhalb von Hyper-V alles können soll, ohne gleich Administrator auf dem Host zu sein, kannst du ihn in die lokale Gruppe "Hyper-V Administrators" aufnehmen. Auf keinen Fall sollte man solche Tasks mit Domänen-Admin-Rechten ausführen! Domänen-Admin ist unabhängig vom Thema in 99 Prozent der Fälle die falsche Gruppe. Gruß, Nils

Moin, nicht ganz. Wenn man mit WSB von einem Virtualisierer zu einem anderen konvertiert, muss man die VM im Zielsystem auch neu anlegen. In sofern unterscheidet sich die Methode nicht grundlegend von den anderen. Sie arbeitet aber innerhalb der VMs mit Bordmitteln, und ich habe gute Erfahrungen damit gemacht. Gruß, Nils

Moin, Windows Server Backup. Dazu muss man zwar in der Quell-VM erst eine zusätzliche Platte einbinden (als VHD, dann kann Hyper-V die direkt lesen), aber es funktioniert ganz hervorragend. Gruß, Nils PS. Das Produkt heißt VirtualBox.

Moin, wie seit letzter Woche bekannt ist, kann man für DLLs auch regsvr32.exe einsetzen - ebenso ein legitimes Windows-Binary. Das hat für Angreifer gleich zwei Vorteile: Es akzeptiert beliebige URLs (und kann auch mit Proxies umgehen) und es führt die DLL sofort aus, auch ohne sie wirklich zu registrieren (braucht zum Ausführen also wohl nicht mal Adminrechte). Gruß, Nils

Moin, ihr macht WAS? So sichert man kein AD! Never-ever! Lies das hier und stell noch vor dem Wochenende euer Backup-Verfahren um: [Video-Tutorial: Active Directory Object Recovery | faq-o-matic.net] http://www.faq-o-matic.net/2009/09/07/video-tutorial-active-directory-object-recovery/ Zu den Betriebsmastern ist hier schon alles Wichtige gesagt worden. Gruß, Nils

Moin, ja, das ist immer der letzte Ausweg ... bei meinem Outlook 2016, wo es ein Problem mit einer früher mal eingebundenen Ressourcenmailbox gab, hat das jetzt dazu geführt, dass Outlook Anywhere von draußen gar nicht mehr geht. Outlook halt. Gruß, Nils

Moin, das ist nicht falsch, aber auch nicht richtig richtig. ;) Teaming bringt nicht automatisch "mehr Performance". Das klappt nur, wenn der Traffic tatsächlich über mehrere Netzwerkkarten parallel laufen kann. Nicht für jedes Szenario ist das gegeben. Und selbst dann müsste der Netzwerktraffic erst mal einen Flaschenhals darstellen, damit es sich auswirkt. Bei einem DC wage ich zu behaupten, dass Teaming so gut wie nie "die Performance" verbessert. Hier kann es also nur um Ausfallsicherheit gehen. Gruß. Nils

Moin, ah, OK. Danke für die Info. Gruß, Nils

Moin, grundsätzlich würde man das so hinbekommen - ist aber die Frage, ob man das will. Da falsche IP-Adressen ziemlich viel Ärger verursachen, sollte man sich das gut überlegen. Dein Verfahren sollte funktionieren, wenn die reservierten IP-Adressen innerhalb des Scopes liegen, den der DHCP verteilen darf. Da du den ganzen Scope ausgeschlossen hast, vergibt der DHCP eben gar keine Adressen, auch nicht die reservierten. Mindestens die müssen freigegeben sein. Dass der DHCP-Server selbst eine IP-Adresse innerhalb des zu vergebenden Subnets haben muss, hast du ja schon festgestellt. Das Routing zwischen beiden Subnets ist eingerichtet? Gruß, Nils

Moin, abgesehen von den allgemeinen zutreffenden Anmerkungen gehe ich davon aus, dass es technisch geht. Ist ja aber auch in zehn Minuten grundlegend und in zwei Stunden vollständig getestet. Gruß, Nils

Moin, wie ist die Zuweisung der vCPUs an die VMs? Ist dort evtl. ein ungünstiges Überbuchungsverhältnis von vCPUs zu Cores? Oder hat die betreffende VM zu wenige vCPUs? Ist die Netzwerkkonfiguration evtl. ungünstig, sodass Pakete Umwege nehmen müssen? Gerade bei den Storage- und Clusternetzen sehe ich da oft Fehlkonfigurationen. Sonst würde mir jetzt noch NUMA einfallen. Standardmäßig ist der CPU-übergreifende RAM-Zugriff aktiv, sodass unter gewissen Umständen der RAM-Zugriff langsamer läuft (CPU muss auf RAM einer anderen CPU zugreifen). Vielleicht mal abschalten und erneut testen. Sonst klingelt da momentan nichts bei mir. Gruß, Nils

Moin, das mag in der Theorie stimmen, nur deuten die Phänomene, die wir hier gerade diskutieren, ja ziemlich klar darauf hin, dass es so einfach nun auch wieder nicht ist. Zumal man ein Backup immer vom Restore her bewerten muss, und da kommen die Anforderungen ins Spiel. Hast du geklärt, was du in welchem Szenario in welcher Qualität wiederherstellen können musst? Das ist keine Bauch-, sondern eine Geschäftsentscheidung. Und hast du mal geprüft, ob du diese Wiederherstellungsqualität auch erreichst? Auf jeden Fall solltest du offenbar noch mal sorgfältig rangehen, um die Probleme deiner Lösung zu beheben (und nicht nur zu verstecken). Gruß, Nils

Moin, richtig, nur in der Kombination. In dem Szenario hat man aber sehr wahrscheinlich ohnehin einen (größeren) Teil seiner Daten dort, sodass in Wirklichkeit kein (ernsthaftes) zusätzliches Problem besteht. Im Heimuser-Szenario soll Bitlocker auch nicht gegen Geheimdienste schützen, sondern gegen Hardware-Diebe. Im Fall von Firmen-/Domänenrechnern landet der Key auch nicht auf dem OneDrive. Gruß, Nils

Moin, äh - wie meinen? Woher nimmst du diese Information? Wenn es tatsächlich so wäre, hättest du natürlich eine gravierende Fehlkonfiguration. Die solltest du bereinigen und nicht durch Begrenzung ein weiteres Problem schaffen. Gruß, Nils

Moin, eher nicht. [How to Determine the Size of the System Volume Information Directory • Helge Klein] https://helgeklein.com/blog/2013/01/how-to-determine-the-size-of-the-system-volume-information-directory/ Gruß, Nils

Moin, ich gehe ziemlich sicher davon aus, dass der Ordner System Volume Information derjenige ist, der so groß ist und anwächst. Und ohne ein Experte für Schattenkopien zu sein, gehe ich davon aus, dass das (aus meiner Sicht völlig übertriebene) Überkreuzbackup die Fehlfunktion verursacht. Wenn nur 700 MB Logs sichtbar sind, gibt es auch nur 700 MB Logs. Gruß, Nils

Moin, wenn ich nicht ganz irre, arbeitet DPM doch im Prinzip so wie Windows Server Backup. Kann es sein, dass die besagte Disk (der Größe nach tippe ich mal, dass es sich um eine virtuelle Disk handelt) von Schattenkopien belegt ist? Wohin erfolgt die Sicherung? Bekommst du Meldungen, dass die Disk voll sei? Wenn du eine 70-GB-Disk hast, die mit 70 GB belegt ist, müsste das System ja laut Alarm schlagen. Und warum mehrere Sicherungsmethoden parallel? Kann es sein, dass die sich in die Quere kommen? Was sagt denn das Eventlog außerhalb von Backup/VSS? Gruß, Nils

Moin, was genau willst du damit sagen? Gruß, Nils

Moin, aber danach hast du nicht gefragt ... Exchange 2010 hat kein Problem mit dem 2012-R2-Schema. [Exchange Server-Unterstützbarkeitsmatrix: Exchange 2013 Help] https://technet.microsoft.com/library/ff728623%28v=exchg.150%29.aspx Gruß, Nils

Moin, das ist sozusagen die andere Richtung: Welchen AD-Level (nota bene: Level, nicht Schema) brauche ich, um Windows 2012 zu betreiben. Die Frage war ja, ob ein 2003-Server mit einem AD-Schema 2012 R2 funktioniert. Und das wird er mit großer Sicherheit tun. Gruß, Nils

Moin, das Schema als solches stellt weder für Server noch für Clients noch für Applikationen ein Hindernis dar - einzige bekannte Ausnahme ist Exchange, das in bestimmten Konstellationen von alter Exchange-Version und neuem Schema Probleme haben kann. Gruß, Nils

Moin, sagen wir es so: Microsoft macht da bezüglich der Begriffe sein eigenes Ding, die Ansätze sind aber praktisch dieselben. Oder genauer: Vor zehn Jahren, als Microsoft das MOF an den Start gebracht hat, war das so. Meines Wissens ist das nie wirklich weiterentwickelt worden. Gruß, Nils

Moin, ja, das kann man schon als allgemeine Empfehlung betrachten. Hypervisoren (nicht nur Hyper-V) kommen mit CPU-Spareinstellungen (leider) oft nicht richtig klar. Komischerweise nicht immer, aber das merkt man dummerweise erst, wenn es schon Probleme verursacht hat. Wichtig, wie zuletzt hier ja auch diskutiert: Nicht nur in Windows einstellen, sondern auch auf BIOS-Ebene. Gruß, Nils