dartzen

Das geht schon, mit halt der Einschränkung, dass es das "www" vorne vor braucht. Ist wie gesagt auch die Konstellation bei uns und das funktioniert wie es soll. Den Rest macht der korrekt konfigurierte Webserver.

So logisch ist das nicht, eine identische Konfiguration existiert bei uns auch und die funktioniert wie sie soll. Also eine Host-A Eintrag im internen Windows DNS www der dann auf die öffentliche IP des Servers beim Hoster zeigt. Am Server des Hosters wird dann trotzdem anhand der eingegebenen URL die richtige Webseite aufgerufen. Habt ihr eventuell mehr als einen DNS Server und die Einträge sind nicht synchron? Oder irgendein System, dass URL-Rewrite betreibt?

Das steht doch auch in dem von mir zitierten und verlinkten Blogpost hier drin, dass wenn man Exchange 2019 + CALs jeweils mit SA hat ist man für SE "sauber", man muss halt nur die SA aktiv halten, wenn die 3 Jahre dann rum sind. Das war ja auch deren Empfehlung für Kunden, die keine Cloud Lizenz haben, bevor der SE veröffentlicht wurde und man direkt dessen Lizenzen erwerben konnte. PS: Da habe ich ja eine Diskussion losgetreten, warum muss das bei MS so kompliziert sein.

Ich möchte dir nur sehr ungern widersprechen, da du mit ziemlicher Sicherheit mehr Ahnung von der MS-Lizenzierung hast als ich. Aber in den Informationen zum Upgrade steht das anders. Da steht explizit: Mal abgesehen davon, dass die den Fall mit E3 Lizenzen ohne "Extended Use Right" dort nicht erwähnen würde das ja trotzdem bedeuten, dass ich für den Server SA brauche. Das ist ja gerade der große Unterschied zu früher, wo SA optional war. Ist dann nach meinem Verständnis vergleichbar mit den Core Lizenzen für den SQL-Server, da brauche ich ja auch zwingend SA, um den benutzen zu dürfen.

Das gilt aber ja nicht für Exchange Server SE, da ich dort zwingend SA haben muss um ihn benutzen zu dürfen. D.h. ohne Verlängerung der SA kein korrekt lizenzierter Exchange mehr. Auch wenn der zumindest nach aktuellem Stand technisch seinen Dienst nicht einstellt, da es im Exchange keine Online Lizenzprüfung gibt, ab dem Moment wäre man ja Lizenzbrüchig.

So wie es mir unser Systemhaus nach Rücksprache mit der Distribution erklärt hat sind die User-CALs durch das M365 E3 durchaus abgedeckt, nur der Server selbst halt nicht wegen dem fehlenden "Extended Use Rights" der CSP Bedingungen bzw. dem MCA. Daher bräuchten wir laut deren Aussage nur die Serverlizenz plus SA. Den dann aktuell halt als OV, da es den ja (zumindest derzeit) in CSP nicht gibt. In den CAL Equivalenten https://www.microsoft.com/licensing/terms/product/CALandMLEquivalencyLicenses/MCA steht zwar derzeit nur der 2019er drin, aber das tut er beim EA auch (und da heißt es ja explizit, dass das mit drin ist), das haben die anscheinend aktuell noch nicht auf den SE angepasst.

Ich habe jetzt mal von unserem Systemhaus ein Angebot über die Serverlizenz mit 3 Jahren SA als OV bekommen. Ist tatsächlich nicht annähernd so teuer, wie ich befürchtet habe. Allerdings musste man uns "Lückenfüllerlizenzen" mit anbieten, da man wohl mindestens 5 Lizenzen in einem OV-Vertrag benötigt. Die kosten aber pro Stück nur ein paar Euros. Wir haben aber mit denen abgesprochen, dass wir nochmal etwas abwarten, ob die Lizenz auch per CSP noch angeboten werden kann. Danke noch mal an alle, die sich hier rege beteiligt haben.

Das Skript macht im wesentlichen nichts anderes wie die hier bereits genannten Kommandos auszuführen inkl. der ProvisionedPackages. Nur halt in einer Schleife für alle gewünschten Apps und das Ganze dann mit Ergebnissen in einer Log-Datei.

Dann erklärt man denen, dass das Problem auf der anderen Seite liegt und man selbst da nichts machen kann. Muss ich unseren Leuten regelmäßig mitteilen, wenn mal wieder Mails wegen fehlerhaftem DKIM oder Absender-IPs auf RBLs abgelehnt werden. Ich gebe denen dann die entsprechende Info, die die dann im Zweifel dem Absender mitteilen können. Muss man halt nur durchziehen, das Log ist auf meiner Seite.

