Depanare Microsoft 365: Ghid Admin 2026

Ghid complet de depanare Microsoft 365 pentru administratori IT în 2026

Să fim sinceri — administrarea Microsoft 365 în 2026 nu mai seamănă deloc cu ce făceam acum câțiva ani. Mediul de lucru hibrid s-a consolidat ca normă în majoritatea organizațiilor, iar complexitatea infrastructurii cloud a crescut (uneori exponențial, alteori doar... haotic). Utilizatorii lucrează de acasă, din spații de coworking, din cafenele și, ocazional, chiar de la birou. Dispozitivele lor variază de la laptopuri corporative gestionate cu Intune până la telefoane personale cu aplicații instalate la inițiativa proprie.

În acest context, echipa de helpdesk trebuie să fie pregătită să diagnosticheze probleme care traversează granița dintre on-premises și cloud, dintre identitatea locală și cea din Entra ID, dintre politicile de securitate și nevoile reale ale utilizatorilor. Nu e ușor, dar e posibil.

Acest ghid a fost conceput special pentru administratorii IT și tehnicienii de helpdesk care gestionează medii Microsoft 365. Vom acoperi cele mai frecvente scenarii de depanare — de la problemele de flux de e-mail din Exchange Online până la erorile de sincronizare din Entra Connect, de la defecțiunile Microsoft Teams până la problemele de licențiere și activare. Fiecare secțiune include comenzi PowerShell reale, pași de diagnosticare concreți și sfaturi practice extrase din experiența de zi cu zi a echipelor de suport IT.

Scopul nostru? Să vă oferim un document de referință pe care să-l consultați atunci când vă confruntați cu o problemă specifică. Nu e un ghid teoretic — e un instrument practic, testat în producție, care vă poate ajuta să reduceți timpul mediu de rezolvare a tichetelor.

Depanarea Exchange Online: fluxul de e-mail și conectivitatea Outlook

Probleme frecvente cu fluxul de e-mail

Exchange Online este, fără îndoială, serviciul Microsoft 365 care generează cele mai multe tichete de suport. Când e-mailul nu funcționează, totul se oprește. Utilizatorii devin nervoși rapid, iar presiunea pe echipa de helpdesk crește proporțional.

Iată cele mai frecvente scenarii pe care le veți întâlni și cum să le abordați sistematic.

E-mailurile nu ajung la destinatar. Acesta e probabil cel mai comun tichet pe care îl veți primi. Primul lucru pe care trebuie să-l faceți e să verificați fluxul mesajului folosind Get-MessageTrace. Această comandă vă permite să urmăriți parcursul unui e-mail prin infrastructura Exchange Online.

# Conectare la Exchange Online folosind autentificare modernă
# IMPORTANT: Parametrul -Credential este depreciat începând cu iunie 2026
# Utilizați exclusiv autentificarea modernă (Modern Auth)
Connect-ExchangeOnline -UserPrincipalName [email protected]

# Urmărirea unui mesaj specific din ultimele 48 de ore
Get-MessageTrace -SenderAddress [email protected] `
    -RecipientAddress [email protected] `
    -StartDate (Get-Date).AddHours(-48) `
    -EndDate (Get-Date)

# Urmărirea tuturor mesajelor care au eșuat pentru un expeditor
Get-MessageTrace -SenderAddress [email protected] `
    -StartDate (Get-Date).AddDays(-7) `
    -EndDate (Get-Date) | Where-Object {$_.Status -eq "Failed"}

Rezultatul comenzii Get-MessageTrace vă arată statusul fiecărui mesaj: Delivered, Failed, Pending, Quarantined sau FilteredAsSpam. În funcție de status, veți ști exact unde să continuați investigația.

Atenție: Comanda Get-MessageTrace acoperă doar ultimele 10 zile. Pentru mesaje mai vechi, trebuie să folosiți Start-HistoricalSearch, care generează un raport disponibil în câteva ore. Da, câteva ore — nu e ideal, dar e singura opțiune.

Cutia poștală plină — problema recurentă

O altă problemă foarte frecventă (și frustrantă) este cutia poștală plină. Utilizatorii primesc mesajul "Your mailbox is full" și nu mai pot trimite sau primi e-mailuri. Pentru a diagnostica rapid această situație, folosiți comanda Get-MailboxStatistics.

# Verificarea dimensiunii cutiei poștale a unui utilizator
Get-MailboxStatistics -Identity [email protected] | `
    Select-Object DisplayName, TotalItemSize, ItemCount, `
    DeletedItemCount, TotalDeletedItemSize

# Verificarea limitelor de cotă configurate
Get-Mailbox -Identity [email protected] | `
    Select-Object DisplayName, ProhibitSendQuota, `
    ProhibitSendReceiveQuota, IssueWarningQuota

# Verificarea dimensiunii folderului Recoverable Items
Get-MailboxFolderStatistics -Identity [email protected] `
    -FolderScope RecoverableItems | `
    Select-Object Name, FolderSize, ItemsInFolder

De multe ori, problema nu e că utilizatorul are prea multe e-mailuri în Inbox. Vinovatul ascuns? Folderul Recoverable Items, care poate crește nejustificat de mare — mai ales dacă există o politică de retenție sau un Litigation Hold activ pe cutia poștală respectivă. Am văzut cazuri în care acest folder ocupa zeci de GB fără ca utilizatorul să aibă habar.

Mesaje blocate în carantină

Politicile de protecție împotriva phishing-ului și spam-ului din Microsoft Defender for Office 365 pot fi uneori prea agresive, blocând mesaje perfect legitime. Când un utilizator raportează că nu primește un e-mail important, verificați întotdeauna carantina.

# Vizualizarea mesajelor din carantină pentru un destinatar specific
Get-QuarantineMessage -RecipientAddress [email protected] `
    -StartDate (Get-Date).AddDays(-7) `
    -EndDate (Get-Date)

# Eliberarea unui mesaj din carantină
Release-QuarantineMessage -Identity <MessageId> `
    -ReleaseToAll

