cj_berlin

Doch, aber er ist auf der CD mit drauf.

Hast Du den Host gepatcht? Das ist eines der bekannten Probleme mit 2012 Hyper-V.

Er kann die Installation starten, dort den Schlüssel abgucken und diesen für Instance Upgrade verwenden.

vor 1 Minute schrieb wiit:

 

Bei der Core Lizenzierung bekommt man ja keine Lizenzkeys mehr mit. 

...sondern was?

Wie würde Dein Freund eine lizenzierte Instanz denn beispielsweise neu installieren mit dem, was er bekommen hat?

https://docs.microsoft.com/en-us/windows/release-health/status-windows-10-1809-and-windows-server-2019#2775msgdesc

vor 34 Minuten schrieb Garant:

... für die restlichen Systeme. Aber was heißt das? Nur Server oder auch Clients - vmtl. nur Ersteres, oder?

Kommt darauf an, was Dein Endziel ist. Ich würde schon wissen wollen, zu wem sich meine Clients so per NTLM authentifizieren bzw. versuchen zu authentifizieren.

Moin,

ich fange mal mit 3 an. VDI-Sizing (Terminalserver inklusive) war schon immer eine schwarze Kunst und keine exakte Wissenschaft. Daher ist es extrem wichtig, ein End-to-End-Monitoring zu haben und in der PoC-Phase eine Reserve für schnelle Anpassungen vorzuhalten. Nach der PoC-Phase hat man hoffentlich genug Real Life-Daten gesammelt, dass man die gesamte Umgebung sizen kann. Zwei Dinge jedoch sind, zumindest in meiner Praxis, unverändert gültig:

• Für Front-End-Workloads gilt die Annahme "die meiste Zeit macht die CPU nix" nicht oder zumindest in deutlich geringerem Maße als für Infrastruktur-Server. Daher sollte das Overcommitment Ratio von 5:1 oder so extrem kritisch betrachtet werden. Am Ende hilft nur die Beobachtung der "CPU ready time" (VMware-Terminologie, hat Hyper-V aber auch als Perfmon-Counter). Die besten Umgebungen (aus User-Sicht), die ich persönlich kenne, laufen auf Overcommitment-Werten von 2:1 oder weniger.
• Für Front-End-Workloads ist das RAM-Core-Ratio wichtig. Pi*Daumen sollte es sich zwischen 2 und 12 GB vRAM pro vCPU bewegen, idealerweise zwischen 4 und 8. Wenn man also Programme fährt, die extrem viel RAM brauchen und ein Terminalserver 128GB vRAM haben muss und sie auch auslastet, sollte er nach dieser Berechnung im Idealfall 12-16 vCPUs erhalten, mit den entsprechenden Auswirkungen auf Scheduling, Ready Time usw.

EDIT: Es bleibt natürlich noch die Frage, wieviele vCPUs ein Terminalserver *mindestens* haben sollte, um X User zufriedenstellend zu bedienen. Dies wird extrem davon abhängen, ob dieser Terminalserver a. Zugriff auf GPU hat (im Falle von Hyper-V also derzeit DDA) und b. in einer Version läuft, die von der GPU auch tatsächlich was hat (2016+). Ich würde, falls GPU tatsächlich verwendet wird, den CPU-Bedarf mindestens halbiert sehen. Da das Scheduling zwischen RDS- (oder auch ICA) Sessions auf einem Server anders funktioniert als zwischen VMs, ist es auch hier schwierig, verbindliche Richtwerte theoretisch zu generieren. Mehr als 5 User pro vCPU mit HyperThreading und ohne Grafik wird aber kaum zufriedenstellend möglich sein - und das kann auch nicht beliebig skaliert werden, denn so würdest Du bei einem Server mit 2x16 Cores (also 60 nutzbare htCores oder 120 vCPUs bei 2:1 overcommitment) bei 600 Sessions Packungsdichte auf einem Server landen, und dass dies unrealistisch ist, sollte jedem klar sein  

