NilsK

Moin, wenn du im Hyper-V-Manager die Eigenschaften einer VM öffnest, siehst im Abschnitt der Netzwerkkarte rechts oben den Namen des virtuellen Switches, auf den diese virtuelle Netzwerkkarte verbunden ist. Was steht dort? Taucht derselbe Name auch im Hyper-V-Manager unter "Manager für virtuelle Switches" auf? Falls ja, ist diese virtuelle Netzwerkkarte (also die VM) mit dem betreffenden virtuellen Switch verbunden. In dem Fall geht es an dieser Stelle weiter: Im Manager für virtuelle Switches siehst du in den Eigenschaften des Switches, mit welcher physischen Netzwerkkarte dieser an das Netzwerk angebunden ist. Dort steht allerdings leider nicht der "sprechende" Name, sondern der Gerätename. Um hier Klarheit zu erreichen, brauchst du die Netzwerkübersicht aus der Systemsteuerung. Rufe z.B. über Start-Ausführen auf: C:\Windows\System32\control.exe netconnections In dem Fenster findest du unten rechts ein kleines Icon, mit dem du in die Detailansicht schaltest (Tastatur: Strg-Shift-6). In der Spalte "Gerätename" findet sich dann der gesuchte Name, der bei dem virtuellen Switch auch auftaucht. Hier ist also wichtig, dass im virtuellen Switch die richtige Netzwerkkarte zugewiesen ist, die physisch mit dem gewünschten Netzwerk verbunden ist. Unter Windows 10 hat der "Standardswitch" besondere Bedeutung: Der ist vom System erzeugt und soll VMs einfachen Internetzugriff geben, indem die Internetverbindung des Hosts (also des PCs) dynamisch weitergereicht wird. Dieser Standardswitch weist den verbundenen virtuellen Netzwerkkarten per DHCP passende Adressen zu und übersetzt diese (NAT). In der betreffenden VM muss also die Netzwerkkonfig auf DHCP gestellt sein, keine feste IP-Adresse. Das ist alles leider sehr unübersichtlich und für "Einsteiger" nicht auf Anhieb zu verstehen. Gruß, Nils

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

Moin, nicht verifiziert, aber es scheint einen Registry-Key zu geben, der das für 1803 ermöglicht: https://social.technet.microsoft.com/Forums/en-US/59183715-0c04-44f7-b5ea-bb37da4125a5/unable-to-join-domain-with-new-windows-10-computers-build-1803?forum=win10itpronetworking Gruß, Nils

Moin, was heißt denn "fehlt die Netzwerkverbindung"? Sind die VMs nach dem Upgrade noch mit einem virtuellen Switch verbunden? Wie soll denn die Netzwerkverbindung sein? Eigene vSwitches und dann ins LAN? Oder ist der vordefinierte vSwitch mit der Internetverbindung des "Hosts" in Verwendung? Beschreibe bitte mal die Konfig und die Anforderungen genauer. Gruß, Nils

Moin, OK, dann passt das. Gruß, Nils

Moin, dann hat der Altaro-Support sich vertan bzw. übersehen, dass es hier um den kostenlosen Hypervisor geht. Der hat ganz, ganz, ganz bestimmt kein GUI. Wenn du dafür ein GUI willst, hast du zwei Optionen: Umsteigen auf die Vollversion mit Lizenz Kaufen des 5Nine Managers für Hyper-V Betreibst du eigentlich VMs mit Windows Server auf deinem Host? In dem Fall wärest du entweder falsch lizenziert oder du könntest sowieso die Vollversion auf dem Host einsetzen. Gruß, Nils

Moin, ja, das ist eine Reaktion darauf, dass der Wechsel vorher nicht richtig funktioniert hat. Wenn man nämlich das GUI abgeschaltet hat, wurde es durch Updates nicht mehr korrekt aktualisiert. Beim Versuch, es dann nach einiger Zeit wieder anzuschalten, gab es dann Fehler, angeblich bis hin zum Bluescreen ... Gruß, Nils

