NilsK

Moin, kann man grundsätzlich so machen. Allerdings ist "die Datensicherung wird einfacher" immer eine heikle Angelegenheit. Da sind stets die Applikationen zu prüfen, ob die Vollsicherung einer VM wirklich ein sinnvolles Vorgehen ist. Dabei sind vor allem die Optionen zur Wiederherstellung relevant - es gibt je nach Applikation Situationen, in denen eine Wiederherstellung mit anderen Mechanismen erforderlich sein kann (beispielsweise nach versehentlichen Änderungen in einem Teilbestand der Daten). Muss man mehrere Applikationen auf einen historischen Stand zurücksetzen (weil man eben nur die ganze VM gesichert hat), obwohl das nur für eine erforderlich wäre, kann das problematisch sein. Eine VM, die man nach Azure gesichert hat, kann man i.d.R. auch direkt in Azure wiederherstellen und starten. Dabei ist aber nicht gesagt, dass die Anwender dann direkt darauf zugreifen können, sie liegt dann ja eben nicht im LAN. Gruß, Nils

Moin, ich gehe davon aus, dass du mit dem genannten Update die Client-Komponenten aktualisiert hast. Das ist dann genau das, was angefordert war und was du erreichen wolltest. Es handelt sich bei den Servern nicht um SQL Server, sondern um Systeme, auf denen Client-Komponenten laufen. Anscheinend gilt für diese Client-Komponenten dasselbe Service Pack wie für den Server. Allgemein kannst du davon ausgehen, dass die Installationsprogramme solcher Service Packs ausreichend Logik mitbringen, um nur das zu aktualisieren, was auch bereits vorhanden ist.* Es ist ziemlich sicher nicht der sinnvollste und effizienteste Weg, um die Client-Software zu aktualisieren (was man ja auch an den unnötigen Einträgen unter Programs and Features sieht), aber es sollte kein Schaden entstanden sein. Unabhängig davon, würde ich euch dringend empfehlen, eure Prozesse zu überprüfen. Solche Handlungsunsicherheit ist bei zentralen Systemen wie SAP nicht gut. * wer jetzt darauf hinweist, dass Exchange-Service-Packs auch zur Vollinstallation dienen: Das ist richtig, aber dann läuft ja auch ein ganzes Setup durch. Die Neuinstallation geschieht dann nicht einfach so. Gruß, Nils

Moin, manche Product Keys funktionieren nur mit bestimmten Produkt-ISOs. Da dein Key wahrscheinlich ein Volumenlizenzkey ist, hast du vermutlich ein ISO von einer Retail-Version von Windows Server. Nimm ein Volume-ISO, damit sollte es klappen. Gruß, Nils

Moin, auch das kann bzw. muss dir der Hersteller der Applikation beantworten. Es ist sehr wahrscheinlich, aber nicht automatisch so. (Google etwa hat jahrelang SAML nur mit einem Teil seiner Apps unterstützt, vielleicht ist das sogar jetzt noch so.) Gruß, Nils

Moin, Ich weiß nicht, was daran noch unklar ist: das musst du alles den Hersteller der Applikation fragen. Wenn kein SAML vorgesehen ist, wirst du das nicht anbinden können. Gruß, Nils

Moin, ob das klappt, hängt von der Applikation ab. Mehr lässt sich auf Basis der Informationen leider nicht dazu sagen. Gruß, Nils

Moin, kurz gesagt: SAML kann man nicht einfach von außen dranflanschen, das muss eine Applikation selbst unterstützen. Die Details deiner Frage habe ich leider nicht verstanden. Gruß, Nils

Moin, ah, OK, danke für das Update. Ist schon ein bisschen her, dass ich mit SQL Server tiefer zu tun hatte. Die TempDB hat auch eine Spezialfunktion, sie ist mit anderen Datenbanken nicht zu vergleichen. Ebenso wie der TO denke ich aber, dass wir hier jetzt Nebenfragen diskutieren, die mit dem Problem nichts zu tun haben. Gruß, Nils

Moin, nö. Die ndf-Dateien gehören immer zu einer mdf. Gibt es also eine mdf und mehrere ndf, ist das zusammen eine Datenbank. Mit den CPUs hat das auch nichts zu tun (zumindest nicht bei normalen Datenbanken), weil eine Tabelle immer in genau einer Datei liegt (Ausnahme sind ggf. partitionierte Tabellen) und ausdrücklich zugewiesen wird. Möglicherweise gibt es da aber Besonderheiten bei der TempDB. Gruß, Nils

