Remedierea problemelor legate de driverul ODBC 18.6.1.1 cu ajutorul Configuration Manager

Driverul ODBC pentru SQL Server, versiunea 18.6.1.1, prezintă probleme cunoscute care pot duce la eșuarea instalărilor site-urilor Configuration Manager și la întreruperea funcționării funcționalităților de notificare către clienți. Soluția constă fie în actualizarea la versiunea mai nouă a driverului ODBC, 18.6.2.1, fie în revenirea la o versiune mai veche, 18.4.1.1.

Versiunea 2309 și versiunile ulterioare ale Configuration Manager necesită instalarea driverului ODBC Microsoft 18 sau o versiune ulterioară pentru SQL Server ca cerință prealabilă.

Versiunea 18.6.1.1 a driverului ODBC include o modificare care impune o gestionare mai strictă a valorilor NULL pentru coloanele care nu acceptă valori NULL. Această modificare poate provoca eșecuri în operațiunile Configuration Manager care încearcă să insereze valori NULL în astfel de coloane. Astfel de eșecuri generează erori în timpul instalării site-ului și al raportării utilizatorului conectat în prezent.

[mai mult...]

Permiteți sau blocați datele mobile folosind Intune

Prin crearea unui profil de catalog de setări, puteți alege să permiteți sau să restricționați accesul la datele mobile pentru dispozitivele Windows gestionate cu Microsoft Intune.

Gestionarea conectivității mobile reprezintă o parte importantă a administrării dispozitivelor finale, în special pentru organizațiile care doresc un control mai strict asupra dispozitivelor corporative, a utilizării serviciilor de roaming și a costurilor cu datele. Cu Microsoft Intune, administratorii pot configura politici care permit sau blochează accesul la datele mobile pe dispozitivele compatibile, în funcție de platformă, tipul de înscriere și modul de gestionare.

În unele cazuri, organizațiile doresc să permită utilizarea datelor mobile pentru angajații care lucrează pe teren și pentru cei care lucrează de la distanță. În alte cazuri, acestea trebuie să blocheze complet datele mobile, astfel încât dispozitivele să funcționeze numai prin Wi-Fi sau prin căi de rețea aprobate. Intune oferă, de asemenea, o setare dedicată pentru gestionarea roamingului de date mobile.

De ce ar trebui să controlați traficul de date mobile cu Intune?

Există mai multe motive pentru care o organizație ar putea dori să gestioneze accesul la rețeaua mobilă pe dispozitivele înregistrate:

  • Reducerea costurilor cu operatorul de telefonie mobilă
  • Prevenirea consumului inutil de date atunci când utilizatorii se află în afara organizației
  • Obligarea dispozitivelor să utilizeze rețele Wi-Fi de încredere
  • Limitarea cheltuielilor de roaming pentru utilizatorii aflați în deplasare
  • Securizarea store-urilor sau a dispozitivelor dedicate care nu ar trebui să utilizeze rețelele mobile
  • Controlați modul în care dispozitivele deținute de companie se conectează în afara biroului.
[mai mult...]

Cum se colectează date din registrul Windows folosind Intune

Această funcționalitate a fost anunțată pentru prima dată odată cu lansarea din iulie (2607) a Microsoft Intune, permițând administratorilor să colecteze date din registru fără a mai fi nevoie de scripturi PowerShell personalizate, colectarea datelor realizându-se prin intermediul Microsoft Device Inventory Agent.

Cu ajutorul acestei noi funcționalități, administratorii IT pot colecta în mod nativ date selectate din registrul HKEY_LOCAL_MACHINE și le pot vizualiza pentru fiecare dispozitiv în inventarul dispozitivelor. Astfel, puteți verifica dacă valorile așteptate din registru există după implementarea politicii. Este o funcționalitate foarte utilă și cred că va fi una dintre cele mai populare funcții din Microsoft Intune. Colectarea datelor din registru de către Intune în inventarul dispozitivelor este inclusă în Microsoft Intune Plan 1.

Nota Bene: La lansarea inițială, datele din registru apar în inventarul dispozitivelor pentru fiecare dispozitiv în parte. Aceasta înseamnă că va trebui să vizualizați datele inventariate accesând fiecare dispozitiv în parte. Microsoft a indicat, de asemenea, că se așteaptă ca experiențele de raportare și explorare mai ample să se extindă în timp.

[mai mult...]

Personalizarea numelui folderului root de sincronizare OneDrive folosind Intune

În mod implicit, numele folderului vizibil pentru utilizator este „OneDrive – {numele organizației}”. Scurtarea acestui nume mărește lungimea disponibilă a căii pentru folderele și fișierele imbricate și asigură coerența mărcii pe toate dispozitivele gestionate.
Când utilizatorii sincronizează OneDrive pe Windows, numele implicit al folderului apare de obicei ca „OneDrive – {numele organizației}”. Acest lucru funcționează bine în multe medii, dar uneori organizațiile doresc un format de denumire mai clar și mai ușor de recunoscut, din motive de branding, consecvență sau simplitate a asistenței. Aici intervine Intune, ajutându-vă să configurați un nume unic al organizației afișat de OneDrive utilizatorilor.

