cj_berlin

Dann hast Du eine dynamische IP, die immer den gleichen Wert bekommt. Das gibt es bei ISPs durchaus.

Die Frage musst Du den Providern stellen, die Deine Mails nicht mehr annehmen.

Ich meinte den TO... war etwas ungünstig formuliert, das gebe ich zu.

...und bevor der TO verzweifelt: Du hast -Delimiter ';' vergessen. Per Default ist ein CSV-Delimiter ein Komma, daher heißt CSV ja auch Comma Separated Values.

Moin, <DISCLAIMER: Keine rechtsverbindliche Lizenzberatung hier im Forum!> wenn die Endgeräte, von denen aus zugegriffen wird, der eigenen Organisation gehören die gleiche oder höhere Version und Edition von Windows ausführen wie die Zielgeräte brauchst Du keine zusätzlichen Lizenzen. Für den Zugriff mit beliebigen Endgeräten musst Du für jede Zielmaschine einen primären User benennen. Dieser darf dann ohne zusätzliche Lizenzen zugreifen. Den User schreibst Du für einen Zeitraum von mindestens 90 Tagen fest. In diesem Zeitraum dürfen andere User remote zugreifen, aber nur von Firmen-Geräten wie oben beschrieben. Bedenke bitte, dass es neben Windows auch andere Produkte gibt, die anders lizenziert werden. Wenn Du Office-Anwendungen auf den Zielmaschinen hast, die nicht aus O365, sondern aus VL, OEM oder Retail stammen, wird der Zugriff per zugreifendem Endgerät lizenziert und nicht per User oder per Installation!

Hmmm.... Teams? Wie ist es denn installiert? Machine wide oder per User?

Moin, nur nebenbei: Server Enterprise gibt es seit 2012 nicht mehr. RemoteFX ist ein Ansatz. Ansonsten mal nach den Klassikern wie Energie-Profil im Host schauen. Ist bei Dir dieser Schwachsinn mit den Per-User-Firewall Rules bereits abgeschaltet? Falls nicht, bereinigen und deaktivieren.

Ja, alle Geräte, die DNS statisch eingetragen haben. Wenn es solche in dieser Umgebung nicht gibt, sollte es soweit passen. Aber wenn Du *irgendeine* Möglichkeit hast, DHCP nicht auf DC zu fahren, solltest Du dieses Upgrade zum Anlass nehmen, das umzusetzen.

Also ein organisatorisches Problem Sobald "Wunsch der GF" und "Ist so" im Anforderungskatalog auftauchen, ist es keine technische Aufgabe mehr. Die Klassifizierungen in FSRM sind nicht nur nach Dateityp möglich, sondern sind extrem mächtig und analysieren auch den Inhalt, solange es sich dabei um Text handelt. Bei Bildern ist aber natürlich game over. Bessere DLP-Engines in Antimalware-Produkten könnten sogar Bilder nach gewissen Kriterien analysieren. 100% wird man mit Technik aber nie erreichen. Aber: Wenn ein Mensch *nachträglich* entscheiden könnte, ob eine Datei geeignet ist oder nicht, ist ja vermutlich die Benennungskonvention so, dass es anhand des Namens möglich ist. Und da kann man auch einen Filter definieren. Letzten Endes kannst Du jemanden, der Schreibrechte in A und in B hat und haben muss, nicht daran hindern, eine Datei von A nach B zu kopieren. Du kannst ihn auch nicht daran hindern, eine richtige Datei mit einem falschen Namen zu versehen. Vielleicht sollte die GF den darunter liegenden Geschäftsprozess nochmal revidieren, denn offensichtlich krankt ja bereits dieser.

Moin, das hört sich nach einem Versuch an, organisatorische Probleme mit technischen Mitteln zu lösen. Das hat noch nie funktioniert. Aber vielleicht kannst Du an einer anderen Stelle ansetzen und den Kopier-Task so umgestalten, dass er sensible Daten nicht auf den Webserver kopiert? Da kann man vielleicht Klassifizierungen aus dem FSRM heranziehen oder die DLP-Funktion der Anti-Malware-Lösung...

Wie gesagt, a. bei Exchange ist es so. Und Eigeninitiative in Produktion endet immer in Tränen. b. VSS-Backup != VM-Snapshot, selbst wenn der Virtualisierungshersteller "VSS-Unterstützung" zusichert. Das sieht man bei Interesse übrigens auch in den Event Logs.

Bei Exchange sollte man nicht diskutieren, sondern einfach nur die Docs beachten. Dafür sie die so ausführlich. Nicht ganz richtig. VSS BACKUP und VSS SNAPSHOT sind zwei verschiedene Befehle und bewirken unterschiedliche Dinge. Und übrigens: Nicht jede Backup Utility, die meint, Exchange zu unterstützen, ist auch *von Exchange* unterstützt.

https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/virtualization?view=exchserver-2019 : Und bitte das Wording beachten: nicht "reverting a VM to a snapshot isn't supported", sondern "making snapshots isn't supported"...

Nein. Aber: Ab dem Zeitpunkt, wo der Standard Server die FSMO-Rollen übernimmt, hast Du 30 Tage, um den Essentials abzuschaffen, sonst fährt er von allein herunter.

Moin, Du musst nur bedenken, dass es die Essentials Experience-Rolle nicht mehr gibt. Du kannst es ganz regulär migrieren, hast dann aber keine Essentials-Funktionalität mehr.

