NilsK

Moin, was genau meinst du? Cached Credentials, Szenario Notebook? Die laufen meines Wissens nicht ab und werden nur genutzt, wenn kein DC erreichbar ist. Gruß, Nils

Moin, dann aber vermutlich nicht richtig ... oder nicht den richtigen Account. Um was für ein Gerät handelt es sich denn? Aber es geht schon um Unternehmensdaten? Dann sollte die Umsetzung auch Hand und Fuß haben. Gruß, Nils

Moin, wenn das NAS nicht in der Domäne ist, kannst du doch den Service Accounts eines anderen Servers gar keine Berechtigungen geben. Eine Möglichkeit wäre, dass du auf dem NAS einen User anlegst, der genauso heißt und dasselbe Kennwort hat wie der Service Account auf dem SQL Server. Ich halte es aber für fraglich, dass du mit dem Konstrukt glücklich wirst. Eine 30-TB-Datenbank will man nicht per SMB 2 oder gar SMB 1 auf einem NAS ansprechen. Wenn das NAS tatsächlich nur für diesen Zweck da ist, sollte man es als Storage nutzen und per iSCSI anbinden. Bietet das Gerät diese Möglichkeit? Und: Von was für einer Nutzung sprechen wir hier? Ist das was Unternehmenskritisches? Gruß, Nils

Moin, ja, ein Netzwerkkabel wird schon im Spiel sein - aber darum geht es nicht, sondern um das Protokoll, was für den Zugriff verwendet wird. Ich nehme einfach mal an, dass das NAS wie ein NAS angesprochen wird, also wie ein Dateiserver. Das ist dann das Protokoll SMB. Vorsicht aber, manche einfachen NAS verwenden immer noch SMB 1.0, und das ist noch weniger für diese Art des Zugriffs geeignet. Mit "das NAS wird anders genutzt" meine ich, ob es parallel auch noch normale Dateizugriffe darauf gibt. Die erzeugen natürlich zusätzliche Last, was tendenziell den Datenbankzugriff weniger zuverlässig macht. Das würde man bei einer "ernsthaft" produktiv genutzten Datenbank vermeiden wollen. Wenn du die Datenbank also auf diese Weise anbinden willst, dann wählst du im SQL Server Management Studio per Rechtsklick auf den Eintrag "Datenbanken" den Befehl "Anfügen", dann den Button "Hinzufügen" und gibst dann oben den UNC-Pfad zur .mdf-Datei an: \\server\share\ordner\datei.mdf. So sollte die Datenbank sich einbinden lassen. Gruß, Nils

Moin, normalerweise arbeitet SQL Server (wie die meisten Datenbanksysteme) mit Blockstorage, d.h. mit lokalen Platten oder Volumes, die mit einem Blockprotokoll wie Fibre Channel oder iSCSI eingebunden sind. Seit einigen Jahren ist dafür auch ein Zugriff auf SMB-Dateifreigaben möglich (ab SMB 2.0). Da diese Art des Zugriffs aber eine Reihe von Einschränkungen hat, steht das unter gewissen Grenzen. Um eine Datenbank von einer Dateifreigabe einzubinden, muss man diese mit einem UNC-Pfad ansprechen. Per Laufwerksbuchstaben eingebundene "Netzlaufwerke" werden nicht unterstützt, weil diese Einbindung immer benutzerspezifisch ist. Wenn die Datenbank produktiv genutzt werden soll, ist eher davon abzuraten, dass diese auf einem NAS liegt, wenn dieses NAS auch noch anders genutzt wird. Gruß, Nils

Moin, naja, in dem Fall reicht es ja aus, alles nur bedarfsweise zu tun. Sichere die DB als "Full Backup", wenn es relevante Änderungen gab. Indizes optimieren und ähnliche Wartungsdinge dürften überflüssig sein, es sei denn, du willst das Prinzip daran nachvollziehen. Gruß, Nils

Moin, eigentlich ist das kein Workaround, sondern die empfohlene Methode. Man steuert das üblicherweise per GPO, indem man genau das von dir genannte Recht verwaltet. Die Gruppe "Benutzer" hingegen ändert man normalerweise nicht. Sie hat auch gar nicht die Aufgabe, Anmeldeberechtigungen zu vergeben. Gruß, Nils

Moin, verabschiede dich bei Datenbanken von der Denke "das muss man tun". Dafür sind Datenbanken in ihrer Nutzung zu unterschiedlich. Was für Datenbank A unabdingbar ist, kann für Datenbank B sinnlos oder sogar hinderlich sein. Die Index-Fragmentierung kann ein Thema sein, wenn eine Datenbank in großem Umfang verändert wird. Selbst dann sind Pauschalregeln aber (leider) selten zielführend. Wenn dein ERP-Dienstleister gut ist, kann er dir Empfehlungen geben, denn ohne Kenntnis der Applikation sind Optimierungen ein weitgehend aussichtsloses Unterfangen. Gruß, Nils

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