Dacă observați un tipar de mesaje legitime blocate în carantină de la același expeditor, luați în considerare crearea unei reguli de transport sau adăugarea domeniului respectiv în lista de expeditori permiși (Allow list) din politica anti-spam. E o ajustare mică, dar vă poate scuti de multe tichete repetitive.

Probleme de conectivitate Outlook

Conectivitatea Outlook e un alt subiect frecvent în coada de tichete. Utilizatorii raportează că Outlook e "Disconnected", că se blochează la "Trying to connect..." sau că primesc erori de autentificare repetate. Iată un plan de diagnosticare structurat:

Verificați starea serviciului: Înainte de orice, consultați Microsoft 365 Service Health Dashboard. Dacă există o problemă cunoscută la nivel de serviciu, nu are rost să depanați local.
Testați conectivitatea de rețea: Verificați dacă utilizatorul poate accesa https://outlook.office365.com din browser. Dacă da, problema e probabil specifică aplicației Outlook de desktop.
Verificați profilul Outlook: Un profil corupt e o cauză surprinzător de frecventă. Creați un profil nou din Control Panel > Mail > Show Profiles.
Ștergeți cache-ul de credențiale: Deschideți Windows Credential Manager și ștergeți toate intrările care conțin "MicrosoftOffice" sau "mso".
Reparați instalarea Office: Din Settings > Apps, selectați Microsoft 365 Apps și rulați Online Repair.

Reguli de transport și impactul lor

Regulile de transport (Transport Rules) pot cauza probleme subtile care sunt dificil de diagnosticat. Un e-mail care dispare fără urmă poate fi rezultatul unei reguli de transport care îl redirecționează, îl șterge sau îl modifică — fără ca expeditorul sau destinatarul să fie notificați. Sincer, am pierdut ore întregi investigând astfel de situații.

# Listarea tuturor regulilor de transport active
Get-TransportRule | Select-Object Name, State, Priority, `
    Description | Format-List

# Verificarea unei reguli specifice cu toate detaliile
Get-TransportRule -Identity "Blocare atașamente executabile" | `
    Format-List

# Testarea impactului regulilor asupra unui mesaj specific
# Folosiți Exchange Admin Center > Mail flow > Message trace
# pentru rezultate vizuale detaliate

Notă importantă despre sesiunile PowerShell: Exchange Online permite maxim 3 sesiuni PowerShell concurente per utilizator. Dacă depășiți această limită, veți primi eroarea "New-PSSession: [outlook.office365.com] Connecting to remote server outlook.office365.com failed". Asigurați-vă că închideți întotdeauna sesiunile deschise cu Disconnect-ExchangeOnline când ați terminat diagnosticarea.

# Deconectare corectă de la Exchange Online
# Executați întotdeauna această comandă la finalul sesiunii
Disconnect-ExchangeOnline -Confirm:$false

Microsoft Entra ID și depanarea sincronizării hibride

Înțelegerea sincronizării cu Entra Connect

Microsoft Entra ID (cunoscut anterior ca Azure Active Directory) este serviciul central de identitate pentru întregul ecosistem Microsoft 365. În mediile hibride, sincronizarea dintre Active Directory on-premises și Entra ID este realizată de Microsoft Entra Connect. Această sincronizare e critică — dacă nu funcționează corect, utilizatorii nu pot accesa resursele cloud, parolele nu se actualizează, iar grupurile nu se propagă.

Ciclul implicit de sincronizare e de 30 de minute. În acest interval, modificările din Active Directory local sunt propagate către Entra ID. Totuși, există situații în care trebuie să forțați o sincronizare manuală sau să investigați de ce anumite obiecte pur și simplu nu se sincronizează.

# Verificarea stării planificatorului de sincronizare
# Rulați pe serverul Entra Connect
Get-ADSyncScheduler

# Rezultatul va arăta:
# AllowedSyncCycleInterval : 00:30:00
# CurrentlyEffectiveSyncCycleInterval : 00:30:00
# NextSyncCyclePolicyType : Delta
# NextSyncCycleStartTimeInUTC : ...
# SyncCycleEnabled : True

# Forțarea unei sincronizări delta (doar modificările)
Start-ADSyncSyncCycle -PolicyType Delta