Rețineți că, atunci când aplicați această configurație prin Intune, aceasta modifică, practic, numele afișat pentru folderul rădăcină OneDrive sincronizat în File Explorer. Aceasta nu afectează folderele OneDrive ale conturilor personale Microsoft.

Nota Bene: Nu este necesar să importați fișierele șablon ADMX pentru OneDrive, deoarece cele mai recente setări pentru OneDrive sunt deja incluse în catalogul de setări. Importul este necesar doar dacă nu puteți găsi o politică specifică pe care o căutați.

De ce să setați un nume personalizat pentru folderul OneDrive?

Din câte cunoastem, pentru majoritatea utilizatorilor, numele folderelor reprezintă un detaliu minor și nimeni nu le acordă atenție în timpul activității. Pentru echipele IT, acestea fac adesea diferența între „totul pare standardizat” și „de ce fiecare captură de ecran de la departamentul de asistență arată diferit?”. O mică ajustare, dar una care conferă implementărilor la nivel de întreprindere un aspect mai bine gândit.

Dacă conduceți o organizație, iată câteva motive pentru care ar trebui să le sugerați utilizatorilor OneDrive să ia în considerare schimbarea numelui vechi al directorului rădăcină de sincronizare.

  • Menținerea consecvenței mărcii pe toate dispozitivele gestionate.
  • O experiență de utilizare mai simplă, cu un nume de folder mai prietenos.
  • Documentație de asistență și capturi de ecran mai ușor de realizat.
  • O distincție clară atunci când utilizatorii lucrează cu mai mulți chiriași sau biblioteci sincronizate.

Ce politică Intune controlează acest aspect?

Microsoft Intune oferă o setare administrativă cunoscută sub numele de „Setare nume personalizat pentru folderul OneDrive”, care vă permite să definiți numele de afișare al organizației care apare în folderul OneDrive local. De obicei, aceasta se configurează prin politica Catalog de setări.

Conform descrierii politicii, dacă activați această setare și furnizați un nume personalizat pentru folder, OneDrive va utiliza acel nume la crearea folderului rădăcină de sincronizare pentru utilizatorii noi. Dacă nu configurați această setare, se va utiliza numele implicit al folderului. Când dezactivați această setare, numele folderului va reveni la „OneDrive – {numele organizației}“.

Utilizatorii existenți care au un nume de folder personalizat trebuie să-și deconecteze și să-și reconecteze contul pentru ca modificările să intre în vigoare, aceasta fiind o cerință a aplicației OneDrive, nu a politicii.

Cerințe preliminare

  1. Înregistrare: Asigurați-vă că dispozitivele Windows sunt înregistrate în Intune. Consultați ghidul de înregistrare Windows 11 în Intune. Utilizatorii trebuie să se autentifice cu un cont de serviciu sau școlar.
  2. Permisiuni: Cont de utilizator care face parte din rolul încorporat „Global Admin” sau „Policy and Profile Manager” din Microsoft Intune.
  3. ID-ul tenantului: Politica pe care o vom configura necesită introducerea ID-ului tenantului. Prin urmare, aceasta este o cerință prealabilă importantă, iar în secțiunea următoare voi arăta unde se poate vedea ID-ul tenantului.
  4. Aplicația OneDrive: Aplicația OneDrive trebuie să fie instalată pe dispozitivele finale pe care intenționați să implementați politica. De asemenea, asigurați-vă că aplicația OneDrive este actualizată la cea mai recentă versiune.

Reguli și restricții privind denumirea

Înainte de a configura politica în cadrul organizației dvs., asigurați-vă că cunoașteți regulile de denumire pentru folderul rădăcină OneDrive și limitările aferente.

  • Trebuie să introduceți cel puțin un caracter pentru numele folderului personalizat.
  • Alegeți un nume care să corespundă identității companiei dvs. și, pe cât posibil, alegeți unul scurt.
  • Calea completă a folderului rădăcină de sincronizare OneDrive (de exemplu, C:\Users{alias}\OneDrive – {numele organizației}) nu poate depăși 120 de caractere.
  • Numele folderelor personalizate nu pot conține caractere nevalide pentru folderele Windows.
  • Cel mai important, numele folderului personalizat nu poate fi „OneDrive”. Va apărea un conflict, iar politica ar putea să nu se aplice în cele din urmă.
  • De asemenea, nu sunt permise spațiile la începutul și la sfârșitul numelor de fișiere sau de foldere.

Găsiți ID-ul de tenant Microsoft Entra

Există mai multe modalități de a găsi ID-ul de tenant Microsoft Entra, iar cea mai simplă este să îl obțineți din Centrul de administrare Entra ID.

  • Conectați-vă la Centrul de administrare Microsoft Entra.
  • Accesați Entra ID > Overview.
  • În secțiunea Basic Information, puteți găsi ID-ul de tenant.
  • Copiați ID-ul de tenant în Notepad sau în orice editor de text; se va folosi în timpul configurării politicii.
[mai mult...]

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

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 se importă date din Excel(XLSX) într-un script PowerShell

