cj_berlin

Mich würde mal interessieren, was es für Sicherheitsgründe sind

Moin, das ist jetzt vielleicht OT, aber ich weiß jetzt wieder, warum ich niemals WDS ohne MDT verwende

Moin, die Lizenz erlaubt ja den Zugriff auf beliebig viele Terminalserver innerhalb derselben Organisation. Insofern dürftest Du gar keine doppelten Lizenzen sehen.

Nach Handbuch geht das nicht. Du kannst aber einen unsupporteten Registry Hack googlen, mit dem Du beides präsentieren kannst. Das Ergebnis kannst Du dann aber nicht mehr mit dem Server-Manager verwalten.

Das ist alles irgendwie konfus. Normalerweise: Du hast eine Farm mit Connection Broker und zwei Session Collections, jede davon beinhaltet einen Server wegen Lizenzierung. Jede SC liefert einen Desktop aus. Du bearbeitest die SC und gibst die erste Anwendung als RemoteApp frei. Ab da liefert sie nicht mehr den Desktop aus, sondern Anwendungen, die innerhalb dieser SC als RemoteApp freigegeben wurden.

Moin, sollte jemand von dem KDC Clusterf**k letzte Woche betroffen sein: Hilfe ist da. https://support.microsoft.com/en-us/topic/november-14-2021-kb5008602-os-build-17763-2305-out-of-band-8583a8a3-ebed-4829-b285-356fb5aaacd7 Siehe auch: Witzig auch, dass die Forum-Software "Bars***e" mit Sternchen markiert, aber "Clusterf**k" durchlässt

Moin, Dein Zitat widerspricht doch nicht dem, was ich geschrieben hatte. Es sind halt nur einige Beispiele, tatsächlich gilt es in jedem Szenario. Zugriff auf virtuelles Windows 10 ist mit der Betriebssystem-Lizenz des physischen Windows 10 abgedeckt (meistens), wenn die VM auf der besagten Physik ausgeführt wird. Das ist dann ja auch kein Remote-Zugriff. Remote-Zugriff = entweder SA für Physik oder VDA.

Ja. Wenn die Clients Windows-Maschinen unter SA wären, bräuchte man für die VM kein VDA. Klar, an der Quelle: https://download.microsoft.com/download/3/D/4/3D42BDC2-6725-4B29-B75A-A5B04179958B/Licensing_brief_PLT_Windows_10_licensing_for_Virtual_Desktops.pdf

Nö. Du musst sicherstellen, dass der scheidende DC richtig aus dem AD weggeputzt wurde. Ansonsten ist es die sanfteste aller Upgrade-Methoden. Du liest deswegen nix darüber im Netz, weil es damit die wenigsten Probleme gibt, solange man es nicht übereilt und alles ordentlich bereinigt, bevor man die neue Maschine hineinbringt. Bei zwei DCs würde ich allerdings einen dritten unter 2019 installieren, um das Schema-Upgrade noch im Redundanzbetrieb durchzuführen, und diesen nach Abschluss der Aktion wieder entfernen.

Moin, Du brauchst für jegliche Art von Remote-Zugriff auf Windows Client-OS SA. Und da die zugreifenden Endpoints keine SA-bewehrten Windows 10-Endgeräte sind, brauchst Du VDA. Das ersetzt quasi SA in diesem Fall, ist aber auch eine wiederkehrende Last und kein einmaliger Kauf.

Gibt es dafür ein "zu oft"? Hat doch bisher nur 4,5x stattgefunden

Dann haben wir vermutlich nicht GPP benutzt, sondern etwas (in diesem Fall) Sinnvolles. Vermutlich habe ich es einfach geskriptet, eine Datenbank dahinter geklemmt, Treiber per Software-Verteilung ausgerollt, fertig. Aber es ist jetzt ziemlich genau 7 Jahre her...

Auch wenn Du den Treiber vorinstallierst? Ich habe das schon länger nicht mehr gemacht, weiß aber noch, dass wir das ohne Printserver und ohne zwei Zentner Skript am Start hatten. Und da ich die Leute immer schon versucht habe, davon zu überzeugen, Printer-Treiber wie Software zu behandeln, dachte ich, das war einer dieser Fälle

Mag alles sein. Aber was ist, wenn wir ehrlich sind, gerade in den Umgebungen, von denen Du sprichst, die Alternative? Richtig, das gleiche Admin-Kennwort auf allen Workstations (und mit etwas Pech, auch auf Servern). Und dieses hat man auch schnell in Erfahrung gebracht - fertig ist das ungehinderte lateral movement.

Moin, was ist falsch an ? Wenn Du das im User-Context versuchst - dann ist es klar, ein User kann kein Gerät hinzufügen, nur einen freigegebenen Drucker verbinden. Und wenn er's kann, ist er kein User mehr, sondern ein lokaler Admin, und Du hast ein viel größeres Problem als nur Drucker. EDIT: Wobei die GPPs sogar das unterstützen würden

Es ist eher die eher unglückliche Eigenart von manchen Exchange-Admins, mit Send-As um sich zu werfen. Das kann man hinterher auch nur sehr schwer wieder einfangen. Für Stellvertretungsszenarien gibt es Stellvertretungen. Da kriegt die Sekretärin auch die Zu- und Absagen auf Einladungen, die sie im Auftrag des Chefs verschickt hat (wenn man es denn so einstellt).

