NilsK

Moin, ich habe keine Umgebung an der Hand, um das auszuprobieren. Der übliche Weg wäre aber, dass du dir mit einem Get-Befehl (vermutlich Get-ADGroup) alle gewünschten Objekte in eine Variable lädst. Die kannst du dann z.B. mit foreach durchgehen und den jeweils gewünschten Wert mit $_.<Eigenschaft> an das Ziel-Cmdlet (also wohl Enable-DistributionGroup) übergeben. Dass das organisatorische Folgen haben kann, ist hier ja schon diskutiert worden. Deine bisherigen Probleme bei der Umsetzung hast du bislang allerdings auch noch nicht beschrieben.Wenn es da zu Fehlern kommt, nenne es bitte genau. Gruß, Nils

Moin, es kann durchaus Sinn ergeben, sich vorher mit den Dingen zu beschäftigen. Die Idee bei RDS ist, dass die Anwendungen auf dem Server laufen, an den Client werden nur die Bildschirminhalte übertragen. Vom Client zum Server gehen die Tastatur- und Mauseingaben. Jeder User hat seine Session auf dem Server. Der Anwender braucht dann nicht mal einen vollwertigen Rechner, sondern es reicht ein Thin Client. Dafür hat man auf dem Server auch nur eine Installation zu pflegen (nicht zehn plus zehn Full-Clients wie in deinem Modell). Ob das zu den Anforderungen passt, kann man dann bewerten, wenn man die kennt. Da du dazu nichts sagen willst, ist für mich hier Schluss. Gruß, Nils

Moin, https://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/ Da steht erst mal alles Wichtige drin ... Gruß, Nils

Moin, welches Abomodell? Meinst du die SA? Ich verstehe immer noch nicht, warum es einzelne VMs sein sollen. Wenn jeder User ohnehin einen PC hat, verdoppelst du damit nur den Aufwand - du musst laufend 20 Maschinen warten statt 10. Erschließt sich mir nicht. Gruß, Nils

Moin, nimm es mir nicht übel, aber das Design ist ... nicht gut. In so einer Umgebung wird ein SQL Server nicht so viel I/O erzeugen, dass er so ein Monster-RAID brauchen würde, schon gar nicht exklusiv. Exchange ist in der Hinsicht unkritisch. Einen SQL Server würde ich nie mit anderen Funktionen kombinieren. Macht also schon drei VMs. Der DC sollte ebenfalls separat sein, macht vier. Ein DC ist für so eine Umgebung zu wenig, macht also entweder fünf VMs oder (besser) einen zusätzlichen kleinen Server als zweiten DC. Exchange niemals per Ex- und Import migrieren, wenn es keinen zwingenden Grund gibt - den gibt es hier offenkundig nicht. Da der Server schon da ist: Mach entweder ein Volume aus den SSDs und pack da alles drauf. Das ist bei weitem schnell genug. Wenn du unbedingt willst, nimm ein RAID-10. Oder mach drei RAID-1 draus, ist aber am Ende wohl nur umständlicher. Was macht ihr eigentlich, wenn der Host mal ausfällt oder Updates braucht? Vielleicht wäre ein wenig externe Beratung vor Projektbeginn eine gute Idee gewesen ... Gruß, Nils

Moin, Wie wäre es, wenn du uns einfach sagtest, was du genau vorhast? Gruß, Nils

Moin, willkommen an Board! Ich bin einigermaßen erstaunt - wer hat denn da das Konzept und das Sizing gemacht? Virtuelle Desktops kann man machen, aber die Technik ist nicht umsonst eher exotisch, weil sie bei näherer Betrachtung nur selten Vorteile bringt. Welches Ziel wird damit denn verfolgt? Dann: 40 Cores?! Was habt ihr mit den VDI-Desktops denn vor? Gerade VDI gilt in aller Regel als Paradebeispiel für sparsame Ressourcennutzung. Rechnerisch hättet ihr vier Cores pro VM quasi exklusiv - wozu sollen die das denn brauchen? Ich wäre sehr erstaunt, wenn man wirklich mehr als, sagen wir, 8 Cores bräuchte. Und selbst damit könnte man einzelnen VMs zwei oder vier virtuelle CPUs geben (wozu auch immer), die werden sie ja nicht alle gleichzeitig zu 100% auslasten. Leider scheint mir, als seien im Zeitalter der Multi-Core-Monster-CPUs die grundlegenden Designregeln virtueller Umgebungen in Vergessenheit geraten. Was die Lizenzierung angeht: Du musst auf dem Server alle Cores lizenzieren. Bleibt es bei 40 Cores, dann musst du in Summe 20 Core-Lizenzpakete haben, weil jedes zwei Cores abdeckt. RDS-Lizenzen brauchst du m.W. nicht, denn RDS wird hier ja gar nicht verwendet. (Obwohl es in vielen VDI-Umgebungen die bessere Wahl wäre.) CALs brauchst du nur dann, wenn weitere Windows-Dienste unter Windows Server 2019 genutzt werden. Wie sieht denn der Rest der Infrastruktur aus? Für die bislang diskutierten "reinen" Client-VMs bräuchtest du keine Server-CALs. Ist aber unwahrscheinlich, dass es dabei bleibt. Windows 10 Pro hingegen wird nicht reichen. Du brauchst eine Lizenzvariante mit Zugriffsrecht auf die virtuelle Instanz. Das heißt entweder Software Assurance für jeden Client oder jeweils eine separate VDA-Lizenz. Alles ohne Gewähr, aber zumindest ist das bisher nach meinem Eindruck eher Käse. Das gilt auch für die Grundidee - wenn ich du wäre, würde ich mich da noch mal eingehend beraten lassen, und zwar nicht vom Disti, sondern von jemandem, der sich mit VDI auskennt. Gruß, Nils

