La teva còpia d'Exchange Online depèn d'un camp de text

Microsoft va encendre l'interruptor avui. Des del 10 d'octubre, al seu núvol multi-tenant, un tenant amb EwsEnabled a $true i la llista d'aplicacions permeses buida deixa de deixar-les passar totes i passa a no deixar-ne passar cap. El 2 d'octubre Microsoft va anotar quins tenants estaven en aquest estat, i el 8 i el 9 els va escriure la llista posant-hi dins les aplicacions a què havia vist fer servir l'EWS els 60 dies anteriors. Si copies les bústies del Microsoft 365, la teva còpia depèn des d'avui d'una llista que probablement no vas escriure tu. I del paràmetre que la desa convé saber una cosa: la documentació el declara com a <String>.

El calendari d'aquesta setmana

L'equip de l'Exchange va publicar l'1 d'octubre el detall dia a dia. El 2 d'octubre, al tancament del dia en hora del Pacífic, Microsoft anota la llista de tenants amb EwsEnabled a $true i sense EwsAllowedAppIDs. Entre el 8 i el 9, també al tancament del dia, crea aquesta llista i l'omple amb els identificadors d'aplicació vistos fent servir l'EWS els 60 dies previs. I a partir del 10 d'octubre activa la configuració que exigeix que la llista hi sigui si EwsEnabled està a $true. Això últim, de moment, només al núvol mundial multi-tenant: la resta de núvols rebran el seu calendari pel centre de missatges.

La taula de comportament que va publicar l'avís MC1447678 a l'agost queda, a partir d'avui, en quatre estats. Amb EwsEnabled a $true i llista escrita, passen només les aplicacions de la llista; és l'únic estat en què decideixes tu. Amb $true i llista buida, es bloqueja tot tret de les relacions entre organitzacions. Amb $false, es bloqueja tot, com sempre. I sense valor assignat, que segons Veeam és on és la majoria de tenants, el tenant queda dins de l'apagada per fases que Microsoft executa al seu ritme. Més lluny queda l'última data: l'1 d'abril del 2027, quan l'EWS es retira del tot.

La llista que tens posada potser no és teva

Aquest emplenament automàtic és el detall que canvia la conversa. Veeam ho resumeix al seu article KB4820: Microsoft omple prèviament la llista segons l'ús d'EWS observat a cada tenant, però només als tenants on no estava ja configurada. El criteri és el que es va veure funcionant en 60 dies, de manera que la llista descriu el passat recent del teu tenant amb força fidelitat i no descriu res més.

Per a una còpia de bústies diària això juga a favor: si la feina corria, l'aplicació era dins d'aquells 60 dies i hauria de ser a la llista. La paraula important és «hauria». La part de qui fa servir l'EWS a casa teva i com s'inventariaria la vam explicar al post d'agost sobre la data límit real, quan la llista encara es podia escriure amb calma.

El paràmetre no admet afegir ni treure

A la sintaxi de Set-OrganizationConfig, EwsBlockList figura com a <MultiValuedProperty> i EwsAllowedAppIDs com a <String>. Per a les llistes antigues, Microsoft documenta la sintaxi @{Add="Valor1"; Remove="Valor2"}, que afegeix i treu sense tocar la resta. Per a la nova no hi ha equivalent, i el mateix fabricant ho diu amb totes les lletres al seu anunci: el cmdlet no admet operacions incrementals d'afegir o treure, i escriure la propietat escriu el valor complet, de manera que els identificadors que ja hi hagués queden reemplaçats tret que els incloguis a la nova ordre.

El patró que publica Microsoft per modificar-la és llegir la llista actual, calcular la nova i escriure-la sencera. Funciona perfectament mentre ho faci algú que sap què hi ha a dins. El dia que s'hagi de donar d'alta l'eina de migració de correu amb pressa i s'escrigui només aquell identificador, el de la teva còpia desapareix: sense avís, sense error i sense que ningú ho hagi volgut fer.

Comprovar-la té truc

L'ordre que qualsevol escriuria, Get-OrganizationConfig | Format-List EwsAllowedAppIDs, retorna el camp buit encara que la llista estigui configurada. Cal demanar-la amb un commutador: Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs. Microsoft ho documenta a la descripció del paràmetre i al blog de l'equip de l'Exchange, on a més n'explica el perquè: s'exigeix per raons de rendiment. On no hi és és a la pàgina de referència de Get-OrganizationConfig, consultada avui amb data de revisió del 27 de febrer del 2026, la sintaxi de la qual només admet -DomainController i l'exemple d'EWS de la qual ensenya les llistes antigues.

