Microsoft 365 Preisänderung per 1. Juli 2026: Defender for Office 365 Plan 1 neu in E3 enthalten

Seit dem 1. Juli 2026 gelten neue Listenpreise für Microsoft 365. Die Erhöhungen sind bitter: je nach Plan von 5 Prozent (Microsoft 365 E5) bis zu 43 Prozent bei den Frontline-Plänen, angekündigt bereits am 4. Dezember 2025. Spannender als die Prozente ist aber, was Microsoft im Gegenzug in die Suiten packt. Für die E-Mail-Sicherheit sticht eine Änderung heraus: Defender for Office 365 Plan 1 ist neu ohne Aufpreis in Microsoft 365 E3 und Office 365 E3 enthalten. Grund genug, die Preisänderung und die drei Schutzstufen für Exchange Online genauer anzuschauen.

Die neuen Listenpreise per 1. Juli 2026

Microsoft hat bisher nur die USD-Listenpreise offiziell publiziert (pro Benutzer und Monat, Annual Commitment). Bestandskunden bleiben bis zu ihrer nächsten Verlängerung auf den bisherigen Preisen.

Plan	Alt	Neu	Änderung
Microsoft 365 Business Basic	$6.00	$7.00	+16%
Microsoft 365 Business Standard	$12.50	$14.00	+12%
Microsoft 365 Business Premium	$22.00	$22.00	unverändert
Office 365 E3	$23.00	$26.00	+13%
Office 365 E5	$38.00	$41.00	+8%
Microsoft 365 E3	$36.00	$39.00	+8%
Microsoft 365 E5	$57.00	$60.00	+5%
Microsoft 365 F1 / F3	$2.25 / $8.00	$3.00 / $10.00	+33% / +25%

Bemerkenswert: Die «ohne Teams»-Varianten steigen prozentual stärker (Microsoft 365 E3 ohne Teams +11%, E5 ohne Teams +6%). Das betrifft auch Schweizer Kunden, da Microsoft die Teams-Entbündelung hier ebenfalls anbietet; auf microsoft.com heissen diese Pläne «EWR (ohne Teams)».

Das Packaging-Update: Diese Funktionen kommen dazu

Microsoft begründet die Erhöhung mit einer Wertsteigerung der Suiten. Der Rollout der neuen Funktionen läuft seit Juni 2026 und soll bis am 1. August 2026 abgeschlossen sein; Tenants erhalten 30 Tage vorher eine Ankündigung im Message Center. Für E-Mail-Administratoren relevant:

Exchange Online - Meeting Organizer bald übertragbar

Ein Benutzer verlässt die Firma – und plötzlich gehört ihm noch eine wichtige wiederkehrende Teams-Besprechung. Für Admins bedeutet das bis heute: unsaubere Workarounds oder kompletter Neuaufbau der Serie.

Microsoft hat nun ein neues PowerShell Cmdlet für Exchange Online angekündigt, das genau dieses Problem adressieren soll. In diesem Beitrag: was bereits bekannt ist, was noch fehlt und wie ihr prüft, ob das Feature in eurem Tenant verfügbar ist.

Das Problem bisher

Für verwaiste Meeting-Serien gab es bisher nur drei Optionen:

• Serie löschen und neu erstellen → Historie geht verloren
• Serie unverändert bestehen lassen → faktisch nicht mehr administrierbar
• Shared Mailbox für den alten Organisator → langfristig keiner zuständig

Keine dieser Varianten ist in produktiven Umgebungen wirklich zufriedenstellend.

Was das neue Cmdlet können soll

Das neue Exchange Online Cmdlet soll es ermöglichen, den Organisator eines Meetings oder einer gesamten Serie zu ändern – ohne Neuaufbau und ohne Verlust der Historie.

Der neue Organisator soll dabei vollständig übernehmen:

• Wiederholungseinstellungen
• Teilnehmerliste
• Titel und Beschreibung
• Teams-Meeting-Link

Display Name Spoofing – Was steckt hinter dem Absendernamen?

Phishing-Angriffe setzen oft nicht auf gefälschte Domains oder komplexe Technik – sie missbrauchen einfach den Anzeigenamen im Absenderfeld einer E-Mail. Das nennt sich Display Name Spoofing, und es ist erschreckend einfach umzusetzen.

Was ist Display-Name-Spoofing?