Moin, als "unzulässig" könnte Microsoft es nur bezeichnen, wenn es gegen Lizenzbestimmungen verstößt. "Nicht supported" bedeutet: wenn "sowas" gemacht wird, leistet der Hersteller keine Unterstützung dafür - typischerweise weder für Probleme, die direkt aus "sowas" entstehen (hier etwa: die Replikation funktioniert nicht), meist aber ausgedehnt auf jede Art von Problem, auch wenn sie nur sehr indirekt mit "sowas" zu tun hat (Beispiel: der Mailversand klappt nicht). Wenn man Lust hat, "sowas" dann selbst zu supporten, hält einen Microsoft nicht davon ab. Nur kann man dann eben nicht bei Microsoft anrufen, wenn was klemmt (um vorzubeugen: doch, kann man schon, die werden aber sehr bald das Gespräch beenden). Da ein solcher Zustand für die meisten Unternehmen indiskutabel ist, kommt "nicht supported" schon nah an "unzulässig" heran. Gruß, Nils

Moin, danke fürs Aufdröseln. Es lebe das Overprovisioning ... Gruß, Nils

Moin, "Tiering" meint in diesem Zusammenhang eine Aufteilung der IT-Systeme in Sicherheitszonen (Ebenen oder eben "Tiers" [engl.]). Das wird seit einiger Zeit im AD-Zusammenhang viel diskutiert, weil ein gut gemachtes "Administrative Tiering" viele ausgefeilte Angriffe verhindern oder deren Auswirkungen eindämmen kann. Hier im Board findet man auch ein wenig was unter dem Stichwort "ESAE" dazu. Ob das Tiering für ein anscheinend eher kleineres Unternehmen wie hier diskutiert ein angemessener Ansatz ist, möge der TO selbst beurteilen. Ausgeschlossen ist das nicht, nach meiner Erfahrung ist in Unternehmen dieser Art aber ausgesprochen viel an Grundlagen zu erledigen, bevor man überhaupt in die Nähe eines implementierbaren Tiering-Konzepts kommt. Gruß, Nils

Moin, ein RAID-10 aus SSDs - für zwei VMs? Wow, Geld scheint keine Rolle zu spielen, wie? Die Anforderungen an VM-Storage ergeben sich zu annähernd 100 Prozent aus den Anforderungen der VMs, die darauf laufen. Was sollen die denn tun? Nuklearexplosionen berechnen? Gruß, Nils

Moin, in deiner Frage fehlte das :80, daher frug ich noch mal nach. Allgemein haben unsere Nachfragen meist ihren Sinn. Ein weiterer wenig aufwändiger Test wäre mit Portqry zu machen. Ich denke zwar auch, dass das Setup falsch antwortet, aber vielleicht ist es einen Versuch wert: https://support.microsoft.com/de-de/help/310099/description-of-the-portqry-exe-command-line-utility Gruß, Nils

Moin, und wenn du dich mit einem Browser auf Port 80 verbindest, was geschieht dann? Sonst wäre noch denkbar, dass die Prüfroutine in Lansweeper fehlerhaft ist. Wäre nicht das einzige Programm, das mehrere Ports prüft, einen davon belegt findet und in der Fehlermeldung dann eine falsche Angabe macht. Gruß, Nils

Moin, hmja, schon - was ich meinte, ist: Wenn ich von einem Client aus die Eigenschaften eines Ordners aufrufe und auf die Größe schaue, dann sehe ich dort den Umfang des aktiven Dateisystems. Was an Snapshots dann "im Hintergrund" belegt ist, sehe ich aus dieser Perspektive nicht. (Das ist doch sicher immer noch so, oder? Hab schon lange nicht mehr selbst mit NetApp zu tun.) Dass die technischen Hintergründe komplexer sind und man sich da als Admin auch schon mal verkalkuliert, steht auf einem anderen Blatt. Dafür sind "einfache" Kontrollmechanismen, die vom Client aus laufen, aber eben blind. Der TO scheint aber schon vom Client aus ein unerwartetes Größenwachstum zu sehen (zumindest interpretiere ich die Angaben so). Gruß, Nils

Moin, ich hatte mich im Zusammenhang mit dem Hyper-V-Buch für WS2016 das letzte Mal mit VMGroups befasst - dann nicht mehr, weil mir das alles noch wenig reif vorkam (ähnlich wie ein paar Jahre vorher die Resource Pools, mit denen es dann auch nicht weiterging). Geht man nach dieser Fundstelle, scheint das auch immer noch so zu sein: https://social.technet.microsoft.com/Forums/en-US/5f49e6b8-cb2b-40f4-987a-ebfa9a001f11/hyperv-vmgroups-and-clusters Ich würde daraus folgern, dass das Ganze nicht ernsthaft clusterfähig ist. Gruß, Nils

Moin, die Frage wäre in der Tat, woran der TO das Größenwachstum feststellt. Läge es an Snapshots, würde das bei einem NetApp-System aber auf der Share-Ebene vom Client aus unsichtbar bleiben. Vielleicht klärt der TO ja bei Gelegenheit noch mal dazu auf. Wenn es Dinge sind, die er mit den genannten Programmen identifizieren kann, dann hat das mit großer Sicherheit nichts mit NetApp zu tun. Gruß, Nils

Moin, also ... neu installieren dauert ne halbe Stunde ... just sayin'. Gruß, Nils

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