Microsoft confirmă: update-urile recente Windows pot bloca RemoteApp în Azure Virtual Desktop. Ce-nseamnă asta pentru utilizatori

Microsoft a confirmat o problemă care îi vizează în special pe clienții enterprise ce folosesc Azure Virtual Desktop: anumite actualizări Windows instalate recent pot provoca eșecuri la conectarea RemoteApp pe dispozitive cu Windows 11 24H2/25H2 și Windows Server 2025. Pe scurt, aplicațiile livrate ca RemoteApp pot refuza să pornească sau să se conecteze, deși sesiunile de desktop complet rămân funcționale.

Impactul e semnificativ tocmai pentru că RemoteApp este folosit ca soluție „subțire” pentru acces la aplicații: angajatul deschide un program ca și cum ar fi instalat local, fără să încarce un întreg desktop virtual. Când acest mecanism cade, organizațiile se trezesc fie cu întreruperi de lucru, fie cu nevoia de a comuta utilizatorii pe sesiuni complete, care pot consuma mai multe resurse și pot complica experiența

RemoteApp este o funcționalitate care permite „streaming” de aplicații individuale din cloud către utilizator, astfel încât acestea să ruleze și să arate ca programe native, fără a porni un desktop virtual complet. În mediile Azure Virtual Desktop, această abordare este apreciată pentru eficiență: pornești doar aplicația necesară, cu timpi mai mici de inițializare și, de regulă, cu o administrare mai ușor de standardizat pentru departamentele IT.

Problema confirmată de Microsoft apare după instalarea actualizării non-securitate din noiembrie 2025, identificată ca KB5070311, sau a unei actualizări ulterioare. În aceste condiții, conexiunile RemoteApp pot eșua pe Windows 11 24H2/25H2 și pe Windows Server 2025, în contexte Azure Virtual Desktop. Un detaliu important pentru triere: sesiunile de desktop complet nu sunt afectate, ceea ce poate crea confuzie inițială („merge AVD, dar nu merge RemoteApp”).

Obiectul colorat care a apărut pe mormântul Rodicăi Stănoiu, după ce a fost înmormântată a doua oară. A fost lăsat de o persoană dragă

Horoscopul chinezesc pentru weekendul 20–21 decembrie 2025. Se anunţă schimbări importante la final de an

Microsoft a precizat și delimitarea publicului afectat: dispozitivele personale cu Windows Home sau Pro nu intră, în mod obișnuit, în această situație, deoarece Azure Virtual Desktop este folosit preponderent în scenarii enterprise. Asta nu înseamnă că Windows Pro nu poate apărea în organizații, ci că problema are relevanță practică mai ales acolo unde există infrastructură AVD și politici de update gestionate central.

Soluții de atenuare: registru, restart și Known Issue Rollback

Pentru organizațiile care întâmpină blocaje RemoteApp, Microsoft a descris o măsură de atenuare ce poate fi aplicată manual: adăugarea unei chei în registru, cu drepturi de administrator, urmată de repornirea sistemului. Ideea este să forțeze pornirea unui comportament asociat componentelor implicate în RemoteApp, astfel încât conexiunile să își revină.

Pașii operaționali, așa cum sunt descriși, arată astfel:

1. deschiderea Command Prompt cu drepturi de administrator
2. rularea unei comenzi de registru
3. repornirea dispozitivului pentru aplicarea modificării

Comanda indicată de Microsoft:

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon\ShellPrograms\RdpShell.exe" /v "ShouldStartRailRPC" /t REG_DWORD /d 1 /f

În paralel, Microsoft a folosit și Known Issue Rollback (KIR), un mecanism Windows care poate „da înapoi” o modificare problematică introdusă printr-un update distribuit via Windows Update. Pentru Windows Pro și Windows Enterprise, compania a anunțat că a aplicat o mitigare prin KIR și a menționat că repornirea dispozitivelor poate accelera aplicarea remedierii acolo unde aceasta se propagă deja. În practică, asta poate face diferența între un incident care persistă zile și unul care se rezolvă după un ciclu de restart planificat.

Ce trebuie să știe echipele IT despre mediile gestionate și despre remedierea definitivă

În mediile enterprise în care actualizările sunt controlate de departamente IT (de exemplu, prin politici și ferestre de mentenanță), distribuția automată a unei remedieri prin canalele standard poate să nu fie suficientă sau poate să ajungă mai lent, în funcție de configurare. Microsoft a indicat că, în aceste scenarii, administratorii pot aplica manual rollback-ul prin instalarea și configurarea unei politici de grup (Group Policy) dedicate pentru Known Issue Rollback, corespunzătoare versiunii de Windows din organizație.

Un aspect esențial al acestei abordări este efectul temporar: politica de grup dezactivează temporar schimbarea care declanșează problema. Cu alte cuvinte, nu este prezentată ca „repararea finală” a componentei, ci ca o revenire controlată la un comportament anterior stabil, până când patch-ul definitiv va fi disponibil și validat. Ca și în celelalte variante, repornirea dispozitivelor rămâne necesară pentru aplicarea setărilor.

Microsoft a mai precizat că lucrează la rezolvarea permanentă a problemei, însă nu a oferit, deocamdată, un calendar public pentru un fix final. Pentru organizații, această lipsă de termen poate complica planificarea, mai ales dacă RemoteApp este o piesă critică din fluxurile zilnice (aplicații ERP, instrumente interne, suite de productivitate livrate centralizat sau software specializat).

Într-un astfel de incident, diferența dintre „merge desktopul complet” și „nu merge RemoteApp” contează: prima variantă poate fi un workaround operațional, dar nu întotdeauna e sustenabilă pe scară largă, din motive de performanță, licențiere, costuri sau experiență de utilizare. De aceea, faptul că Microsoft a documentat atât o intervenție rapidă prin registru, cât și o cale de rollback controlată pentru medii gestionate, oferă organizațiilor opțiuni concrete până la apariția unei remedieri definitive.