Stații de lucru

OS - Windows 9166 Solutii

Reguli si plangeri 11 Solutii

OS - OS X 410 Solutii

Reguli de configurare 12 Solutii

Licentiere 18 Solutii

Securitate 182 Solutii

Copie de rezerva (Backup) 68 Solutii

Antivirus 72 Solutii

Aplicatii specifice 5297 Solutii

Hardware 291 Solutii

Migrarea utilizatorilor si datelor Office 365 de pe un tenant M365 pe altul, fara pierderea datelor

Prima confuzie de eliminat: licentele Microsoft 365 nu se pot muta dintr-un tenant in altul. O licenta este legata de tenantul (organizatia) unde a fost achizitionata. Ce se migreaza efectiv sunt datele utilizatorilor — cutii postale (mail, calendar, contacte), OneDrive, SharePoint si, in anumite conditii, Teams. Pe tenantul nou se cumpara licente noi si se re-atribuie utilizatorilor. Asadar, obiectivul real este: mutarea datelor fara pierderi, cu re-licentiere pe tenantul destinatie.

Metode de migrare disponibile

  • Cross-Tenant Migration nativ (Microsoft): foloseste licenta add-on si instrumentele Microsoft (Exchange Online PowerShell + MRS pentru mail, functia nativa pentru OneDrive). Datele nu parasesc niciodata cloud-ul Microsoft. Recomandat pentru fuziuni/achizitii.
  • Microsoft FastTrack: gratuit pentru clientii eligibili, ofera indrumare si, in anumite cazuri, servicii de migrare pentru mail si fisiere.
  • Instrumente terte (BitTitan MigrationWiz, Quest On Demand, AvePoint Fly): cele mai potrivite pentru migrari complexe sau volume mari; pastreaza structura, permisiunile si minimizeaza downtime-ul.
  • Manual (export/import PST + SharePoint Migration Tool): doar pentru medii mici; consuma mult timp si risca pierderea metadatelor si a link-urilor de partajare.

Pasul 1 — Evaluare si inventar (pre-migrare)

  • Inventariati toate cutiile postale, site-urile SharePoint, conturile OneDrive, echipele Teams si resursele partajate.
  • Stergeti conturile inactive, licentele expirate si datele vechi, pentru a reduce volumul de migrat.
  • Verificati existenta hold-urilor legale sau a politicilor de retentie — un OneDrive sub hold NU poate fi migrat pana cand hold-ul nu este eliminat.
  • Confirmati ca Customer Key (Purview) NU este activat pe tenantul sursa pentru OneDrive, altfel migrarea nativa nu functioneaza.

Pasul 2 — Pregatirea celor doua tenanturi

  1. Cumparati si pregatiti licentele Cross-Tenant User Data Migration (verificati ca le puteti achizitiona inainte de orice altceva).
  2. Pre-creati conturile de utilizator in tenantul destinatie si atribuiti-le licentele M365 noi.
  3. Stabiliti relatia de incredere intre tenanturi (organization relationships / cross-tenant trust in Entra ID).
  4. Adaugati un domeniu temporar de rutare (ex. onmicrosoft.com) pentru sincronizarea initiala a mail-ului.
  5. Asigurati-va ca sursele OneDrive sunt read/write (nu read-only).

Pasul 3 — Migrarea propriu-zisa

Cutii postale (Exchange Online): migrarea foloseste MRS (Mailbox Replication Service) si se declanseaza prin Exchange Online PowerShell cu New-MigrationBatch. Se pastreaza structura de foldere, calendarul, contactele si regulile.

OneDrive & SharePoint: se foloseste migrarea nativa cross-tenant sau un instrument tert. In timpul migrarii OneDrive, contul ramane read-only doar cateva minute, iar datele nu ies din cloud-ul Microsoft.

Strategia de taiere (cutover): pentru organizatii mici, un singur eveniment de comutare cu downtime scurt; pentru organizatii mari, migrare in batch-uri esalonate pe parcursul mai multor zile/saptamani.

Pasul 4 — Cutover DNS si finalizare

  1. Transferati dreptul de proprietate asupra domeniului personalizat catre tenantul destinatie.
  2. Actualizati inregistrarile DNS la momentul cutover: MX, SPF, DKIM, DMARC si autodiscover.
  3. Re-creati cutiile postale partajate (shared mailboxes) si grupurile pe tenantul destinatie.
  4. Reconfigurati profilurile Outlook ale utilizatorilor pe noul tenant.

