wznutzer

Darf ich fragen, welcher Key das ist? Gibt es da einen bestimmten Grund? Ich frage, weil ich auch bei Azure VMs mit CPUs außerhalb der 2er Potenzen mieten kann. Grüße und eine schöne Woche

Guten Abend, ein altes Thema. Lange galt die Faustregel man sollte das Pagefile auf das 1,5 fache des RAMs setzen. Man kann aber auch einfach Windows machen lassen. Mich würde interessieren wie Ihr das so macht? Einfach ein Erfahrungsaustausch. Ich meine wenn man einen Hyper-V Host mit 512GB RAM hat oder einen SQL-Server mit 128 GB RAM, macht man doch nicht das 1,5 fache, oder doch? Danke und einen schönen Abend

Ja, ich meinte den reinen KdcProxy der mit einem RDS-Gateway installiert wird. Von mache nicht über mache ich doch, wenn MS das extra dafür baut, bis jetzt wieder mache ich nicht, war so der Gedankengang. Gut, dass Du das auch so siehst. In dem verlinkten Artikel von Steve Syhfus schreibt er auch, dass man sich extern für Angriffe wie dem Kerberoasting aussetzt. Ich lasse das Loch zu. Zwar jetzt etwas OT, aber verwundert war ich, dass ich mit Domäne\Benutzername über den KdcProxy per Kerberos authentifiziert werde und per Name@Domäne üer NTLM. Das ist doch normalerweise andersrum. Ich habe das mehrfach probiert, ist einfach so. RDP zeitgt ja bei Kerberos oben das Schloss an. Danke und schönes Wochenende

Dagegen spricht nichts. Aber mir geht es darum, ob ich den Kerberos-Proxy ohne Nachteile öffnen kann. Da hilft mir ein Zertifikat ja nicht.

Ich will nichts spezielles wie SSO erreichen. Selbst das Zertifikat ist kein Problem. Die User klicken sowieso auf alles. Ich will einfach nur herausfinden was die sicherste Methode für die Veröffentlichung des Gateway ist. Nützlich wäre, wenn sich die User mittels der RDP-Anmeldung ein neues Passwort vergeben könnten. Das ist aber nur ein angenehmer Nebeneffekt. Ich bin davon abgerückt, dass die User die Passwörter oft ändern müssen. Meine erste Überlegung war zwar falsch, weil ja bei NTLM das Passwort auch nicht übertragen wird, aber es ist halt eine URL mehr die erreichbar ist. Mit der URL /KdcProxy ist das Loch größer und dafür muss es dann einen Grund geben.

Genau deswegen bin ich draufgekommen. Internet testweise abgedreht und dann mal in das Firewall-Log geschaut und gesehen was so ein W2K22 alles im Vergleich zu einem W2K12 R2 machen will. Zusammen mit der CPU-Last die ich dann noch gesehen hatte, habe ich nach der Ursache gesucht, das war dann die Telemetrie. Ich hätte das aber gerne komplett weg, auch auf den Systemen die in das Internet kommen müssen wie RDSHs. Wenn man die Telemetrie ausschaltet ist das Log wieder klein. Bei mir ist das halt GData mit deren Cloud-Erkennung. Ich weiß, kann man drüber streiten, ob das sinnvoll ist oder nicht .

Ergänzung: Wenn man sich bei einem RDS-Gateway mit domäne\Benutzername anmeldet, wird Kerberos verwendet, wenn ich den UPN verwende nicht. Unter der Voraussetzung, dass /KdcProxy erreichbar ist. Da bei Kerberos das Passwort nicht über die Leitung geht und der Kerberos Proxy von Microsoft explizit für das RDS-Gateway und Direct-Access gemacht ist, wird das wohl in Ordnung sein das freizugeben.

Nur ein wenig Erfahrungsaustausch und ob irgendein Nebeneffekt, den man nicht gerne haben will, bekannt ist. Ich werde das in Zukunft auf jeden Fall konsequent abdrehen, jedenfalls soweit es die Möglichkeiten zulassen.

