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...]

Modalități de a afla versiunea schemei Active Directory

Schema AD reprezintă definiția la nivel de forest/ierarhie elemente a tuturor claselor de obiecte și a atributelor care pot exista în Active Directory. Aceasta descrie elemente precum utilizatorii, grupurile, computerele și proprietățile acestora, și se modifică numai atunci când extindeți sau actualizați forest-ul la noi versiuni de Windows Server sau de produse. Cu alte cuvinte, este setul de reguli pe care îl respectă fiecare controler de domeniu din forest.

[mai mult...]

Utilizarea instrucțiunii „Return” în funcțiile și scripts PowerShell

Principala utilizare a instrucțiunii „return” în PowerShell este aceea de a returna rezultatul unei funcții și/sau de a ieși din domeniul de aplicare curent. Domeniul de aplicare poate fi o funcție, un script sau un bloc de script. După ce instrucțiunea „Return” este invocată, PowerShell iese din funcție și returnează controlul către codul apelant. În acest articol, vom analiza exemple de utilizare a instrucțiunii „Return” în scripturile PowerShell.

[mai mult...]

Cum se pot trunchia și reduce jurnalele de tranzacții din SQL Server

Jurnalele de tranzacții(Transaction logs) ale Microsoft SQL Server tind să crească în timp și pot, uneori, să ocupe tot spațiul liber de pe unitatea de stocare a serverului. Pentru a evita această situație, ar trebui efectuate copii de siguranță periodice ale jurnalelor de tranzacții sau să utilizați operațiunile de trunchiere și reducere a jurnalelor de tranzacții din SQL Server.

Diferența dintre operațiunile „truncate” și „shrink” ale fișierelor jurnal din SQL Server

Trebuie să fiți familiarizați cu modelele de recuperare din SQL Server înainte de a putea înțelege diferența dintre operațiunile „truncate” și „shrink”:

  • Modelul de recuperare simplu — SQL Server marchează fișierele jurnal virtuale inactive ca fiind reutilizabile după un punct de control și atunci când niciun factor (cum ar fi copiile de siguranță sau tranzacțiile active), nu blochează trunchierea. Acest mod de recuperare este destinat exclusiv mediilor de dezvoltare sau de testare și nu este recomandat pentru mediile de producție;
  • Modelul de recuperare complet — jurnalele de tranzacții nu vor fi șterse până când nu se finalizează o copie de rezervă a jurnalului de tranzacții (nu are loc o truncare automată a jurnalului). Jurnalul de tranzacții va fi trunchiat numai după efectuarea copiei de rezervă a acestuia. Acest mod reprezintă cea mai bună metodă de recuperare a datelor după o defecțiune și este utilizat atunci când este necesară o recuperare la un moment dat.
  • Jurnalizare în bloc — acest mod permite reducerea spațiului utilizat de jurnal prin utilizarea setărilor de jurnalizare minimă. SQL Server trunchiază jurnalul de tranzacții numai după efectuarea cu succes a unei copii de rezervă a acestuia.

Copierea de rezervă completă a bazei de date SQL Server nu trunchiază jurnalul de tranzacții. Configurarea copierii de rezervă periodice a jurnalului de tranzacții este singura modalitate valabilă de a trunchia fișierele jurnal. Operațiunea de trunchiere eliberează spațiul, dar nu reduce dimensiunea fișierului jurnalului de tranzacții de pe disc.

Reducerea dimensiunii ar trebui utilizată pentru a reduce dimensiunea jurnalului de tranzacții SQL Server de pe unitate. În timpul operațiunii de reducere, MSSQL mută paginile alocate din fișierul jurnal în spațiul liber și dezalocă VLF-urile neutilizate de la sfârșitul fișierului. Spațiul liber este apoi dezalocat și returnat sistemului de fișiere.

[mai mult...]

Activarea sau dezactivarea comenzii „sudo” în Windows 11

Ce este Sudo pentru Windows?

Sudo pentru Windows îți permite să execuți comenzi cu drepturi de administrator dintr-o consolă cu drepturi ridicate, adăugând prefixul „sudo” în fața comenzii. De exemplu, „sudo netstat -ab”; atunci când folosești „sudo”, Windows îți solicită în continuare să confirmi cererea de ridicare a drepturilor.

