A metà dicembre 2026 Microsoft #Edge 159 disattiverà per impostazione predefinita il supporto nativo a #XSLT nel #browser, con #Chrome che si muove in parallelo. Per la maggior parte dei siti moderni il cambiamento passerà inosservato, ma per chi gestisce infrastrutture #Windows Server con RD #Web Access il rischio è concreto: l’interfaccia di accesso remoto dipende ancora da XSLT per il rendering, e senza interventi potrebbe smettere di caricarsi dall’oggi al domani. Vediamo cosa cambia, perché Microsoft lo sta facendo e quali contromisure adottare prima della scadenza.

Perché XSLT viene eliminato dai browserXSLT (eXtensible Stylesheet Language Transformations) è lo standard, nato a cavallo degli anni 2000, che permette di trasformare documenti XML in HTML, testo o altri formati XML direttamente lato client, tramite l’API JavaScript XSLTProcessor o una processing instruction XML che referenzia un foglio di stile .xsl. Nei browser basati su Chromium (e quindi anche in Edge) l’elaborazione XSLT è gestita da libxslt, una libreria nativa scritta in C che non riceve aggiornamenti sostanziali da anni.

Il problema è proprio questo: libxslt elabora contenuti XML potenzialmente non attendibili con un motore nativo datato, ampliando la superficie d’attacco a fronte di un utilizzo ormai marginale nel web moderno, dove le trasformazioni XML→HTML si fanno quasi sempre lato server o con librerie JavaScript. Microsoft e #Google hanno quindi deciso, in coordinamento, di rimuovere il motore nativo e lasciare che siano gli sviluppatori a migrare verso alternative più sicure.

Le date da segnare in calendarioIl rollout è scaglionato in due fasi distinte, comunicate da Microsoft tramite il Message Center (riferimento MC1509789):

Edge 159 (metà dicembre 2026): XSLT nativo disattivato per impostazione predefinita, worldwide, inclusi gli ambienti GCC, GCC High e DoD. Resta disponibile una policy temporanea per riattivarlo.

Edge 176 (estate 2027): rimozione completa della policy temporanea e del motore XSLT. Da questo momento non ci sarà più alcun modo di riabilitarlo lato browser.

Sono coinvolti l’oggetto XSLTProcessor e le processing instruction XML che puntano a fogli di stile XSLT; quelle che referenziano CSS non sono interessate. Un avviso precedente (MC1491832) aveva già segnalato, per metà novembre 2026, rischi di rendering failure legati a XSLT su RD Web Access: le tempistiche comunicate da Microsoft in annunci diversi non sono sempre perfettamente allineate, quindi conviene considerare dicembre 2026 come finestra di sicurezza entro cui completare la verifica, senza aspettare l’ultimo giorno.

Il caso concreto: RD Web Access su Windows ServerIl portale RD Web Access (Accesso Web ai Desktop remoti), componente dei Servizi Desktop remoto su Windows Server, utilizza ancora XSLT per il rendering lato client delle pagine. Quando il browser disattiva XSLT, gli utenti che tentano di accedere al portale possono trovarsi di fronte a una pagina bianca, un errore di rendering o un comportamento anomalo nell’elenco di RemoteApp e desktop pubblicati. Microsoft ha pubblicato una nota di supporto dedicata (KB5130994, “RD Web Access fails to load when XSLT is disabled in Microsoft Edge or Google Chrome”) proprio per questo scenario.

È un impatto che riguarda una fetta minoritaria ma non trascurabile di organizzazioni: molte aziende italiane usano ancora RD Web Access per il lavoro remoto o per pubblicare applicazioni legacy, specialmente dove #Azure Virtual Desktop o soluzioni VDI più moderne non sono state ancora adottate.

Come verificare se la tua organizzazione è a rischioPrima di intervenire, conviene fare un inventario delle applicazioni interne che potrebbero dipendere da XSLT. Microsoft suggerisce di usare Lighthouse, integrato negli strumenti di sviluppo di Edge:

Apri l’applicazione da verificare in una versione aggiornata di Edge ed esegui l’accesso, se richiesto.

Premi F12 (o Ctrl+Shift+I) per aprire i DevTools, quindi seleziona il pannello Lighthouse (in “More tools” se non visibile).

Imposta Mode su Navigation e Category su Best Practices.

Per le applicazioni autenticate, disattiva l’opzione “Clear storage” nelle impostazioni di Lighthouse, così da non perdere la sessione.

Avvia “Analyze page load” e cerca nel report voci relative a XSLT, deprecated API o XSLTProcessor, controllando in particolare le sezioni “Uses deprecated APIs” e gli avvisi nel pannello Issues dei DevTools.

Ripeti il test per ogni pagina e flusso applicativo rilevante, non solo per la home page.

Per RD Web Access non serve nemmeno il test: se il server è ancora basato sui componenti classici dei Servizi Desktop remoto (non il nuovo client web HTML5), va messo in lista a prescindere.

Le tre strade per mettersi al riparo1. Riattivare temporaneamente XSLT con la policy XSLTEnabledÈ la soluzione tampone più rapida, pensata per guadagnare tempo mentre si pianifica la migrazione vera e propria. La policy XSLTEnabled è disponibile sia per Edge sia, con lo stesso nome, per Chrome.

Da riga di comando elevata (Prompt dei comandi come amministratore), per Edge:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v XSLTEnabled /t REG_DWORD /d 1 /fPer Chrome:

reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v XSLTEnabled /t REG_DWORD /d 1 /fIn alternativa, tramite Criteri di gruppo (GPO), su un ambiente di dominio:

Apri la Console di gestione dei criteri di gruppo e modifica (o crea) il GPO da applicare ai server/client interessati.

Vai in Configurazione computer → Modelli amministrativi → Microsoft Edge (il template ADMX è MSEdge.admx, da importare nel repository centrale se non già presente).

Apri la voce Control the availability of the XSLT feature, impostala su Enabled e salva.

Collega il GPO all’unità organizzativa che contiene i server RD Web Access o i client interessati, poi forza l’aggiornamento con gpupdate /force.

Importante: la policy è temporanea e verrà rimossa con Edge 176 (estate 2027) insieme al motore XSLT, quindi non va considerata una soluzione definitiva ma solo una finestra per completare la migrazione.

2. Migrare al client web HTML5 di Desktop remotoLa soluzione strutturale per RD Web Access è passare al client web moderno, che non dipende da XSLT. È raggiungibile all’indirizzo:

https://<nome_server_rdweb>/RDWeb/webclient/index.htmlsostituendo <nome_server_rdweb> con l’FQDN del server. Il client HTML5 richiede però una configurazione preliminare lato server (ruolo RD Web Access aggiornato, certificati validi, eventuale pubblicazione tramite RD Gateway) che va pianificata e testata prima del passaggio in produzione: non è un semplice cambio di URL da comunicare agli utenti.

3. Usare la modalità Internet Explorer di Edge come ripiegoPer scenari in cui non è possibile intervenire rapidamente sul server, Edge offre la modalità di compatibilità Internet Explorer, che Microsoft prevede di mantenere disponibile almeno fino al 2029:

Apri Impostazioni → Browser predefinito in Edge.

Attiva l’opzione “Consenti il ricaricamento dei siti in modalità Internet Explorer”.

Aggiungi l’URL del portale RD Web Access all’elenco “Pagine in modalità Internet Explorer”.

Al primo accesso il browser potrebbe chiedere di abilitare ActiveX, necessario per il single sign-on: un dettaglio da comunicare in anticipo agli utenti per evitare segnalazioni al service desk. È comunque solo un ponte verso una delle due soluzioni precedenti, non una destinazione finale.

Checklist operativa per i sysadminUn piano d’azione ragionevole prima di dicembre 2026:

Censire le applicazioni interne (RD Web Access incluso) che usano XSLT, con il test Lighthouse descritto sopra.

Applicare da subito, in via precauzionale, la policy XSLTEnabled sui server e client che accedono a RD Web Access, per evitare interruzioni impreviste al rollout di Edge 159.

Pianificare e testare in un ambiente non di produzione la migrazione al client web HTML5 di RD Web Access.

Per applicazioni custom con output XSLT lato client, valutare la trasformazione lato server o librerie JavaScript indipendenti dal motore nativo del browser.

Monitorare i prossimi annunci nel Message Center, perché le date comunicate finora non sono sempre coerenti tra loro.

ConclusioneLa rimozione di XSLT dai browser Chromium è un classico esempio di debito tecnico che arriva a scadenza: una tecnologia poco usata ma con una dipendenza nascosta in un componente critico come RD Web Access. Microsoft ha lasciato una finestra ragionevole e una policy di riattivazione temporanea per gestire la transizione senza fretta, ma come spesso accade la scadenza reale arriverà più vicina di quanto sembri: vale la pena verificare oggi, non a dicembre, se la propria infrastruttura è tra quelle a rischio.

Fonte: 4sysops.com, con riferimenti a Microsoft Message Center (MC1509789, MC1491832) e Microsoft Learn.

Read Time:3 Minute, 21 Second

Microsoft has confirmed that security updates released for Windows Server on October 13 can interfere with on-premises Exchange Server operations. Affected organizations may see Outlook on the web become unavailable, messages remain in users’ Outboxes, and mail queues grow as database connectivity falters.

The problem can affect Exchange Server 2016, Exchange Server 2019, and Exchange Server Subscription Edition. Microsoft has provided a registry workaround and explicitly advises administrators not to remove the Windows security updates. The company currently describes the issue as mitigated while its investigation continues.

The operating system update is the triggerThis incident is easy to misdiagnose because it coincides with Microsoft’s October Exchange security releases. However, the confirmed cause is a change delivered through Windows Server updates, not the separate Exchange patches. An Exchange host may therefore experience the failure even if the latest Exchange-specific update has not been installed.

Microsoft has linked the behavior to four Windows packages: KB5126646 for Windows Server 2025, KB5126655 for Windows Server 2022, KB5126651 for Windows Server 2019, and KB5126868 for Windows Server 2016. Impact varies by workload, so two apparently similar servers may behave differently and some systems may never show symptoms.

The updates introduced a default ceiling of 512 simultaneous Endpoint Lookup calls. Endpoint Mapper supports remote procedure call communications, and the limit is intended to constrain memory consumption. Busy Exchange environments can exceed that allowance, causing dependent services and database communications to fail.

Symptoms administrators may encounterFor end users, the most visible sign is an inability to authenticate to Outlook on the web. Outlook clients may appear to send messages while leaving them stuck locally. Behind the scenes, administrators can encounter expanding transport queues, mailbox access failures during replication, or Database Availability Group members that cannot maintain quorum.

Restarting a server may temporarily restore operation, but it does not address the underlying capacity limit. Affected hosts can also log Application Event ID 1006. Another useful diagnostic clue is the error MapiExceptionMdbOffline, accompanied by a message that the client cannot connect to the server and the values hr=0x80004005 and ec=1142.

Because these indicators overlap with other Exchange outages, response teams should correlate the timing of the first failures with Windows update installation and inspect all members of a high-availability group. A partial failure can create confusing symptoms when traffic is redirected among healthy and unhealthy nodes.

Microsoft’s registry mitigationMicrosoft’s Exchange guidance raises the Endpoint Mapper saved-context capacity. From an elevated Command Prompt on each affected Exchange server, administrators can run the following command:

reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f

The server must be restarted after applying the change. Microsoft says this adjustment has resolved the problem in customer environments it has handled. If failures recur, the company advises increasing the limit further, although its public guidance does not specify a universal second value. Organizations needing an additional mitigation can contact Microsoft Support.

Confirm the affected Windows update and document when symptoms began.

