DocData

Du kannst selbstverständlich per GPO, unabhängig von den Policy Files für Horizon, steuern, dass die Profile beim Abmelden gelöscht werden sollen. Da ich selber einige Horizon Projekte gemacht habe lass dir gesagt sein: Dein Projekt wird scheitern. Hol dir externe Unterstützung. Gerade Windows 10 und Horizon ist anspruchsvoll.

Welche Version von Horizon View? Welche Version von Windows 10? Welcher Build von Windows 10? Was für einen Pool-Typ setzt du ein?

Das habe ich mir gedacht. Dann muss das wohl so sein und du kannst den EVC Mode einfach hochziehen. Wie bereits erwähnt musst du die VMs aber einem Power Cycle unterziehen.

EVC ist nur dann sinnvoll, wenn man dauerhaft Hosts mit unterschiedlichne CPU Generationen betreiben will. Für so Migrationszenarien ist der EVC Mode schlicht nicht notwendig. Deine VMs haben jetzt Sandy Bridge gesehen und lassen sich problemlos auf alles was gleich Sandy Bridge oder höherwertig ist. Selbst zurück geht, solange die VMs nicht auf einem neuen Host aus- und wieder eingeschaltet wurden. Insofern: EVC einfach aus, VMs rüberschieben und bei Zeiten mal aus- und wieder einschalten.

Seht mal zu, dass ihr auf Blast wechselt, statt PCoIP zu optimieren. Blast nutzt H264, was heute jeder Toaster kann.

Köar gibt es einen guten Grund: Aufwand und Nutzen. Und: Legacy-Zeug, dass aus Gründen (tm) enthalten ist und keiner mehr Anpacken will.

Datenschutzrechtlich problematisch und auch hinsichtlich minimal notwendiger Rechte für Administratoren fragwürdig.

Seit wann braucht ein „Backup-Konto“ Rechte auf Benutzerordner? Für sowas gibt es seit JAHREN APIs.

Welches Problem hast du mit IPv6? Es löst Probleme, die mich bei IPv4 zum Wahnsinn treiben.

Zwei ESXi Hosts? Werden es mehr? Wenn es nicht mehr als vier werden: MSA 2052 mit 12G SAS. Robust und billig.

Das sehe ich anders. Aber deine Argumentation habe ich oft gehört, insbesondere von Leuten ohne Hochschul- bzw. Universitätsabschluss.

Ist immer toll, wenn „Partner“ so Gerüchte streuen.

Mutwillige Beschädigung mit einem scharfen Gegenstand. Ziemlich eindeutig.

Das stimmt nicht. Dein Partner erzählt Blödsinn.

Det Trend geht nicht in Richtung HC. DataCore hätte das sicher gerne... Ich hatte schon alles mögliche als Backend... viel FC, mittlerweile häufig SAS, selten iSCSI. Oft HPE, HDS, seltener Fujitsu oder IBM. Oder halt No-Name Zeug.

Wie soll es da aussehen? Was interessiert dich da genau?

Generell. Mir fällt kein Use Case ein, wo dedizierte VoIP Infrastruktur notwendig wäre.

Nö, warum sollten sie das auch tun? SSV juckt das nicht, am Ende determiniert das OS die maximale Größe. DataCore SSV läuft einfach. Wann immer ich in einer Umgebung Ärger hatte war das Backend das Problem. Ist halt kostspielig und seitdem viele Speichersysteme ordentlichen Failover können, werden es bei mit weniger Installationen. Es gibt übrigens einen Use Case der bei mir nie Anwendung fand, den DataCore aber immer gerne gesehen hätte: Die Weiternutzung von „altem“ oder „lahmen“ Storage. Wann immer ich DataCore implementiert habe kam neues Equipment im Backend zum Einsatz. In der letzten Zeit habe ich viele DataCore > 3PAR Migrationen.

Dedizierte physikalische Infrastruktur ist Nonsens. VLAN und fertig. Starface... so, so. Kunde ist damit gerade Baden gegangen. Zwei Starface-Partner haben es nicht hinbekommen den Kram binnen eines Jahres stabil (500 Endgeräte) and Fliegen zu bekommen.

Ziemlich einfach: Blödsinn. Totaler Blödsinn.

Ja, ich.

Das mit der N-Serie war gut!

Und ich bleibe bei der 3PAR mit Peer Persistence.

Oh nice, mit Tape Silo dahinter? Hatten wir damals am Institut als Datengrab für uns HPC Leute... Sehr geil!

Genau, seit cDot! Mit dem Ergebnis, dass 7-Mode Kunden mit einem stretched Metro Cluster (die Mehrzahl der MC Kunden) keinen Upgrade-Pfad ohne Investitionen hatten. Und jetzt? Jetzt gibt‘s wieder das zwei Knoten stretched Metro Cluster mit cDot, wieder mit oben genannten Nachteil. Machen wir uns nix vor: NetApp ist nir noch Flickwerk. Ganz gruselig.