cj_berlin

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

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

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

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. 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. 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. 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.

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.

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

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? Dass die Software wie von Dir gewünscht funktioniert, darauf bestand bei Standardsoftware noch nie ein Anspruch. "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: 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. 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.

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.

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)"

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/

Verifiziere doch erst mal, dass es funktioniert. Start-ManagedFolderAssistant oder bis morgen warten und dann schauen, ob der Tag den Elementen zugewiesen wurde.

Wenn die im KB zitierte Ursache zuträfe (Folder ist Client-Only), hättest Du ja kein Issue, oder?

Moin, Du kannst einen Retention Policy Tag für SyncIssues anlegen und dann mittels Retention Policy die Vorhaltezeit auf ein paar Tage oder Wochen setzen.

Die Anmeldemaske zeigt doch seit Windows 8 nur eine Domäne an? *welche* das ist, dafür gibt es tatsächlich eine Richtlinie. Die ist aber computerbezogen.