NilsK

Moin, dabei geht es um NUMA. Nicht um die Unterscheidung von CPUs und Cores, eine solche hat Hyper-V nicht. Gruß, Nils

Moin, das ist in der Tat nicht eindeutig. Tatsächliche Aufklärung kann hier nur der Lizenzgeber leisten, alles andere ist Spekulation. Etwas unterhalb der Stelle, die du zitiert hast, heißt es: Man könnte das evtl. als Konkretisierung auffassen. Dann könnte evtl. der Einsatz zum Testen kommerziell entwickelter Software erlaubt sein. Da sich die VMs auch im Developer-Bereich befinden und das ganze Programm, zu dem sie gehören, auf Developer-Unterstützung zielt, liegt zumindest die Vermutung nahe, dass sie zum Testen (auch kommerzieller) Software einsetzbar sind. Tatsächlich aber, wie gesagt, würde nur Microsoft das beantworten können. Gruß, Nils

Moin, glaub ich nicht. Wie kommst du darauf? Und was meinst du überhaupt mit "Socket"? Das ist ein Begriff, der in Hyper-V gar nicht auftaucht. Gruß, Nils

Moin, hm, ich glaube, das ist was anderes. Bleibt aber die Frage, was der TO denn eigentlich erreichen möchte. Gruß, Nils

Moin, nur um es erwähnt zu haben: Ich halte es für höchst bedenklich, kommerzielle Software aus nicht autorisierten Quellen herunterzuladen. Da ändert es auch nichts, dass es sich um eine deutsche Uni handelt. Neben Sicherheitsfragen ist das auch lizenzrechtlich problematisch. Gruß, Nils

Moin, in der Tat lässt sich dein Screenshot praktisch nicht lesen. Ich meine aber erkannt zu haben, dass der Test "Advertising" für DC02 fehlgeschlagen ist. Das kann mehrere Ursachen haben. Eine davon sind verwaiste DC-Objekte. Hattest du vielleicht vorher schon mal versucht, einen DC namens DC02 zu installieren? Bevor wir jetzt lange troubleshooten: Es handelt sich ja vermutlich um eine Testumgebung. Ich würde den DC02 plattmachen und alle Verweise darauf aus dem AD sowie aus DNS löschen. Auch unter "AD-Standorte und -Dienste" löschen. Dann würde ich den Server als DC03 neu installieren (um erneute Namensprobleme zu vermeiden). Sofern die DNS-Einstellungen korrekt sind, sollte es dann funktionieren. Gruß, Nils

Moin, womit der Fall sehr wahrscheinlich gelöst ist. Eine Proxy-Policy ist userbezogen, also wirkt diese Policy vermutlich nur auf Userkonten in der Domäne. Die Einstellung, von der wir die ganze Zeit reden, wirkt sich aber nur auf Computerobjekte aus. Erzeuge also ein GPO, das an die OU mit den Rechnern gebunden ist. Setze dort die diskutierte Einstellung. Starte deinen Rechner neu. Nun sollte sich die Einstellung auswirken. Gruß, Nils

Moin, selbst wenn es technisch ginge, willst du das nicht tun. Wenn sich ein Inplace-Upgrade bei einem Server vermeiden lässt, dann vermeidet man es. Für den DC installierst du eine neue VM mit dem Ziel-OS, stufst den Server zum DC hoch und deinstallierst danach den alten DC. Für Exchange im Prinzip genauso: Installiere eine neue VM mit dem Ziel-OS, installiere dort Exchange in die bestehende Organisation, verschiebe die Mailboxen und Öffentlichen Ordner, passe ggf. Connectoren an. Dann zwei Wochen warten, damit möglichst alle Outlook-Clients sich umkonfigurieren. Dann deinstallierst du den alten Exchange. Gruß, Nils

Moin, ich wiederhole mich gern, daher: Die NTLM-Warnung hat mit deinen Netzlaufwerken nichts zu tun. Und sehr wahrscheinlich liegt dein Problem an der bereits diskutierten Einstellung, und deine Korrekturversuche setzen an der falschen Stelle an. Also, in welcher Gruppenrichtlinie an genau welcher Stelle hast du die Einstellung gesetzt? An welchen Container des AD ist diese Gruppenrichtlinie gebunden, und in welchem Container befindet sich das Computerkonto des hier diskutierten Rechners? Gruß, Nils

Moin, dazu wirst du im Web sehr viel finden. Generell gilt die Aussage: In Ruhe lassen. Das System weiß sehr gut, wie es das handhaben soll. In praktisch allen Situationen passt das auch. Gruß, Nils