Nachtrag: https://www.gruppenrichtlinien.de/artikel/windows-10-telemetrie-und-diagnosedaten-richtig-abschalten

Guten Abend, RDP lässt sich ja prima per RDS Gateway freigeben, wenn man eine passende Lizenz hat funktioniert das auch sehr gut mit der Azure MFA. Ich mache das z. B. mit einem Reverse-Proxy. Da hat man dann die Möglichkeit die URL /KdcProxy freizugeben oder auch nicht. Funktionieren tut beides. Mit Freigabe von /KdcProxy: Kerberos-Authentifizierung Keine Zertifikatsabfrage (RDP-Zertifikat) auch wenn der Client nicht Mitglied der Domäne ist. Passwortänderung geht von einem Client aus der nicht Mitglied der Domäne ist (STRG + ALT + ENTF) Ohne Freigabe von /KdcProxy: NTLM Zertifikatsabfrage des RDP-Zertifikats wenn das nicht zuvor irgendwie verteilt wurde. Passwortänderung nicht möglich, wenn der Client nicht Mitglied der Domäne ist. Ein paar Infos z. B. hier: https://syfuhs.net/kdc-proxy-for-remote-access Da das von Microsoft ja explizit für das RDS-Gateway vorgesehen ist, müsste das kein Problem sein. Aber ist es tatsächlich auch sicher? Ich meine, macht das Freigeben ein Loch auf, das ich ohne diese Freigabe nicht habe? Vielen Dank

Guten Morgen, teilweise verursacht die Telemetrie, auch auf einem Windows Server 2022, doch eine hohe CPU-Last. Auch wenn es nicht unbedingt schlimm ist, hätte ich das gerne weg. Telemetrie ausschalten 1) Taskplaner, Microsoft, Windows, Application Experience ==> Microsoft Compatibility Appraiser -> deaktivieren 2) sc config DiagTrack start= disabled In sconfig steht die Telemetrie dann noch immer auf "Erforderlich" aber auch da kann man das ausschalten. Ob das aber irgendwas zusätzlich bewirkt konnte ich nicht rausfinden. Fragen Sind Nebeneffekte bekannt wenn man das macht? Ich konnte bisher nichts feststellen. Macht Ihr das oder lasst Ihr das? Grüße und Danke

Für alle die hier auch noch am lernen sind, Veeam hat das in gewohnter Qualität beschrieben. https://www.veeam.com/blog/hyperv-set-management-using-powershell.html Lt. meinen Tests ist die Kommunikation der VMs untereinander schneller, wenn diese an so einem vSwitch hängen, als bei einzelnen vSwitchen, somit alles prima. Nach „außen“, also nicht die VMs am vSwitch untereinander“, bleibt einen Ticken langsamer als ohne Teaming 🤷‍♂️.

Es ist nie zu spät etwas nicht zu wissen .

Die meisten hier werden es ohnehin wissen, aber evtl. nicht alle die auf diesen Thread stoßen. Deswegen folgender Hinweis: Wenn bei einer RDP-Bereitstellung Zertifikate einer eigenen Zertifizierungsstelle verwendet werden muss auf die Einhaltung von RFC2818 geachtet werden. Das Zertifikat wird sonst "nur" noch vom Internet-Explorer akzeptiert (lt. meinen Tests jedenfalls). Fehler: ERR_CERT_COMMON_NAME_INVALID Die RFC fordert, dass die Identität nicht mehr durch den CN festgestellt wird, sondern durch einen oder mehrere DNS-Einträge im SAN. https://tools.ietf.org/html/rfc2818 Das HTML5-Control funktioniert mit einem so ausgestellten Zertifikat auch nicht. Grüße