Al fòrum de Veeam hi ha un fil de setembre amb dos administradors que hi van arribar amb el mateix ensurt: la llista configurada i la consulta en blanc. El que els va acabar retornant els valors no va ser el commutador a seques sinó -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs. Convé tenir-ho a mà abans de concloure que la llista no hi és.

Els rellotges tampoc no van iguals. Segons l'equip de l'Exchange, els canvis a EwsAllowedAppIDs triguen 24 hores a fer efecte, perquè els servidors refresquen la seva memòria cau una vegada al dia, mentre que un canvi a EwsEnabled sol aplicar-se en menys d'una hora, amb pics de fins a quatre. Una prova feta deu minuts després de tocar la llista no demostra res, i empeny a tocar una altra vegada el que ja estava bé.

I queda una frase de la documentació que avui significa el contrari del que sembla: per treure la restricció per identificador d'aplicació, diu, se li passa $null al paràmetre. Amb l'interruptor encès i EwsEnabled a $true, un tenant sense llista bloqueja tot. La sortida d'emergència documentada tanca la porta.

Quina part de la teva còpia penja d'aquest camp

Veeam manté un article específic, el KB4820, publicat el 25 de març del 2026 i modificat per última vegada el 7 d'octubre. Afecta el Veeam Backup for Microsoft 365 —recomanen la versió 8.6 o posterior— i el Veeam Data Cloud for Microsoft 365. La frase que importa és curta: un cop bloquejat l'accés EWS al teu tenant, les còpies de les bústies d'Exchange Online fallen. Nosaltres gestionem còpies amb Veeam i amb Proxmox Backup Server, així que això no ho llegim com una notícia de sector sinó com una tasca.

El mateix article explica per què encara hi ha EWS pel mig el 2026, i ho explica amb nom: el que falta al Graph és el suport de sincronització diferencial que necessiten les còpies incrementals. Microsoft manté a més un mapa públic de forats de paritat amb l'estat de cada peça. No és una elecció de Veeam ni peresa de ningú; són dos calendaris que no estan sincronitzats.

El forat que deixa el tall

Quan es restableix l'accés, diu el KB4820, la primera feina fa una sincronització completa —més lenta que un incremental normal, encara que ocupi el mateix— i les bústies que no es van copiar durant el tall queden amb una finestra de cobertura absent al seu historial de restauració. Els dies bloquejats no s'omplen sols. La feina torna a sortir en verd demà i aquest verd és cert cap endavant, però a la setmana passada no s'hi torna: si algú demana la bústia d'una persona tal com era dimarts i el dimarts cau dins del forat, aquest punt de restauració no existeix.

Això converteix un ajust de PowerShell en un assumpte de continuïtat i compliment. Si el teu document de continuïtat promet un punt de recuperació de 24 hores per al correu, el dia que la llista es quedi curta aquest número deixa de ser cert i ningú t'enviarà un correu avisant-te'n. S'assembla al que vam veure amb el Backup del Microsoft 365 quan s'activa casella a casella: el que no està marcat no està copiat, i l'informe no distingeix entre «no hi havia res» i «no s'ha mirat».

La capa de sota no entén d'identificadors

Si la còpia falla per a tres bústies de quatre-centes, no miris el tenant. Cada bústia té el seu propi EwsEnabled, amb valor per defecte $true, i la seva pròpia política d'aplicacions permeses o bloquejades, escrita en cadenes d'agent d'usuari i no en identificadors de l'Entra. La documentació precisa que el valor de la bústia només és rellevant si el de l'organització no està a $false; què passa en sentit contrari no ho diu. Preguntat exactament això al seu fòrum, el gestor de producte de Veeam va respondre que esperaria que un $false de bústia continués tancant l'accés, i que ho confirmaria amb l'equip d'aliances. Quan la millor resposta disponible és «esperaria», convé provar-ho en una bústia abans que en quatre-centes.

La pregunta del 2 d'abril del 2027

La llista de permesos és una pròrroga. L'1 d'abril del 2027 l'EWS s'apaga del tot i aquesta data no té casella que la desactivi, així que l'endemà és el que convé tenir pensat. El forat del Graph té nom i té mapa, com dèiem; el que no existeix en cap pàgina pública és la frase que digui què copia les bústies d'Exchange Online si aquest mapa es desplaça un trimestre.