Wenn Du dich von erfahrenen VDI-Consultants beraten lässt, werden sie ihre Erfahrungen mit Dir teilen. Die User Experience wird aber in jedem Fall im PoC beurteilt werden müssen. /EDIT.

Für Infrastruktur-Workloads muss man schauen, ob sie parallelisieren können und müssen. SQL kann es, wenn aber in den Datenbanken keine Stored Procedures verwendet werden, sondern höchstens mal Views oder Functions, wird der Parallelisierungsgrad nicht so hoch ausfallen. Exchange könnte zwar theoretisch (seit 2013) einen CPU-Thread pro Datenbank zuweisen, aber die Datenbank-Engine lastet die CPU nicht aus, sondern höchstens die Indexing-Engine, und die ist nicht wirklich parallelisierungsfähig und willig. Bei IIS muss man schauen, ob die AppPools so konfiguriert sind, dass sie mehrere Worker spawnen können.

Das Ziel dieser Übung ist es, Server-VMs zu bestimmen, die mehr als 2 vCPUs brauchen können, und dort jeweils die minimale Anzahl zu errechnen, die man wirklich braucht. Alle anderen Windows Server 2012+ VMs kriegen 2 vCPUs zugewiesen. 2008 und Lightweight-Linux-Maschinen (Betonung liegt auf Lightweight) könnten evtl. mit einer vCPU zufriedenstellend bedient werden, in diesem Fall kriegen sie auch nur die eine, bis sie sich beschweren.

Die Logik ist also, sich der benötigten CPU-Anzahl stets von unten anzunähern. Dabei wieder die CPU Ready Time im Blick behalten. Wenn diese nach einer Anpassung von vCPU-Zuweisungen dauerhaft ansteigt, braucht man mehr physische Rechenleistung.

Artikel kann ich keinen beibringen. Alles, was bei @NilsK steht, gilt für den Teil der Planung, der in Excel passiert, nach wie vor. Alle Optimierungen, die die Scheduler im Laufe der Jahre erfahren haben, sind nicht deterministisch, und deren Auswirkung kann nur durch Monitoring in einer konkreten Umgebung bewertet werden.

Bin aber jetzt schon gespannt auf weitere Stimmen, die ihre VDI seit Jahren erfolgreich bei 7:1 Overcommitment und die Infrastruktur-VMs bei 15:1 fahren  

vor 2 Stunden schrieb Sunny61:

 

Da soll mir noch einer erzählen, das ist versehentlich passiert. :)

Bestimmt. Wäre es absichtlich passiert, würde Teams aufgehen... oh, wait... 

vor 1 Stunde schrieb Thomas Maggnussen:

Wie wärs denn sich mal mehr Zeit für ein sicheres OS zu nehmen statt dauernd irgendwelche neuen Features einzubauen die eh keiner braucht? 

Haben sie gemacht. Nannte sich Vista. 10 Jahre Entwicklung, den Kernel in großen Teilen 'from scratch' neu geschrieben. Wollte keiner haben, weil die Sicherheitsfeatures Uralt-Treiber und gewohnte unsichere Arbeitsweisen blockiert haben.

vor 1 Stunde schrieb Thomas Maggnussen:

Aber mir reicht es jetzt. Microsoft Server fliegen jetzt hochkant raus.

Und das, völlig emotionsfrei, ist eine absolut legitime Reaktion. Wenn mehr Firmen sich sowas trauen würden, wäre auch die Qualität besser gesichert.

vor 1 Stunde schrieb Thomas Maggnussen:

Von Linux ist mir überhaupt nichts bis heute bekannt, dass da jemand derart einfach Adminrechte bekommt. DAS wurde von Grund auf anders und sicher kompensiert. Genausowenig hört man da oft was von Apple wo auch irgendwo ein Unix/Linux läuft.

Naja, HeartBleed und Baron Samedit reichen mir.

Und MacOS ist auf der Pwn2Own regelmäßig das OS gewesen, das am schnellsten übernommen werden konnte.