Beides ist richtig. Es sind 4 vSwitche angelegt. 11 VMs sollen auf 3 vSwitche, so wie geschrieben, aufgeteilt werden. Einer davon ist ein Beinchen in einem anderen Netz. *Derzeit* sind 5 VMs drauf die 1 vSwitch nutzen. Somit trat der Fehler mit der einfachen Konfig auf. Danke. Ich fasse zusammen, dass man zwar nicht pro NIC ein vSwitch anlegt, stattdessen lieber ein Team macht, das aber auch nicht zu Fehlern führt. Bei Performance-Problemen sollte man sich aber durchaus VMQ, RSS, LSO usw. anschauen. Aber egal, die Fehler sind weg. Nach einem Restart des LXCC (nicht das OS, das Servermanagement) werden diese Fehler nicht mehr geloggt. Treiber waren natürlich aktuell.

Ja, genau so ist es ja auch. Der eine vSwitch mit dem einen Port wird genutzt. Die anderen sind ungenutzt vorhanden. Mit zwei mache ich jetzt halt testweise mal ein Team und probiere etwas rum, so lerne ich ja was. Aber alle Anleitungen, auch die verlinkte, zu VMQ, RSS gehen ja von einem Teaming aus. Also das was jeder macht. Und unabhängig von meinen Fehler im Log würde ich gerne lernen, ob die Ports der NIC-Teams jeder speziell so konfiguriert wie das oft zu lesen ist. So wie sich das liest ist es ja essentiell wichtig dafür zu sorgen, dass CPU-Kern 0 niemals genutzt wird. Da wir nun beim NIC-Teaming sind. Es gibt Software der NIC-Hersteller um das zu konfigurieren oder ist es inzwischen problemlos das in W2K22 (z. B. im Servermanager) zu machen? Vor langer Zeit W2K12R2 habe ich beim experimentieren mit https://www.cfos.de/en/ping/ping.htm gesehen, dass einzelne vSwitche (einer pro Port ) bessere Laufzeiten hatte als ein Team. Warum auch immer, ich habe keine Erklärung dafür, das auch nur am Rand. Grüße

Weil ich das 1. nicht besser wusste und 2. auf das Teaming verzichten kann. Teaming ist eine Funktion die evtl. Ärger machen kann und darauf verzichte ich, wenn ich das nicht benötige. Um in Deiner Analogie zu bleiben, wäre der separate Switch für jeden PC unnötig und somit würde ich das nicht nutzen, wenn ich noch einen Port zum Patchfeld frei hätte. Habe ich keinen Port frei, nutze ich den Switch und nehme die zusätzliche Fehlerquelle in Kauf, weil es einen Nutzen bringt. Ich nehme mit, dass Teaming (auch wenn man das nicht braucht) als "best practice" angesehen wird. Das habe ich gelernt. Aber was mir noch nicht klar ist, wird VMQ, RSS auch immer speziell konfiguriert und nie "out of the box" genutzt?

Ich habe nicht so eine Umgebung. Am Ende werden da 11 VMs verteilt auf 3 vSwitche drauf laufen und die meiste Zeit würde für den Traffic wahrscheinlich sogar ein vSwitch mit 10GB-Anbindung ausreichen. Alles was ich nicht unbedingt brauche, nutze ich nicht. Was ich nicht nutze kann keinen Fehler verursachen. Das ist die Denke dahinter. Ich habe hier alles etwas kleiner als das was die meisten hier wohl so haben. Das was ich mit Konfiguration von VMQ meine, ist hier gut beschrieben: https://blog.apps.id.au/hyper-v-and-vmqs-mythbusting/ Unabhängig davon, ob das meine Fehler im Log beseitigt, liest sich das so, als ob die Standardkonfiguration eher "bad practice" ist und das immer individuell konfiguriert werden muss. Da würde mich eben interessieren ob Ihr das immer so macht oder nur im Ausnahmefall? Wenn ein NIC-Team Probleme löst, anstatt zu verursachen, mache ich das schon. Edit: Ergänzung, sollte ein separater Post werden, die Forumssoftware hängt das aber an den letzten Post.

Die NIC hat 4 Ports, jeder Port ein vSwitch. Jeder 10GB Port geht auf ein 10 GB Port auf den Switch. Ich verteile die VMs so manuell auf die Ports. Ist das falsch und die Ursache für Ärger? Über eine zusätzliche Intel-NIC (X710). Der Server hat 6x 10GB SFP28 Ports. Nein, über den LXPM von Lenovo installiert. Das ist notwendig, weil sonst Lenovo UpdateXpress nicht alle Treiberaktualisierungen findet. Lenovo oder Microsoft? Habe ich noch nicht gefragt, bin bisher von einer Unwissenheit meinerseits ausgegangen.

Guten Tag, beim Rumspielen mit einem neuen Server ist mir folgendes aufgefallen: W2K22 - alle Updates Lenovo SR665 2 CPUs - alles aktuell (Firmware, Treiber) NIC: Broadcom SFP28 57454 4 Ports kein Teaming, für jeden Port ein separater vSwitch Es wurden bisher keine Parameter verändert. Es funktioniert auch alles, aber es sind halt diese Fehler im Log. Es treten diese Events auf: Event 280 VMS Utilization Plan Vport QueuePairs wurde von angeforderter Anzahl (16) auf aktuell (4) angepasst. Grund:Auf die nächstgelegene Zweierpotenz abgerundet. NIC-Name: /DEVICE/{9A08C856-FC4D-4E6F-A66A-59F34813E3B0} (Anzeigename: Broadcom 57454 10/25GbE SFP28 4-port OCP Ethernet Adapter #2). Event 281 VMS Utilization Plan Vport QueuePairs: Fehler. Grund: QP ist nicht mehr verfügbar. Status: Nicht ausreichend Systemressourcen, um die API abzuschließen.. NIC-Name: /DEVICE/{9A08C856-FC4D-4E6F-A66A-59F34813E3B0} (Anzeigename: Broadcom 57454 10/25GbE SFP28 4-port OCP Ethernet Adapter #2). Event 113 Failed to allocate VMQ for NIC 7F18CB75-1D9D-416F-AEBA-CE494BD9E487--1C5FC570-55E6-47F0-B2D8-0BF21D378BE5 (Friendly Name: Netzwerkkarte) on switch 857A8E05-3258-4F41-B120-4C27D3BD7F88 (Friendly Name: SFP28OCP_01). Reason - Der Auslastungsplan kann nicht ausgewertet werden. Status = Nicht ausreichend Systemressourcen, um die API abzuschließen. 1) Oft wird empfohlen VMQ einfach abzuschalten, aber das kommt mir falsch vor. VMQ sorgt ja dafür, dass die Last schön auf alle CPU-Kerne verteilt wird. 2) Warum diese Fehler auftreten ist mir nicht ganz klar. Es ist ja die Standardkonfiguration von W2K22 und Hyper-V und die sollte doch ohne Fehler funktionieren. Ist es nicht nur "best practices" sonder ist es notwendig, auch ohne NIC-Teams, VMQ und RSS extra zu konfigurieren? Mit konfigurieren meine ich die ganzen Anleitungen mit denen jeder einzelne NIC-Port einem CPU-Kern zugewiesen wird, damit nicht alles auf Kern 0 läuft? Vielen Dank für eure Meinungen.

Das ist selbstverständlich richtig, auch wenn es wahrscheinlich nicht best practice ist. Da sind mir fremde Clients im Sinn.

Das ist nicht korrekt. Der Name auf dem Zertifikat scheint egal zu sein. Er muss vom Client noch nicht einmal aufgelöst werden können. Hauptsache dem Zertifikat wird vertraut.

Guten Morgen, evtl. kann mir jemand hierzu etwas erklären, kommentieren, bestätigen oder auf einen Irrtum hinweisen. Die Angaben wann was notwendig ist, gehen in diversen Youtube-Videos und Tutorials auseinander. Entschuldigt die Länge. Allgemein Ab dem Zeitpunkt des Domain-Join hat der Client die lokale Zertifizierungsstelle als vertrauenswürdige Stammzertifizierungsstellt im Zertifikatsspeicher. Zertifikat jedes Windows PC mit aktiviertem RDP Mal noch ohne RDS gedacht. Jeder PC hat für RDP ein selbsigniertes Zertifikat (egal ob domain-joined oder nicht). Mit diesem Zertifikat weist sich dieser PC bei einer RDP-Anmeldung aus. certlm -> Remotedesktop -> Zertifikate (Keine Zertifikatskette, eben selbst signiert) 1) Greife ich von einem domain-joined PC auf einen anderen (ebenfalls domain joined) per RDP zu, erscheint keine Zertifikatswarnung? Warum? Es handelt sich doch um ein selbsigniertes Zertifikat, ohne Bezug zur lokalen CA? 2) Greife ich von einem nicht domain-joined PC zu ==> Zertifikatswarnung. Klar, das Zertifikat ist unbekannt Warum kommt keine Warnung per RDP von einem domain-joined PC auf einen anderen, obwohl das Zertifikat keine Kette zur lokalen CA aufweist? RDS-Zertifikate RDS - Verbindungsbroker SSO (einmaliges Anmelden) Wird benötigt um z. B. von einem PC an dem ich bereits angemeldet bin, beim Zugriff auf RDS nicht noch einmal die Anmeldedaten eingeben zu müssen. Lautet auf den internen Namen des PC mit der Rolle des Verbindungsbrokers. Nicht unbedingt notwendig, wenn kein SSO konfiguriert. RDS - Verbindungsbroker - Veröffentlichung Wird zur Signierung der RDP-Dateien verwendet die man im Portal über Web Access herunterladen kann. Lautet auf den internen Namen des PC mit der Rolle des Verbindungsbrokers. Wenn ich die RDP-Dateien auch außerhalb der Domäne nutzen will, brauche ich für den Verbindungsbroker ein öffentliches Zertifikat. Nicht unbedingt notwendig, dann erscheinen halt Warnungen wenn die RDP-Datei ausgeführt wird. RDS - Web Access Wird für die Webseite des IIS für das Web Access Portal verwendet. Lautet auf den internen Namen des PC mit der Web Access Rolle. Im Falle einer Veröffentlichung sollte auch ein öffentliches Zertifikat verwendet werden. RD-Gateway Das Gateway ist die einzige Rolle die auf jeden Fall ein öffentliches Zertifikat benötigt. Öffentliche vs. interne Zertifikate Während das Gateway die einzige Rolle ist die ohne öffentliches Zertifikat nicht funktioniert, kann bei allen anderen eine Warnung weggeklickt werden. Man könnte aber auch für alles öffentliche Zertifikate nutzen, auch für den standalone PC mit offenem PC-Port. Dazu richtet man im DNS eine eigene Zone ein, damit die externen Namen auch intern aufgelöst werden können. Man könnte für alles auch ein SAN oder Wildcard Zertifikat verwenden. Habe ich das richtig verstanden? Danke und Grüße Kann es sein, dass sich die PCs dann per Kerberos untereinander authentifizieren? Nur wenn das nicht geht müsste dann TLS (und somit Zertifikate) verwendet werden.

Die QuickStart-Bereitstellung installiert unter W2K22 keinen Lizenzserver. Egal, die Erfahrung zeigt, dass es eben problemlos geht und im schlimmsten Fall müsste man das halt ändern, wenn davon die Bearbeitung eines Tickets abhängig ist.

Ja, gut beschrieben. Bei mir kommt noch hinzu, dass so hin und wieder mal Outlook hängt. Beim Öffnen einer Mail braucht es mal 3 Sekunden, nach dem Klick auf Senden kurz mal 4 Sekunden. Nicht immer, aber doch hin und wieder. Das ist aber erst seit wir zu O365 migriert haben so. Mit dem Exchange im Keller waren die User auch ohne Cache zufrieden. Cache habe ich pauschal auf 6 Monate.