Als nostres proveïdors els estem preguntant això mateix, i cap en un correu: quina data interna manegeu per a la sincronització diferencial, i quin pla hi ha si arriba l'abril del 2027 sense ella. Una resposta vaga a aquesta pregunta també és informació.

Comprovacions que caben en un matí

• Llegeix la llista amb el commutador documentat i, si surt en blanc, repeteix-ho amb Select-Object -ExpandProperty EwsAllowedAppIDs abans de concloure res. EwsEnabled es llegeix a part. Desa aquesta sortida abans de tocar: és la còpia de seguretat de la llista, i no n'hi ha cap altra.
• Mira què et va escriure Microsoft el 8 o el 9 i coteja-ho amb l'informe d'ús d'EWS. El que interessa són les aplicacions que no van córrer els últims 60 dies, que són les que falten per definició; i les de Microsoft compten, perquè també es bloquegen.
• Confirma que l'identificador de la teva eina de còpia hi és a dins, i deixa escrit al procediment que qualsevol canvi en aquest paràmetre es fa llegint, recomponent i escrivint la llista sencera. Aquesta nota val més que l'ordre.
• Si falla un subconjunt de bústies i no totes, baixa a la bústia: Get-CASMailbox -Identity <bústia> | Format-List Ews*.
• I mira enrere, no només endavant: comprova si hi ha dies sense punt de restauració a les bústies durant aquesta setmana. És la comprovació que ningú no fa, perquè el tauler només ensenya l'última feina.

El que no faríem: escriure el paràmetre sense haver desat abans el valor anterior, perquè no hi ha desfer i el que esborres no surt en cap registre que vagis a mirar. Tampoc donaríem l'assumpte per tancat perquè la feina surti verda l'endemà, que és mirar el costat del calendari que ja està arreglat. I no deixaríem aquesta dependència sense data de revisió, tenint una caducitat publicada i pendent de resoldre l'abril del 2027.

Un camp de text davant de la teva còpia

El que ens crida l'atenció no és l'apagada d'una API vella, que feia anys que estava anunciada i té la seva lògica. És que la peça de la qual depèn avui la còpia de les bústies de qualsevol tenant d'Exchange Online sigui un camp de text sense historial, sense amo declarat i sense operació d'afegir, emplenat automàticament fa dos dies amb una foto de 60 dies. Si administres Microsoft 365, aquest camp acaba d'entrar a la teva llista de coses crítiques, i és de les que no solen ser a cap inventari.

Fonts: blogs de l'equip de l'Exchange a Microsoft Tech Community, «Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement» i «EWS Deprecation Is Here – What This Means To You» (aquest últim de l'1 d'octubre del 2026), d'on surten el calendari del 2, del 8-9 i del 10 d'octubre, la limitació al núvol mundial multi-tenant, l'emplenament automàtic amb els 60 dies previs, la manca d'operacions incrementals d'afegir o treure, el patró de llegir-recompondre-escriure, el commutador de consulta i el seu motiu, i els temps de 24 hores i de menys d'una hora. Avís del centre de missatges MC1447678, del 5 d'agost del 2026, per a la taula de comportament i l'excepció de les relacions entre organitzacions. Referències de Microsoft Learn de Set-OrganizationConfig, Get-OrganizationConfig i Set-CASMailbox (tipus dels paràmetres, sintaxi @{Add=…}, cadenes d'agent d'usuari, valor per defecte de la bústia i la nota sobre $null), consultades el 10 d'octubre del 2026. Article KB4820 de Veeam, «What Microsoft's EWS Retirement Means for Your Veeam Backups», publicat el 25 de març del 2026 i modificat el 7 d'octubre del 2026: productes i versions, fallada de les còpies, sincronització completa amb finestra de cobertura absent a l'historial de restauració, emplenament automàtic només on no hi havia llista, i la sincronització diferencial com a capacitat pendent del Graph. Fil públic dels fòrums de Veeam sobre EwsAllowedAppIDs, de setembre del 2026, per a la consulta que sí que retorna els valors i per a la resposta del gestor de producte sobre el nivell de bústia. No hem verificat cap dada d'aquest article contra tenants de clients: tot l'anterior és documentació pública.