Aber es ist auch völlig egal - Software wird immer von Menschen geschrieben und als solche nicht perfekt.

vor 1 Stunde schrieb Thomas Maggnussen:

Nur wie unfähig ich bin und viel weniger Ahnung hab als ihr selber.

Hat niemand auch nur mit einem Wort behauptet. Wir kennen uns hier, bis auf einige Ausnahmen, nicht persönlich, und ich würde mir nie ein Urteil über Dich und Deine Fähigkeiten anmaßen, bis wir uns tatsächlich kennen. Und auch dann würde ich es nicht öffentlich äußern.

Gesagt wurde lediglich: Ungetestet patchen ist keine gute Praxis (gelinde ausgedrückt). Wenn Du zum ungetestet Patchen in Produktion aus Überzeugung stehst, sagt es etwas über Dich aus. Wenn Du einfach keine Zeit hast und keine Unterstützung kriegst, sagt es etwas über die äußeren Umstände aus, für die Du vielleicht nichts kannst. Und diese etwas aufgeheizte Diskussion ging ja *eigentlich* auch nicht mit Dir, obwohl Du den Thread gestartet hast.

Gerade eben schrieb phatair:

Deine Logik ist ja interessant. Danach kann jeder Hersteller machen was er will und einfach sagen, ist halt so. Bist a Depp

Es ist nicht meine Logik, sondern es steht in dem Vertrag, den man unterschrieben hat. Lies ihn ruhig, ist ganz interessant. Lies auch mal "the software conspiracy" von Mark Minasi, aus dem Jahr 2000 oder 99. Das gab's mal als PDF umsonst, ist jetzt leider wieder weg, oder ich finde es nicht. Auch damals hat Mark gesagt: Der einzige, der was an der Qualität der Software ändern kann, ist der Kunde, indem er sie nicht kauft. Der Hersteller hat kein Incentive, Qualitätssicherung zu machen. Das ist bei Hardware anders - die muss man zurücknehmen und einschmelzen. Software kann man patchen, und wieder patchen, und immer wieder - der Leidtragende ist immer der Kunde. Wenn der sich nicht wehrt, bleibt es für immer so.

Ich hätte auch lieber den Weltfrieden und funktionierende Software.

vor 2 Stunden schrieb Wolke2k4:

Ich habe aktuell 2 Kunden mit RDS und Performanceproblemen. Sind 2 Schulen...

In beiden Fällen Hyper-V Server als Host, hatten vorher 2008R2 RDS drauf, da gab es keine derartigen Probleme. Nun sind es 2019-er Server...

 

Wir sind derzeit noch bei der Ursachensuche.

Das Thema mit Zehntausenden von User-basierten Firewall-Regeln schon bereinigt?

vor 8 Minuten schrieb phatair:

Ähm... diesen Anspruch sollte man an eine Software haben dürfen. Komischerweise schaffen das auch viele Hersteller und MS hat das auch lange Zeit geschafft. 

Ach, komm. Ich mach seit den 90ern mit MS Produkten rum, und die Patchqualität von MSFT war schon immer Gegenstand des lauten Gejammers. Das war mal mehr und mal weniger schlimm. Besser als diesmal war es meistens, aber da liegt die Latte auch nicht besonders hoch. That said, in meinem Dunstkreis hat es kaum jemanden erwischt. Vielleicht haben meine Kunden Server, die eher so sind wie die von Microsoft?

vor 10 Minuten schrieb phatair:

Ich wußte nicht, dass "The SOFTWARE is provided AS-IS." bedeutet, dass die Software bei jedem Update nicht mehr wie gewünscht funktioniert.

Dass die Software wie von Dir gewünscht funktioniert, darauf bestand bei Standardsoftware noch nie ein Anspruch.

vor 11 Minuten schrieb phatair:

Das ist vollkommen an der Realität vorbei argumentiert. 

"Die Realität" musst Du erst mal akzeptieren, dann kommen wir auch zusammen. Du musst nämlich zwischen Schuld und Verantwortung unterscheiden.

