Soluții

Cum se schimbă organizatorul întâlnirii în Outlook folosind metoda de administrare cu Powershell

Dacă ați fost vreodată nevoiți să încheiați colaborarea cu o persoană care organiza jumătate din întâlnirile recurente din companie, cunoașteți problema. Seria de întâlniri continuă, participanții primesc în continuare notificări, dar organizatorul nu mai este.

Nu exista o soluție clară pentru a remedia această situație. Fie anulați întâlnirea și rugați pe cineva să o creeze din nou de la zero, fie vă împăcați cu existența unui organizator „fantomă” atâta timp cât adresa de e-mail rămânea activă. Acum lucrurile s-au schimbat. Microsoft a introdus în sfârșit o modalitate de a transfera dreptul de proprietate asupra meeting-urilor.

Problema legată de schimbarea proprietarului unei întâlniri

Outlook și Teams nu au avut niciodată un buton de „transfer al proprietății” pentru întâlniri. Teams îți permite să adaugi coorganizatori, iar Outlook îți permite să delegi accesul la calendar, dar niciuna dintre aceste opțiuni nu transferă efectiv proprietatea.

Așadar, singura opțiune era să anulezi seria de întâlniri și să rogi pe altcineva să o recreeze, ceea ce duce la pierderea istoricului de prezență, a componentelor Loop și a elementelor legate de întâlnirile/meetings din Teams.

O soluție alternativă folosită de unele organizații era programarea întâlnirilor recurente importante dintr-o căsuță partajata/shared maillbox, în loc de una personală. În acest fel, nu era nevoie să se schimbe niciodată proprietarul. Funcționează, dar înseamnă să planifici dinainte pentru o problemă care nici nu ar fi trebuit să existe.

Cerințe

Înainte de a putea utiliza cmdletul, asigurați-vă că îndepliniți următoarele condiții:

  • Modulul PowerShell ExchangeOnlineManagement, versiunea 3.10 sau o versiune ulterioară, instalat
  • Cel puțin rolul de administrator Exchange Online.
  • Conectați-vă inainte de orice la Exchange Online in Powershell ca de obicei:

Connect-ExchangeOnline

[mai mult...]

Actualizarea cumulativa din septembrie 2026 impacteaza RDS. Cum se poate remedia situatia

Windows Update are obiceiul de a provoca probleme, iar de data aceasta este vorba despre Remote Desktop Services = Serviciul de desktop la distanță. Gazdele de sesiune funcționează fără probleme câteva ore după repornire, dar apoi conexiunile rămân blocate la „Connecting…”, utilizatorii nu se pot deconecta, iar în cele din urmă singura soluție este o resetare forțată.

Revenirea la versiunea anterioară a actualizării este adesea cea mai simplă soluție, dar versiunea lansată luna Septembrie 2026 remediază vulnerabilitatea CVE-2026-69525, o vulnerabilitate critică de tip RCE = de execuție a codului la distanță pentru Serviciile de desktop remote, cu un scor CVSS de 9,8, plus două vulnerabilități de tip zero-day care sunt deja exploatate activ. Așadar, revenirea la versiunea anterioară s-ar putea să nu fie cea mai bună opțiune.

Ce se întâmplă

Mai mulți administratori au descris același tipar de eroare si anume ca gazdele sesiunilor RDS funcționează normal după o repornire, apoi se blochează câteva ore mai târziu, când utilizatorii încep să se deconecteze.

Odată ce problema apare, noile conexiuni RDP rămân blocate la „Connecting…” și nu ajung niciodată la ecranul de autentificare. Sesiunile existente nu se pot deconecta corect. Task Manager, Setări și majoritatea instrumentelor care interacționează cu starea sesiunii intră în blocaj, deoarece nu pot obține un răspuns de la Local Session Manager (LSM). Chiar și o repornire normală se blochează. Numai o resetare forțată restabilește funcționarea gazdei.

Problema pare să fie legată de o rutină numită RDPSERVERBASE!WDLIB_Close, care este apelată în timpul închiderii sesiunii. Atunci când un anumit indicator de funcționalitate intern(3802373433) este activ, această rutină apelează funcția RtlWaitOnAddress fără limită de timp, ceea ce determină firul de execuție să aștepte pe termen nelimitat.

Deoarece LSM serializează modificările stării sesiunii printr-o singură secțiune critică, acel thread blocat blochează tot ce se află în aval de el = conexiuni noi, deconectări și solicitări către broker, până când host-ul este resetat forțat.

Acestea sunt semnăturile si avertismentele din jurnalul de evenimente care indică această eroare specifică:

  • Eveniment 20498 din TerminalServices-RemoteConnectionManager: „Remote Desktop Services has taken too long to complete the client connection”
  • Eveniment 6005 din Winlogon: „The winlogon notification subscriber SessionEnv is taking long time to handle the notification event (Disconnect)”
  • Starea TermService: StopPending în loc de Running

Problema afectează toate versiunile actuale de Windows Server prin intermediul actualizărilor cumulative din septembrie 2026.

De ce revenirea la o versiune anterioară este o soluție de ultimă instanță