Sudo pentru Windows este funcția integrată de la Microsoft care permite executarea comenzilor cu drepturi ridicate direct dintr-o sesiune de consolă fără drepturi ridicate în Windows 11. Aceasta este concepută pentru fluxurile de lucru din linia de comandă în care doriți să adăugați prefixul „sudo” la o comandă, în loc să deschideți mai întâi o consolă de administrator separată. Sudo pentru Windows este disponibil în Windows 11 versiunea 24H2 și versiunile ulterioare. Pentru mai multe informații, consultați linkul:

https://learn.microsoft.com/en-us/windows/advanced-settings/sudo/   

Setarea Sudo se găsește în meniul Settings > System > Advanced. Pe dispozitivele cu Windows 11 versiunea 25H2 și versiunile ulterioare.

Cerințe preliminare

Înainte de a începe, asigurați-vă că pe computer rulează Windows 11 24H2 sau o versiune ulterioară, deoarece Sudo pentru Windows nu este disponibil pe versiunile anterioare de Windows 11. De asemenea, rețineți că, pe dispozitivele gestionate, opțiunea „Setări avansate” poate lipsi sau poate fi dezactivată dacă organizația dvs. aplică politici care o restricționează. Prin urmare, dacă nu vedeți opțiunea „Advanced settings/Setari avansate” în aplicația Setări pe un dispozitiv gestionat, cel mai probabil aceasta este dezactivată de o politică de grup sau de o politică Intune.

[mai mult...]

Funcționalități eliminate și învechite în Windows Server 2025

Windows Server 2025 introduce îmbunătățiri majore în materie de securitate, identitate și platformă, dar continuă totodată procesul de eliminare a componentelor, protocoalelor și instrumentelor de administrare mai vechi inițiat de Microsoft. Pentru administratori, acest lucru este important deoarece unele funcționalități sunt eliminate complet și nu mai sunt disponibile, în timp ce altele sunt doar învechite, ceea ce înseamnă că există încă în prezent, dar nu mai sunt dezvoltate activ și ar putea dispărea într-o versiune viitoare.

Funcții învechite vs. funcții eliminate

O funcție învechită este încă prezentă în Windows Server, beneficiază în continuare de suport pentru utilizarea în producție și primește în continuare actualizări de securitate și de calitate, conform ciclului de viață al produsului. Cu toate acestea, Microsoft nu o mai dezvoltă în mod activ, iar aceasta ar putea fi eliminată într-o versiune viitoare. Pe de altă parte, o funcție eliminată nu mai este disponibilă în imaginea produsului instalat, iar aplicațiile sau fluxurile de lucru care depindeau de aceasta trebuie să treacă la o alternativă.

[mai mult...]

2 moduri de a dezactiva funcția „Unlock Premium” în Microsoft Teams

Soluția constă în dezactivarea înscrierii în regim de autoservire pentru Microsoft Teams Premium prin Centrul de administrare M365 sau PowerShell și în asigurarea faptului că utilizatorii din organizația dumneavoastră nu se abonează și nu inițiază perioada de probă Premium pentru Teams.

Microsoft a introdus versiunile de încercare și achizițiile în regim de autoservire în produsele sale pentru a oferi utilizatorilor flexibilitatea de a le testa fără consimțământul unui administrator. Motivul este că acest lucru poate ajuta administratorii să înțeleagă și să gestioneze cererea. În mod implicit, toate produsele noi sunt configurate pentru a permite utilizatorilor să efectueze achiziții în regim de autoservire, ceea ce este puțin îngrijorător.

Multe organizații nu au fost încântate să vadă noua opțiune „Unlock Premium” în aplicația Microsoft Teams pentru utilizatorii lor. Acest lucru se datorează faptului că utilizatorii se pot înscrie pentru perioade de probă în regim self-service la Teams Premium pe conturile Microsoft 365 existente ale organizației lor, folosind datele de autentificare de serviciu. În plus, nu este necesară introducerea datelor de plată la înscrierea pentru o perioadă de probă(o licență de încercare a serviciului cu o durată de 60 de zile, iar la încheierea perioadei de încercare, utilizatorii sunt invitați să efectueze o achiziție).