Există două metode populare de accesare a datelor dintr-un fișier Excel din PowerShell:

  • Folosind obiecte COM (necesită instalarea Microsoft Excel pe computer)
  • Folosind modulul terț Import-Excel (poate fi utilizat fără a instala aplicația Excel)

Conditii preliminare

Microsoft Excel instalat
Windows PowerShell sau PowerShell 7(Windows)

Modulul PowerShell ImportExcel

  • Install-Module -Name ImportExcel -Scope CurrentUser -Force
  • Import-Module ImportExcel
  • Get-Module ImportExcel
[mai mult...]

Cum se pot lista sau modifica rolurile utilizatorilor în SQL Server

Rolurile din Microsoft SQL Server reprezintă un element central al securității serverului de baze de date. Rolurile sunt utilizate pentru a controla accesul la obiecte și pentru a atribui permisiuni utilizatorilor și/sau grupurilor de securitate. Rolurile din SQL Server sunt similare cu grupurile de utilizatori din Windows.

Roluri predefinite în SQL Server

SQL Server include mai multe roluri predefinite (fixe) la nivel de server și de bază de date. SQL Server 2022 introduce, de asemenea, roluri fixe suplimentare la nivel de server, care oferă permisiuni mai detaliate, bazate pe Principiul privilegiului minim:

Roluri fixe la nivel de server – roluri încorporate utilizate pentru a atribui permisiuni în SQL Server. De exemplu, aceste roluri permit utilizatorilor să modifice configurația serverului, să creeze baze de date și să efectueze alte sarcini administrative.
Roluri fixe la nivel de bază de date – permit gestionarea permisiunilor asupra bazelor de date. Aceste roluri sunt utilizate în mod obișnuit atunci când se acordă permisiuni pentru crearea de tabele sau interogarea datelor.

Permisiunile atribuite rolurilor fixe din SQL Server nu pot fi modificate. Administratorul poate crea, de asemenea, roluri de server sau de bază de date definite de utilizator, cu un set personalizat de permisiuni.

[mai mult...]

Fereastra de recuperare este acum configurabilă în Microsoft Backup 365

Perioada de recuperare era una dintre cele mai mari limitări ale Microsoft 365 Backup. O durată fixă de un an, fără excepții. Acum, însă, lucrurile se schimbă. Microsoft lansează o fereastră de recuperare configurabilă pentru Microsoft 365 Backup, care vă permite să o setați între 3 luni și 2 ani, în funcție de politica aplicabilă. Pe hârtie, este o schimbare minoră, dar rezolvă o problemă reală pentru oricine dorește să controleze costurile de stocare și perioada de păstrare.

În prezent, fiecare politică de backup Microsoft 365 utilizează aceeași perioadă de recuperare de 1 an, indiferent dacă faceți backup pentru un site de proiect activ sau pentru o căsuță supusă cerințelor de conformitate. Odată cu această actualizare, puteți seta perioada de recuperare pentru fiecare politică în parte: mai scurtă pentru datele pe care nu este necesar să le păstrați atât de mult timp și mai lungă pentru cele care implică cerințe de conformitate extinse.

Nota Bene: Valoarea implicită rămâne la 1 an. Nu se modifică nimic automat; trebuie să accesați setările și să le modificați manual, pentru fiecare politică în parte.

Această funcționalitate se lansează la nivel mondial începând cu sfârșitul lunii iulie 2026, disponibilitatea generală fiind preconizată pentru începutul lunii august 2026. Este asociată cu Roadmap-ul Microsoft 365 cu ID-ul 481834, așa că o puteți urmări acolo dacă doriți să aflați calendarul exact pentru tenantul dumneavoastră.

Odată ce funcția este activă, setarea unei noi perioade de recuperare este simplă:

  1. Accesați Centrul de administrare Microsoft 365
  2. Accesați secțiunea „Microsoft 365 Backup”
  3. Selectați politica de backup pe care doriți să o modificați
  4. Deschideți opțiunea „Update recovery window”
  5. Setați perioada dorită (între 3 luni și 2 ani)
  6. Verificați și confirmați.

Nota bene: Dacă reduceți intervalul de recuperare al unei politici existente, datele de rezervă care nu se încadrează în noul interval vor fi șterse definitiv după o perioadă de grație. Este o măsură ireversibilă, așa că consultați-vă cu persoana responsabilă de conformitate din organizația dumneavoastră înainte de a reduce acest interval.

Aceasta este o soluție binevenită pentru o limitare care exista încă de la lansarea serviciului Microsoft 365 Backup. Dacă organizația dvs a fost nevoită să plătească pentru o perioadă de păstrare de 12 luni de care nu avea nevoie sau și-a dorit să poată păstra anumite date mai mult timp, această actualizare vă oferă în sfârșit acest control.

Odată ce această funcționalitate va fi implementată, merită să treceți rapid în revistă politicile existente pentru a verifica dacă perioada implicită de 1 an mai este adecvată sau dacă unele dintre ele ar trebui să fie mai scurte sau mai lungi. Nu modificați însă nimic până când nu sunteți siguri de ceea ce aveți voie să ștergeți.

[mai mult...]