Das Microsoft Build Event ist eines der wichtigsten Veranstaltungen für Entwickler und IT-Profis weltweit. Jedes Jahr werden neue Innovationen und Technologien aus dem Microsoft-Ökosystem präsentiert. Obwohl der Fokus auf Entwicklern liegt, gehen in der Microsoft-Cloud-Welt inzwischen so ziemlich alle Bereiche fließend ineinander über. Daher ist es falsch zu erwarten, dass auf einem Entwicklerevent nur Dinge vorgestellt werden, die ausschließlich Entwickler betreffen.
Ich konnte die meisten Themen überspringen, da sie für mich als Integrator nicht wirklich relevant sind, und musste mich durch einen Sumpf an KI-Buzzwords kämpfen (das diesjährige Book of News erwähnte 207 Mal AI und 167 Mal Copilot). Zwischen all den Sessions gibt es jedoch letztendlich wertvolle Informationen zu den Themen Azure, Security, Windows, Edge und M365.
Die GenAI-Hypewelle schwappt ohnehin schon so ziemlich alles aus diesem Bereich in unsere Feeds, daher starte ich in diesem Artikel mit den News, die nicht aus dem KI-Feld stammen. Die KI-Features, die ich interesant fand folgen in Part 2.
Falls nicht klar genug, ich versuche hier nicht ein umfassendes Summary des Events zu geben, sondern habe die Nachrichten gesammelt, zu denen ich Gedanken habe 😉
Security
Dafür, dass Microsoft Security über alles priorisiert hat, haben mich keine Ankündigungen in dem Bereich besonders beeindruckt. Allerdings muss man beachten, dass diese neue Ausrichtung in der Enterprise Timeline noch sehr frisch ist – ich bin daher gespannt, was in zukünftigen Events angekündigt wird.
Windows Security
Die meisten neuen Windows Security Features sind in der Theorie sehr gut, eine bessere Zusammenfassung findet sich im dedizierten Security Blog Post.
Das wichtigste Takeaway ist für mich, dass das Ende von NTLM immer näher rückt. Ein Plan für das zweite Halbjahr 2024 wurde genannt – falls bei euch noch nicht NTLM auditiert und abgelöst haben, findet ihr hier ein Blog Post was gemacht werden muss.
Ein neues interessantes Werkzeug zur Steuerung von Netzwerk Traffic ist Zero Trust DNS. Wenn aktiviert, kann Nutzung eines vertrauenswürdigen DNS erzwungen werden. Auf unerwünschtem Wege aufgelöste IP-Adressen werden blockiert. Dies erschwert beispielsweise die Verbindung von Malware mit Command-and-Control-Servern sowie die Umgehung von DNS Blocklisten. Dabei wird es notwendig sein, einige Ausnahmen zu pflegen. Gerade in Zeiten, in denen wir unsere Clients nicht durch Firewalls auf Infrastrukturebene steuern können, sind mehr Client-Level-Kontrollen sehr willkommen.
Wie Zero Trust DNS konfiguriert wird und welche Erfahrungswerte in der realen Welt gesammelt werden, werden wir sehen, wenn das Feature aus Private Preview herauskommt.
Es wurden auch einige Features vorgestellt, die auf Virtualization Based Security (VBS) basieren – also der Isolation von besonders schützenswerten Prozessen vom lokalen Administrator und möglichen Schwächen im Host-Betriebssystem, indem sie in einer eigenen virtuellen Umgebung ausgeführt werden.
An sich handelt es sich um gute Features, ich habe jedoch ein fundamentales Problem mit ihnen: Die Architektur ist extrem Windows-spezifisch und komplex. Ich habe Schwierigkeiten mir vorzustellen, dass Drittanbieter-Softwareentwickler sich so eng an Microsoft-Sicherheitsmechanismen binden werden – ich glaube, die Nachfrage ist einfach nicht da. Vor allem, wenn man darüber nachdenkt, wie oft erschreckende Sicherheitspraktiken in der Softwareentwicklung noch in freier Wildbahn anzufinden sind – von Klartext-Passwortdatenbanken bis hin zu Geheimnissen im Code. Die Implementierung von VBS wird wahrscheinlich – hoffentlich – weit unten auf der Prioritätenliste für sehr viele Entwickler stehen, selbst wenn Zeit für Security bleibt. Diese Features müssten in Bibliotheken eingebaut oder vom Betriebssystem bei der Laufzeit übernommen werden, sonst wird sich daran so schnell nichts ändern… es sei denn…
Attestation, Trusted Signing, Smart App Control – Microsoft übernimmt zunehmend die Kontrolle darüber, welche Software vertrauenswürdig ist und welche nicht. Ich gehe davon aus, dass (unter anderem) diese Sicherheitsmechanismen immer häufiger verpflichtend werden, damit eine App überhaupt auf Windows laufen darf. Die Grundprinzipien sind gut, und ich unterstütze sie im Unternehmensbereich vollständig, sofern weiterhin Ausnahmen gesteuert werden dürfen. Für Privatpersonen bin ich jedoch kein Fan davon, dass eine Organisation entscheidet, was ausgeführt werden darf, insbesondere wenn diese Organisation zunehmend eigene Konkurrenzprodukte für jede etablierte Softwarekategorie anbietet.
Power Platform Security Hub
Auch in der Power Platform sind Governance und Sicherheit wichtig, da hier oft geschäftskritische Abläufe mit teilweise sehr hohen Rechten entwickelt werden. Entsprechend war ich sehr erfreut zu sehen, wie der Gedanke der Secure Scores weiter verfolgt wird – eine Übersicht, die leicht verständliche Empfehlungen sammelt, um die Sicherheit zu verbessern. Und das was hier Empfohlen wird sieht schon mal gut aus und wird sicherlich laufend erweitert.
Wird dies dort helfen, wo Organisationen in ihrem Tenant noch nie im Power Platform Admin Center waren und vielleicht sogar Self-Service-Käufe aktiviert sind? Wahrscheinlich nicht – aber es bietet zumindest einen guten Ausgangspunkt, wenn man sich doch dorthin verirrt.
Mein absolutes Highlight wäre gewesen: Support für Managed Identities. Die Häufigkeit, mit der ich Programmlogik sehe, die mit den Anmeldeinformationen regulärer Benutzer arbeitet oder abgelaufene Geheimnisse aufwendiges Troubleshooting verursachen, ist definitiv zu hoch. Auch für die Ersteller der Flows und Apps wäre es ein Segen, sich weniger um Anmeldeinformationen Gedanken machen zu müssen. Ich spreche das an, da Microsoft im März erst Hoffnungen geweckt hat:
Aber es scheint, dass ich noch eine Weile warten muss – eine eigene API-Implementierung dafür zu bauen, halte ich doch für etwas übertrieben.
- Hier würde ich auf eine Microsoft Doku das Security Hub verweisen, wenn ich eine finden könnte 🤣
- Build Power Platform Blog
Edge for Business
Wer sich mit der Kontrolle von Datentransfers in M365 auf dem Desktop beschäftigt hat, wird wissen, dass bisherige Lösungen oft unhandlich oder beschränkt sind. Mit neuen Features nähert sich Edge for Business dem Prinzip der Intune App protection policies – granulare Steuerung einzelner Applikationen auf fremden Geräten. Ich belasse es mal bei der Anmerkung, dass Feature-Parität zu Defender for Cloud App Policies ohne die entsprechenden Schwächen sehr willkommen wäre. Ich werde hoffentlich in naher Zukunft tiefer in dieses Thema einsteigen 😉
Also hier die Kurzfassung:
-
- Wie auch schon in einigen anderen Lösungen möglich, kann Edge demnächst das Erstellen von Screenshots und Bildschirmaufzeichnungen erschweren
- Dieses Feature wird "in den kommenden Monaten" verfügbar sein
-
Mehr Kontrolle durch Sensitivity Labels
- Sensitivity Labels werden wahrscheinlich mehr Auswirkungen haben, einschließlich irgendwann der kommenden Screenshot Prevention.
- Hier wird von den nächsten Wochen gesprochen, also hoffentlich passend zu der Zeit die ich mit Labeling verbringen werde
-
Defender for Cloud Apps Kontrollen durch Edge
- Edge respektiert jetzt nativ Session-Kontrollen aus MDCA, ohne durch den Reverse Proxy gehen zu müssen!
- Seit März in Public Preview, nehme ich auch die Wiederholung mit, da ich mich schon freue das ganze zu testen
Ich akzeptiere das Kürzel MDA für Defender for Cloud Apps nicht, bis die Lösung auch außerhalb des Browsers funktioniert. 😤
Azure
Entwickler nutzen im "You Build it, You Run it"-Prinzip Infrastruktur, die sie selbst aufsetzen. Entsprechend kann ich verstehen, dass auf diesem Event einige Neuerungen für Azure-Ressourcen vorgestellt wurden. Aber auch für mich als nicht-entwickelnder Azure-Nutzer sind dies Highlights:
Neues Feature: Compute Fleet
Wer schon einmal versucht hat, in kleineren Azure-Regionen (*Hust* Germany West *Hust*) mehrere virtuelle Maschinen zu erstellen, hat möglicherweise eine anstrengende Suche erlebt. Oft ist es schwierig, verfügbare Größen zu finden, manchmal schon bei wenigen Maschinen.
Um dies zu vereinfachen, sind Compute Fleets im Anmarsch. Man muss vereinfacht nur noch zwei Dinge angeben und Azure kümmert sich um den Rest:
- Die VM Größen (Sizes), die für einen in Frage kommen
- Die Anzahl der zu erreichenden Server
Dabei mag "Anzahl an VMs" sicherlich nicht immer der ideale Steuerhebel sein. Ich bin mir aber sicher, dass Granularität, wie sich die Flotte zusammensetzen soll (z.B. CPU-Kerne im Pool, RAM, etc.), folgen wird. Genauso wie hoffentlich relativ bald andere Regionen neben East und West US verfügbar werden. In den USA wird die Kostenoptimierung sicherlich das attraktivere Feature sein, aber ich finde die automatische Suche nach freien Kapazitäten interessanter. Ich zahle ja nicht die Rechnungen 😜
Falls nicht offensichtlich genug: der letzte Satz ist ein Scherz. Kostenoptimierung ist natürlich wichtig, nur für mich nicht so interessant.
Azure Functions: Flex Consumption und Visual Studio Code Web
Vorneweg: Ich mag Azure Functions, weil On-Premises Script Hosts anfällig für schwache Credentials in Form von Service Accounts und Abhängigkeitskonflikten zwischen installierten Scripts sind. Will man sich davon lösen, leisten Automation Accounts für einfache Scheduled Tasks noch gute Dienste. Sollen es aber Ausführungen auf Abruf werden, ist eine Azure Function für mich der richtige Weg. Webhooks ohne Authentifizierung bei Automation Accounts sind für mich ein No-Go.
Das Problem: Bei Azure Functions hatte man bisher vereinfacht die Wahl zwischen dem kostengünstigen "Consumption Plan" und dem teureren, aber dafür performanteren "Premium Plan". Der große Vorteil des "Consumption Plan" ist dabei, dass man praktisch nur für die ausgeführten Aufrufe zahlt. Beim "Premium Plan" hat man zwar erheblich mehr Optionen, die darunterliegenden Hosts anzupassen, jedoch trägt man dafür höhere Grundkosten.
Der größte Nachteil beim "Consumption Plan" ist der sogenannte Kaltstart, bei dem die erste Antwortzeit erheblich länger sein kann. Es muss nämlich zunächst der erste Host gestartet (provisioniert) werden, da ohne Nutzung die verfügbaren Ressourcen komplett abgebaut werden. Währenddessen kann beim "Premium Plan" immer mindestens eine Host-Instanz aktiv (heiß) bleiben, wodurch die Funktion immer sofort antwortet – aber wie gesagt, dieser Plan ist in der Regel spürbar teurer.
Können wir keinen Zwischenweg haben?
Auftritt der "Flex Consumption": Ein erweiterter Consumption Plan, bei dem wie im Premium Plan einige Instanzen immer heiß gehalten werden können.
Ist der Cold-Start kein Problem, gibt es weitere Gründe zum neuen Plan zu wechseln:
- Unterstützung für Azure VNets
- Schnelleres Scaling
- Unbegrenzte Ausführungszeiten
Ich denke jedoch, dass der Wechsel von einem Premium Plan zu einem Consumption Plan häufiger vorkommen wird. Wer bisher mit einem Consumption Plan ausgekommen ist, wird kaum bereit sein, aufgrund des höheren GB-s Preis und des niedrigeren Freibetrags extra zu zahlen 😼.
Hinderlich beim Wechsel ist auch, dass man den Plan einer bestehenden Function nicht ändern kann. Wenn man also nicht gerade Lust hat, eine ganze Reihe von Side-by-Side Migrationen zu starten, ist dies eine Überlegung für neue Azure Functions.
Auch exklusiv für den Flex Consumption Plan: Integration mit Visual Studio Code für das Web.
Das Feature soll in PowerShell Core, Python und .Net-Umgebungen verfügbar sein. Man könnte also Functions vollständig im Browser verwalten. Zwar nicht mit allen bekannten Extensions, aber in Fällen, in denen es schwierig ist, eine Verbindung aufzubauen oder wenn man kurz prüfen will, was aktuell konfiguriert ist, kann ein ordentlicher Editor das Leben sehr erleichtern.
Stand 28.05.24 schlägt bei mir in diesen Umgebungen schon das Erstellen eines HTTP-Triggers fehl. Ich finde auch keine Dokumentation, wie das aussehen sollte. 🙁
- ⚠️ Wer Infrastructure-as-Code-Deployments nutzt, sollte prüfen, ob die Eigenschaften noch passen ⚠️
- Pricing Informationen (Falls keine Preise angezeigt werden, Region wechseln)
- Flex Consumption Announcement Blog
- Flex Consumption Dokumentation
Dev Box: Bessere Governance
Dev Boxen sind eine Erweiterung des M365 Cloud PC, die zusätzliches Tooling enthält, um schneller und projektspezifisch notwendige Bibliotheken und Softwareumgebungen in VMs für Entwickler aufzusetzen. Es sind auch erheblich höhere Kapazitäten an Arbeitsspeicher und CPU-Kernen verfügbar, um den höheren Anforderungen von Entwicklern gerecht zu werden.
Generell finde ich, dass gerade diese Maschinen ein absoluter Top-Kandidat dafür sind, aus der eigenen Infrastruktur in die Cloud verbannt zu werden. Auf Entwickler-Maschinen finden sich immer wieder lokale Admin-Rechte und sonstige Sicherheitsrisiken. Je mehr Distanz man also zwischen diesen Systemen und den wirklich produktiven schaffen kann, desto besser…
Die wichtigste Neuerung aus meiner Beraterperspektive sind die neuen Möglichkeiten zur Kostenkontrolle. Hier ist die Dokumentation jedoch noch etwas dünn – ich interpretiere also aus dem Text und meinem aktuellen Verständnis. Es wird sicherlich in den nächsten Wochen mehr Klarheit geben.
Zitat aus dem Microsoft Dev Box Blog:
One of these new features is Dev Box hibernation, which helps control costs for dev boxes when they’re not in use. A hibernating Dev Box saves its current state and won’t accrue additional charges, making it ideal for when developers aren’t at work or are switching between multiple dev boxes for different tasks. To enable this feature at scale, admins can now set up automatic daily hibernation schedules or set Dev Box to hibernate when developers disconnect. When developers are ready to continue, they can quickly wake up their Dev Box and pick up right where they left off. We’re also introducing the ability to cap the number of dev boxes used on a per-developer, per-project basis, allowing for fine-tuning of this critical resource across the organization.
Hibernation soll eine schnellere Startzeit der Maschinen ermöglichen, ohne dass sie abrechnungsfähige Stunden generieren. Dies liegt bisher in den Händen der Entwickler, die jedoch nicht immer an Kosten denken können und sollen. Entsprechend wäre ein Feature, das als Alternative zum täglichen Shutdown auch administratives Hibernate ermöglicht, sehr hilfreich. Aus eigener Erfahrung weiß ich, dass es meinen Workflow erheblich stören würde, meinen Rechner täglich neu zu starten.
Bisher finde ich zum Hibernate Preview nur die Möglichkeit, Hibernation im Image zu aktivieren:
Wo ich jetzt den automatischen Hibernate und Hibernate bei Disconnect konfigurieren können soll, ist mir nicht ganz klar – ich gehe davon aus, dass dies noch Teil des Private Preview ist.
Ebenfalls angekündigt, aber zumindest für mich noch nicht sichtbar: Es soll möglich sein, in einem Projekt VM Limits pro Entwickler anzuwenden. Bisher kann man nur ein projektweites Cap angeben. Wenn man jedoch weiß, dass bestimmte Personen extra Anforderungen haben oder weniger Maschinen benötigen, wäre eine Steuerung pro Person wahrscheinlich sehr von Vorteil.
Neben den Kostenspetifischen Punkten sollen mehr Werkzeuge in die Hände von Team Leads gegeben werden, um Images nach ihren Anforderungen zu bauen. Leider habe ich hier bisher keine Demos gesehen, sondern finde nur das Preview-Sign-up. Es wäre jedoch sehr wünschenswert, dass hier tatsächlich rundum Self-Service für Entwickler möglich wird, statt dass umständlich Anforderungen zwischen Abteilungen abgestimmt werden müssen.
Microsoft Teams
Teams ist inzwischen das Werkzeug, in dem ich mindestens die Hälfte des Tages verbringe. Es ist spannend zu beobachten, wie aus einem anfänglich vielerorts Skype for Business unterlegenen Schnellschuss ein wirklich beeindruckendes Produkt geworden ist. Vor allem seitdem es nicht mehr 80 % meines Arbeitsspeichers beansprucht. Die Verbesserungen hören einfach nicht auf.
Schnellere Navigation mit Slash Commands
Teams hat inzwischen so viele Features, dass es manchmal schwer ist, die richtige Stelle zum Klicken zu finden. Dies kann daran liegen, dass man sich nicht erinnert wohin, die Knöpfe in verschachtelten Untermenüs versteckt sind oder alles zu klein wird. Wer beispielsweise aus Confluence kennt, mit einem Tastenschlag Zugriff auf alle gängigen Features zu haben, wird sich freuen, dass im Juni den Rollout beginnt. Für diejenigen, die es noch nicht kennen: besser als die Microsoft-Demo kann ich es nicht erklären:
Meet Now in Group Chats
Wenn man mit einer bestimmten Gruppe von Leuten telefonieren wollte, war es bisher etwas umständlich, einfach alle anzurufen. Kennt ihr Nachrichten im Format "Hey, ich bin wieder da, kannst du mich noch mal dazu holen?" Jetzt können auch Nachzügler in Gruppenchats mit dazukommen und mitreden.
Aus Protest erwähne ich nur kurz Features, die nicht in Teams Premium sein sollten:
Granularere Steuerung durch den Organisator, wer Aufzeichnungen und Transkriptionen starten kann
Den eigenen Benutzern verbieten, in den Meetings anderer Organisationen ihren Bildschirm zu teilen
- Offensichtlicher Bypass (?): Der Benutzer meldet sich ab und nimmt anonym am Meeting teil
Windows on ARM – Third Times the Charm ?
Hätte sich Microsoft noch nie an ARM versucht, wäre diese Ankündigung viel bedeutender. ARM-Chips bieten eine deutlich höhere Energieeffizienz und sind für typische PC-Anwender besser geeignet als die inzwischen überdimensionierten x86-CPUs. Apple macht seit Jahren vor, wie beeindruckend eine gut integrierte ARM-Architektur sein kann.
Warum also steht dieses Thema hier unten? Sehen wir uns die Historie an: Schon 2011/12 sollte Windows 8 unsere Notebooks und Smartphones vereinen – das Ergebnis war… sagen wir enttäuschend. 2019 sollte das Surface Pro X die Ära von Windows on ARM einläuten. Ein Emulator für x32-Applikationen sollte die Zeit überbrücken, bis native Apps verfügbar sind. Doch auch hier galt die Plattform nur als „akzeptabel“, wenn man ausschließlich den Edge-Browser und die wenigen verfügbaren ARM-Apps nutzte.
Nun sollen die Copilot+ PCs Windows auf ARM massentauglich machen. Beunruhigend ist, dass die „Neural Processing Unit“ für KI-Aufgaben häufiger erwähnt wird als der neue „Prism“ x86-Emulator. Trotz der ARM-Portierungen großer Softwarehersteller wird die x86-Alternative im Windows-Bereich noch lange bestehen bleiben – Microsoft kann nicht einfach x86 Chips auslaufen lassen wie Apple es tat. Das mindert stark den Druck, für die neue Plattform zu entwickeln. Könnte Microsoft also aufgrund des Schwerpunkts auf KI erneut an den gleichen Problemen scheitern, die schon zwei vorherige Versuche mit ARM scheitern ließen – der Performance von Nicht-KI-Apps?
Ich bleibe skeptisch und warte gespannt auf die ersten unabhängigen Reviews – auch wenn Microsoft mich privat aus anderen Gründen bereits an Linux verloren hat.
TL:DR;
Hier also meine Highlights in Kurzfassung. Habe ich etwas vergessen oder sie sind anderer Meinung? Nehmen sie an der Diskussion auf LinkedIn Teil.
Sicherheitsverbesserungen
- NTLM-Abschaffung ist für die zweite Hälfte des Jahres 2024 geplant.
- Zero Trust DNS zur Durchsetzung von DNS-basierter Sicherheit.
- Power Platform Security Hub vereinfacht Governance- und Sicherheitsempfehlungen.
- Edge for Business kündigt Beschränkungen für Screenshots und Bildschirmaufzeichnungen "in den nächsten Monaten" an.
Azure-Innovationen
- Compute Fleets erleichtern die Bereitstellung von virtuellen Maschinen, indem sie automatisch nach verfügbaren Kapazitäten suchen.
- Azure Functions Flex Consumption Preismodell balanciert Kosten und Leistung.
- Dev Box wird die Kostenkontrolle durch Funktionen wie automatischen Ruhezustand und VM Begrenzung pro Entwickler verbessern.
Microsoft Teams-Updates
- Slash Commands ermöglichen schnellen Zugriff auf Funktionen durch Tippen.
- Sofortbesprechung in Gruppenchats vereinfacht das spontane Beitreten und Verlassen von Diskussionen.
Windows auf ARM
- Leistungs- und Kompatibilitätsbedenken bei x86-Anwendungen bleiben trotz neuer KI-Hardware-Integrationen bestehen.