Moin, ja, dann bleibt es aber bei der Empfehlung: Fang mit was Einfachem an. Beim Scripting ist es oft so, dass man sich einen groben Plan macht und dann diverse einzelne Fundstücke zusammenfügt. Es ist ja keine Anwendungsentwicklung - für die meisten Scripte reicht CP/M völlig aus (Copy, Paste & Modify). Also etwa: Auswahl als Text anzeigen, den User auswählen lassen Einen Benutzer im AD grundlegend anlegen Das wären zwei Dinge, die du recherchieren und üben kannst. Du findest dazu viele Beispiele im Web. Und dann baust du dir aus den Erkenntnissen ein Skript, das sich dem annähert, was du lösen sollst. Das verfeinerst du dann, bis es fertig ist. Gruß, Nils

Moin, willkommen an Board! Wenn du PowerShell-Neuling bist, solltest du erst mal mit einfachen Dingen anfangen und nicht mit komplexen. Genau wie bei jeder neuen Sache. Ein fertiges Skript werden wir dir nicht liefern, wir können nur Hinweise geben. Zunächst wäre zu kären, was du eigentlich meinst. Benutzer kann man keinen AD-Standorten (Sites) zuweisen. Vermutlich meinst du was anderes. Beschreibe das bitte. Gruß, Nils

Moin, erstmal solltest du dir angewöhnen, vollständige Informationen zu geben. Es ist nicht nachzuvollziehen, was du willst und was du versucht hast. Natürlich kannst du Benutzern aus Domäne A und aus Domäne B über eine Gruppe Zugriff auf einen Share geben, der in einer der Domänen liegt. Voraussetzung ist die Vertrauensstellung zwischen A und B. Du musst dann eine Gruppe bilden, die Benutzer aus beiden Domänen aufnehmen kann und gleichzeitig zur Berechtigungsverwaltung in der Zieldomäne nutzbar ist. Das trifft auf Domänenlokale Gruppen zu: Lege in der Domäne der Ressource (also wo die Freigabe ist) eine DL-Gruppe an und gib ihr die passenden Berechtigungen. In diese DL-Gruppe nimmst du dann die jeweiligen User aus beiden Domänen oder (besser) die passenden Globalen Gruppen aus beiden Domänen auf. Danach ist es dann wichtig, dass die User sich ab- und neu anmelden, damit die geänderten Mitgliedschaften wirksam werden. Gruß, Nils

Moin, die fehlenden Netzlaufwerke haben sehr wahrscheinlich mit der NTLM-Meldung nichts zu tun. Das wird sicher an dem liegen, was lefg oben vermutet. http://www.gruppenrichtlinien.de/artikel/fast-logon-schnelles-anmelden-asynchrones-startverhalten-ehemals-faq-36/ Was die NTLM-Meldung anbelangt: In der Tat gilt NTLM nicht mehr als sicheres Protokoll. Es wirklich loszuwerden, kann aber etwas Aufwand bedeuten, weil es von den (Server-) Anwendungen im Netzwerk abhängt. Sollte man angehen, ist aber nichts für eine schnelle Umsetzung. Gruß, Nils

Moin, nein, ganz bestimmt nicht. Eine Globale Gruppe kann nur Mitglieder aus ihrer eigenen Domäne enthalten. Zuerst bitte klären, was wirklich der Fall ist. Zusätzlich: [Windows-Gruppen richtig nutzen | faq-o-matic.net] http://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/ Gruß, Nils

Moin, möglicherweise liegt da das Problem. Wenn das Programm eine 32-Bit-Anwendung ist, die auf eine nicht erwartete Umgebung (64-Bit-System) trifft, dann kann es zu solchen Phänomenen kommen. Zudem scheint die Software ja, dem Eröffnungspost nach zu urteilen, eine Reihe von Treibern mitzubringen (dort "Schnittstellentreiber" genannt), die dann vermutlich auch in 32-Bit-Implementierung vorliegen. Solche Treiber können auf 64-Bit-Systemen laufen, müssen aber nicht. Und sie können dann eben auch undefinierte Fehler verursachen. In solchen Situationen habe ich durchaus schon erlebt, dass die Deinstallation solcher Komponenten nicht sauber arbeitet und diese Komponenten eben doch noch das System beeinflussen. Darauf würde ich den Hersteller mal ansprechen - oder es selbst verifizieren: Neue 32-Bit-VM mit der neuen Version der Software aufsetzen und sehen, ob die Probleme da auch auftreten. Ziemlich sicher ist es jedenfalls kein Hyper-V-Problem (auch wenn sich sowas in der IT nie vollständig ausschleßen lässt). Gruß, Nils

Moin, du hast genau das Kernproblem von SMTP getroffen. Es ist nun mal ein "Simple"-Protokoll, das noch dazu "uralt" ist und daher kaum Sicherheitsmechanismen hat. Seit Jahren und Jahrzehnten gibt es Bemühungen, das zu ändern, aber die werfen eben immer Kompatibilitätsprobleme auf oder erschweren die Nutzung, daher haben sie sich nicht richtig durchgesetzt. Ja, das ist ärgerlich, aber keineswegs neu. Gruß, Nils

