cj_berlin

Da ist ein Reset- und ein Clear-Button (Loch) vorne links. Damit geht es auch ohne Verbindungen.

Die fehlt nicht, die heißt einfach "CU3 und älter". Ist doch klar: later, älter, das passt schon Ich denke bei sowas immer an "Katzenpfötchen" - da gab es mal einen Artikel in den Docs zu "PAW" (Privileged Admin Workstations)

Richtig, und Exchange 2016 geht nicht auf Server 2019. Umgekehrt auch nicht

Gibt es auch. Für ein vollwertiges RDS-Deployment mit RemoteApps oder mehreren Session Collections,

Ja, freilich. Solange Heinz, Klaus und Christa unterschiedliche Usernamen haben, haben sie auch unterschiedliche Benutzerprofile Und ja, die Anwendung muss a. serverfähig und b. multisession-fähig sein. Aber wenn der Hersteller zum Terminalserver geraten hat, würde ich das in diesem Fall voraussetzen...

Wenn das die Adresse des Servers ist, ja Ich würde bei so etwas zwar immer lieber mit DNS-Namen arbeiten als mit IP-Adressen, aber es ist Dir natürlich überlassen,

Es ist ein MULTIUSER System. Alle verbinden sich zum gleichen Server und jeder kriegt einen eigenen Desktop. Sofern Du nichts einschränkst, stehen dann auf diesem Desktop alle auf dem Server installierten Applikationen zur Verfügung. Wenn Du das einschränken willst, verfahre genau so wie Du es bei einem Desktop-PC machen würdest, auf dem mehrere Personen sich abwechselnd anmelden: Zugriffsrechte, AppLocker usw. Wenn Du die Applikation als Einzelapplikation anbieten willst, brauchst Du einen Connection Broker und RDWeb. Dann kannst Du die Applikation als RemoteApp veröffentlichen, ohne jedem User einen ganzen Server-Desktop zur Verfügung zu stellen. Oder Du definierst die Anwendung als "bei Start der Sitzung starten", das will aber gut getestet werden, eigentlich will Microsoft davon weg.

Moin, wie schon vermutet: Du vermischst Äpfel mit Birnen. Terminalserver = RD Session Host = sitzungsbasierte VDI = Multi-User Windows = mehrere User melden sich gleichzeitig am selben Server an und jeder kriegt eine eigene Sitzung. VDI = RD Virtualization Host = Maschinenbasierte VDI = Single-User Windows = jeder User bekommt eine separate VM aus einer Vorlage. Wenn Deine Anwendungen in einer Multiuser-Umgebung gut spielen, bist Du mit Terminalservern normalerweise besser bedient.

Moin, grundsätzlich ist jede Server-Lizenz downgradefähig. Wo Du a. die Binaries und b. den Schlüssel findest, falls Du keinen KMS oder HVBA oder ADBA benutzt, sagt Dir der Hersteller allerdings nicht.

Ja, und wo soll da ein Unterschied sein? Die Windows - Oberfläche des Servers ist auch der Desktop. Wenn Du VDI brauchst (warum?), bist Du beim Terminalserver falsch.

Was ist denn für Dich ein VDesktop? Und nein, es geht vermutlich nicht um IP-Virtualisierung.

"Funktioniert nicht" ist keine Fehlerbeschreibung. Erwartest Du, dass die neue Maschine ihre Adresse per DHCP bezieht? Oder hast Du ihr eine fixe IP gegeben? Kann sie den Host pingen? Kann sie den Gateway pingen? usw. usw.

Moin, wenn der Terminalserver und die Endgeräte sich in derselben Domäne befinden oder sich die Domänen vertrauen, würdest Du mit etwas handwerklichem Geschick auch einen Single-Sign-On zum Terminalserver hinkriegen. Wenn zwischen dem Client und dem Terminalserver keine gemeinsame Authentifizierungsbasis existiert, nun ja... dann brauchst Du logischerweise zwei Logins. Ich rate dringend davon ab, Terminalserver als Workgroup, d.h. ohne AD, zu betreiben. Die Integration mit O365 erfordert eine Synchronisierung der Benutzer ins Azure AD, damit man ihnen a. Lizenzen zuweisen kann, und sie b. diese für sich beanspruchen können. Du kannst die User zwar auch ausschließlich in der Cloud pflegen, aber es ist nicht effektiv und Du hast zwingend eine zusätzliche Anmeldung.

Mit LDP.exe tut's laut OP. Würde mich auch wundern, falls nicht

Also, ich habe das hier gerade ausprobiert. Auch wenn die Linux-Box der CA nicht vertraut, wird beim Handshake-Versuch auf Port 636 das Zertifikat, welches am DC gebunden ist, korrekt von openssl ausgegeben. Wenn ich den OP richtig verstehe, klappt es in der Umgebung von @Subtellite nicht. Damit ist jedoch noch nichts darüber gesagt, ob eine LDAPS-Verbindung möglich sein wird oder nicht.