[mai mult...]

Stocarea cheilor de recuperare BitLocker în Active Directory

Baza de date Active Directory poate fi utilizată ca locație centrală pentru stocarea cheilor de recuperare BitLocker. Puteți configura Politica de grup (GPO) pentru a salva automat cheile de recuperare pentru computerele cu BitLocker activat în AD. Administratorii pot apoi recupera în siguranță cheile de recuperare pentru computere din AD și pot debloca unitățile de stocare criptate ale dispozitivelor în cazul în care un utilizator uită parola BitLocker.

Peisajul administrării BitLocker

În prezent, Active Directory nu mai este sistemul principal/recomandat pentru gestionarea cheilor de recuperare BitLocker. Astăzi, pentru administrarea BitLocker, aveți la dispoziție soluții mai bune bazate pe cloud:

Microsoft Endpoint Manager (Intune). Acesta este înlocuitorul principal al MBAM.
Microsoft BitLocker Administration and Monitoring (MBAM) este învechit.
În mediile conectate la Entra ID și în cele hibride, cheile de recuperare BitLocker sunt de obicei depozitate la Entra ID prin intermediul politicilor Intune/de înscriere a dispozitivelor.

Stocarea cheilor BitLocker bazată pe AD este utilizată acum, de obicei, pentru:

  • Mediile locale vechi
  • Dispozitivele hibride alăturate la domeniu
    Rețelele izolate/fără conexiune la internet

Pentru organizațiile care planifică noi implementări, recomandăm să acorde prioritate gestionării BitLocker bazate pe Intune și depozitării cheilor de recuperare în Entra ID în locul stocării de recuperare bazate pe AD DS vechi, ori de câte ori este posibil.

Reguli de decizie

Ar trebui să utilizați copiile de rezervă BitLocker din AD DS în următoarele cazuri:

  • mediu exclusiv Active Directory local
  • nu există o identitate în cloud (Entra ID)
  • rețeaua dvs. este restricționată/izolată

Ar trebui să utilizați Intune/Entra ID în următoarele cazuri:

  • există o identitate în cloud sau hibridă
  • dispozitivele sunt alăturate la Entra ID sau într-un mod hibrid
  • Microsoft Endpoint Manager este disponibil

Nota Bene: Rețineți că Entra ID/Intune este planul de control implicit pentru recuperarea BitLocker în mediile Microsoft moderne. AD DS este o soluție de rezervă mai veche, pe care ar trebui să o utilizați numai în cazul în care identitatea în cloud nu este disponibilă.

În cazul în care utilizați Intune/Entra ID, ar trebui să omiteți toate secțiunile referitoare la schema AD și GPO. În cazul în care utilizați AD DS, omiteți secțiunile referitoare la Intune/Entra.

Cerințe de mediu și validarea schemei Active Directory

Nota Bene: Înainte de a configura backup-ul BitLocker în AD, vă recomandăm să verificați dacă schema AD a fost extinsă corespunzător și dacă atributele legate de BitLocker sunt prezente la nivel de schemă.

Rețineți că metoda de stocare a cheii de recuperare BitLocker depinde de arhitectura mediului. Ar trebui să alegeți una dintre următoarele:

  • AD DS local (vechi/hibrid)
  • Microsoft Entra ID (nativ în cloud)
  • Politici BitLocker gestionate de Intune (aceasta este abordarea modernă recomandată)

Cerințe de sistem

  • Computere cu Windows 10 sau 11 care rulează edițiile Pro, Education sau Enterprise;
  • Schema Active Directory trebuie să conțină un set de atribute personalizate ale obiectelor de tip computer pentru stocarea cheilor de recuperare BitLocker (disponibile în AD începând cu Windows Server 2012).

Pentru a verifica versiunea schemei AD:

(Get-ADObject `
(Get-ADRootDSE).schemaNamingContext `
-Properties objectVersion).objectVersion

Această operațiune verifică versiunea schemei AD pentru a se asigura că extensiile schemei sunt aplicate la nivel de pădure. Rețineți că versiunea schemei are doar caracter informativ (trebuie să verificați compatibilitatea cu BitLocker folosind verificarea prezenței ldapDisplayName).

