cj_berlin

Oh, doch... schon immer. Hier mal ein Writeup aus 2005: http://techgenix.com/citrix-presentation-servers-application-isolation-environments/

Moin, mit App-V meine ich App-V Anwendungsvirtualisierung von Microsoft, ehemals SoftGrid. Was Du für VDI an Lizenzen brauchst, kommt darauf an, wie die zugreifenden Clients lizenziert sind. Wenn es Wndows 10 Enterprise unter SA ist, brauchst Du nichts weiter (die RDS CALs aber weiterhin). Andernfalls brauchst Du eine VDA-Lizenz. Je nachdem, was für Verträge Du bei Microsoft hast, kommst Du da ran oder auch nicht. Eine Alternative wäre noch der Windows Virtual Desktop (ein Cloud-Service von Microsoft), wenn diese Anwendung nicht massiv auf irgendein Datenbank-Backend bei euch in der Umgebung zugreift.

Moin, die RemoteApps in Microsoft RDS sind nichts anderes als eine Desktopsitzung, wo alles außerhalb des App-Fensters abgeschnitten ist, plus die Fähigkeit, lokal gespeicherte Dateien bestimmter Typen mit der RemoteApp zu öffnen. Insofern sind da keine Wunder zu erwarten, und die Antwort auf Deine Frage ist ein vorsichtiges Nein. Wenn die Aktualisierung der Citrix-Umgebung nicht gewünscht ist, bleibt Dir vermutlich nur App-V.

Moin, nein, zum Thema POP-Connector und MX musst Du nicht zwingend den gesamten SMTP-Space auf Exchange umstellen. Vielmehr lässt Du den MX nicht auf Strato zeigen, sondern auf Deinen Exchange, und die Adressen, die im Exchange nicht gefunden wurden, gehen per Überlauf (external Relay) dann an Strato. An den Clients muss nichts geändert werden.

Moin, "besser" ist in der IT immer so eine Sache. Token Ring war "besser" (aus Ingenieurssicht) als Ethernet, NetWare war besser als NT3.51 (in dem, was sie beide konnten). Und wo sind diese "besseren" Technologien jetzt? Es gibt richtig abgefahrene Lösungen, die elektromagnetische Profile der LAN-Adapter aufzeichnen, d.h. wenn Du zwar die gleiche Karte, aber mit einem anderen SFP nimmst, bist Du schon ein Fremder. Ist das besser? Kommt darauf an. Was gern genommen wird, und das war zu 2008R2-Zeiten gefühlt noch weiter verbreitet, ist so etwas wie MACMON oder ARP-GUARD. Beide können auf Wunsch auch 802.1X, würden aber ansonsten MAC-Kontrolle machen. Der Vorteil hier ist aus meiner Sicht nur die Einfachheit: Du brauchst nur das Wissen über die Physik des Clients, nicht aber irgendwas auf dem Client selbst. Dies kann aber auch ein Nachteil sein: Schafft jemand, auf einem als vertrauenswürdig eingestuften Endgerät ein anderes OS zu booten, schon ist auch jenes für den Netzwerkzugriff zugelassen. Und auch die Verwandtschaft zwischen der LAN- und der WLAN-Schnittstelle eines Rechners muss man im herkömmlichen NAC organisatorisch pflegen, währen bei 802.1X mit Zertifikaten alle Schnittstellen mit einer Identität bedient werden können. Ich bin persönlich ein Freund von 802.1X. Es gibt aber sehr wohl Einsatzszenarien, wo ein anderes NAC besser geeignet ist.

Moin, offizielle Guidance zu dem Thema endet bei Server 2016, und da war es auch nicht angeblich, sondern definitiv nicht möglich. Vielleicht hat sich das zu 2019 geändert, vielleicht hast Du einen glücklichen Mondstand erwischt. Die wenigsten, die sich regelmäßig mit Windows Server beschäftigen, haben das jemals versucht, da eine nicht aktivierte Vollversion zum Spielen genauso gut ist wie eine Eval...

Oha. Bedeutet also, dass der Server auch auf Port 3389 ungefiltert ins Internet horcht? Dann gute Nacht Warum nicht AD am gleichen Server: Der Server wäre dann ein AD-Domaincontroller, und die User müssten sich interaktiv am Domain Controller anmelden. Da benimmt sich einiges anders als auf einem Member- oder Standalone-Server.

Für Lizenzen? Computer\Windows-Komponenten\Remotedesktopdienste\Remotedesktopsitzungs-Host\Lizenzierung.