Apply the registry change through normal change-control procedures.

Restart one server at a time where resilient Exchange architecture permits it.

Monitor mail queues, database replication, DAG quorum, webmail access, and Event ID 1006.

Escalate recurring failures to Microsoft rather than repeatedly rebooting production hosts.

Keep the security fixes in placeUninstalling a security update can restore old, vulnerable code and should not be the default response to an availability problem. Microsoft’s position is to retain the October Windows updates and use the mitigation while engineering work continues. Administrators should also avoid assuming that installing or removing the separate Exchange update will solve this particular fault.

The timing adds pressure for organizations still operating Exchange 2016 or 2019. October 2026 is their final scheduled Extended Security Update release, while future routine security servicing is focused on Exchange Server Subscription Edition. Teams troubleshooting the outage should use the incident as an opportunity to confirm support status, patch governance, tested rollback plans, and a migration path for aging deployments.

Microsoft ha ufficializzato quello che molti amministratori di sistema temevano da tempo: #Windows Deployment Services (WDS), insieme al suo motore #PXE (Preboot Execution Environment), è stato dichiarato deprecato a partire dalla prossima #release di Windows Server. Non si tratta di una rimozione immediata — il ruolo resta funzionante su Windows Server 2016, 2019, 2022, 23H2 e 2025 — ma la direzione è chiara, e chi gestisce infrastrutture di imaging bare-metal farebbe bene a iniziare a pianificare la migrazione già ora, prima che la finestra di manovra si riduca.

In questo articolo vediamo cosa cambia esattamente, perché Microsoft ha preso questa decisione, e quali sono le alternative concrete indicate dalla documentazione ufficiale, con relativi pro e contro per chi deve scegliere il percorso di migrazione.

Cosa viene deprecato, nel dettaglioLa deprecazione non riguarda un singolo componente, ma l’intero stack WDS:

Il ruolo server WDS e i suoi componenti Deployment Server / Transport Server

La funzionalità di PXE boot e network bootstrap fornita da WDS

Gli strumenti di gestione, le CLI (wdsutil), le API e i percorsi di attivazione del servizio

Il trasporto multicast e i flussi di deployment che ne dipendono

I componenti WinPE-WDS-Tools usati per costruire immagini di boot personalizzate

Non è una novità improvvisa: già nel 2021 Microsoft aveva deprecato i flussi di boot.wim basati su WDS per Windows 11 e versioni successive, e ad aprile 2026 gli scenari di deployment “hands-free” tramite WDS sono stati disabilitati di default nelle installazioni più recenti. La deprecazione formale del ruolo server è quindi l’ultimo tassello di un percorso iniziato da anni.

Perché ora?WDS si appoggia su un’architettura di rete e boot (BIOS/PXE legacy, multicast, protocolli TFTP non cifrati) che non si allinea più con i requisiti di sicurezza moderni: niente autenticazione del client prima del trasferimento dell’immagine, nessuna cifratura del traffico di boot, e una superficie di attacco che include il classico problema del “server DHCP/PXE non autorizzato in rete”. Con l’adozione crescente di UEFI Secure Boot, TPM 2.0 e gestione #cloud-first dei dispositivi, mantenere un componente legacy come WDS come via principale di provisioning ha sempre meno senso per Microsoft.

Le alternative raccomandate1. Configuration Manager PXE responder (senza WDS)È l’alternativa che Microsoft raccomanda in modo più esplicito per chi già #usa (o può adottare) Microsoft Configuration Manager (ConfigMgr/MECM). Il PXE responder di ConfigMgr può funzionare in modalità standalone, senza dipendere dal ruolo WDS sottostante, gestendo direttamente le richieste di boot di rete. La distribuzione del sistema operativo tramite ConfigMgr (task sequence, immagini, driver package) resta una capacità pienamente supportata e non deprecata: cambia solo il livello di trasporto della fase di boot iniziale.