Moin, das klingt deutlich danach, dass die Treiber in der VM das Problem verursachen. Leider habe ich darüber hinaus keine konkreten Hinweise. Eurem Kunden ist bekannt, dass er eine spezielle Lizenz braucht, um ein Desktop-Betriebssystem in einer VM zu betreiben? Eine normale Windows-7-Lizenz reicht dafür nicht aus. Gruß, Nils

Moin, SMTP kennt keine Absenderverifizierung. Daher kann man als Absender eintragen, was man will. Da das natürlich schlecht ist, gibt es verschiedene Ansätze, das "nachträglich" abzusichern, aber die kranken daran, dass sie nicht flächendeckend genutzt werden und bisweilen Kompatibilitätsprobleme aufwerfen. Gruß, Nils

Moin, ja, das ist aber genau der Unterschied, den ich meine. Natürlich macht NetApp Failover, aber sie machen es anders als ein Windows-SoFS - zumindest als ich das letzte Mal genauer recherchiert habe, gab es etwa keine Resilient File Handles, die beim SoFS den größten Teil des Witzes ausmachen. Außerdem fehlen (oder fehlten zumindest "damals") die Clusterfunktionen, die man für Shared-VHDX braucht. In der Summe war das Ergebnis (und das sehe nicht nur ich so), dass SMB 3.0 auf Storage-Geräten durchaus nett ist, aber gerade für das Hyper-V-Szenario einen SoFS nicht ersetzt. Und wenn man schon die entscheidenden Vorteile nicht nutzen kann, dann spricht einiges dafür, das Storage in der Art einzusetzen, wie es ursprünglich gebaut ist. Gruß, Nils

Moin, naja, was soll man zu so einer pauschalen Frage sagen? Denkbar sind zwei Antworten: Ja, pauschal kann das nachteilig sein. Kommt drauf an. Gerade bei einem SQL Server kann die Last sehr unterschiedlich sein. Auch wenn ein ERP im Spiel ist. Hä? Wer empfhiehlt denn sowas? Der Hypervisor greift so gut wie nie auf seine Systemplatte zu, nur beim Booten. Die Disk-Performance möchte man i.d.R. für die VMs haben. Es mag dabei durchaus VMs geben, die mit SATA genug Dampf bekommen, aber in praktisch allen produktiven Umgebungen macht man um SATA für Virtualisierung einen schwungvollen Bogen. Danke. :) Ja, eben. Hab ich doch gesagt, oder? Meinte ich zumindest. Nein, wie Norbert schon sagt, würde ich das bei Hyper-V immer machen. Man muss eben dran denken, und wenn man nicht dran gedacht hat, kann man hinterher abwägen, ob es den Aufwand lohnt, das Volume zu leeren und neu zu formatieren - das war eher mein Punkt. Gruß, Nils

Moin, deshalb schrob ich ja auch, dass du das manuell in den Dialog eintragen musst: COMPUTER\User ... Da es sich um den lokalen Kennwortdialog handelt, vermute ich mal, dass das auch bei installiertem Novell-Client funktioniert. Gruß, Nils

Moin, ich weiß ja nicht, wie du suchst, aber ich habe dies hier gefunden: https://www.petri.com/change_user_password_from_a_remote_computer Ich kann es gerade nicht testen (mangels Standalone-Rechnern, auf denen ich ein Konto habe), aber eigentlich müsste das bei einem moderneren Betriebssystem noch genauso gehen. Bei Windows 10 etwa kann ich im Kennwört-Ändern-Dialog ganz oben die Kobination aus Rechner/Konto bzw. Domäne/Konto manuell bearbeiten. Wenn also der Zielrechner SERVER15 hieße und ich dort ein Konto "Horst" hätte, trüge ich dort ein: SERVER15\Horst. Sieht zumindest so aus, als sollte man das probieren. Gruß, Nils

Moin, he, nun lasst uns nicht noch Verwirrung stiften! ;) GMX und andere haben eine Funktion, mit der ein User automatisiert Mails aus anderen Postfächern (von anderen Providern) abholen und in seine GMX-Mailbox bringen lassen kann. Das kann Exchange nicht, weil es einfach anders positioniert ist. Gruß, Nils

Moin, nur der Windows-SoFS unterstützt alle Vorteile, die Microsoft für SMB 3.0 angibt. Den Implementierungen der Storage-Hersteller fehlen i.d.R. einige Funktionen, etwa beim Failover. Auch die Eignung für Shared-VHDX (kann für Gast-Cluster interessant sein) ist meist nicht gegeben. Anspruchsvolle Features wie TCP Multichannel oder RDMA findet man dort meist auch nicht. Tendenziell würde ich solche Systeme so einsetzen, wie sie vom Design her gedacht sind. Ein klassisches SAN-System kann eben SAN am besten. Gruß, Nils