Moin, zwei Paar Schuhe. Kostenloser Hyper-V-Server: kein GUI, nur Kommandozeile. Wenn GUI, dann lizenzpflichtiger "vollwertiger" Server. Den "echten" Windows Server kann man auch als Core-Installation einrichten, dann hat er auch kein GUI. Ein solcher Core-Server ist nicht identisch mit dem "kostenlosen" Hyper-V-Server. Nur bei dem lizenzierten Core kann man das aber wieder auf GUI ändern. Zumindest theoretisch, in der Praxis funktioniert das Hin- und Herschalten zwischen GUI und Core nicht zuverlässig. Wenn du sowieso die kostenlose Version nutzt, warum steigst du dann jetzt von 2012 (uralt) auf 2012 R2 (alt) um und nicht gleich auf 2016 (aktuell)? Gruß, Nils

Moin, wie praktisch immer bei Leerzeichen sollten auch hier Anführungsstriche helfen. Fasse also das %%G in dem Do-Zweig mal in Anführungsstriche ein, dann sollte es gehen. Gruß, Nils

<Popcorn hol /> Gruß, Nils ... SCNR ...

Moin, für neue Dokumente kann man den Benutzernamen in den Office-Optionen ändern. Darunter gibt es (zumindest in der aktuellen Version) ein Häkchen, mit dem man Word anweist, diese Werte auch dann zu verwenden, wenn man mit einem anderen Namen an Office 365 angemeldet ist. Word verwendet ab da den "neuen" Namen (also auch bei der Information, wer zuletzt gespeichert hat). Damit sollte sich zumindest eine Vorgabe für die Zukunft umsetzen lassen. Wenn allerdings diese Metainformationen sowieso nicht verwendet werden, dann wäre es evtl. eine sinnvollere Option, diese komplett aus den Dokumenten zu entfernen. Rechtliche Angreifbarkeit sehe ich da nicht, denn es gibt keinen Anspruch, in den Metainformationen eines Dokuments ausgewiesen zu werden. Das müsste im Zweifel aber ein Rechtsanwalt beurteilen. Gruß, Nils

Moin, bitte wärme keine uralten Threads wieder auf! Eröffne einen neuen. @Mods, bitte abtrennen. Inhaltlich: Ein Non-authoritative Restore braucht man eigentlich nie, es ist nur von theoretischem Wert. In der Praxis geht es schneller, einen DC neu zu installieren, sofern noch weitere laufen. [Video-Tutorial: Active Directory Object Recovery | faq-o-matic.net] https://www.faq-o-matic.net/2009/09/07/video-tutorial-active-directory-object-recovery/ Gruß, Nils

Moin, in aller Regel bekommt man das so konfiguriert, dass das AD nutzbar und von da aus ein weiterer Restore möglich ist. Was da genau zu tun ist, ist anhand der vorliegenden Informationen schwer zu beurteilen und möglicherweise für ein Forum zu aufwändig. Bezüglich des DNS etwa kann es durchaus sein, dass eine Art Deadlock vorliegt: Die DNS-Daten stehen im AD, aber das AD kann nicht angesprochen werden, weil DNS keine Antwort gibt. Außerdem kann es natürlich sein, dass die Sicherung einen "Hau" hat. Nicht zuletzt aus solche Gründen empfehle ich immer, vom AD mindestens zwei Sicherungen zu machen, davon eine per Systemstate. Damit hat man im Zweifel eine Sicherung, die auch von Microsoft unterstützt wird. Da es sich um einen Test handelt, würde ich jetzt: eine zusätzliche Sicherung per Systemstate einrichten das AD im "Normalbetrieb" auf korrekte Funktion und Konfig überprüfen die Veeam-Sicherung noch mal genau prüfen ein Recovery-Szenario entwerfen das Recovery mit den neuen, möglicherweise korrigierten Konfigurationen neu testen, mit beiden Methoden (Veeam und Systemstate) Gruß, Nils

Moin, je nach Umgebung kann es eben erforderlich sein, die Konfiguration eines DCs nach dem Recovery anzupassen. Das ist völlig normal. Ein Forest Restore ist ganz gewiss keine Plug-&-Play-Angelegenheit. Nicht umsonst empfiehlt man, die nötigen Schritte regelmäßig zu erproben und zu dokumentieren. Welche das sind, kann wiederum von der Situation abhängen - welche Teile der Umgebung sind wiederhergestellt worden, was funktioniert noch? Da sollte man sich genügend Zeit nehmen. Gruß, Nils

