Stații de lucru

Ghid de Diagnosticare și Soluționare pentru Eroarea Server Manager „Online – Data retrieval failures occurred” (Cod Eveniment 10149 / WinRM / WMI)

• Data 31/08/2026
• Autor Mihai Geambasu
• 1
• 41

1. Introducere și Descrierea Erorii

În mediile de administrare bazate pe sistemele de operare Windows Server (Windows Server 2016, 2019, 2022 și 2025), consolă centralizată Server Manager utilizează protocoale de comunicare la distanță (WinRM – Windows Remote Management și WMI – Windows Management Instrumentation) pentru a colecta starea nodurilor, performanța, serviciile și jurnalele de evenimente (Event Logs).

Atunci când consola Server Manager afișează avertismentul:

Status: Online – Data retrieval failures occurred

Eroare WinRM / Event ID: 10149 (The WinRM service is not listening for WS-Management requests / WS-Management service cannot process the request)

aceasta indică întreruperea sau refuzul transportului de date inter-noduri. Deși serverul afectat este funcțional și raportat ca fiind „Online”, consola nu poate extrage blocurile de date/jurnale necesare pentru a compune o imagine completă de stocare, cluster sau roluri.

2. Cauzele Principale ale Erorii (Cod 10149 / Data Retrieval Failure)

Scenariile tehnice cele mai frecvente care declanșează această eroare includ:

1. Depășirea Dimensiunii Pachetului de Date (MaxEnvelopeSizekb):

   • Atunci când un server face parte dintr-un cluster (WSFC / Failover Cluster, DAG Exchange, S2D / Azure Stack HCI), numărul de jurnale și obiecte interogate generează un răspuns HTTP/SOAP a cărui dimensiune depășește limita implicită WinRM de 512 KB (512000 bytes).

2. Coruperea sau Blocarea Jurnalelor de Evenimente Diag (Kernel-IoTrace):

   • Jurnalul de sistem Microsoft-Windows-Kernel-IoTrace/Diagnostic poate deveni corupt sau prea masiv, cauzând blocaje de timp (timeouts) la interogările Server Manager.

3. Serviciul WinRM (Windows Remote Management) Oprit sau Misconfigurat:

   • Ascultătorii (Listeners) WinRM pe portul 5985 (HTTP) sau 5986 (HTTPS) nu sunt activi sau binding-ul de rețea s-a pierdut pe IP-urile clusterului (Event ID 10149).

4. Lipsa Drepturilor de Acces pe Jurnalele de Evenimente:

   • Contul de computer al clusterului sau contul de administrare nu deține permisiuni de citire în grupul Event Log Readers.

3. Ghid Pas cu Pas pentru Remediere

Pasul 1: Mărirea Limitei de Dimensiune a Pachetului WinRM (MaxEnvelopeSizekb)

Aceasta este cauza principală în peste 80% din cazurile de Server Manager Data Retrieval Failures pe servere în cluster sau Exchange DAG.

1. Deschideți Windows PowerShell cu drepturi de Administrator pe serverul afectat.

2. Executați comanda pentru a mări limita pachetului de la 512 KB la 8192 KB (sau până la 10240 KB):

   PowerShell

   Set-WSManInstance -ResourceURI winrm/config -ValueSet @{MaxEnvelopeSizekb = "8192"}
   

   Alternativ, din Command Prompt (cmd):

   DOS

   winrm set winrm/config @{MaxEnvelopeSizekb="8192"}
   

3. Alternativ, prin intermediul Registry Editor (regedit):

   • Navigați la: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client

   • Creați sau modificați valoarea DWORD (32-bit) cu numele maxEnvelopeSize.

   • Setați valoarea în Hexazecimal la 2000 (corespunzător valorii 8192 în Zecimal).

4. Reporniți serviciul WinRM:

   PowerShell

   Restart-Service WinRM
   

Pasul 2: Dezactivarea și Curățarea Jurnalului Corupt Kernel-IoTrace

În nodurile de Failover Clustering / S2D, jurnalul Kernel-IoTrace este o cauză cunoscută pentru blocurile de colectare Server Manager.

1. Rulați PowerShell ca Administrator și verificați politica de Dump a Clusterului:

   PowerShell

   (Get-Cluster).DumpPolicy
   

2. Dezactivați canalul de diagnosticare corupt din Registri:

   • Navigați la cheia:

     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-Kernel-IoTrace/Diagnostic

   • Modificați valoarea Enabled (REG_DWORD) la 0.

3. Reporniți serviciul de jurnale (Windows Event Log) sau efectuați un reboot al nodului afectat.