Der Anzeigename im Absenderfeld («From») ist frei wählbar – z. B. Hans Muster, CEO. Die eigentliche Absenderadresse (z. B. hans.muster.ceo@betrug-mail.com) stimmt dabei nicht mit der Identität überein. Viele Mailprogramme zeigen standardmässig nur den Anzeigenamen an, die vollständige Adresse bleibt verborgen.

Typische Merkmale:

• Der Anzeigename entspricht einer bekannten Person (z. B. CEO, Finanzleiter, IT-Administrator)
• Die E-Mail-Adresse dahinter gehört nicht zur Organisation
• Ziel ist meist, Empfänger zu Überweisungen, dem Teilen vertraulicher Daten oder dem Öffnen von Schadlinks zu bewegen

Wie erkennt Microsoft solche Angriffe?

Bei reinem Display-Name-Spoofing schlägt SPF/DKIM/DMARC nicht fehl – die Absenderdomain (z. B. @gmail.com) ist technisch legitim authentifiziert. Microsoft Defender for Office 365 setzt deshalb auf eine Kombination aus modernen Erkennungsmethoden:

SPF, DKIM und DMARC – Was steckt dahinter und warum lohnt sich die Auswertung?

E-Mail ist nach wie vor das wichtigste Kommunikationsmittel im Geschäftsalltag – und gleichzeitig eines der beliebtesten Angriffsziele. Phishing, Spam und Domain-Spoofing nehmen zu. Mit SPF, DKIM und DMARC stehen drei bewährte Mechanismen zur Verfügung, die zusammen einen wirksamen Schutz bilden. In diesem Beitrag erkläre ich, wie die drei Protokolle funktionieren, was Alignment bedeutet und welchen konkreten Nutzen die Auswertung von DMARC-Reports bringt.

Die drei Säulen der E-Mail-Authentifizierung

SPF (Sender Policy Framework) legt fest, welche Mailserver berechtigt sind, E-Mails im Namen einer Domain zu versenden. Der Eintrag wird als TXT-Record im DNS veröffentlicht. Exchange Online-Kunden verwenden typischerweise:

v=spf1 include:spf.protection.outlook.com -all

DKIM (DomainKeys Identified Mail) versieht ausgehende E-Mails mit einer digitalen Signatur. Der empfangende Mailserver kann anhand eines öffentlichen Schlüssels im DNS prüfen, ob die Nachricht unverändert ist und wirklich von der angegebenen Domain stammt.

DMARC (Domain-based Message Authentication, Reporting and Conformance) baut auf SPF und DKIM auf. Es legt fest, wie ein empfangender Mailserver mit Nachrichten umgehen soll, die die Prüfungen nicht bestehen – und liefert Reports darüber, was im Namen der eigenen Domain versendet wird.

Entfernung des letzten lokalen Exchange Servers nach Hybridbetrieb

Einleitung

Dieser Post beschreibt den vollständigen und unterstützten Ablauf, um den letzten lokalen Exchange Server nach einer abgeschlossenen Hybridmigration ausser Betrieb zu nehmen. Es richtet sich an Umgebungen, in denen alle produktiven Postfächer bereits nach Exchange Online migriert wurden, die Identitäten jedoch weiterhin im lokalen Active Directory verwaltet und über Azure AD Connect mit Microsoft Entra ID (Azure AD) synchronisiert werden.

Ziel ist es, den lokalen Exchange Server sicher zu entfernen, ohne die Empfängerverwaltung zu verlieren, und gleichzeitig sicherzustellen, dass keine hybriden Abhängigkeiten mehr bestehen. Dabei werden die Exchange Server SE Management Tools zur weiteren Verwaltung verwendet, und das Microsoft-Skript CleanupActiveDirectoryEMT.ps1 sorgt für die abschliessende Bereinigung der lokalen Active Directory-Objekte.

Checkliste

1)       Ausgangslage prüfen

• Alle produktiven Postfächer sind in Exchange Online. Keine Benutzer-, Shared-, Ressourcen- oder Archivpostfächer mehr on-prem.
  Beispiel vor Ort:

    Set-ADServerSettings -ViewEntireForest $true
Get-Mailbox -ResultSize Unlimited

Exchange SE Lizenzen

Lizenzsituation Exchange Server im Hybridbetrieb

Du planst 2 lokale Exchange-Server, die mit Exchange Online verbunden sind (Hybrid). Die Lizenzkosten hängen davon ab, ob es noch lokale Postfächer gibt und welche Microsoft 365 Lizenzen im Einsatz sind.

---

1. Alle Postfächer in der Cloud → kostenlose Hybridlizenz