Pasul 5 — Verificare post-migrare

  • Validati dimensiunea cutiilor si numarul de elemente migrate fata de sursa.
  • Verificati integritatea folderelor, a calendarului si a permisiunilor de partajare OneDrive.
  • Testati trimiterea/primirea de mail cu noul domeniu si fluxul de autentificare.
  • Confirmati accesul utilizatorilor la fisierele din noul OneDrive/SharePoint.

Limitari de care sa tineti cont

  • Teams: istoricul chat-urilor private si anumite metadate au suport limitat in migrarea nativa — verificati scenariul cu un instrument tert daca Teams este critic.
  • Timp: planificati ferestre de migrare realiste — volumul de date si throttling-ul Microsoft influenteaza durata.
  • Escaladare: pentru probleme in timpul migrarii native, contactati echipa de cont Microsoft — nu exista un canal dedicat de suport pentru add-on-ul de migrare.
[mai mult...]

Crearea unui punct de restaurare automat zilnic in Windows 11

System Restore este o plasa de siguranta excelenta cand o actualizare, un driver sau o aplicatie strica sistemul. Problema: Windows creeaza puncte de restaurare rar si imprevizibil, iar in mod implicit limiteaza crearea unui punct nou la maximum unul la 24 de ore. Solutia de mai jos creeaza automat, in fiecare zi, cate un punct de restaurare, folosind un script PowerShell rulat de Task Scheduler.

Pasul 1 — Activarea System Restore

System Restore poate fi dezactivat implicit. Activati-l pe partitia de sistem dintr-o consola PowerShell ca administrator:

Enable-ComputerRestore -Drive “C:\”

Optional, alocati spatiu pe disc pentru punctele de restaurare (ex. 5%):

vssadmin resize shadowstorage /for=C: /on=C: /maxsize=5%

Pasul 2 — Eliminarea limitei de 24 de ore (optional)

In mod implicit, Windows refuza sa creeze un punct nou daca exista deja unul mai recent de 24 de ore. Daca vreti ca sarcina zilnica sa functioneze garantat, ajustati aceasta frecventa din registru:

New-ItemProperty `

-Path “HKLM:\Software\Microsoft\Windows NT\CurrentVersion\SystemRestore” `

-Name “SystemRestorePointCreationFrequency” `

-Value 0 -PropertyType DWord -Force

Valoarea 0 permite crearea unui punct oricand, fara limita de un punct pe zi.

Pasul 3 — Scriptul PowerShell

Creati folderul C:\Scripts si salvati in el un fisier numit DailyRestorePoint.ps1 cu urmatorul continut:

$data = Get-Date -Format ‘yyyy-MM-dd HH:mm’

Checkpoint-Computer `

-Description “Punct automat zilnic – $data” `

-RestorePointType ‘MODIFY_SETTINGS’

Tipul MODIFY_SETTINGS este cel recomandat pentru puncte create manual/programat. Descrierea include data si ora, ca sa identificati usor punctul in lista.

Pasul 4 — Crearea sarcinii programate

Puteti crea sarcina direct din PowerShell (rulat ca administrator), fara interfata grafica. Exemplul ruleaza scriptul in fiecare zi la ora 12:00, cu privilegii ridicate:

$action = New-ScheduledTaskAction `

-Execute ‘powershell.exe’ `

-Argument ‘-NoProfile -ExecutionPolicy Bypass -File “C:\Scripts\DailyRestorePoint.ps1″‘

 

$trigger = New-ScheduledTaskTrigger -Daily -At 12:00PM

 

$principal = New-ScheduledTaskPrincipal `

-UserId “SYSTEM” -LogonType ServiceAccount -RunLevel Highest

 

$settings = New-ScheduledTaskSettingsSet `

-StartWhenAvailable -AllowStartIfOnBatteries `

-DontStopIfGoingOnBatteries

 

Register-ScheduledTask `

-TaskName “Punct de restaurare zilnic” `