Aceeași actualizare care a provocat defecțiuni la RDS a remediat și vulnerabilitatea CVE-2026-69525, o vulnerabilitate critică de execuție a codului la distanță în Serviciile de desktop la distanță, cu un scor CVSS de 9,8. Versiunea din septembrie a remediat, de asemenea, vulnerabilitățile CVE-2026-81963(Windows Update) și CVE-2026-85880 (Windows Advanced Local Procedure Call), ambele fiind vulnerabilități de tip „zero-day” deja exploatate activ și incluse în catalogul CISA al vulnerabilităților cunoscute ca fiind exploatate.

Dacă serverele RDS sunt utilizate doar intern și nu sunt expuse la internet, riscul este mai mic, iar revenirea la versiunea anterioară ar putea fi cea mai simplă opțiune. Însă, dacă serverul RDS este accesibil de pe internet, revenirea la versiunea anterioară ar trebui să fie ultima soluție.

[mai mult...]

Cum rezolvi eroarea 0x80070035 – the network path was not found in Windows 11

Eroarea 0x80070035 – The network path was not found apare in Windows 11 atunci cand sistemul nu poate accesa o resursa din retea, cum ar fi un folder partajat, un NAS sau un alt calculator.

De exemplu, eroarea poate aparea la accesarea unei cai de forma:

\\SERVER\Shared

sau:

\\192.168.1.100\Shared

Problema poate fi cauzata de setarile de network discovery, firewall, serviciile Windows necesare pentru descoperirea dispozitivelor sau de configuratia SMB.

1. Verifica daca echipamentul este accesibil in retea

Deschide Command Prompt si testeaza conexiunea:

ping 192.168.1.100

Inlocuieste IP-ul cu adresa serverului, NAS-ului sau calculatorului pe care doresti sa il accesezi.

Daca primesti raspuns:

Reply from 192.168.1.100...

conectivitatea IP functioneaza.

Daca folosesti numele calculatorului:

\\SERVER\Shared

incearca accesul direct prin IP:

\\192.168.1.100\Shared

Daca prin IP functioneaza, dar prin numele serverului nu, problema este cel mai probabil legata de DNS / name resolution.

2. Verifica portul SMB

Windows foloseste in principal portul TCP 445 pentru accesarea folderelor partajate.

Deschide PowerShell si ruleaza:

Test-NetConnection 192.168.1.100 -Port 445

Rezultatul corect ar trebui sa contina:

TcpTestSucceeded : True

Daca rezultatul este False, trebuie verificat firewall-ul, configuratia serverului sau conectivitatea dintre retele/VLAN-uri.

3. Activeaza Network Discovery si File Sharing

Acceseaza:

Settings → Network & Internet → Advanced network settings → Advanced sharing settings

Activeaza:

Network discovery
File and printer sharing

Verifica aceste optiuni pentru profilul de retea utilizat, de regula Private networks.

De asemenea, verifica daca reteaua Windows este configurata ca Private, nu Public.

4. Verifica serviciile Windows necesare

Apasa:

Win + R

scrie:

services.msc

si verifica urmatoarele servicii:

Function Discovery Provider Host
Function Discovery Resource Publication

Pentru fiecare:

  • seteaza Startup type pe Automatic sau Automatic (Delayed Start);
  • porneste serviciul daca acesta este oprit.

Aceste servicii ajuta Windows sa descopere si sa publice resursele disponibile in reteaua locala.

5. Verifica Windows Defender Firewall

Deschide:

Control Panel → Windows Defender Firewall → Allow an app or feature through Windows Defender Firewall

Verifica daca este permis:

File and Printer Sharing

pentru reteaua Private.

Alternativ, din PowerShell pornit ca Administrator:

Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True

Dupa modificare, testeaza din nou accesul:

\\192.168.1.100\Shared

6. Sterge conexiunile SMB vechi

O conexiune existenta cu credentiale incorecte poate impiedica accesarea resursei.

Deschide Command Prompt:

net use

Pentru eliminarea conexiunilor SMB existente:

net use * /delete

Confirma stergerea si incearca din nou conectarea.

Poti conecta manual share-ul folosind:

net use Z: \\192.168.1.100\Shared /user:USERNAME

Windows va solicita parola contului.

7. Verifica Credential Manager

Acceseaza:

Control Panel → Credential Manager → Windows Credentials

Cauta eventuale credentiale salvate pentru serverul respectiv, de exemplu:

SERVER
192.168.1.100

Daca exista credentiale vechi sau incorecte, sterge-le si incearca din nou conectarea.

8. Verifica suportul SMB

Windows 11 foloseste implicit SMB 2 si SMB 3.

Daca resursa accesata este foarte veche, de exemplu:

  • Windows XP;
  • un NAS vechi;
  • un server legacy;
  • un echipament industrial mai vechi,

este posibil ca acesta sa suporte numai SMB 1.0.

Poti verifica SMB1 din:

Control Panel → Programs → Turn Windows features on or off

si cauta:

SMB 1.0/CIFS File Sharing Support

SMB1 este un protocol vechi si vulnerabil si nu este recomandata activarea lui decat daca este absolut necesar. Solutia recomandata este actualizarea serverului sau NAS-ului astfel incat acesta sa suporte SMB2/SMB3.

9. Test final

Dupa efectuarea modificarilor, incearca:

Win + R

si introdu:

\\192.168.1.100

sau:

\\SERVER

Daca serverul devine accesibil, incearca apoi accesarea directa a share-ului:

\\SERVER\Shared
[mai mult...]