# Forțarea unei sincronizări complete (toate obiectele)
# ATENȚIE: Poate dura mult în medii mari (zeci de mii de obiecte)
Start-ADSyncSyncCycle -PolicyType Initial

Erori frecvente de sincronizare

Erorile de sincronizare sunt printre cele mai complexe probleme pe care le veți întâlni. Iată cele mai frecvente scenarii:

1. Conflict de atribute (AttributeValueMustBeUnique). Această eroare apare când două obiecte din Active Directory au aceeași adresă de e-mail proxy sau același UserPrincipalName. Entra ID impune unicitatea acestor atribute la nivel de tenant — fără excepții.

# Identificarea obiectelor cu atribute conflictuale
# Rulați în Active Directory on-premises
Get-ADUser -Filter {ProxyAddresses -like "*smtp:[email protected]*"} `
    -Properties ProxyAddresses | `
    Select-Object Name, SamAccountName, @{
        Name="ProxyAddresses";
        Expression={$_.ProxyAddresses -join "; "}
    }

# Diagnosticarea erorilor de sincronizare cu instrumentul integrat
Invoke-ADSyncDiagnostics

2. Obiecte care nu se sincronizează. Dacă un utilizator sau un grup nu apare în Entra ID după sincronizare, verificați următoarele:

Obiectul se află într-un OU (Organizational Unit) care e inclus în scopul de sincronizare? Verificați configurația din Entra Connect Wizard.
Obiectul îndeplinește regulile de filtrare configurate? Entra Connect poate filtra obiecte pe baza atributelor.
Obiectul are erori de validare? De exemplu, un utilizator fără atributul userPrincipalName nu va fi sincronizat.
Contul de serviciu Entra Connect are permisiunile necesare în Active Directory local?

# Căutarea unui obiect specific în metaverse-ul Entra Connect
# Deschideți Synchronization Service Manager pe serverul Entra Connect
# sau folosiți PowerShell:

# Verificarea stării sincronizării unui obiect specific
$connector = Get-ADSyncConnector | Where-Object {$_.Name -like "*contoso*"}
$csObject = Get-ADSyncCSObject -ConnectorIdentifier $connector.Identifier `
    -DistinguishedName "CN=Ion Popescu,OU=Utilizatori,DC=contoso,DC=local"

# Verificați dacă obiectul are erori de export
Get-ADSyncRunProfileResult | Where-Object {$_.Result -ne "success"} | `
    Select-Object -First 20

Dispozitive blocate în starea "Pending"

În mediile cu Hybrid Azure AD Join (acum Hybrid Entra Join), dispozitivele Windows trebuie să fie înregistrate atât în Active Directory local, cât și în Entra ID. O problemă frecventă — și destul de enervantă — este că dispozitivele rămân blocate în starea "Pending", ceea ce înseamnă că nu pot beneficia de politicile de Conditional Access care necesită dispozitive conforme.

Cauzele cele mai frecvente sunt:

Service Connection Point (SCP) configurat incorect: SCP-ul trebuie să existe în Active Directory și să pointeze către tenant-ul Entra ID corect.
Probleme de comunicare cu endpoint-urile Microsoft: Dispozitivul trebuie să poată accesa https://enterpriseregistration.windows.net și https://login.microsoftonline.com.
Task-ul programat nu rulează: Hybrid Join e inițiat de un task programat (Automatic-Device-Join) care trebuie să ruleze în contextul dispozitivului, nu al utilizatorului.
Certificatul dispozitivului nu a fost emis: Hybrid Join necesită un certificat care e solicitat de la un endpoint intern al AD FS sau direct de la Entra ID (în cazul Managed Domains).

# Pe dispozitivul client, verificați starea înregistrării
dsregcmd /status

# Căutați secțiunile:
# Device State - ar trebui să arate "AzureAdJoined : YES"
# Tenant Details - informații despre tenant
# Diagnostic Data - erori specifice

# Dacă starea este Pending, verificați logurile de evenimente
# Event Viewer > Applications and Services Logs >
# Microsoft > Windows > User Device Registration > Admin

Monitorizarea cu Entra Connect Health

Microsoft Entra Connect Health este un serviciu de monitorizare bazat pe cloud care oferă vizibilitate asupra stării sincronizării. Sincer, e unul dintre acele instrumente pe care nu le apreciezi suficient până când nu ai nevoie de ele. Pentru a-l utiliza eficient:

Verificați că agentul Entra Connect Health este instalat și actualizat pe serverul Entra Connect.
Monitorizați alerta "Sync has not completed in the last 120 minutes" — aceasta indică o problemă critică.
Verificați periodic rapoartele de erori de sincronizare din portalul Entra ID > Entra Connect > Connect Health.
Configurați notificări prin e-mail pentru alertele critice.

# Verificarea versiunii agentului Entra Connect Health
Get-WmiObject -Class Win32_Product | `
    Where-Object {$_.Name -like "*Health*Agent*"} | `
    Select-Object Name, Version

# Verificarea serviciilor asociate
Get-Service -Name "AzureADConnectHealthSyncInsights", `
    "AzureADConnectHealthSyncMonitor" | `
    Select-Object Name, Status, StartType

Depanarea Microsoft Teams: conectivitate, autentificare și calitatea apelurilor