Meines Wissens nicht. Aber wenn Du ein Microsoft-Konto für nichts anderes als die Lizenzprüfung von Office benutzt, was wäre daran so schlimm? Der einzige wirkliche Use Case wäre ja ein Rechner ganz ohne Internet-Zugang, nicht einmal alle 30 Tage. Wofür benötigt man da ein hochmodernes Office? Vielleicht tut's auch ein Office 2013 oder so? Gepatcht würde ein 100%-Offline-Rechner schließlich auch nicht...

Moin, https://www.microsoft.com/de-de/microsoft-365/p/office-home-business-2021/CFQ7TTC0HPN4?activetab=pivot:requirementstab sagt:

So ist es auch. Für Inbound. Für Outbound muss sich nur derjenige authentifizieren, der sendet, also praktisch Hop Nr. Null, und nicht der Hop Nr. N-2 gegenüber Hop Nr. N-1...

Hmmm. Wir reden hier zwangsläufig vom Einreichen nach innen gerichteter externer Mails. Die Authentifizierung geschieht mit einem AD-Account. Dieser Account ist unabhängig sowohl vom Absender (der ja extern ist) als auch vom Empfänger (der ja variieren kann). Ich wüßte, ehrlich gesagt, weder dass es geht, noch wozu es gut ist. IP-Adressen einschränken und TLS ist in diesem Szenario das, was Dir übrig bleibt.

...aber denkt daran: Die beschriebenen Events werden nicht zum Spaß geloggt. Das sind die Applikationen, mit deren Authentifizierungsgewohnheiten ihr euch in den kommenden 6 Monaten beschäftigen müsst. ...und wenn wir schon dabei sind: https://support.microsoft.com/en-au/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1 hat auch einen Enforcement Mode, der im April 2022 aktiv wird. Allerdings kann man das Verhalten mit den neuen Flags im dsHeuristics-Attribut dauerhaft abschalten.

Dumm nur, dass in vielen Fällen, gerade bei Benamsung, "Frau Meyer möchte" als Anforderung gilt. Oder "der Betriebsrat hat beschlossen", was auf das gleiche hinausläuft.

Moin, kein Backup --> kein Mitleid wenn es SATA- oder SAS-Platten sind, sollten sie sich theoretisch alle wieder finden, die Signaturen und Konfigurationen sind ja auf den Platten selbst gespeichert. praktisch ist es besser, sie an die alten Anschlüsse zu stecken. Ein wenige Beschriftung sollte ja nicht das Problem sein. selbst wenn Storage Spaces da empfindlich reagieren sollte, Daten gehen ja erst mal nicht verloren, der Pool wird halt im Status "Platten fehlen" hochgefahren. Dann musst Du halt umstecken. Dein nächster Server sollte ein redundantes Netzteil haben und eine Kabelführung, welche das Tauschen des Netzteils ohne Abstecken von Platten ermöglicht.

Moin, Microsoft VDI ist ein sehr starres Produkt und kann euren Fall vermutlich nicht abbilden, weil es keine persistenten Desktops realisieren kann. Es ist genau für den Fall gedacht, den ihr nach Deinen Angaben nicht habt - einige wenige Images für relativ viele Sessions. Mit Microsoft-Bordmitteln seid ihr bei 1x Session Collection pro Benutzer, die jeweils eine einzige Maschine enthält. Gebt einfach jedem User eine statische VM mit einer fixen IP, dann habt ihr eure Client-Landschaft noch einmal virtuell nachgebildet, aber mehr scheint ja nicht gefordert zu sein. Der Connection Broker bringt euch dabei exakt Null, da er ja jedem User jeden Tag immer die gleiche VM zuweisen müsste. Warum ausgerechnet in eurer Firma ein Shared Desktop "nicht praktikabel" sein soll, gehört vermutlich in den Bereich des Anforderungsmanagements und nicht in den der technischen Umsetzbarkeit

Nein. Denn wenn ein Host stirbt, sterben alle Desktop-VMs darauf mit, und es sorgt der Connection Broker dafür, dass sie neu aus dem Image geklont werden, auf einem Host, der noch lebt. Anders ist es, wenn Du Terminalserver hast, die aus Sicht des Connection Brokers ja fix provisioniert sind. Unter solchen VMs möchte man in der Tat eine hochverfügbare Plattform haben - wenn man sie denn virtualisiert. Aber da steuert der Connection Broker auch nicht die Virtualisierung. Apropos: Denk daran, dass im Microsoft VDI-Szenario jeder User oder Client eine RDS CAL braucht, weil ja der Connection Broker (und evtl. RDWeb und RDG) im Spiel ist. Und ja, es ist so b***d wie es sich anhört: Microsoft VDI --> RDS CAL nötig XenDesktop oder View --> keine RDS CAL nötig. Will damit sagen: Wenn man auch das komplett fehlende Image Management in der Microsoft VDI mit ins Kalkül nimmt, ist es vermutlich auf lange Sicht billiger, ein Third Party VDI-Produkt einzusetzen, es sei denn, man hat die RDS CALs bereits. In diesem Fall sollte man aber die Möglichkeit von Terminalservern ausschöpfen, bevor man zu VDI greift, unabhängig vom Technologie-Anbieter.

Es ist Rußland, nicht Andorra - 20 Stück sind keine "größeren Mengen" Vermutlich ein Schreibbüro ausgestattet plus 3x Reserve,