cj_berlin

Sorry, aber Posts wie Dein letzter zeigen ganz deutlich, was @NilsK schrieb: Du brauchst Beratung. Die Cloud ist schon für die erfahrenen Cloud-Consultants und -Admins verwirrend genug, und Du steigst gleich mit Information Protection ein - einem der komplexesten Themen, die es in M365 gibt, und vor allem mit einem, das gern in Tränen endet, wenn Du es falsch aufziehst...

Genau, und wenn man Jira installiert hat, ist man agil

Hmmm. Ich bin da bei @teletubbieland - auch wenn's nicht die Lösung ist, aber hast Du die Möglichkeit, wenigstens kurz einen anderen AP zu benutzen, der am LAN-Port der FB hängt? Mit der dann gewonnenen Erkenntnis könnte man ja an AVM herantreten. Die Jungs und Mädels sind an sowas eigentlich immer interessiert.

Moin, ungefähr die Hälfte meiner O365-Kunden setzt AIP oder wie auch immer das heute Nachmittag heißt in irgendeiner Ausprägung ein. Tendenz ist steigend, weil Microsoft es geschafft hat, das einigermaßen beherrschbar zu verpacken, auch für den Endbenutzer. Das Zeug existiert ausschließlich innerhalb O365, daher brauchst Du nicht nur Azure AD, sondern auch z.B. SharePoint Online, OneDrive for Business usw. Aber auch Dateien auf Deinem NAS kannst Du *eventuell* mit dem AIP-Schutz versehen. Du kannst Labels mittels Policies bzw. Regeln automatisch zuweisen. Wie passend und präzise das dann wird, hängt von Deinen Dokumenten ab. On premises (und ja, es heißt nicht onPremise, sonder on premises) hast Du, wie von mir oben bereits ausgeführt, AD RMS, da musst Du deine PKI im Griff haben und Deine Anwendungslandschaft auch, und hast nicht alle Features, die Du online geboten bekommst. Ist aber in Deiner Windows Server-Lizenz bereits enthalten. Für die Klassifizierung gibt es seit Server 2003 den File Server Resource Manager. Ist es das Gelbe vom Ei? Nein. Aber on-prem und ohne Zusatzkosten. Last but not least: Information Protection jenseits der Zugriffsrechte setzt voraus, dass die Programme, mit denen die Dateien bearbeitet werden, dafür gerüstet sind. Wenn Du ein exotisches CAD-Programm einsetzt, welches keinen Schutz vor Weiterverbreitung bietet, ist alles AIP machtlos, und es bleiben nur Zugriffsrechte und, wenn Du Bock auf Rechtsstreitigkeiten hast, Zugriffsprotokolle.

Erster Teil richtig, zweiter Teil falsch. Nur ist mein Auftrag bei diesen Kunden nicht "mach, dass läuft, egal wie", sondern "mach, dass wir nicht als nächste in der Zeitung stehen wg. Ransomware". Und dahin führen in Bezug auf das Thema dieses Threads nur zwei Wege: Im Shopfloor-Netz läuft vernünftige Software in vernünftigen Konfigurationen. Das Shopfloor-Netz ist von der Außenwelt isoliert. Alles dazwischen ist Augenwischerei und endet in Tränen. Und mit "der Fachabteilung" musste ich auch ein paarmal reden. Der geschäftsführende Direktor war dabei und sagte zum Produktionsleiter: "Ich kann dich nicht entlassen, wenn was passiert, aber WENN was passiert und diese Technik war schuld, sorge ich dafür, dass dein Name sehr prominent genannt wird". Plötzlich war ein abgeschottetes Segment für den Uralt-Dreck doch keine so schlechte Idee mehr. Es geht nicht um das Vetorecht der IT, sondern um begründete Argumentation. Und heutzutage hast Du in diesem Kampf einen weiteren Verbündeten: die IT-Ausfallversicherung. Es dauert nicht mehr lange, und die Brüder werden ausnahmslos prüfen, bevor sie die Höhe der Prämie festlegen. Und wenn der Versicherungsvertreter dann sagt, dass man 10 Millionen im Jahr mehr an Versicherung zahlen muss, wenn die Maschine für 5 Millionen ins Netz kommt, dürfte das Gespräch mit "der Fachabteilung" auch anders verlaufen. Aber bau ruhig den Linux-Proxy. Du hast ja das Know-How und die Zeit, um den 24x7x52 zu supporten. Ach ja, richtig - die IT hat ja keine SLAs. Drum hat sie auch kein Vetorecht.