Gut zu wissen, dass das Paketabhängig ist. Wäre ja auch zu schön, wenn sich das konsistent verhalten würde.

Hast du die Befehle in einer administrativen Powershell laufen lassen? Nur dann funktioniert der Schalter -AllUsers. Ansonsten deinstalliert er nur für den angemeldeten Benutzer. Gilt das nicht nur für Nutzer, die noch nie angemeldet waren? Ich hatte das so verstanden, dass das Remove-AppxPackage mit -AllUsers für alle vorhandenen Profile greift und die ProvsionedPackages dann für neue.

Ups, das kommt davon wenn man Befehle tippt statt sie zu kopieren. Hab's korrigiert, danke für den Hinweis.

Ich schließe mich den Kollegen an, Catch-All ist etwas, was man möglichst nicht haben will. Das NDRs bei manchen Absendern nicht anzukommen scheinen hatten wir auch schon mal, aber ganz ehrlich, dafür würde ich mir die Nachteile des Catch-All definitiv nicht antun wollen. Wenn ich sehe was auf unserem Mailgateway alles aufschlägt und abgewiesen wird würde ich ja aus dem Aussortieren gar nicht mehr rauskommen.

Hallo Bourbon, das geht grundsätzlich mit dem "Remove AppxPackage" Kommando in Powershell. Für Copilot und das neue Outlook wären das dann diese: Get-AppxPackage -Name Microsoft.Copilot | Remove-AppxPackage -AllUsers Get-AppxPackage -Name Microsoft.MicrosoftOfficeHub | Remove-AppxPackage -AllUsers Get-AppxPackage -Name Microsoft.OutlookForWindows | Remove-AppxPackage -AllUsers Der zweite ist übrigens für den "M365 Copilot". Das gilt aber alles meine ich nur für bereits bestehende Nutzer, nicht für welche, die sich erstmals an dem Rechner anmelden. Dafür müsstest du das Ganze dann mit "Remove-AppxProvisionedPackage" machen, aber das klappt mit dem Copilot zumindest bei mir nicht, da der dort nicht auftaucht.

Wir setzen nur einen Exchange ein, und haben knapp 100 User, die den benutzen. Den Exchange 2019 hatten wir damals über einen Open-Value Vertrag lizenziert, sowie auch unsere Windows Clients. Für Office hatten wir O365 Business Premium, weil da Teams mit bei war. Als dann der Open-Value ausgelaufen ist sagte man uns, dass MS diese Art Verträge nicht mehr verlängert. Da wir zu dem Zeitpunkt auch angefangen haben VDI einzuführen, hätten wir sowieso Windows Clients nachlizenzieren müssen und da kam dann das Angebot, alles über M365 E3 abzubilden, da hier ja auch die Windows Lizenzen pro User abgedeckt sind, sowie alle nötigen CALs für den Exchange. Das war dann kostenmäßig für uns die sinnvollste Variante, wir wollten aber mit den Servern halt On-Prem bleiben und nicht zu Exchange Online wechseln. Unser Systemhaus hat's mir so erklärt, dass die E3 Lizenz zwar die CALs abdecken würden, aber nicht den Server selbst. Und den können die uns als CSP derzeit auch nicht anbieten, es gibt ihn dort schlicht nicht im Angebot. Ich finde es halt extrem fies, dass MS in den Blogposts die ganze Zeit davon schreibt (und auch in den Kommentaren auf Nachfrage bestätigt hat) dass eine M365 E3/E5 Lizenz das Produkt komplett abdeckt und man nichts weiter braucht. Verlinken sogar die Nutzungsbedingungen, wo das "Extended Use Right" erklärt wird, ohne aber irgendwie darauf hinzuweisen, dass das nicht in allen Szenarien gilt. Aktuell schweigen die sich in den Kommentaren zum Blogpost zu den entsprechenden Rückfragen zu CSP auch komplett aus.

OK, ich habe jetzt zumindest schon mal von unserem Systemhaus die Info bekommen, dass unsere Lizenzen tatsächlich CSP Lizenzen sind und man uns, zumindest aktuell, den Exchange SE nicht mal anbieten kann. Herzlichen Glückwunsch. Bin ja mal gespannt, ob sich das bis Oktober noch ändert, ansonsten wird's lustig. Danke mal wieder für nichts, Microsoft. Danke an alle, die hier Ihre Kenntnisse zusammen getragen haben.

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.