Probleme de conectivitate în Teams

Microsoft Teams e aplicația centrală de comunicare în majoritatea organizațiilor, iar problemele cu Teams au un impact imediat asupra productivității. Depanarea Teams poate fi complexă deoarece aplicația depinde de multiple servicii backend: Exchange Online (pentru calendar și prezență), SharePoint Online (pentru fișiere), Entra ID (pentru autentificare) și infrastructura proprie de conferință și chat.

Probleme cauzate de firewall și proxy. Teams necesită acces direct (fără inspecție SSL) la o serie de endpoint-uri Microsoft. Dacă organizația dumneavoastră folosește un proxy cu inspecție SSL sau un firewall restrictiv, aceasta e prima zonă pe care trebuie s-o verificați.

Endpoint-urile critice pentru Teams includ:

*.teams.microsoft.com — servicii Teams principale
*.skype.com — infrastructura de apeluri și conferințe
*.sfbassets.com — resurse statice
13.107.64.0/18 și 52.112.0.0/14 — intervale de IP-uri pentru traficul media
Porturile UDP 3478-3481 trebuie să fie deschise pentru traficul media (audio/video) — aceasta e o cerință critică pe care multe organizații o ignoră, din păcate

Probleme DNS. Teams e extrem de sensibil la latența DNS. Dacă serverele DNS interne sunt lente sau dacă există probleme de rezoluție pentru domeniile Microsoft, veți observa timpi lungi de încărcare, erori de conectare și calitate proastă a apelurilor. Asigurați-vă că rezoluția DNS pentru teams.microsoft.com returnează un răspuns în mai puțin de 100ms.

Erori de autentificare în Teams

Erorile de autentificare sunt printre cele mai frustrante probleme din Teams. Mesajele de eroare sunt adesea generice și neinformative. Cel mai frecvent scenariu? Utilizatorul vede ecranul de încărcare la infinit sau primește eroarea "We're sorry — we've run into an issue". Nu prea ajută, nu-i așa?

Procedura de depanare recomandată:

Ștergeți cache-ul Teams. Aceasta rezolvă surprinzător de multe probleme. Închideți complet Teams (inclusiv din System Tray), apoi ștergeți conținutul directorului de cache.

REM Închideți Teams complet, apoi executați în Command Prompt:

REM Pentru Teams clasic (dacă încă este utilizat):
rd /s /q "%appdata%\Microsoft\Teams"

REM Pentru Teams nou (bazat pe WebView2):
rd /s /q "%localappdata%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache"