Moin, dann ist es ja OK. Ich schrieb ja auch "enge Grenzen", die hältst du offenbar ein. Es war aber nicht klar, ob wir hier von produktiver Nutzung sprechen, und wir haben am Board eine Grundregel, dass wir Lizenzverstöße nicht unterstützen, daher fragen wir bei Grenzfällen schon mal nach. Gruß, Nils

Moin, wieso läuft der SQL Server überhaupt unter einem Client-Betriebssystem? Du weißt, dass das nur in sehr engen Grenzen lizenzrechtlich zulässig ist? Gruß, Nils

Moin, Die Anmeldung ist in Windows ein einmaliger Vorgang. Es besteht keine dauerhafte Verbindung zum Anmeldeserver. Gruß, Nils

Moin, Hätte man nur eine einzige Kopie der Daten, würde man diese zu reparieren versuchen. Du hast aber drei, also wirf die kaputte weg und lass eine neue dritte automatisch erzeugen. Das ist einer der Gründe für das Redundanzkonzept des AD. Gruß, Nils

Moin, Schalt den DC ab, entferne ihn aus den AD und richte einen neuen ein. Gruß, Nils

Moin, Ich nehme an, dem TO geht es darum, dass beim Druck nicht versehentlich -zig teure Farbdrucke entstehen, nur weil die Vorlage einen farbigen Rand hat. Gruß, Nils

Moin, Gut, dann sind es vier VMs. Da die Standard Edition jeweils zwei Windows-Server-VMs enthält, brauchst du für den Host zwei Lizenz-Sets Standard. Ein Set hat minimal 16 Cores, also acht Core-Pakete. Macht hier 16 Core-Pakete. Kommen eine fünfte und sechste Windows-Server-VM hinzu, wird ein weiteres Set fällig, das sind dann in Summe 24 Pakete, dann ist Schluss. Die Datacenter-Edition, die unbegrenzt viele VMs enthält, ist nicht im Katalog enthalten. Gruß, Nils

Moin, Das sind fünf VMs. Sofern du mit Standard-Lizenzen arbeitest, braucht dein Host also drei Sets davon. Damit wäre das Kontingent aufgebraucht, das dir zur Verfügung steht. Gruß, Nils

Moin, nein, du missverstehst mich. wenn du den Explorer manuell über den TM abschießt, startet er sich nicht selbst neu. Stürzt er hingegen ab (wie gesagt, das kann an "Plugins" liegen), dann startet Windows ihn meist selbst neu. Man sieht das daran, dass die Taskleiste kurz verschwindet und dann wieder auftaucht. Sowas kann auch beim Absturz des Videotreibers passieren, was gar nicht so selten ist. eine neu aufgebaute Taskleiste ordnet dann die Vorschaufenster neu an. Andere Fenster, auch andere Explorer-Fenster, sind nicht davon betroffen. Das muss jetzt bei deinen Usern nicht so der Fall sein. Ohne Prüfung würde ich das aber nicht ausschließen. Und, wie gesagt, im Normalbetrieb ordnen sich die Vorschaufenster nicht neu an, und sie lassen sich auch nicht verschieben. Gruß, Nils

Moin, ohne die Dinge verkomplizieren zu wollen - dieser Tipp passt nicht zu dem beschriebenen Problem. Man kann die Icons auf der Taskleiste mit gedrückter Maustaste anders anordnen. Die Vorschaufenster bei gruppierten Icons kann man aber nicht manuell verschieben. Ziehen mit der Maus hat dort keinen Effekt. Eine Idee dazu: Beobachten bzw. abfragen, wann bzw. wie oft dieses Umordnen auftritt. Vielleicht stürzt bei den Anwendern ja z.B. zwischendurch der Explorer ab (was z.B. durch Shell-Integrationen minderer Qualität passieren kann) und nach dem automatischen Neustart ordnet Windows dann die Previews anders an. EDIT: Ich hab das gerade mal simuliert, indem ich den Explorer per Task Manager abgeschossen und neu gestartet habe. Hinterher sind die Preview-Fenster (in dem Fall auch von Excel) tatsächlich anders angeordnet. Vorher: A - B- C. Hinterher: C - B - A. Gruß, Nils