In "der Realität" hat Dein Arbeitgeber (in der Annahme, dass Du interne IT bist) zwei Verträge:

1. Mit Microsoft. In dem steht: The software is provided as-is. Er ist diesen Vertrag aus Gründen eingegangen, die Du vermutlich nicht beeinflussen kannst.
2. Mit Dir. In dem steht: Dein Job ist es, die Umgebung am Laufen zu erhalten. Nach bestem Wissen und Gewissen, versteht sich - Du sollst weder zaubern noch hellsehen können. Aber nichtsdestotrotz ist die Lauffähigkeit der Umgebung DEIN Job.

Merkst Du es? DEIN Job. Wie Du das Ergebnis erreichst, ist Dir überlassen. Wenn Dir dafür Mittel fehlen, musst Du das nach oben melden, erst ab dann bist Du entlastet, und es ist der Job der GL. Wenn Du nichts sagst, meint der Arbeitgeber, Du hast es im Griff, und ist um so mehr verwundert, wenn der Kram am Montag steht. Du hast nämlich Deinem Arbeitgeber gar nicht die kaufmännische Entscheidung überlassen, X Tausend ins Testen zu investieren oder ein Risiko einzugehen, sondern Du hast beschlossen, dass das Testen eh an der Realität vorbei ist und man es deswegen gleich lassen kann.

Aber es ist nicht der Job von Microsoft oder auch von irgendeinem anderen Hersteller, dafür zu sorgen, dass Deine Umgebung läuft. Es gibt Ausnahmen: Azure Stack zum Beispiel. Da garantiert Dir Microsoft zusammen mit dem Hardware-Hersteller eine gewisse Verfügbarkeit. Aber da hast Du auch keine administrative Gewalt mehr über die Plattform, auch wenn sie bei Dir on prem steht.

Und man kann es nicht oft genug wiederholen: An der miserablen Qualität der MSFT-Patches gibt es nichts zu diskutieren. Das ist eines Weltkonzerns unwürdig, und wir sind alle sehr enttäuscht. Es steht Dir frei, Deinen Job besser zu machen. Sobald Du die Qualitäts Deines Jobs der Microsoft-Qualität unterordnest, sieht auch Deine Arbeit bescheiden aus.

vor 2 Minuten schrieb phatair:

Admins sind keine beta tester und in einer einigermaßen normalen Windows IT Umgebung sollten solche Fehler nicht passieren, wenn Microsoft seinen Job machen würde. 

Wo steht das denn bitte? Woraus leitet sich bei Dir dieser Anspruch ab? Der "Job" von Microsoft steht in der EULA, der die Admins bei der Installation des Produktes zugestimmt haben. Willst Du den Wortlaut der "Jobdefinition" nochmal hören? Gerne:

The SOFTWARE is provided AS-IS.

Für den Hersteller ist es eine Abwägung: Wenn ich 300 hochqualifizierte Leute mehr einstellen muss, um QA zu verbessern, kostet mich das im Jahr 50 Millionen. Wenn X Kunden zu Linux wechseln, kostet mich das im Jahr Y Millionen. an verlorenem Lizenzumsatz. Wir haben doch freie Marktwirtschaft, oder nicht? Die Theorie ist, der Kunde hat die Wahl  

Der Vergleich mit dem Auto hinkt insofern, als dass der Hersteller das fertige Auto in seiner Gewalt hatte, bevor es an Dich ausgeliefert wurde, und somit eine Qualitätssicherung des gesamten Konstruktes prinzipiell möglich war. Bei Dir ist ja nicht "das Windows" in die Bootschleife gegangen, sondern ein von Dir gebauter und konfigurierter Server mit diesem Windows drauf, der auch noch Teil einer größeren Umgebung ist. Diesen Server als Ganzes hat der Hersteller noch nie gesehen, Und ja, vielleicht haben sie auch krass andere Server. Entzieht sich meiner Kenntnis. Sie sind aber definitiv nicht identisch mit unseren.