REM Alternativ, din PowerShell:
Remove-Item -Path "$env:APPDATA\Microsoft\Teams\*" -Recurse -Force
Remove-Item -Path "$env:LOCALAPPDATA\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\*" `
    -Recurse -Force -ErrorAction SilentlyContinue

Verificați credențialele stocate. Deschideți Windows Credential Manager și ștergeți toate intrările legate de Teams și Microsoft Office.
Verificați politicile Conditional Access. O politică de Conditional Access restrictivă poate bloca accesul la Teams fără a oferi un mesaj de eroare clar. Verificați logurile de Sign-in din Entra ID > Monitoring > Sign-in logs și filtrați după aplicația "Microsoft Teams".
Testați în browser. Dacă Teams funcționează la https://teams.microsoft.com în browser dar nu în aplicația de desktop, problema e specifică aplicației locale.

Diagnosticarea calității apelurilor

Calitatea apelurilor e o zonă critică, mai ales în contextul muncii hibride unde fiecare angajat are o conexiune diferită la internet. Microsoft pune la dispoziție instrumente puternice pentru a investiga problemele de calitate:

Call Quality Dashboard (CQD) din Teams Admin Center oferă o vedere de ansamblu asupra calității apelurilor la nivel de organizație. Puteți identifica probleme recurente legate de rețea, dispozitive sau locații specifice.

Per-user call analytics permite investigarea problemelor pentru un utilizator specific. Din Teams Admin Center > Users, selectați utilizatorul și accesați tab-ul "Meetings & calls" pentru a vedea detaliile fiecărui apel: jitter, packet loss, latența și tipul de conexiune utilizat.

Indicatorii de calitate de urmărit:

Jitter: Ar trebui să fie sub 30ms. Valori peste 30ms indică instabilitate în rețea.
Packet Loss: Ar trebui să fie sub 5%. Peste această limită, problemele devin audibile.
Round Trip Time (RTT): Ar trebui să fie sub 100ms. Valori mari indică latență în rețea sau o rută suboptimală către serverele Microsoft.

Utilizarea Teams Admin Center pentru depanare

Teams Admin Center (https://admin.teams.microsoft.com) e punctul central de administrare și depanare. Pe lângă gestionarea politicilor și configurațiilor, acordați o atenție deosebită următoarelor secțiuni:

Meeting policies: Verificați că utilizatorul are politica corectă asignată. O politică restrictivă poate împiedica partajarea ecranului, înregistrarea sau alte funcționalități.
Voice > Phone numbers: Dacă organizația folosește Teams Phone, verificați aici asignarea numerelor de telefon și politicile de apeluri.
Devices: Monitorizați starea dispozitivelor Teams Rooms și a telefoanelor Teams înregistrate în organizație.
Analytics & reports: Folosiți rapoartele de utilizare pentru a identifica tendințe și probleme potențiale înainte ca utilizatorii să le raporteze.

Gestionarea licențelor și depanarea problemelor de activare

Eroarea "Not Licensed" și variațiile sale

Problemele de licențiere sunt printre cele mai confuze din ecosistemul Microsoft 365. Un utilizator poate raporta că "Word nu mai funcționează", dar cauza reală e o problemă de licență care afectează întreaga suită Office. Am văzut asta de nenumărate ori.

Scenariile cele mai frecvente sunt:

1. Licența nu e asignată sau a fost eliminată accidental. Verificați în Microsoft 365 Admin Center > Users > Active users > selectați utilizatorul > Licenses and apps. Asigurați-vă că licența corectă (de exemplu, Microsoft 365 E3 sau Business Premium) e asignată și că serviciile individuale din cadrul licenței sunt activate.

2. Licența e asignată, dar activarea a eșuat. Această situație apare de obicei când există credențiale stocate vechi sau când profilul de activare Office e corupt.

REM Verificarea stării activării Office din Command Prompt
REM Navigați la directorul Office (ajustați calea după versiune)
cd "C:\Program Files\Microsoft Office\Office16"
cscript ospp.vbs /dstatus

REM Dacă starea arată "NOTIFICATIONS" sau "UNLICENSED":

REM Pasul 1: Ștergeți token-urile de activare
cscript ospp.vbs /unpkey:XXXXX
REM (unde XXXXX sunt ultimele 5 caractere ale cheii afișate de /dstatus)

REM Pasul 2: Ștergeți credențialele Office din Credential Manager
cmdkey /list | findstr "MicrosoftOffice"
REM Ștergeți fiecare intrare găsită:
cmdkey /delete:MicrosoftOffice16_Data:ADAL:<ID>

REM Pasul 3: Deconectați și reconectați contul din orice aplicație Office
REM File > Account > Sign out, apoi Sign in din nou

3. Limita de dispozitive depășită. Majoritatea licențelor Microsoft 365 permit activarea pe un număr limitat de dispozitive (de obicei 5 PC-uri/Mac-uri + 5 tablete + 5 telefoane). Dacă utilizatorul a depășit această limită, activarea pe un dispozitiv nou va eșua. Puteți dezactiva dispozitivele vechi din portalul https://myaccount.microsoft.com sau din Admin Center.

Activare partajată pentru VDI și RDS

În mediile cu Virtual Desktop Infrastructure (VDI) sau Remote Desktop Services (RDS), activarea standard a aplicațiilor Office nu funcționează corect. În aceste scenarii, trebuie să utilizați Shared Computer Activation — un mecanism special care permite mai multor utilizatori să folosească aplicațiile Office pe același dispozitiv, fiecare cu propria licență.

REM Verificarea dacă Shared Computer Activation este activată
REM Deschideți orice aplicație Office > File > Account
REM Ar trebui să vedeți "Shared Computer Activation" în loc de
REM informații despre abonament

REM Dacă trebuie să activați SCA prin registry:
REG ADD "HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration" `
    /v SharedComputerLicensing /t REG_SZ /d 1 /f

REM Sau prin Office Deployment Tool (configuration.xml):
REM <Property Name="SharedComputerLicensing" Value="1" />

REM După activarea SCA, fiecare utilizator care se autentifică
REM pe dispozitivul partajat va primi un token de licență individual
REM stocat în profilul său local

Probleme frecvente cu Shared Computer Activation:

Token-uri de licență expirate: Token-urile SCA expiră după 30 de zile de inactivitate. Dacă un utilizator nu se autentifică periodic, va trebui să se reautentifice.
Eroarea "UNLICENSED PRODUCT" pe VDI: Verificați că licența utilizatorului include dreptul de Shared Computer Activation (necesită Microsoft 365 Apps for Enterprise, nu versiunea Business).
Profile de roaming: Dacă utilizați profile de roaming sau FSLogix, asigurați-vă că directorul %localappdata%\Microsoft\Office\16.0\Licensing e inclus în profilul de roaming.

Licențiere bazată pe dispozitiv

Începând cu 2024, Microsoft oferă și device-based licensing pentru Microsoft 365 Apps — o opțiune utilă pentru dispozitivele partajate din fabrici, laboratoare sau spații comune. În acest model, licența e asignată unui grup de dispozitive din Entra ID, nu utilizatorilor individuali.

Problemele frecvente cu licențele bazate pe dispozitiv includ:

Dispozitivul nu e membru al grupului corect în Entra ID.
Obiectul dispozitivului nu a fost sincronizat corect din Active Directory local.
Licența de tip "Microsoft 365 Apps for Enterprise (device)" nu a fost asignată grupului.
Dispozitivul nu poate comunica cu serviciile de licențiere Microsoft (verificați conectivitatea la https://activation.sls.microsoft.com).

Microsoft Support and Recovery Assistant (SaRA): diagnosticarea la distanță

Ce este SaRA și de ce ar trebui să-l folosiți

Microsoft Support and Recovery Assistant (SaRA) este un instrument de diagnosticare gratuit oferit de Microsoft care poate identifica și rezolva automat o gamă largă de probleme cu produsele Microsoft 365. Onest, e unul dintre cele mai subutilizate instrumente din arsenalul unui helpdesk. Versiunea Enterprise e deosebit de valoroasă deoarece poate fi rulată de la distanță și prin linia de comandă, fără interacțiune din partea utilizatorului.

Scenarii suportate de SaRA:

Probleme de conectare Outlook (profil corupt, configurare greșită, probleme de autentificare)
Probleme de activare Office
Probleme de sincronizare OneDrive
Diagnosticarea configurației Teams
Probleme de autentificare în aplicațiile Microsoft 365
Verificarea configurației de rețea pentru serviciile Microsoft 365

Utilizarea SaRA din linia de comandă

Versiunea Enterprise a SaRA permite rularea scenariilor de diagnosticare prin linia de comandă, ceea ce o face ideală pentru automatizare și diagnosticare la distanță prin instrumente de management precum SCCM, Intune sau remote PowerShell.

REM Descărcarea SaRA Enterprise
REM https://aka.ms/SaRA_EnterpriseVersion

REM Rularea unui scenariu de diagnosticare Outlook din linia de comandă
SaRACmd.exe -S OlkCalCheck -AcceptEula

REM Scenarii disponibile frecvent utilizate:
REM -S ExpertExperienceAdminTask    Diagnosticare generală
REM -S OlkCalCheck                  Probleme calendar Outlook
REM -S TeamsAddinScenario           Probleme add-in Teams în Outlook
REM -S ResetOfficeActivation        Resetare activare Office

REM Rularea cu output către un fișier de log
SaRACmd.exe -S OlkCalCheck -AcceptEula -LogFolder "C:\SaRA_Logs"

REM Verificarea codului de retur
REM 0 = Succes, problema rezolvată
REM 1 = Problema detectată dar nu a putut fi rezolvată automat
REM 2 = Scenariul nu a putut fi rulat

Important: SaRA are o perioadă de valabilitate a build-ului de 90 de zile. După această perioadă, versiunea descărcată va înceta să funcționeze și va trebui să descărcați o versiune actualizată. Planificați un task recurent pentru actualizare — altfel veți descoperi problema fix când aveți cel mai mult nevoie de instrument.

Sfat practic: Distribuiți SaRA Enterprise pe toate stațiile de lucru prin Intune sau SCCM și creați scripturi care rulează scenariile cele mai frecvente. Acest lucru vă permite să rezolvați multe probleme fără a accesa fizic sau prin remote desktop stația utilizatorului.

Monitorizare proactivă și prevenirea incidentelor

Microsoft 365 Service Health Dashboard

Monitorizarea proactivă a serviciilor Microsoft 365 e esențială pentru a reduce numărul de tichete și pentru a îmbunătăți timpul de răspuns. Service Health Dashboard e prima destinație pe care ar trebui s-o verificați atunci când primiți mai multe tichete similare în același timp.

Accesați Service Health Dashboard din Microsoft 365 Admin Center > Health > Service health. Aici veți găsi:

Active issues: Incidentele curente care afectează serviciile Microsoft 365. Fiecare incident include un ID (de exemplu, EX123456), o descriere a impactului, actualizări de stare și un timp estimat de rezolvare.
Advisories: Probleme cunoscute cu impact minor care nu necesită acțiune imediată.
Post-incident reviews: Analize detaliate ale incidentelor majore după rezolvare — extrem de utile pentru a înțelege ce s-a întâmplat.
Planned maintenance: Ferestre de mentenanță planificată care pot afecta disponibilitatea serviciilor.

# Verificarea stării serviciilor Microsoft 365 prin PowerShell
# Necesită modulul Microsoft.Graph
Connect-MgGraph -Scopes "ServiceHealth.Read.All"

# Obținerea incidentelor active
Get-MgServiceAnnouncementHealthOverview | `
    Where-Object {$_.Status -ne "serviceOperational"} | `
    Select-Object Service, Status

# Obținerea detaliilor unui incident specific
Get-MgServiceAnnouncementIssue -ServiceHealthIssueId "EX123456"

Testul de conectivitate rețea Microsoft 365

Microsoft oferă un instrument dedicat pentru testarea conectivității de rețea către serviciile Microsoft 365: Microsoft 365 Network Connectivity Test (https://connectivity.office.com). Acest instrument testează:

Latența către cele mai apropiate puncte de prezență (PoP) Microsoft
Calitatea conexiunii pentru traficul Exchange Online, SharePoint Online și Teams
Configurația DNS și detectarea proxy-urilor intermediare
Disponibilitatea porturilor necesare pentru Teams (UDP 3478-3481)

Rezultatele testului includ un scor general și recomandări specifice. Dacă scorul e sub 80%, există probleme de rețea care afectează experiența utilizatorilor și care trebuie investigate. Nu ignorați acest indicator.

Strategii de monitorizare proactivă

O echipă de helpdesk matură nu așteaptă ca utilizatorii să raporteze problemele — le detectează proactiv. Iată câteva strategii concrete pe care le puteți implementa chiar acum:

Configurați alerte în Service Health Dashboard: Din Admin Center > Health > Service health > Preferences, configurați notificări prin e-mail pentru incidentele care afectează serviciile critice din organizația dumneavoastră.
Monitorizați sincronizarea Entra Connect: Configurați o alertă care să vă notifice dacă sincronizarea nu s-a finalizat în ultimele 120 de minute. Folosiți Entra Connect Health sau un script PowerShell planificat.
Verificați periodic expirările de certificate și secrete: Certificatele utilizate de aplicațiile Enterprise din Entra ID au o durată de viață limitată. Configurați alerte pentru expirările care se apropie.
Monitorizați utilizarea licențelor: Verificați periodic că aveți suficiente licențe disponibile. O lipsă de licențe poate cauza probleme de activare pentru utilizatorii noi.
Urmăriți rapoartele de securitate: Verificați zilnic rapoartele de Sign-in cu risc și utilizatorii compromiși din Entra ID Protection.

# Script exemplu pentru monitorizarea sincronizării Entra Connect
# Poate fi planificat ca task recurent

$lastSync = Get-ADSyncScheduler
$lastRun = $lastSync.LastSyncCycleStartTimeInUTC
$timeSinceLastSync = (Get-Date).ToUniversalTime() - $lastRun

if ($timeSinceLastSync.TotalMinutes -gt 120) {
    # Trimiteți o alertă prin e-mail sau către sistemul de monitorizare
    $subject = "ALERTĂ: Sincronizarea Entra Connect nu a rulat de peste 2 ore"
    $body = "Ultima sincronizare: $lastRun UTC`n"
    $body += "Timp scurs: $($timeSinceLastSync.TotalMinutes) minute"

    # Exemplu: trimitere notificare
    Send-MailMessage -To "[email protected]" `
        -From "[email protected]" `
        -Subject $subject `
        -Body $body `
        -SmtpServer "smtp.contoso.com"
}

Crearea alertelor personalizate

Pe lângă alertele native din Microsoft 365, puteți crea alerte personalizate folosind Microsoft Graph API și Azure Logic Apps sau Power Automate. De exemplu:

O alertă care vă notifică când un utilizator cu rol de administrator se autentifică dintr-o țară neașteptată.
O alertă când numărul de autentificări eșuate pentru un utilizator depășește un prag în ultimele 24 de ore.
O alertă când o regulă de transport e creată sau modificată — aceasta poate indica o compromitere a contului de administrator.
O alertă când expirările de licențe se apropie de pragul critic (mai puțin de 10% licențe disponibile).

Bune practici pentru documentarea tichetelor Microsoft 365

De ce documentarea corectă contează

Un tichet bine documentat e diferența dintre o rezolvare rapidă și una care se prelungește zile întregi cu schimburi nesfârșite de e-mailuri. Toți am fost acolo. În contextul Microsoft 365, unde problemele pot implica mai multe servicii și echipe, documentarea precisă e și mai importantă.

Informații esențiale de colectat

1. Identificarea utilizatorului afectat:

Nume complet și UserPrincipalName (UPN) — de exemplu, [email protected]
Departament și locație fizică
Tipul de licență Microsoft 365 asignată
Dacă utilizatorul e sincronizat din AD on-premises sau e cloud-only

2. Descrierea problemei:

Ce încearcă utilizatorul să facă? (acțiunea specifică)
Ce se întâmplă în loc? (comportamentul observat)
Ce ar trebui să se întâmple? (comportamentul așteptat)
Mesajul de eroare exact — inclusiv coduri de eroare, ID-uri de corelație (Correlation ID) și timestamp-uri
De când apare problema? A funcționat vreodată? Ce s-a schimbat?

3. Informații tehnice:

Dispozitivul utilizat: sistem de operare, versiune, dacă e gestionat de Intune sau nu
Aplicația afectată și versiunea: Outlook 365 versiune 2401, Teams new client, etc.
Tipul de conexiune: rețea corporativă, VPN, rețea de acasă, hotspot mobil
Reproducibilitate: problema apare constant sau intermitent? Pe un singur dispozitiv sau pe toate?

4. Pași de diagnosticare deja efectuați:

S-a verificat Service Health Dashboard?
S-a testat în browser? (pentru a izola problemele aplicației de desktop)
S-a șters cache-ul aplicației?
S-a testat pe un alt dispozitiv sau cu un alt cont?

REM Colectarea rapidă a informațiilor de diagnosticare de pe stația utilizatorului

REM Versiunea Office
REG QUERY "HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration" /v VersionToReport

REM Starea activării
cd "C:\Program Files\Microsoft Office\Office16" && cscript ospp.vbs /dstatus

REM Starea înregistrării dispozitivului în Entra ID
dsregcmd /status

REM Informații de rețea relevante
ipconfig /all
nslookup outlook.office365.com
nslookup teams.microsoft.com

REM Test de conectivitate către endpoint-urile Microsoft 365
Test-NetConnection -ComputerName outlook.office365.com -Port 443
Test-NetConnection -ComputerName teams.microsoft.com -Port 443

Structura recomandată pentru tichetele de helpdesk M365

Iată un model de structură pe care îl recomand pentru tichetele Microsoft 365:

Titlu: [Serviciu afectat] - Descriere scurtă a problemei — exemplu: "[Exchange Online] - Utilizatorul nu primește e-mailuri externe"
Prioritate: Stabilită pe baza impactului (câți utilizatori sunt afectați) și urgenței (cât de critic e serviciul afectat)
Categorie: Exchange Online / Teams / Entra ID / Licențe / SharePoint / OneDrive / Securitate
Descriere detaliată: Include toate informațiile enumerate mai sus
Pași de reproducere: Pași clari și numerotați pentru a reproduce problema
Capturi de ecran: Includeți întotdeauna capturi de ecran ale mesajelor de eroare
Log-uri: Atașați log-uri relevante (Event Viewer, SaRA reports, message traces)

Proceduri de escaladare

Nu toate problemele pot fi rezolvate la primul nivel de suport. Iată când și cum să escaladați:

Escaladare la nivelul 2 (administratori M365):

Probleme care necesită modificări în Exchange Online (reguli de transport, politici de protecție)
Erori de sincronizare Entra Connect care necesită intervenție pe serverul de sincronizare
Probleme de licențiere care necesită achiziții sau realocări la nivel de organizație
Configurări de Conditional Access care blochează accesul utilizatorilor

Escaladare către Microsoft Support:

Incidente de serviciu confirmate care nu sunt încă documentate în Service Health
Probleme pe care le-ați investigat exhaustiv și pentru care nu ați găsit o soluție
Probleme care afectează un număr mare de utilizatori și care par a fi cauzate de o modificare pe partea Microsoft
Includeți întotdeauna în cererea de suport: Correlation ID-uri, timestamp-uri exacte, rezultatele comenzilor de diagnosticare și pașii deja efectuați

Informații esențiale pentru escaladarea către Microsoft:

REM Obținerea Correlation ID din Entra ID Sign-in Logs
REM Portal: Entra ID > Monitoring > Sign-in logs
REM Filtrați după utilizator și copiați "Request ID" și "Correlation ID"

REM Obținerea Message Trace ID pentru probleme de e-mail
Get-MessageTrace -MessageTraceId <GUID>

REM Obținerea informațiilor de diagnosticare din Outlook
REM Ctrl + Right-click pe iconița Outlook din System Tray
REM > Connection Status > selectați toate > Copy to Clipboard

REM Generarea unui raport de diagnosticare Teams
REM În Teams: Settings > General > Download diagnostics
REM (va genera un fișier .zip cu log-uri detaliate)

Concluzii și resurse suplimentare

Depanarea Microsoft 365 în 2026 necesită o combinație de cunoștințe tehnice solide, instrumente adecvate și procese bine definite. Mediul de lucru hibrid a amplificat complexitatea problemelor, dar a creat și oportunități pentru automatizare și monitorizare proactivă.

Iată un rezumat al principalelor puncte de reținut din acest ghid:

Exchange Online: Folosiți Get-MessageTrace ca primă linie de investigație pentru problemele de flux de e-mail. Verificați întotdeauna carantina și regulile de transport. Nu depășiți limita de 3 sesiuni PowerShell concurente.
Entra ID și sincronizarea hibridă: Monitorizați constant starea sincronizării. Folosiți Invoke-ADSyncDiagnostics pentru a identifica rapid problemele. Ciclul implicit de sincronizare e de 30 de minute.
Microsoft Teams: Ștergerea cache-ului rezolvă o proporție surprinzător de mare din probleme. Asigurați-vă că porturile UDP 3478-3481 sunt deschise pentru traficul media. Folosiți Call Quality Dashboard pentru analiza sistematică.
Licențiere: Verificați întotdeauna starea licenței înainte de a investiga alte cauze. Nu uitați de Shared Computer Activation pentru mediile VDI/RDS.
SaRA: Folosiți versiunea Enterprise pentru diagnosticare la distanță. Actualizați-o la fiecare 90 de zile.
Monitorizare: Configurați alerte în Service Health Dashboard. Creați scripturi de monitorizare pentru sincronizarea Entra Connect.
Documentare: Colectați întotdeauna Correlation ID, timestamp-uri, mesaje de eroare exacte și informații despre dispozitiv și rețea. Un tichet bine documentat se rezolvă de două ori mai repede.

Notă finală privind autentificarea modernă: Începând cu iunie 2026, parametrul -Credential din Connect-ExchangeOnline e depreciat. Asigurați-vă că toate scripturile și procedurile dumneavoastră sunt actualizate pentru a utiliza exclusiv autentificarea modernă (Modern Auth) cu Connect-ExchangeOnline -UserPrincipalName sau cu certificate de aplicație pentru scenariile automatizate. Această schimbare face parte din strategia mai amplă a Microsoft de eliminare a autentificării bazice.

Peisajul Microsoft 365 evoluează constant, cu noi funcționalități, modificări de politici și deprecieri de servicii care apar în fiecare lună. Investiți timp în formarea continuă, participați la sesiunile Microsoft Ignite și urmăriți blogurile oficiale Microsoft. O echipă de helpdesk informată nu doar rezolvă problemele — le previne.