Pentru a verifica prezența extensiei de schemă BitLocker, executați următoarea comandă:

$schemaNC = (Get-ADRootDSE).schemaNamingContext
Get-ADObject $schemaNC -Property objectVersion, name
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
-Filter “ldapDisplayName -like ‘msFVE*'” `
-Properties ldapDisplayName |
Select-Object ldapDisplayName

Validarea compatibilității BitLocker cu Active Directory ar trebui să includă:

  • Verificarea versiunii schemelor
  • Confirmarea prezenței atributelor legate de BitLocker (msFVE*)
  • În cele din urmă, verificarea stării de funcționare cu ajutorul comenzii:

Get-ADReplicationFailure -Target * -Scope Forest
Get-ADReplicationPartnerMetadata -Target * | Select LastReplicationSuccess

Chiar și în cazul în care atributele de schemă sunt prezente, copierea de rezervă BitLocker poate eșua din următoarele motive:

  • lipsa aplicării GPO
  • lipsa permisiunilor de scriere pe computer
  • direcționarea incorectă către unitatea organizațională (OU)
  • dispozitivul hibrid nu este conectat corespunzător la AD DS

Pentru o implementare reușită a BitLocker, trebuie să îndepliniți toate condițiile următoare:

  • Există o parolă de recuperare
  • Starea protecției BitLocker este activată
  • Obiectul msFVE-RecoveryInformation există în AD
  • Parola de recuperare poate fi recuperată din ADUC/PowerShell

Atribute obligatorii ale schemei Active Directory

Trebuie să existe următoarele cinci atribute:

  • ms-FVE-KeyPackage
  • ms-FVE-RecoveryGuid
  • ms-FVE-RecoveryInformation
  • ms-FVE-RecoveryPassword
  • ms-FVE-VolumeGuid
[mai mult...]

Cum se setează mesajul Out Of Office Message in Outlook pentru un alt utilizator

Cerințe:

  • Drepturi de administrator pentru Exchange Online. Se vor ilustra pașii necesari folosind o organizație Exchange Online dintr-un tenant Microsoft 365. Aceleași comenzi se aplică și organizațiilor cu servere Exchange locale.
  • Acces la Consola de administrare Exchange pentru căsuțele poștale Exchange locale.
  • Asigurați-vă că aveți instalat modulul Exchange Online PowerShell V3 pe computerul dumneavoastră dacă lucrați cu căsuțe Exchange Online.

Metode de configurare a mesajului Out of Office pentru un alt utilizator

Puteți configura mesajul Out of Office al unui alt utilizator folosind clientul Outlook. Această metodă este cea mai potrivită dacă doriți să creați mesajul de absență folosind un editor vizual din cadrul clientului Outlook. Rețineți că metodele bazate pe Outlook necesită acces complet la căsuța ; dacă utilizați metoda PowerShell, nu veți avea nevoie de un astfel de acces, motiv pentru care aceasta este cea mai bună opțiune.

Acordarea permisiunii de acces complet la căsuță

Însă, mai întâi, trebuie să dețineți permisiunea de acces complet la cutia poștală înainte de a putea modifica configurarea mesajului de absență. Iată cum se procedează.

1. Deschideți Consola de administrare Exchange (On-Prem) sau conectați-vă la sesiunea PowerShell Exchange Online.

2. În PowerShell, executați această comandă pentru a vă acorda permisiunea de acces complet la căsuță:

Add-MailboxPermission `
-AccessRights FullAccess `
-Identity ‘MAILBOX’ `
-User ‘USER’ `
-AutoMapping:$false

Comanda acordă permisiunea „FullAccess” pentru căsuța specificată și nu o va adăuga automat la profilul dvs. Outlook.

Notă importantă. În cazul în care acordați permisiunea „FullAccess”, aceasta va face vizibil conținutul căsuței poștale; vă recomandăm să evitați acest lucru pe cât posibil. Vă recomandăm să utilizați metoda PowerShell, deoarece oferă un nivel mai ridicat de securitate.

Eliminarea permisiunii de acces complet