Moin, Du musst dem RD Session Host ja mitteilen, am besten per GPO, an welchen Lizenzserver er sich wenden soll (auch wenn er's selber ist) und welche Lizenzart (Device/User) er da anfordern soll. Was das Webcam-Thema angeht... Hast Du neben dem Browser auch irgendeine kamerafähige Anwendung ausprobiert, mit der Deine User arbeiten werden? Treiber musst Du normalerweise keine installieren, da die Umleitung ja nicht auf Hardware-Ebene, sondern auf Protokoll-Ebene erfolgt.

Moin, probiere mal den UPN. Ist es sichergestellt, dass der User nicht sein Passwort ändern muss? Wird bei dem betroffenen User der Bad Password-Counter hochgezählt?

Doch, wenn es absichtlich ist, ist es nicht fahrlässig

Kann es sein, dass da einige Clients sich einen Computernamen teilen?

COSINE / X.500 LDAP specification. Siehe RFC4524 und Vorgänger.

ich dachte, da fehlt ein "e"... so kann man sich irren

Moin, Du musst Dich mit der Syntax von Get-ChildItem und Get-Item auseinandersetzen. Grundsätzlich hilft es sehr, Parameter von Cmdlets namentlich anzugeben und sich nicht auf die Reihenfolge zu verlassen ("dir" in Deinem Beispiel wird ja als Alias zu Get-ChildItem aufgelöst, ist also kein Batch-Befehl!)

Moin, rein von der X.509-Spezifikation her spricht IMHO nichts dagegen. Die Interpretation des Zertifikats durch die betroffenen Applikationen ist eine andere Frage, und da helfen keine RFCs Auch ich habe noch nie ein solches Zertifikat außerhalb eines PKI-Labors gesehen, daher würde ich Dir raten, die Anforderung mit anderen Mitteln zu lösen. Hinweis: O365 verwaltet Zehntausende, wenn nicht Hunderttausende Domains, und schaffen das auch. Vielleicht schaust Du dir mal an, wie die das machen, dann wird Dir einiges klarer.

Und, weil es auch im Jahre 2021 nicht oft genug wiederholt werden kann: DHCP nicht auf einem DC.

@lizenzdoc: Du übersiehst nichts, genau so wird das gemacht, wenn man kein Abo möchte.

Naja, mit SA für alle + VDA für manche ist es ohne weiteres möglich und wird auch ständig gemacht. Das sind natürlich de-facto Mietlizenzen. Und warum auch nicht In manchen Fällen macht es kaufmännisch durchaus Sinn. Für alle anderen Fälle bleibt die VDI mit Server-OS und RDS-CALs. Oder, falls alle Anwendungen mitspielen, Terminalserver. Macht technisch und kaufmännisch nach wie vor mehr Sinn als VDI.

Moin, ich bin natürlich kein Jurist, und niemand wird Dir hier in einem freien offenen Forum einen gerichtlich belastbaren juristischen Rat erteilen. Dies vorausgeschickt, liest sich der von Dir zitierte Paragraph d. für mich wie folgt: mit dem Abschnitt (iv) (Virtualisierung) bist Du soweit im Reinen, Der Abschnitt (v) (Remotezugriff) besagt, dass der Nutzer, der das Gerät "physisch" verwendet, von einem beliebigen Gerät, und andere Nutzer von lizenzierten Geräten aus darauf zugreifen können. Jetzt kann man sich bei einer virtuellen Instanz streiten, wem diese denn "physisch" zugewiesen ist. Und unsere intuitive Deutung der Begriffe spielt dabei, wie immer bei Vertragstexten, keine Rolle. Mir wurde bisher in jeder Lizenzberatung gesagt, VDI mit Windows-Clientbetriebssystemen ist mit Retail-Lizenzen nicht möglich. Insofern, wenn Du von einem qualifizierten Lizenz-Reseller oder von einem Lizenzanwalt eine andere Aussage erhältst, wäre es für viele kleine Firmen sehr interessant.

Du musst bitte, wenn Du zitierst, auf die Quelle verlinken. Denn es ist nicht egal, aus welchem Bezugskanal Deine Lizenzen stammen, und die entsprechenden Lizenzbedingungen gelten dann.

Moin, ja, zeig mal Deine Ergebnisse. Nach meinem begrenzten Wissen erfordert der Remote-Zugriff auf ein Windows Client-OS eine Enterprise-Lizenz mit SA: Entweder diese Lizenz klebt an dem zugreifenden Endgerät oder sie muss noch durch eine VDA (Virtual Desktop Access) ergänzt werden, was, ähnlich wie SA, eine Abo-Lizenz ist und kein einmaliges Abo. Auf welcher Plattform das Windows virtualisiert ist, ist in beiden Fällen egal.

Das ist bei Hyper-V aber im Gegensatz zu VMware nicht unbedingt erforderlich. Ben Armstrong hat das mal aufgedröselt und empfohlen, die Synchronisierung aktiviert zu lassen. @chrismue Schalte doch bitte mal das Logging des Zeit Service ein und poste den Log nach dem Restart des Dienstes.

Naja, wie wäre es, die User werden zu Mail-enabled Users, und ihre externen Adressen werden als externe Forwarding-Adressen eingetragen. Kostet keine Exchange-Lizenz, Attribute werden mit Exchange verwaltet, Mail wird zugestellt. Und wenn Du die User "nicht nur in einer extra OU" separierst, dann reden wir von einem extra Forest. Und dann hast Du multiforest Citrix, multiforest Jira, multiforest GPO usw. usw. Ob das so *der* Lösungsansatz ist...

Moin, das offensichtliche ist aber geklärt: Auf den Zielservern ist die Druckerumleitung als Solche nicht totgetreten? Ansonsten, Nested RDS hat offizielle Einschränkungen. Hier ein älterer Artikel: https://docs.microsoft.com/en-us/troubleshoot/windows-server/remote/run-remote-desktop-connection-session Allerdings funktioniert Dein Szenario in meinem Labor einwandfrei. Dann musst Du wohl die Logs lesen (auf den Zielservern).