dartzen

Ja, da steht als Kanal "Handelspartner" und dann entsprechend da dann ALSO. Unter "Abrechnungskonto" steht dann wiederum als Typ "Microsoft Kundenvereinbarung". Ich werde dann denke ich tatsächlich mal unserem Systemhaus eine Anfrage schicken um das klären. Als wir damals von Office 365 Business Premium nach Microsoft 365 E3 gewechselt sind war die Geschichte mit der "Extended Use Right" für uns nämlich auch schon relevant. Finde ich aber trotzdem sehr "unfein", dass die gleichen Lizenzen unterschiedlich bewertet werden, je nachdem über wen man die kauft.

Erst mal danke für eure Antwort. Woran erkenne ich aber nun, ob meine Lizenz eine CSP ist oder nicht? Das ist für mich gerade immer noch nicht ganz ersichtlich.

Hallo zusammen, ich stolpere gerade ein bisschen über die Lizenzbedingungen für den Exchange Server SE und erhoffe mir etwas Erleuchtung. Laut dem Microsoft Blog Post hier ist man ja mit M365 E3 Lizenzen berechtigt, den Exchange SE On-Prem zu betreiben (Extended Use Right). Das war ja mit dem Exchange 2019, den wir aktuell verwenden, auch so. Trotzdem sehe ich bisher den Exchange Server SE noch nicht im Admin-Center, was aktuell ja noch nicht schlimm ist, da man ja erst später einen neuen Key benötigt. Nun gibt es aber in den Kommentaren des Blogeintrags zum Release des Exchange SE diese Diskussion. Hier wird dann von Nutzern aufgeführt, dass das Extended Use Right nicht für E3/E5 Lizenzen gilt, die über einen CSP bezogen werden, für die gäbe es momentan keine Möglichkeit, den SE zu lizenzieren. Es hat sich aber noch kein MS Mitarbeiter dazu geäußert. Ich bin daher jetzt verunsichert, wir haben unsere Lizenzen von einem Systemhaus, die wiederum beziehen die über den Distributor ALSO. Die ALSO steht bei uns auch im Tenant als Partner für die Lizenz drin. Die Lizenz an sich heißt "(NCE) Microsoft 365 E3". Ist das jetzt eine CSP-Lizenz oder eine "normale"? Und woran erkenne ich das? Ich muss gestehen, dass ich bisher nicht mal wusste, dass es unterschiedliche Lizenzen mit dem gleichen Namen gibt. Wenn mir da jemand auf die Sprünge helfen könnte wäre ich dankbar. Danke schön.

Wir haben bei uns die beiden Gruppenrichtlinien "Point-and-Print Einschränkungen" auf "aktiviert" und "Point-and-Print für Pakete - Genehmigte Server" auf "aktiviert". Bei beiden entsprechend den FQDN des Printservers eingetragen. Bei der "Einschränkungen" GPO dann nur die Sicherheitshinweise ausgeschaltet. Das funktioniert bei uns problemlos, die Drucker können entweder über "Drucker und Geräte" oder über den FQDN des Printservers angebunden werden.

OK, das mit dem OneDrive war mir nicht bewusst, ich hatte das Appx-Paket "OneDriveSync" im Verdacht und mich dann gewundert, dass sich das in den Provisioned Packages nicht findet. Kriege ich das auch schon vor Installation aus dem Image irgendwie raus? Genau das Paket meine ich, dass ist irgendwie erst da, wenn sich ein Benutzer anmeldet aber nicht in den Provsioned Packages der aktuellen install.wim. Das löschen über das Kommando hatte ich versucht, es wird damit auch beim aktuellen Benutzer entfernt, aber sobald sich ein neuer Benutzer anmeldet ist es für ihn wieder da. Das -AllUsers scheint hier irgendwie nicht zu greifen oder nur für bestehende Nutzerprofile, nicht für ganz neue. Sieht man auch sehr schön mit Get-AppxPackage-allusers, da taucht das weiterhin auf,

Hallo zusammen, ich stehe gerade irgendwie auf dem Schlauch und bräuchte mal einen Denkanstoß von euch bitte. Bei uns werden die Clients per Softwareverteilung mit Windows betankt, dafür haben wir bisher immer die Standard ISOs aus dem M365-Portal verwendet. Da ja inzwischen jede Menge "Müll" mit vorinstalliert wird (Outlook new z.Bsp.) habe ich mir mal die Mühe gemacht die unerwünschten Pakete aus der install.wim zu entfernen. Klappt soweit auch, aber ich scheitere daran, den Copilot (nicht M365-Copilot, den habe ich gefunden und bin den auch losgeworden) und OneDrive loszuwerden. Wenn ich die install.wim mounte und dann mit "Get-AppxProvisionedPackage" schaue finde ich da beide nicht. Entsprechend kann ich die auch nicht rausnehmen. Beides ist aber nach der Installation vorhanden und für jeden Benutzer installiert, der sich anmeldet, im Fall von OneDrive sogar im Autostart. Kann mir einer von euch einen Tipp geben, wie ich die aus dem Installationsimage rausbekomme? Lieben Dank.

