Wie installiert man das sinnvollste jemals von Microsoft zur Druckerverwaltung bereitgestellte „Print Management“ (Druckverwaltung) unter Windows 11 oder Windows Server nach? Druckverwaltung schnell (windows-Schnell) hinzufügen.
Wie man überhaupt auf die Idee kommen kann, dieses Tool nicht automatisch überall installiert zu haben, ist für uns nicht nachvollziehbar …
Dass Microsoft seit 2025 ein ausgewachsenes Vibecoding-Problem hat, ist Eingeweihten nicht neu. Hier das neueste „kreative“ Office-Problem.
Problem
Wenn man Umlaute in eine E-Mail verwendet (ä, ü, ö) oder Sonderzeichen nutzt (Wie das Durchmesser-Symbol „⌀“) werden diese als Fragezeichen verschickt. Das Fragezeichen bleibt auch in den „Gesendeten Objekten“ als solches erhalten.
Lösung
Laut dem zugehörigen Microsoft-Artikel ist das Problem zwar schon länger bekannt, aber es gibt noch keine Lösung:
Workaround #1: Das neue Outlook (…) oder Outlook Web Access (OWA) verwenden. Dort tritt der Fehler bisher nicht auf. Vermutlich bis es ein noch neueres Outlook new new 2 final gibt (</sarkasmus>).
Workaround #2: Auf eine funktionierende Version downgraden.
Um auf die (bekannt funktionierende) Version 2512 (Build 19530.20184) zurückzuspringen, öffnet man eine Eingabeaufforderung „als Administrator“ und sagt dem Click-to-Run Client das man ein bestimmtes Image starten möchte:
"%programfiles%\Common Files\Microsoft Shared\ClickToRun\officec2rclient.exe" /update user updatetoversion=16.0.19530.20184
Dann deaktiviert man in einer Office-App unter Datei > Office-Konto > Updateoptionen auswählen > „Updates deaktivieren“ die erneute Aktualisierung.
⚠️ Updates, auch Sicherheitsupdates, bleiben dann abgeschaltet. Das sollte keine Dauerzustand sein. Microsoft meint, das man zum „10. März“ Updates erneut versuchen soll. Vielleicht ist der Fehler ja dann behoben.
Auch nach vielfacher Kontrolle der IKE Proposals (IKEv2 in diesem Fall), lässt sich ein VPN-Tunnel manchmal partout nicht aufbauen. Das ist uns ein paar mal bei Gegenstellen von Palo Alto begegnet – was aber Zufall sein mag. IPSEC Implementierungen gibt es viele. Auf der Lokalen Seite waren es verschiedene Setups, darunter Lancom, SonicWall, Sophos und ein nativer strongSwan.
Der Tunnelaufbau scheitert direkt in Phase 1, nachdem die Encryption Proposals akzeptiert wurden:
Message: IKEv2 Initiator: Proposed IKE ID mismatch Notes:VPN Policy: POLICYNAME; id <IP>, does not match peer IKE id in policy
Lösung
Die lokale und remote IKE ID müssen vom Typ IP(v4) sein und eine IP(v4) Adresse enthalten.
RFC 7296 definiert für IKEv2 sieben verschiedene ID Typen (Peer ID / Local ID). DArunter FQDN, ASN Identifier, IPv6 und weitere. Aber es gibt einen spannenden „should“ Passus, der die Kompatibilität der Verhandlung potenziell einschränkt:
To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these four types. Implementations SHOULD be capable of generating and accepting all of these types.
Genau das macht Palo Alto nicht: Die (heute) aktuellen Geräte unterstützen nur einen einzigen Typ: IPv4 (einzelne IP-Adresse). Ob das ein RFC-Verstoß ist, ist eine Frage der Rhetorik, denn die Typen „sollen“ ja auch nur unterstützt werden. MÜSSEN konfigurierbar sein (unserer Ansicht nach auch eher zweifelhaft), SOLLEN aber gesendet und empfangen werden können.
Alle anderen Typenkombination (die wir ausprobiert haben) scheiterten. Auch wenn das ID-Feld in Panorama wie ein „String“ Feld aussieht und sich (eingabetechnisch) auch so verhält – der Typ der im IKE-Paket ausgegeben wird, ist immer „IP“. Stell man beide Seiten auf IP, geht der Tunnel (mit diesem Fehler) sofort auf.