...und dieser springende Punkt bringt Dir was genau? Außer Ärger mit dem Betriebsrat und möglicherweise auch mit dem DSB natürlich? Die Firma muss dafür sorgen, dass a. die Mitarbeiter nicht kündigen, b. wenn sie kündigen, sie im Guten gehen c. die Kundenbeziehungen so sind, dass sie auch das Ausscheiden eines Mitarbeiters überstehen. Alles andere ist ein Versuch, ein strukturelles Problem mit technischen (und wenn ich den Ton Deines Posts richtig deute, auch juristischen) Mitteln zu lösen.

Das kannst Du nicht verhindern. Und wenn Du es "gut genug" einschränkst, passiert folgendes (schon in unzähligen Firmen beobachtet): Firma stellt Vertriebler ein, weil sie Kunden mitbringen, kauft also de-facto nicht die Person ein, sondern primär ihr Rolodex diese Vertriebler tun den Teufel, ihre Daten ins System des Arbeitgebers einzuspielen - im Zweifel bleibt das Rolodex physisch vorhanden dann gehen die Vertriebler wieder und nehmen ihr Rolodex wieder mit --> die nächste Firma stellt sie ein, weil sie Kunden mitbringen Auch ich als Nicht-Vertriebler habe Kunden, die mir durch mehrere Arbeitgeberwechsel gefolgt sind. Habe ich sie "mitgenommen"? Nein, es stand jedem Arbeitgeber frei, sich als Firma beim Kunden zu beweisen und anderes Personal dort zu etablieren, auch nach meinem Ausscheiden noch. Wenn niemand daran Interesse hatte, ist es nicht mein Problem. Das ist ja wohl auch der Sinn der Sache Entweder Du willst DLP oder Du willst freien Informationsfluss. Beides geht nicht. Microsoft macht da für eine Bude mit 50 Sitzen keine Beratung, aber es gibt Partnerfirmen, die das können und gern für euch tun werden. DLP ist genau dafür gedacht. Das gab es und gibt es übrigens auch on premises und auch ohne SharePoint, nennt sich Rights Management Services. Aber das, was in der M365-Cloud angeboten wird, ist natürlich unendlich komfortabler zu bedienen und zu administrieren. Genau genommen hat kaum jemand die Kompetenz, das on-prem sauber aufzubauen und über Jahre verlustfrei zu betreiben.

Also quasi Pipe?

Das nicht, aber die Dokumentation des Herstellers: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/advanced-security-auditing-faq Und die Relevanz der Einträge hängt davon ab, was Du versuchst festzustellen. Ich habe schon global agierende Konzerne erlebt, wo noch nie jemand ins Security Log auf irgendeinem System geschaut hat.

Die Frage war jedoch nicht, was für Maßnahmen ihr ergreift, sondern, welcher konkreten - oder meinetwegen auch abstrakten - Gefährdung ihr damit vorbeugen wollt. Aber Deine Nicht-Antwort ist genau das, was ich erwartet hatte. Ihr wisst es nicht, denkt aber, dass wenn die IT einen Desktop-Lockdown-Krieg gegen die eigenen User anfängt, alles irgendwie sicherer wird.

Nix ist da automatisch. Du musst lernen, mit Encodings umzugehen. Je nach Herkunft der Textdateien und deren geplanter Verwendung, ist es ein nahezu bodenloses Fass. Aber in einfachen Fällen funktioniert das mit -Encoding. Eventuell musst Du auch schon beim Import die Codierung angeben.

https://www.smartertools.com/smartermail/microsoft-outlook

...und PowerShell legt den Standard beim Exportieren sogar so aus, dass *jeder* String in Gänsefüßchen eingeschlossen wird, egal, ob er den Delimiter enthält oder nicht. Beim Importieren werden aber RFC4180-konforme Dateien korrekt importiert.

Das ist aber alles sehr schwammig. Welche konkrete Gefährdung - der Datensicherheit, des Datenschutzes, usw. - wird durch das Sperren der Taskleiste abgewendet?

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