Na was denn nu? Getrennt oder abgemeldet? Bei einer getrennten Sitzung sind die Dateien ja noch da, und der User kann sich durchaus wieder verbinden und weiter arbeiten.

Doch, der Link ist richtig und deckt sich auch mit meinen Screenshots. Du musst Send-As wegnehmen, denn das schlägt alles andere.

Ich hatte einmal sogar schon die Anforderung auf dem Tisch, aber die hatte sich dann doch wieder zerschlagen. Viel lohnender wäre vermutlich die Integration in ein bestehendes IDM- oder Workflow-System.

Moin, die Sache mit den ganztägigen Terminen hat zwei Aspekte: Technisch: Die Termine sind einfach doof zu handeln, und wenn mehrere sich am gleichen Tag überschneiden, verklickt man sich ständig. Das hat @NilsK auch gerade angerissen. Organisatorisch. Und da kann ich jedes Mal ausflippen, wenn mich jemand für vier Tage Workshop bucht und mir einen Termin, ganztägig oder nicht, von Dienstag um 9 bis Freitag um 16 Uhr reinknallt. Ich stehe zwischen Dienstag 18 Uhr und Mittwoch 8 Uhr für diesen Termin NICHT zur Verfügung und möchte dort vielleicht etwas anderes planen, ohne dass es zu Überschneidungen kommt. Es wird vielleicht ein Tag ausfallen. Dann macht man halt entweder vier Termine oder eine Serie (Täglich 08-18 beginnt am Di endet am Fr oder nach 4 Vorkommen),

Moin, Du wolltest doch (s. OP), dass nicht der Besitzer des Kalenders, sondern die tatsächlich Einladende als Absender zu sehen ist. Wie aus den obigen Screenshots ersichtlich, ist es nicht zu erreichen, wenn der Termin vom Kalender des Chefs aus initiiert ist. Daher muss die Kollegin den Termin ganz regulär als sie selbst starten, von ihrem eigenen Kalender aus. Dann kann sie, falls sie Bearbeitungsrechte auf dem Kalender des Chefs hat, dorthin wechseln und den Termin, der dort "unter Vorbehalt" steht, annehmen. Wenn es ausreichend ist, dass die Eingeladenen "Kollegin im Auftrag vom Chef" sehen, dann zeigen die obigen Screenshots, dass jede Kombination der Berechtigungen außer Send-As genau diesen Effekt erzeugen wird. Bedeutet: Send-As wegnehmen Falls Send-As für andere Dinge als Kalender gefordert wird, den Leuten sanft erklären, dass man Exchange nicht beliebig verbiegen kann.

Spannend. Hat es schon jemand im Einsatz? Meine Industrie- und Finanzkunden schwanken meistens zwischen "Wir führen LAPS in 2022 ein" und "Bei uns gibt es keine (dauerhaft aktiven) lokalen Adminkonten." Da dieser Password Decryption Service sowieso bei jeder Operation kontaktiert werden muss und somit den Single Point of Bottleneck darstellt, frage ich mich, wozu man den Ciphertext überhaupt noch im AD speichern muss, denn ohne den PDS und dessen Keystore kann man mit dem Ciphertext ja nix anfangen. Dann könnte man ja einen anderen Vault nehmen und es als Feature verkaufen, dass man das AD-Schema nicht erweitern muss In jedem Fall funktioniert das Ganze (im Gegensatz zu LAPS) nicht in einer Site, die zum Zeitpunkt der Passwortänderung von der Zentrale (wo der PDS läuft) getrennt ist. Aber die Möglichkeit, das Admin-Passwort sicher (?) durch den User anfordern zu lassen ist schon nicht ganz uncool... EDIT: Sie ließe sich aber auch in ein paar Stunden für LAPS programmieren. Gibt's bestimmt sogar schon.

...und bitte immer unaufgefordert auf Cross-Posts hinweisen: https://social.technet.microsoft.com/Forums/de-DE/cbb038c7-3242-43ea-98ca-719e3702ff5f/zusammenspiel-ad-und-laps?forum=active_directoryde

Moin, per Default installiert LAPS "im AD" gar nix. Installieren tust Du nur eine DLL (GPO client side extension) auf jedem Rechner, deren lokaler Administrator mit LAPS gemanagt werden soll. Vielleicht noch die Mini-GUI auf den Management-PCs für den Service Desk zum Nachschauen des Kennwort. Im AD musst Du: das Schema erweitern, damit die LAPS-Attribute überhaupt erscheinen (LAPS PowerShell-Modul) Die Computer in den betroffenen OUs berechtigen, diese Attribute für das eigene Computer-Objekt zu beschreiben (LAPS PowerShell-Modul) Die geeigneten Benutzer-Gruppen auf OU-Basis berechtigen, diese Attribute aus den Computer-Objekten zu lesen (LAPS PowerShell-Modul) die ADMX-Vorlage in den Central Policy Store kopieren Gruppenrichtlinien definieren, welche das Verhalten von LAPS auf den Zielcomputern steuern.

Also ein wenig PowerShell lernen solltest Du schon selber. Was sagt denn die Suchmaschine Deines Vertrauens zu "PowerShell sortieren" ?