Permisiunea de acces complet la cutia poștală trebuie eliminată după ce v-ați îndeplinit sarcina. Menținerea permisiunii de acces complet pentru administrator pe termen nelimitat reprezintă o practică necorespunzătoare. Pentru a elimina permisiunea, executați această comandă în PowerShell.

Remove-MailboxPermission `
-AccessRights FullAccess `
-Identity «MAILBOX» `
-User «USER»

Notă. Nu uitați să înlocuiți MAILBOX și USER cu identificatorii reali ai căsuței poștale și ai utilizatorului atunci când executați comanda.

Configurarea mesajului de Out of Office folosind PowerShell

Fără a accesa căsuța din Outlook, puteți configura mesajul Out of Office al utilizatorului prin intermediul PowerShell. Această metodă presupune ca contul dvs. de administrator să dețină cel puțin permisiunile RBAC de gestionare a destinatarilor. Nu este necesar să aveți acces complet la căsuța.

În sesiunea dvs. de PowerShell Exchange, executați această comandă.

Set-MailboxAutoReplyConfiguration -Identity “MAILBOX” `
-AutoReplyState Scheduled `
-StartTime “04/19/2026 05:00:00” `
-EndTime “04/25/2026 05:00:00” `
-InternalMessage “<html><body><p>Sunt in vacanta pana pe 25 Aprilie.</p></body></html>” `
-ExternalMessage “<html><body><p>Sunt in vacanta pana pe 25 Aprilie.</p></body></html>” `
-ExternalAudience Known

Iată ce face fiecare parte a codului:

Set-MailboxAutoReplyConfiguration: Acest cmdlet configurează răspunsul automat pentru o căsuță.
Identity „MAILBOX”: Aceasta specifică numele căsuței pentru care se configurează răspunsul automat.
AutoReplyState Scheduled: Aceasta specifică faptul că răspunsul automat va fi trimis într-un interval de timp programat.
StartTime „04/19/2026 05:00:00”: Aceasta specifică ora de începere a perioadei de răspuns automat.
EndTime „04/25/2026 05:00:00”: Aceasta specifică ora de încheiere a perioadei de răspuns automat.
InternalMessage „<html><body><p>Bună ziua,</p><p>Sunt în vacanță. Vă rog să nu mă deranjați.</p><br/><p>NumeleMeu</p></body></html>”: Aceasta specifică mesajul formatat în HTML care va fi trimis utilizatorilor interni. Mesajul include o formulă de salut, un mesaj și o semnătură.
ExternalMessage „<html><body><p>Bună ziua,</p><p>Sunt în vacanță. Vă rog să nu mă deranjați.</p><br/><p>NumeleMeu</p></body></html>”: Aceasta specifică mesajul formatat HTML care va fi trimis contactelor externe. Mesajul include o formulă de salut, un mesaj și o semnătură.
ExternalAudience Known: Aceasta specifică faptul că răspunsul automat va fi trimis numai tuturor contactelor externe cunoscute (adresele din lista de contacte a utilizatorului căsuței). Alte opțiuni valide sunt:

  • None — dezactivează răspunsurile automate externe.
  • All — activează răspunsurile automate externe către toate adresele.

Dacă comanda se execută cu succes, nu va apărea niciun mesaj pe ecran.

În cele din urmă, să verificăm dacă mesajul de absență este configurat, executând această comandă.

Get-MailboxAutoReplyConfiguration -Identity “NumeleMeu” | `
Format-List AutoReplyState, StartTime, Endtime, `
ExternalAudience, InternalMessage, ExternalMessage

Adăugarea unui mesaj Out of Office la căsuța a altui utilizator se poate realiza în câteva moduri. În calitate de administrator, puteți obține permisiuni complete pentru căsuța respectivă și o puteți deschide în Outlook pentru desktop sau în Outlook pe web. De acolo, puteți edita configurația răspunsurilor automate folosind un editor grafic.

Dacă adăugarea permisiunilor complete pentru căsuța nu este posibilă (sau permisă), puteți realiza aceeași sarcină folosind Set-MailboxAutoReplyConfiguration în PowerShell. Această metodă este mai rapidă și necesită mai puțini pași pentru a fi finalizată. De asemenea, nu expune inutil conținutul căsuței poștale oricui ar accesa-o.

[mai mult...]