• Wenn wirklich kein einziges Postfach On-Prem liegt, kannst du den kostenlosen Exchange Hybrid Server einsetzen.

• Keine Kosten für Serverlizenzen oder CALs.

• Lizenz wird über den Hybrid Configuration Wizard angefordert.

• Einschränkung: Die kostenlose Hybridlizenz darf nur für einen einzelnen Exchange-Server genutzt werden – kein zweiter Server für Hochverfügbarkeit oder Lastverteilung möglich.

---

2. Lokale Postfächer vorhanden, alle Benutzer mit Microsoft 365 E3/E5

• E3/E5 enthalten die Exchange-CAL-Rechte für On-Prem-Zugriff.

• Du brauchst nur die Serverlizenzen (Exchange SE Standard inkl. SA).

• 2 Server: aktuell ca. CHF 1’000 pro Jahr, ab Juli 2025 ca. CHF 1’100 pro Jahr (+10 % Preissteigerung).

---

3. Lokale Postfächer vorhanden, nicht alle Benutzer mit M365 E3/E5

• Für Benutzer ohne E3/E5 brauchst du zusätzlich CALs (ca. CHF 62 pro Benutzer/Jahr).

• Beispiel mit 5 lokalen Benutzern:

  • Serverlizenzen: CHF 1’000/Jahr

  • CALs: CHF 310/Jahr

  • Total: aktuell ca. CHF 1’310/Jahr, ab Juli 2025 ca. CHF 1’457/Jahr (wegen +10 % Serverpreis, +15 % CAL-Preis).

---

Fazit:

• Am günstigsten ist es, wenn alle Benutzer E3/E5 haben – dann fallen nur Serverkosten an.

• Wenn keine lokalen Postfächer vorhanden sind, kannst du komplett kostenlos mit der Hybridlizenz arbeiten, musst aber auf Hochverfügbarkeit verzichten.

• Sobald ein Postfach On-Prem liegt, reicht die Hybridlizenz nicht mehr aus.

Hyper-V Livemigration auf Windows Server Core schlägt fehl (0x8009030D)

 Die Installation eines Hyper-V Hostes mit Windows Server Core bietet sich an. Oder ihr verwendet eine der kostenlosen Windows Versionen "Hyper-V Server 2016" oder "Hyper-V Server 2019". Die kosten nichts, können aber nicht mit Desktop experience installiert werden.

Die Verwaltung der virtuellen Computer auf dem Hyper-V Host lässt sich wunderbar remote erledigen.

Doch vor kurzem habe ich doch etwas gefunden, was sich von der Ferne schlecht erledigen lässt. Wie ihr sicher wisst, funktionieren Livemigrationen von virtuellen Computern zwischen Hyper-V Hosts, auch wenn sie sich nicht als Cluster verbunden sind. Am einfachsten geht das zwischen Hyper-V Host welche Mitglied der gleichen Domäne sind.

Ich hatte damit nie Probleme, bis ich versucht habe eine VM per Livemigration von einem Hyper-V Host auf einen anderen Hyper-V Host zu verschieben und bei der Hyper-V Host's waren mit Windows Server Core installiert. Mir wurde eine unschöne Fehlermeldung angezeigt, die besagte, dass die Authentifizierung zwischen den Hyper-V Hosts nicht funktionierte und darum die VM nicht verschoben werden kann.

Dies ist die Fehlermeldung als Text:

Failed to establish a connection with host 'host name': No credentials are available in the security package (0x8009030E)

und in Deutsch:

Fehler beim Herstellen einer Verbindung mit dem Host 'host name': Die Anmeldeinformationen, die dem Paket übergeben wurden, wurden nicht erkannt. (0x8009030D).

Das Problem ist, dass für die Authentifizierung zwischen den Hyper-V Hosts standardmässig CredSSP verwendet wird. Dies hat einen entscheidenden Nachteil: 

Man muss interaktiv an dem Hyper-V Host angemeldet sein, von dem aus man die Livemigration startet. Nur lässt sich auf einem Windows Server Core die Hyper-V Verwaltungskonsole nicht installieren. Man verwaltet die VMs aus der Ferne auf einem Admin-Server mit GUI.

Es gibt viele Vorschläge, wie man diese Problem lösen kann. Aus meiner Sicht ist es aber am einfachsten, die Livemigrationen direkt auf dem Hyper-V Host mit PowerShell zu starten:

Move-VM -Name Test-VM001 -DestinationHost Host01 -IncludeStorage -DestinationStoragePath "D:\Hyper-V\Test-VM001"