Moin, man verwechsle die Support-Statements nicht mit einer "Kompatibilitätsliste" und deute vor allem keine Aussage à la "läuft in jedem Szenario bestens" dort hinein. Die Supportliste heißt: Grundsätzlich gewährt Microsoft für diese Kombination Unterstützung bei Problemen. Die Abgrenzung ist: Steht ein System nicht auf der Supportliste, dann wird Microsoft den Support ablehnen, entweder sofort und komplett oder nach kurzer Zeit - egal, ob das konkrete Problem mit dem nicht unterstützten Systemteil zu tun hat. Und "Support" heißt wiederum nicht, dass jedes mögliche Problem aus der Welt zu schaffen wäre. Performanceprobleme sind in komplexen Umgebungen leider immer sehr schwer zu greifen. Man muss abwägen, was der sinnvollere Weg ist - viel Aufwand in die Analyse stecken, um möglicherweise dann den entscheidenden Splitter zu finden, den man ziehen kann. Oder rechtzeitig nach Alternativen suchen. Was du an Beobachtungen anführst, legt in der Tat die Vermutung nahe, dass hier im Gesamtstack irgendwas klemmt. Viel mehr kann man aber nicht sagen, man kann auch keine allgemeinen Aussagen ableiten, ob sich das auf allen ähnlich installierten Systemen so verhalten würde. Untergekommen ist es mir bislang noch nicht, aber das liegt auch daran, dass die Kombination Host 2012 und VM Win10 eher selten ist. Wo ich dir zustimme: Die Blocksize im Dateisystem wird erst in High-Performance-Umgebungen relevant, die in Grenzbereichen laufen. Ungünstige NUMA-Konfiguration könnte hingegen durchaus Auswirkungen haben, und da wäre möglicherweise auch ein Zusammenhang zu Windows 10, das sicher in einer VM anders auf NUMA reagiert als das gut abgehangene Windows 7. Gruß, Nils

Moin, dann sollte der TO erst recht nachfragen. Das lässt sich interpretieren als: Minimal muss er acht solche Pakete nehmen. Da sein Server eine kleine CPU hat, würde das reichen. Nach drei solchen Servern wäre aber Schluss (= 24 Pakete). Ob die Interpretation zutrifft, wäre mit dem Lieferanten zu klären. Gruß, Nils

Moin, interessant ... also, ich würde keine Bestellung auslösen, wenn es noch so viele Unbekannte gibt. Aber bitte. Keine Ahnung, warum alle immer glauben, dass Windows und sein GUI per se solche Ressourcenfresser seien. Zwischen "mit GUI" und "ohne GUI" wirst du in der Praxis keinen Unterschied für die Performance feststellen. Sehr wohl aber in der Bedienbarkeit und Entstörung. Nimm also das GUI dazu, lizenzieren musst du es ohnehin (selbst dann, wenn du ESXi nimmst). Sicher, dass du da nicht was verwechselt hast? Core-Lizenzen gibt es nur in gerader Zahl. Sprichst du hier evtl. von CALs? Davon bräuchtest du ja anscheinend nur zehn laut Eröffnung des Threads. Gruß, Nils

Moin, ein DC sollte immer nur eine Netzwerkkarte haben. Auch kein Team, das braucht man bei einem DC nicht. Für alles Weitere klinke ich mich dann aber aus, die Informationen kommen zu kleckerweise, als dass ich hier noch sinnvolle Antworten geben könnte. Gruß, Nils

Moin, mit "ausführlich" meine ich mehr als drei Zeilen. Und etwas mehr Sorgfalt. Von was für einem DC sprichst du? Ist dein Server ein Domänencontroller und du willst nachträglich Hyper-V dort einrichten? Falls ja, lass das bleiben. Ein DC ist ein DC (und nichts anderes parallel) und ein Hyper-V-Host ist ein Hyper-V-Host (und nichts anderes parallel). Denkbares Design: Den Host neu installieren. Keine Anwendungen oder Serverrollen einrichten. Die vier Netzwerkkarten zu einem Team zusammenfassen. Hyper-V einrichten. In Hyper-V einen virtuellen Switch auf dem Team einrichten. Nur für den Host eine einzelne IP-Adresse einrichten. VMs einrichten, soviele du brauchst. Die virtuellen Netzwerkkarten mit dem virtuellen Switch einrichten. Die IP-Konfiguration für die VMs innerhalb der jeweiligen VM-Betriebssysteme vornehmen. Falls das was Produktives sein soll, vorher ausreichend Kenntnisse aneignen. Deine Angaben und Fragen lassen vermuten, dass du dich noch nicht genug auskennst. Gruß, Nils

Moin, wie kommt ihr beiden auf DC? Davon hat der TO nichts geschrieben. Verstanden habe ich bislang aber auch wenig. @Sylmo, bitte ausführlich, sonst können wir das auch lassen. Gruß, Nils