Per chi ha già un’infrastruttura ConfigMgr consolidata, questa è generalmente la strada a minor attrito: la migrazione richiede di riconfigurare il ruolo di distribuzione point per gestire il PXE senza il servizio WDS legacy sottostante, verificando compatibilità di firmware e switch di rete (in particolare per IP helper/DHCP relay).

2. Soluzioni PXE di terze partiEsistono implementazioni PXE non Microsoft, sia commerciali sia open source, che restano ovviamente non toccate dalla deprecazione. Tra le più note in ambito #Linux/eterogeneo:

Esempio: avvio di un server PXE minimale con dnsmasq su Linux

sudo apt install dnsmasq
cat <<EOF > /etc/dnsmasq.d/pxe.conf
interface=eth0
dhcp-range=192.168.10.100,192.168.10.200,12h
dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/srv/tftp
EOF
sudo systemctl restart dnsmasqSoluzioni come netboot.xyz, iPXE o piattaforme MDM/deployment di terze parti offrono spesso funzionalità più moderne (boot via HTTP/HTTPS, script di boot dinamici, interfacce #web) rispetto al vecchio WDS, ma richiedono comunque un progetto di migrazione: mappatura delle immagini esistenti, retraining del personale, e in alcuni casi costi di licenza.

3. UEFI HTTP(S) BootPer i dispositivi con firmware UEFI moderno, il boot via HTTP(S) è un’alternativa nativa al PXE tradizionale, con il vantaggio di poter cifrare il trasferimento dell’immagine di boot. Microsoft è però esplicita nel dire che non è un sostituto diretto del PXE responder di ConfigMgr: si tratta di un meccanismo di trasporto complementare, utile in scenari specifici (ad esempio boot attraverso reti che non supportano bene il multicast/broadcast PXE), ma che da solo non copre tutte le funzionalità di un flusso di OS deployment completo.

4. Windows Autopilot per i nuovi dispositiviPer chi acquista hardware nuovo, Microsoft continua a spingere verso Windows Autopilot: il provisioning avviene “out of the box”, senza immagine personalizzata da distribuire via rete, con il dispositivo che si registra e si configura da cloud (Entra ID/Intune) al primo avvio. Non è un rimpiazzo 1:1 di WDS per il re-imaging di parco macchine esistente, ma per il ciclo di vita dei nuovi PC riduce drasticamente (o azzera) la necessità di un’infrastruttura PXE.

Come pianificare la migrazionePrima di scegliere una strada, la documentazione Microsoft raccomanda alcuni passi di analisi che vale la pena seguire alla lettera:

Censire tutte le implementazioni WDS attive nell’organizzazione, comprese quelle “nascoste” in filiali o laboratori

Verificare le dipendenze da Configuration Manager, immagini WinPE personalizzate e utilizzo di wdsutil in script di automazione

Valutare l’impatto sulla capacità di deployment unicast se oggi si fa affidamento sul multicast di WDS per grandi rollout simultanei

Validare le alternative in condizioni realistiche di rete e firmware, non solo in laboratorio: switch, VLAN, IP helper e compatibilità UEFI vanno testati sul campo

Per organizzazioni di medie e grandi dimensioni, la combinazione più pragmatica nel breve-medio termine è spesso: ConfigMgr PXE responder per il parco macchine esistente da re-immaginare, e Windows Autopilot per tutto l’hardware di nuovo acquisto. Le soluzioni di terze parti restano un’opzione valida soprattutto per ambienti eterogenei Linux/Windows che già non dipendevano fortemente da WDS.

ConclusioneNon c’è ancora una data di rimozione definitiva per WDS, ma il messaggio di Microsoft è inequivocabile: è il momento di uscire dalla comfort zone del vecchio PXE responder integrato in Windows Server. Chi gestisce infrastrutture di imaging dovrebbe iniziare subito il censimento delle dipendenze e un piccolo pilot su una delle alternative disponibili, per evitare di trovarsi a rincorrere la migrazione quando il supporto verrà effettivamente ritirato.

Fonte: Microsoft Support e 4sysops