Produktionsserver aus Backup zum Testen zurückholen ist ein Ansatz und wird auch bei manchen Firmen praktiziert, um den Preis der "doppelten TB". Natürlich wird es nicht händisch gemacht. Der andere Ansatz ist eine Testumgebung parallel zur Produktion zu betreiben, halt mit weniger Daten drin. Dort wird dann alles Neue zuerst eingespielt und geschaut, ob die Umgebung wieder hochkommt. Da Du in Deiner "Produktion" ja bestimmt Monitoring am Start hast, kannst Du doch maschinell beurteilen, wie der Gesundheitszustand der Umgebung so ist.

Auch ich wünsche mir das mit der Patch-Qualität anders. Aber am Ende des Tages, wenn ich die Umgebung betreiben soll, kann ich nicht Teile dieser Betriebsverantwortung stillschweigend auf die Hersteller auslagern, ohne dass sie wissen, dass sie diese Verantwortung jetzt tragen, und dem zugestimmt haben.

Wir erzählen den Leuten seit 20 Jahren, dass man Patches testen soll, und alle nicken dabei verständnisvoll, tun's aber am Ende nicht oder höchstens als "Smoke-Test". Wer Code - egal ob es eine neue Anwendung oder ein Patch der bestehenden ist - ungetestet in die Produktionsumgebung rauslässt, hat keine Produktionsumgebung, sondern nur eine Testumgebung, die er produktiv benutzt.

Meinst Du, man muss sich die Cloud mit dem Nachtschichten-Kaffee schöntrinken?

So isses. 

Greift das Intranet parallel auf eure Datenbank zu? Lässt sich da vielleicht nachts ein Abzug in eine andere Instanz machen und das Intranet von dort befeuern? Diese Instanz kann man dann CPU- und RAM-technisch beschneiden. Dann ist das Intranet zwar langsam, aber dafür muss die Hauptapplikation nicht leiden.

Da 2022 auch FL 2008 kann, geht es auch ohne Zwischenschritt.

Moin und herzlich Willkommen,

<Disclaimer: Keine verbindliche Rechts- oder Lizenzberatung in einem freien offenen Forum möglich!>

Die Befürchtung ist begründet. Sobald irgendwas auf den zweiten Knoten zugreift, ob lesend oder schreibend, ist er zu lizenzieren.

Ja, das sehe ich auch. Wenn das Update bzw. die Prüfung einmal fertig ist, beruhigt sich das wieder.

Moin,

die Migration auf DFS-R musst Du vor dem dcpromo des neuen DC durchführen, da Server 2016+ kein NTFRS mehr können.

vor 2 Minuten schrieb CoNtAcT2000:

Dann probiere es mal aus. Bei mir hat er ohne das umwandeln in String den distinguished name in extensionAttribute1 geschrieben. Warum auch immer.

Darum: Du versuchst den String so aufzulösen (Kopie von oben):

extensionAttribute1="BisherigerWertAus$User.department"

Das bedeutet für den Parser:

extensionAttribute1="BisherigerWertAus$($User).department"

weil für ihn der Punkt ein Begrenzungszeichen für Variablennamen ist.

Und für ein AD-Objekt löst sich die Variable im String in den distinguishedName auf.

Wenn Du eine Property durch String Expansion verwenden möchtest, musst Du das dem Parser explizit mitteilen:

extensionAttribute1="BisherigerWertAus$($User.department)"

vor 7 Minuten schrieb Marco31:

Wenn's so wäre dann wäre ja noch interessant ob's nur Hyper-V guest DCs betrifft oder auch unter VMware

In meinem Lab hat es von den >20 vorhandenen DCs auf beiden Plattformen keinen einzigen betroffen.

Updates sind raus: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-january-2022-exchange-server-security-updates/ba-p/3050699

Und Domain Controller nicht vergessen: https://dirteam.com/sander/2022/01/11/three-active-directory-vulnerabilities-were-addressed-during-microsofts-january-2022-patch-tuesday/