Moin, da widerspreche ich. OEM-Installationen bei Business-Rechnern sind durchaus oft in Ordnung, pauschal würde ich da nicht zum Neumachen raten. Was das Problem angeht: In der Tat sollte eine Deinstallation des Programms helfen. Ergänzend könntest du mal in den Geplanten Aufgaben nachsehen, vermutlich sind da Tasks definiert, die solche Dell-Programme aufrufen. Wenn da nichts ist, kann ein Blick mit Autoruns von Sysinternals (= Microsoft) Aufschluss bringen. Gruß, Nils

Moin, ich habe den TO so verstanden, dass es nur einen DC gibt. Replikationsprobleme können es dann nicht sein. Gruß, Nils

Moin, welche GUIDs haben denn die anderen beiden Varianten? Wahrscheinlich bekommt man das in den Griff, aber ich würde da weder über ein Forum eine Anleitung geben noch es über ein Forum ausprobieren. Dafür ist das Risiko von Missverständnissen zu hoch. Wenn ich was daran täte, dann nur direkt. Daher der Vorschlag, einen Case bei Microsoft zu eröffnen oder sich einen Spezialisten ins Haus zu holen. "Default Naming Context" bzw. die deutsche Übersetzung sind einfach nur andere Begriffe für die Domänen-Partition des AD. Und "hartkodiert" meint, dass die DDP und die DDCP die einzigen Policies sind, die vorinstalliert werden und die immer dieselben GUIDs haben, in jeder Umgebung. Eine echte, harte technische Abhängigkeit gibt es nicht, aber durchaus Prozesse im System, die darauf aufsetzen. https://www.gruppenrichtlinien.de/index.php?id=31&tx_ttnews[tt_news]=162&cHash=2b6b1bfe8644de808622128630a0cb8b Gruß, Nils

Moin, deine Probleme deuten für mich auf Kommunikationsprobleme im Netzwerk oder sowas hin. Ist die DNS-Konfiguration korrekt? Gibt es evtl. Probleme beim Zeitabgleich in der Domäne? Gruß, Nils

Moin, auch eine Einzeldomäne ist immer ein Forest ... Du hast jetzt aber zwei getrennte Forests vor dir. Gruß, Nils

Moin, bitte beschreibe dein Vorgehen noch mal genauer. Was exakt tust du und wann kommt dieser Fehler? Mit was für einen Account bist du in dem Moment selbst angemeldet? Was heißt "Dieser Fehler tritt nicht bei allen Usern auf. Andere User kann ich problemlos hinzufügen."? Du fügst mehrere User im selben Schritt hinzu, einige werden akzeptiert, andere nicht? Du fügst in mehreren Schritten, aber in derselben Session mehrere dieser Vorgänge aus? Du machst das an verschiedenen Rechnern, zu verschiedenen Zeitpunkten, ...? Gruß, Nils

Moin, naja ... wenn die Developer auf Systemebene entwickeln oder Dinge kontrollieren müssen, dann ist es schlicht nicht zu umgehen, dass sie lokale Adminrechte haben. Das heißt aber noch lange nicht, dass sie lokale Adminrechte auf ihrem produktiven Client haben müssen, der sich in der Unternehmensdomäne befindet. Virtualisierung existiert schon eine Weile. Gruß, Nils

Moin, nein, wenn man oft genug auf die Bilder klickt, bekommt man sie irgendwann lesbar. ;) Gruß, Nils

Moin, SharePoint? Wobei das für mich eher nach einer Organisations- und Prozessfrage klingt, die man mit Technik üblicherweise nicht lösen, sondern bestenfalls unterstützen kann. Daher würde ich die Aussage "es reicht eigentlich ..." noch mal hinterfragen und mit den Prozess-Ownern im Detail betrachten. Meist kommt dann doch hier noch was und da noch was, und plötzlich ist die vorhandene Lösung keine mehr, weil das Problem sich verändert hat. Gruß, Nils

Moin, sicher, dass du die "Default Domain Policy" genommen hast und nicht die "Default Domain Controllers Policy"? Mit den Benutzerrechten kenne ich mich im Detail ncht aus, aber zumindest gibt es welche, die man für den jeweiligen Prozess erst aktivieren muss. Vielleicht ist das hier auch so. Ansonsten kann ich dazu jetzt nicht mehr viel beitragen. Gruß, Nils

Moin, naja, das ist eine Anforderung. Als "normalerweise" würde ich das noch lange nicht bezeichnen. ;) Gruß, Nils