Pasul 3: Reconfigurarea Serviciului și Ascultătorilor WinRM (Fix pentru Codul 10149)

Codul de eroare 10149 indică faptul că serviciul WinRM a oprit ascultarea pe interfețele de rețea.

1. Verificați dacă există un ascultător WinRM activ pe porturile standard:

   PowerShell

   winrm enumerate winrm/config/listener
   

2. În cazul în care nu există ascultători sau sunt marcați cu erori, reinițializați configurația WinRM:

   DOS

   winrm quickconfig -q
   

3. Re-înregistrați SPN-urile (Service Principal Names) și reparati legăturile WMI/WinRM:

   DOS

   netsh advfirewall firewall set rule group="Windows Remote Management" new enable=yes
   winrm r /config /service @{AllowUnencrypted="true"}
   

Pasul 4: Verificarea Permisiunilor de Acces la Jurnale (Event Log Readers)

Pentru medii cu Active Directory și Cluster Virtual Objects (CNO):

1. Deschideți lusrmgr.msc (sau Active Directory Users and Computers dacă este Domain Controller).

2. Navigați la Groups $\rightarrow$ Event Log Readers.

3. Adăugați contul de computer al serverului/clusterului și contul cu care vă autentificați în Server Manager în acest grup.

4. Rulați comanda de actualizare a politicilor:

   DOS

   gpupdate /force
   

4. Rezumat și Recomandări de Prevenție

Concluzie:

În majoritatea scenariilor de producție (în special pe noduri de cluster, Hyper-V sau Exchange), eroarea Server Manager Cod 10149 / Data retrieval failures se rezolvă prin mărirea dimensiunii MaxEnvelopeSizekb la 8192 și repornirea serviciului WinRM, eliminând astfel gâtul de sticlă la transportul volumelor mari de date administrative.

Diagnosticarea și Remedierile Erorii Windows 0xC00000A5 (STATUS_BAD_IMPERSONATION_LEVEL)

• Data 31/08/2026
• Autor Mihai Geambasu
• 1
• 19

1. Introducere și Definiția Erorii

Eroarea 0xC00000A5, reprezentată în arhitectura Windows NT prin codul STATUS_BAD_IMPERSONATION_LEVEL, este o eroare de securitate la nivelul nucleului (kernel-level security error).

Aceasta apare în momentul în care un proces server sau un serviciu încearcă să execute o acțiune în numele unui utilizator (client impersonation), dar nivelul de impersonalizare oferit de token-ul de securitate al clientului este insuficient sau incompatibil cu operațiunea solicitată.

În arhitectura de securitate Windows, impersonalizarea (impersonation) permite unui fir de execuție (thread) al unui proces să ruleze sub un context de securitate diferit de cel al procesului părinte. Dacă nivelul de impersonalizare permis este prea scăzut, sistemul blochează apelul de sistem și emite codul de eroare 0xC00000A5.

2. Contextul Tehnic: Nivelurile de Impersonalizare în Windows

Pentru a înțelege de ce eșuează apelul API, trebuie analizate cele 4 niveluri de impersonalizare definite în arhitectura COM/DCOM și RPC:

1. SecurityAnonymous (Nivel 0): Serverul nu poate obține informații de identificare despre client și nu îl poate impersonaliza.

2. SecurityIdentification (Nivel 1): Serverul poate obține identitatea clientului (SID, grupuri) pentru verificări de acces, dar nu poate executa cod în numele clientului.

3. SecurityImpersonation (Nivel 2): Serverul poate impersonaliza clientul pe sistemul local. Acesta este nivelul standard necesar pentru majoritatea serviciilor de sistem.

4. SecurityDelegation (Nivel 3): Serverul poate impersonaliza clientul atât pe sistemul local, cât și pe sisteme la distanță în rețea (necesită suport Active Directory / Kerberos Delegation).

Cauza directă a erorii 0xC00000A5:

Un serviciu (ex. IIS, SQL Server, un agent de securitate sau o aplicație C++/C#) apelează funcția ImpersonateLoggedOnUser() sau o metodă COM, dar token-ul furnizat are un nivel de impersonalizare mai mic decât SecurityImpersonation (de cele mai multe ori este setat la SecurityIdentification sau SecurityAnonymous).

3. Cauze Principale ale Erorii

1. Privilegii insuficiente ale contului de serviciu (User Rights Assignment):

   • Contul sub care rulează serviciul nu deține dreptul local SeImpersonatePrivilege (Impersonate a client after authentication).

2. Setări de securitate DCOM / COM+ incorecte:

   • Nivelul implicit de impersonalizare (Default Impersonation Level) în dcomcnfg este setat la Identify sau Anonymous în loc de Impersonate.

3. Restricții impuse de software terț (Antivirus / EDR / Security Suites):

   • Modulul de protecție împotriva atacurilor de tip Token Manipulation (ex: CrowdStrike, Bitdefender, Defender for Endpoint) blochează procesul de delegare al token-ului.

4. Probleme în codul sursă al aplicației custom:

   • Aplicația apelează DuplicateToken() sau DuplicateTokenEx() specificând un nivel SecurityImpersonationLevel incorect (ex. SecurityIdentification).

5. Configurație incorectă în Active Directory (Delegare Kerberos):

   • Lipsa flag-ului TRUST_FOR_DELEGATION pe contul de computer/serviciu într-un mediu cu autentificare dublă (double-hop scenario).

4. Ghid Pas cu Pas pentru Diagnosticare și Remedie

Pasul 1: Verificarea Dreptului SeImpersonatePrivilege (Local Security Policy)

Dacă eroarea apare la executarea unui serviciu Windows sau IIS Application Pool:

1. Deschideți secpol.msc (Local Security Policy).

2. Navigați la: Local Policies $\rightarrow$ User Rights Assignment.

3. Căutați politica: Impersonate a client after authentication (SeImpersonatePrivilege).

4. Asigurați-vă că grupurile și conturile relevante sunt prezente:

   • SERVICE

   • LOCAL SERVICE

   • NETWORK SERVICE

   • Administrators

   • Contul specific de serviciu (dacă se folosește un Managed Service Account – MSA).

5. Dacă contul lipsește, adăugați-l și rulați comanda:

   DOS

   gpupdate /force
   

Pasul 2: Configurarea Nivelului de Impersonalizare DCOM

Dacă eroarea apare în aplicații care comunică prin arhitectură COM/DCOM:

1. Apăsați Win + R și tastați dcomcnfg.

2. Navigați în arbore la: Component Services $\rightarrow$ Computers $\rightarrow$ My Computer.

3. Faceți clic dreapta pe My Computer și selectați Properties.

4. Deschideți tab-ul Default Properties.

5. La Default Impersonation Level, modificați din Identify în Impersonate.

6. La Default Authentication Level, asigurați-vă că este setat pe Connect sau Packet Integrity.

7. Apăsați Apply și reporniți sistemul.

Pasul 3: Remedieri pentru Dezvoltatori Software (C++ / C# / API Calls)

Dacă dezvoltați o aplicație și primiți STATUS_BAD_IMPERSONATION_LEVEL la apeluri Win32:

• Verificați apelul DuplicateTokenEx: Asigurați-vă că parametrul ImpersonationLevel este setat explicit la SecurityImpersonation:

  C++

  HANDLE hNewToken;
  BOOL result = DuplicateTokenEx(
      hExistingToken,
      TOKEN_ALL_ACCESS,
      NULL,
      SecurityImpersonation, // NU SecurityIdentification!
      TokenImpersonation,
      &hNewToken
  );
  if (!result) {
      DWORD error = GetLastError(); // Verificare eroare
  }
  

• Verificați deschiderea Token-ului de proces: Când apelați OpenProcessToken() sau OpenThreadToken(), solicitați drepturile TOKEN_DUPLICATE și TOKEN_IMPERSONATE.

Pasul 4: Analiza Logurilor cu Process Monitor (Sysinternals)

Dacă sursa erorii rămâne neclară:

1. Descărcați și rulați Procmon.exe din suita Microsoft Sysinternals.

2. Setați un filtru pe numele procesului afectat: Process Name is nume_aplicatie.exe.

3. Adăugați un filtru pe rezultat: Result is BAD IMPERSONATION LEVEL sau Result contains 0xC00000A5.

4. Examinați firul de execuție (Call Stack) pentru a identifica DLL-ul sau modulul care generează apelul blocat.

5. Concluzie

Eroarea 0xC00000A5 - STATUS_BAD_IMPERSONATION_LEVEL este un mecanism de protecție al sistemului de operare Windows împotriva escaladării neautorizate a drepturilor de acces. Soluționarea ei implică acordarea dreptului SeImpersonatePrivilege contului de executare, corectarea setărilor DCOM la nivelul Impersonate, sau ajustarea parametrilor de securitate din codul sursă al aplicației.

How to disable ‘Let’s finish setting up your device’ with ‘Remind me in 3 days’ prompt on Windows 11

• Data 19/08/2026
• Autor duse dorin
• 1
• 49

To prevent Windows 11 from showing the page to finish setting up your device, follow these steps: