cj_berlin

Huch? https://www.microsoft.com/de-de/windows-server/pricing sagt: Standard = $972, also $486 pro VM, und DC = $6.155, somit 12,66x der Betrag. Wo ist der Fehler? Du bist der Profi

Die VMs sind für den Teil, wo mit Cores gerechnet wird, völlig uninteressant, denn die Windows Server-Lizenzierung gilt für das Blech. Die Anzahl VMs kommt dann ins Spiel, wenn Du entscheiden musst, ob Du Windows Server Datacenter brauchst oder mit Standard oder 2x Standard auskommst. *Dann* nimmst Du nämlich die maximale Anzahl Windows Sever-VMs, die zu irgendeinem Zeitpunkt theoretisch auf einem Host gleichzeitig laufen könnten. Liegt die Zahl über 12, ist Datacenter billiger. Liegt sie darunter, musst Du so oft Standard lizensieren, bis die doppelte Anzahl der Standard-Lizenzen über der Maximalzahl VMs liegt.

Gegenfrage: Was verwendest Du denn sonst?

...aber leider werden User *reportet* und nicht Menschen. Darüber muss man dann halt mit dem Auditor sprechen. Mit 2019 werden User CALs übrigens auch getrackt, daher wird das Halbieren evtl. nicht zum Ziel führen.

Hmmm. Ich habe es gerade aus Spaß im Labor ausprobiert. Der Session Host erbt nicht das Zertifikat vom Deployment, dieses ist in keinem Store vorhanden: Und dennoch wird bei der Verbindung... ...das Zertifikat des Deployments (und auch dessen Name) verwendet: Die einzige Anpassung, die ich gemacht habe, ist: aber das beseitigt *eigentlich* einen anderen Pop-Up. Der RD-Listener am Broker hat allerdings sehr wohl das Wildcard-Zertifikat gebunden. Na toll, jetzt kann ich keine Screenshots mehr posten. Aber eine andere Idee: Hat Dein Wildcard-Zertifikat den Wildcard-String auch im SAN oder evtl. nur im Subject?

Nein, User CALs in eine nicht vertrauende Domain pumpen kann der RDS-Lizenzserver nicht. Das ist das, wovon ich vorhin schrieb: Du brauchst einen Lizenzserver pro Forest und das Lizenzpaket somit 2x installiert.

Dann ist irgendwas mit Deinem Deployment nicht so wie es sein soll. Normalerweise spielen die individuellen Zertifikate der Hosts keine Rolle. Hast Du evtl. eine GPO für die Infrastruktur-Server, die zufällig auch auf Deine Farm wirkt und wo die Zertifikatsvorlage für RDP-Zertifikate festgelegt wird? Kannst Du die Session Hosts einmal aus dem Deployment entfernen und wieder hinzufügen? Oder einfach schnell eine VM in eine neue Session Collection stecken und schauen, ob das Problem immer noch auftritt?

Das allererste Beispiel sollte es tun.

Bestimmt nicht. Es gibt keine lebendigen Systeme mehr, die zwar .BAT, aber keine .CMD unterstützen Hier sind nette Beispiele für FTP-Skripte mit Windows-Bordmitteln: https://www.dostips.com/DtTipsFtpBatchScript.php

Moin, die Texteingabe der SID sollte funktionieren.

...allerdings wird diese Konstellation in Bezug auf die RDS-CALs immer zu Gesprächsbedarf führen, denn diese werden rein technisch sowohl doppelt vorgehalten als auch doppelt ausgestellt. Aber wenn die Namenskonventionen in beiden Segmenten so sind, dass man glaubhaft machen kann, dass AD1\bondj007 und AD2\bondj007 ein und dieselbe physische Person sind, ist der Auditor dann meistens auch schnell beruhigt.

Moin, erstens, auch ein SHA-256-Zertifikat hat auch ein SHA-1-Thumbprint. zweitens, das Farm-Zertifikat wird nur dem Broker über das Deployment zugewiesen (hast Du ja schon gemacht). Es ist schließlich nicht vorgesehen, dass man direkt auf einen RDSH aus einer Farm zugreift. Und wenn, dann ist man Admin und weiß mit der etwaigen Warnung umzugehen. Was genau funktioniert denn nicht? Wenn Du Pop-Ups kriegst, kann es einen anderen Grund haben, je nachdem, welche Pop-Ups das sind...

OK, ich habe mir das nochmal angeschaut. Leases bekommst Du weder mit DUMP noch mit EXPORT, beide liefern de facto nur die Config. Wenn er beim Import meckert, sind wahrscheinlich falsch aufgelöste Sonderzeichen Schuld. Du kannst es viel robuster per XML mit Export-DHCPServer und Import-DHCPServer machen. Und da kannst Du, zumindest beim Export, auch die Leases mitnehmen, wenn Du sie für die Nachwelt dokumentiert haben möchtest

Mit Windows Server? RRAS. Ich sehe kein Incentive, da mit einem Third Party-Produkt anzufangen...

Aaaalso, zwei Dinge: Wenn der Scope 10.32.0.0/16 noch in der aktiven Konfiguration drin ist, kannst Du 10.32.0.0/24 oder 10.32.1.0/24 nicht hinzufügen, denn sie würden sich ja überlappen. Wenn Du nur die Maske geändert hast, versuchst Du laut Deinem Post ja Elemente mit 10.32.1.x in das Subnetz 10.32.0.0/24 zu schieben, wo sie nicht mehr hingehören. Aber vielleicht habe ich den Punkt ja missverstanden. Das Subnetz des Scope ändern geht nur über Löschen/Hinzufügen, die ausgeteilten Leases gehen dabei verloren. Was aber nicht schlimm ist, denn sie werden beim Refresh erneuert.

Moin, und der VPN-Endpunkt läuft auch auf dem Server oder ist da vom RZ-Provider etwas vorgeschaltet? Im Prinzip geht das mit der Windows-Firewall: Den Zugriff für RDP auf diejenige IP einschränken, die Dein Client bei der VPN-Einwahl bekommt.

RDWeb kann das theoretisch auch, aber dann brauchen die User eine RDS CAL, selbst wenn keine anderen RDS-Dienste verwendet werden...

Moin, wenn ich das richtig verstanden habe, sind die Adressen, die als Filterkriterium dienen, extern. In diesem Fall ist es tatsächlich keine "Benutzergruppe", sondern eine Text-Übereinstuimmung im Empfänger (bei ausgehenden Mails) bzw. im Absender (bei eingehenden). Den Absender kann man, wenn es dem Use Case entspricht, anhand der Domain identifizieren ("SenderDomainIs"-Prädikat) oder halt explizit ("FromAddressContainsWords" bzw. "FromAddressMatchesPatterns"). Die gleichen drei Identifizierungsarten gelten für den Empfänger. An der Stelle hoffe ich, dass es nicht allzu viele von diesen Adressen gibt, sonst wird es unübersichtlich, die Regeln zu pflegen.