@Subtellite: Da bisher niemand das kommentiert hat, muss ich das nun machen: Zertifikate, die eine private CA ausstellt, sind keine Self-Signed Certs. Self-Signed, wie der Name schon sagt, bedeutet, dass der Subject gleich dem Issuer ist. In einer PKI, egal ob privat oder öffentlich, gibt es in der Regel nur ein Self-Signed Zertifikat: Das der Root CA.

Kein Ahnung. Ich habe nur Erfahrung mit den großen Clouds. Man muss schauen, wie der Service bei Strato definiert ist und ob man da ein Subnetz bekommen kann. Wenn ja, dann kann man das natürlich routen, ob es nun privat oder öffentlich ist. Und pfSense war nur ein Vorschlag. Wenn Du Erfahrung mit Endian hast, dann nutze lieber das

Moin, in der Regel brauchst Du ein Site-2-Site-VPN zwischen dem Cloud-Subnetz und Deinem OnPrem-Subnetz. Das gibt es in Azure, in AWS und in GCP. Wie Strato das macht, weiß ich nicht. Einen produktiven Server mit Node-2-Site-VPN anbinden... Naja. Ich würde sagen, lieber nicht. Bei Applikationen, die AD-konform arbeiten, ist es ja bei solchen Einzel-VPNs auch schwierig, sie einer bestimmten Site zuzuweisen... Und dann noch das DNS-Update, wenn sich die VPN-IP ändert, und, und, und.... Wenn Du da mehrere VMs betreiben kannst und Strato selbst keine VPN-Gateway anbietet, kannst Du ja eine kleine pfSense-VM laufen lassen, die den Tunnel aufbaut und aufrechthält. Deine Server in der Cloud haben dann alle ihre fixe IP-Adressen.

Moin, Einstellungen aus der GPO wohnen standardkonform unter HKLM\SOFTWARE\Policies\Microsoft\W32Time\* Sind sie gesetzt, überschreiben sie die Einstellungen im CurrentControlSet-Zweig. Ein Ping auf ntp.metas.ch kommt bei mir nicht zurück, aber ich pinge ja auch aus Deutschland Genaue Aussagen über das, was im Zeitdienst so passiert, liefert das Debug-Protokoll, welches Du auch auf Deinem DC einschalten kannst mit w32tm /debug /enable /file:c:\sys\ntp.log /entries:0-300 /size:1024000 Das ist aber nicht ganz einfach zu lesen... Was ist bei Dir in der GPO hinsichtlich der globalen Konfigurationseinstellungen des Zeitdienstes gesetzt? Ich habe festgestellt, dass der Wert "PhaseCorrectRate" im Begleittext zwar als Default 7 Sekunden angegeben ist, wenn man die Policy aber einschaltet, steht er auf 1 Sekunde, und das ist i.d.R. zu wenig.

...die "Fehlkonfiguration" war aber sehr weit verbreitet

...aber warum? HTML5 kann MS-RDS auch so, und RDG ist ja auch da. Brauchst nur einen Windows Server mit zwei Beinen... Und es gab auch letztes Jahr eine Lücke, die erst durch den NetScaler möglich war

Du kannst - und sollst - auch einen einzelnen Terminalserver hinter einem Gateway "verstecken". Alles andere ist grob fahrlässig. Es gab, wenn ich mich recht erinnere, letztes Jahr auch eine Lücke, die sogar erst durch NLA ermöglicht wurde. Und RDWeb musst Du den Leuten auch bei einer Farm nicht zwingend antun. Du kannst durch RDWeb signierte .RDP-Dateien herunterladen und sie den Usern einfach so zum Draufklicken überlassen. Wir hatten das bei einer Behörde für ein Dutzend Applikationen fünf Jahre lang so praktiziert.

Moin, RDS übers Internet geht nur durch einen RD Gateway. An dieser Stelle kannst Du MFA integrieren oder eine andere Art Prä-Authentifizierung einbauen, damit Brute Force von Kennwörtern nicht möglich ist. Auch um einen Single Point of Entry zu haben brauchst Du den Gateway, denn Du kannst ja kein NAT von einer Public IP zu mehreren Zielen auf dem gleichen Port haben, und ich glaube nicht, dass jemand so viele Public IPs für die Farm bereitstellt wie sie Server hat Das alles gilt für Citrix oder VMware genau so. Du kannst eine normale XenApp-/View-Farm rein technisch nicht ins Internet öffnen, ohne einen NetScaler/UAG als Gateway vorzuschalten - allein schon aus dem Argument der Public IPs heraus, und die Sicherheit kommt natürlich hinzu. Und in dem Szenario mit Gateway *und* MFA ist es in meinen Augen nicht weniger sicher als alles andere. Es darf natürlich nur Port 443 inbound erlaubt sein

Moin, ist der Ordner denn da? Dann ist es vielleicht doch nur ein false positive