Ein ziemlich großes Problem scheint es in Verbindung mit ReFS zu geben. Im Veeam Forum wurde das ziemlich ausführlich diskutiert, dass es da wohl massiv Probleme mit Auslastung von CPU/RAM zu geben scheint, weswegen Server sogar komplett unbenutzbar wurden. MS hat das Problem Veeam gegenüber bestätigt, gibt aber so weit ich weiß noch keine Lösung dafür. Falls das jemand nachlesen möchte, hier ist der Beitrag im Veeam Forum: https://forums.veeam.com/veeam-backup-replication-f2/server-20225-high-cpu-and-ram-t96912.html

Grundsätzlich hast du Recht, wobei wirklich weg sind die ja nicht sofort, sondern erst nach der eingestellten Löschzeit, default müssten das 30 Tage sein. Solange kann man das ja jederzeit wieder aktivieren und es ist noch alles da. Löschen nimmt ja direkt den AD-User mit, was man vielleicht nicht unbedingt will.

Hi, zum ESET kann ich nichts sagen, aber der Rest stimmt soweit. Das Postfach und dessen Funktion Mails anzunehmen interessiert nicht, ob der AD-Benutzer deaktiviert ist oder nicht, es muss der Benutzer nur existieren. Das deaktivieren im AD verhindert nur, dass sich der Benutzer anmelden kann. Dieses Verhalten ist auch so gewollt, da z.Bsp. freigegebene Postfächer per default genau diese Konstellation haben, also aktiviertes Postfach und deaktivierter Benutzer. Daher muss man das Postfach im Exchange separat deaktivieren. Achtung Falle: Nicht das Postfach löschen, das löscht auch automatisch den User im AD. Außerdem werden die Mails des deaktivierten Postfachs nach 30 Tagen gelöscht. Solange das noch nicht passiert ist, kann man das Postfach inkl. Inhalt jederzeit wieder aktivieren und einem User zuordnen.

OK, ich hatte das nicht auf dem Schirm, dass die das rausgenommen haben. Wie gesagt war bei mir schon länger her, dass ich als Dienstleister mit TeamViewer gearbeitet habe und damals ging das noch (und war auch gefühlt immer notwendig damit das sauber funktionierte). Daher war das so das erste, was mir dazu einfiel. Das mit der Konsolensitzung im Taskmanager kenne ich auch nur so, dass die Sitzung nur angezeigt wird, wenn auch wirklich ein User direkt angemeldet ist. Macht ansonsten ja auch wenig Sinn. Kann man übrigens auch sehr schon über ein quser sehen, der zeigt das gleiche an. Dafür musst du nicht mal am Server angemeldet sein, du kannst auf einem anderen PC in der cmd mit "quser /server:<Servername>" alle Sitzungen auf dem Server anzeigen lassen. Da wird auch keine Console angezeigt, wenn keiner angemeldet ist. Aber vielleicht hat noch ein anderer Forenteilnehmer eine zündende Idee.

Hallo Samoth, ich lese aus deiner Beschreibung heraus, das TeamViewer das Tool ist. Verstehe ich das korrekt, du möchtest dich per TeamViewer auf dieses Server verbinden? Falls ja ist die Aussage vom Support teilweise irreführend und teilweise auch schlicht falsch. Prüfe mal in den Einstellungen vom TeamViewer auf dem Server, ob dort der "Mehrbenutzermodus" aktiv ist. Wenn ja dann ausschalten und anschließend die neue ID merken. Langfassung: Ist schon etwas her, seit ich das letzte Mal mit zu tun hatte, aber ich kann mich an ein ähnliches Problem erinnern. Da war es so, dass obwohl "unbeaufsichtigter Zugriff" eingerichtet war und der Teamviewer somit als Dienst lief, sich man sich nicht verbinden konnte, wenn die Usersitzung nicht angemeldet war, von der man sich die ID aufgeschrieben hatte, bzw. die man in der Geräteliste hatte. Das lag daran, dass der TeamViewer auf einem Server standardmäßig im Mehrbenutzermodus startet und somit für jeden angemeldeten Benutzer eine eigene ID erzeugt. Diese ist aber nur dann verbunden, wenn auch der Nutzer angemeldet ist. Wenn man diese Funktion ausschaltet sieht man als ID die "Geräte-ID", die ist immer erreichbar, wenn der Server an ist und der TeamViewer Dienst läuft. Völlig unabhängig von irgendwelchen Nutzern.