-Action $action -Trigger $trigger `

-Principal $principal -Settings $settings

Explicatie pe scurt:

  • -StartWhenAvailable: daca PC-ul era oprit la ora programata, sarcina ruleaza la urmatoarea pornire.
  • RunLevel Highest + SYSTEM: Checkpoint-Computer necesita privilegii de administrator.
  • -AllowStartIfOnBatteries: ruleaza si pe laptop, chiar daca nu e in priza.

Pasul 5 — Testarea

Rulati sarcina manual, fara a astepta ora programata:

Start-ScheduledTask -TaskName “Punct de restaurare zilnic”

Verificati apoi ca punctul a fost creat:

Get-ComputerRestorePoint | Select-Object -Last 5

Ar trebui sa vedeti in lista punctul cu descrierea „Punct automat zilnic” si data curenta.

[mai mult...]

Configurarea Windows LAPS pentru rotirea automată a parolelor de administrator local

In multe retele, contul de administrator local are aceeasi parola pe toate statiile si serverele, sau o parola care nu se schimba niciodata. Daca un atacator afla acea parola de pe o singura masina, o poate folosi pentru a se deplasa lateral pe toate celelalte (lateral movement). Windows LAPS (Local Administrator Password Solution) rezolva asta: genereaza automat cate o parola unica si complexa pentru fiecare masina, o stocheaza criptat in Active Directory si o roteste periodic.

Spre deosebire de vechiul Microsoft LAPS (care necesita un client instalat separat), Windows LAPS este integrat nativ in sistemul de operare incepand cu actualizarile din 11 aprilie 2023 si mai noi.

Cerinte preliminare

  • Sisteme suportate: Windows Server 2019/2022/2025, Windows 10 22H2/21H2 si Windows 11, toate cu actualizarile din aprilie 2023 sau mai recente.
  • Domain Controllere la zi: rulati Windows Update pe TOATE controllerele de domeniu inainte de a extinde schema. Daca actualizati doar un DC, extinderea schemei va da eroare.
  • Nivel functional: Windows Server 2016 Domain/Forest Functional Level sau mai nou, necesar pentru criptarea parolelor in AD.
  • Permisiuni: cont membru al grupurilor Schema Admins si Enterprise Admins pentru extinderea schemei.

Pasul 1 — Extinderea schemei Active Directory

Pe un Domain Controller, deschideti PowerShell ca administrator si verificati mai intai ca modulul LAPS este disponibil:

Get-Command -Module LAPS

Daca nu apare niciun rezultat, sistemul nu este actualizat la o versiune suportata. Apoi extindeti schema:

Update-LapsADSchema -Verbose

Comanda va cere confirmarea. Apasati A (Yes to All) pentru a adauga toate atributele necesare. Parametrul -Verbose afiseaza detalii despre operatiune.

Pasul 2 — Acordarea permisiunilor pe unitatea organizatorica (OU)

Acordati computerelor dreptul de a-si scrie singure parola in AD. Rulati comanda pe OU-ul care contine statiile/serverele gestionate:

Set-LapsADComputerSelfPermission `

-Identity “OU=Workstations,DC=firma,DC=local”

Optional, restrictionati cine poate citi parola (doar administratorii IT, nu utilizatorii obisnuiti):

Set-LapsADReadPasswordPermission `

-Identity “OU=Workstations,DC=firma,DC=local” `

-AllowedPrincipals “IT_Admins”

Pasul 3 — Configurarea politicii prin Group Policy

Deschideti Group Policy Management, creati un GPO nou legat de OU-ul dorit si navigati la:

Computer Configuration > Policies > Administrative Templates > System > LAPS

Setari recomandate:

  • Configure password backup directory: Enabled → setati pe Active Directory.
  • Enable password encryption: Enabled (necesita nivel functional 2016+).
  • Name of administrator account to manage: Enabled → introduceti numele contului local de administrator gestionat (ex. lapsadmin).
  • Password Settings: configurati lungimea (ex. 20 de caractere), complexitatea si varsta maxima a parolei (ex. 30 de zile).
  • Do not allow password expiration time longer than required by policy:

Pasul 4 — Aplicarea si verificarea

Pe statiile client, fortati actualizarea politicii si repornirea gestionarii:

gpupdate /force

Pentru a verifica din PowerShell parola stocata a unei masini (rulat cu un cont care are drept de citire):

Get-LapsADPassword -Identity “STATIE01” -AsPlainText

Verificati evenimentele LAPS pe client in Event Viewer:

Applications and Services Logs > Microsoft > Windows > LAPS > Operational

Cautati Event ID 10018 — „Password successfully updated in AD”. Puteti verifica si atributul msLAPS-PasswordExpirationTime pe obiectul computerului, sau folosi tab-ul LAPS din Active Directory Users and Computers (necesita RSAT).

[mai mult...]