Configurare program

Cum rezolvi eroarea „Windows cannot access \ComputerName” când share-ul de fișiere funcționează doar prin IP

Cum rezolvi eroarea „Windows cannot access \ComputerName” când share-ul de fișiere funcționează doar prin IP (Activare NetBIOS / SMB1/SMB2 guest access)

  • Problema: În rețeaua locală (LAN), poți accesa un alt PC sau NAS tastând \\192.168.1.100, dar primești eroare dacă încerci prin nume (\\ServerPC sau \\NumeCalculator).

  • Cauza: Windows 10/11 a dezactivat autentificarea necriptată de tip Guest și protocolul NetBIOS over TCP/IP pentru anumite profiluri de rețea din motive de securitate.

 

[mai mult...]

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

Diagnosticarea și rezolvarea erorii „Kernel panic – not syncing: Attempted to kill init!”

1. Introducere și definirea erorii

Eroarea Kernel panic - not syncing: Attempted to kill init! reprezintă o stare critică de eroare neremediabilă în sistemele de operare Linux. În această stare, nucleul (kernel-ul) oprește complet executarea oricărei instrucțiuni pentru a preveni coruperea datelor sau deteriorarea fizică a sistemului de fișiere.

Mesajul indică direct faptul că primul proces lansat de kernel la pornirea sistemului (procesul cu PID 1, numit init sau systemd) a fost oprit neașteptat sau a fost terminat forțat (killed). Deoarece procesul init este „părintele” tuturor celorlalte procese din sistem, oprirea lui face imposibilă funcționarea în continuare a sistemului de operare.

2. Cauzele principale ale erorii

Defectarea sau prăbușirea procesului init are loc, în general, în prima fază de boot (încărcare) a sistemului și este cauzată de următoarele categorii de probleme:

A. Coruperea sau lipsa imaginii initramfs / initrd

Imaginea Initial RAM Disk (initramfs) conține driverele și modulele necesare kernelului pentru a putea citi și monta discul principal. Dacă această imagine este coruptă, lipsă sau a fost generată greșit după o actualizare de kernel, sistemul nu poate lansa init.

B. Probleme legate de configurarea Bootloader-ului (GRUB)

  • Anumiți parametri de boot din configurarea GRUB trimit kernelul către un disc greșit (ex: o adresă root=UUID=... incorectă).

  • Parametrul init= arată către o cale inexistentă (ex: /sbin/init lipsește sau este corupt).

C. Coruperea sistemului de fișiere sau a discului (Filesystem / Hardware)

  • Sector defect pe disc (SSD/HDD) în zona unde se află executabilul /sbin/init sau /lib/systemd/systemd.

  • Corupere cauzată de o oprire necorespunzătoare a alimentării cu energie electrică.

D. Lipsa spațiului pe disc în timpul actualizărilor (/boot plin)

O cauză extrem de frecventă pe servere și calculatoare de birou este umplerea partiției /boot. Dacă la un update de sistem (apt upgrade / dnf update) discul este $100\%$ plin, noul kernel sau imaginea initramfs se va scrie parțial, rezultând o imagine invalidă la următorul restart.

E. Neconcordanță între arhitectura sistemului și module

Executarea unui kernel pe $64$ de biți cu un proces init compilat pentru o altă arhitectură necompatibilă sau din cauza unor permisiuni de fișiere alterate (/sbin/init și-a pierdut drepturile de execuție chmod +x).

3. Ghid 

Când întâmpinați această eroare, sistemul nu mai poate porni normal. Rezolvarea necesită intervenția prin mediul de recuperare (GRUB sau un Live USB).

Pasul 1: Pornirea dintr-o versiune anterioară de Kernel (Meniul GRUB)

Aceasta este cea mai rapidă metodă de testare și recuperare:

  1. Reporniți sistemul și țineți apăsată tasta Shift sau Esc pentru a afișa meniul GRUB.

  2. Selectați Advanced options for Ubuntu/Debian/RHEL.

  3. Alegeți o versiune anterioară de kernel (de exemplu, o versiune mai veche care nu are eticheta recovery mode).

  4. Dacă sistemul pornește cu succes, problema este legată strict de ultimul kernel instalat sau de imaginea sa initramfs.

Pasul 2: Regenerarea imaginii initramfs

Dacă ați reușit să intrați într-un kernel vechi sau folosind un Live USB (prin metoda chroot), regenerați fișierele de boot:

  • Pe sisteme bazate pe Debian / Ubuntu:

    Bash

    sudo update-initramfs -u -k all
sudo update-grub

  • Pe sisteme bazate pe RHEL / CentOS / Fedora:

    Bash

    sudo dracut --regeneration --force
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Pasul 3: Repararea sistemului de fișiere (fsck)

Dacă eroarea este provocată de un disc corupt:

  1. Porniti dintr-un Live USB/CD de Linux.

  2. Deschideți un terminal și identificați partiția de sistem (ex: /dev/sda1 sau /dev/nvme0n1p2) cu comanda lsblk.

  3. Rulați verificarea și repararea partiției:

    Bash

    sudo fsck -y /dev/sda1

Pasul 4: Curățarea spațiului din partiția /boot

Dacă partiția /boot este plină și a blocat actualizarea:

  1. Porniți din Live USB și montati partiția de sistem.

  2. Ștergeți kernel-urile vechi nefuncționale sau fișierele temporare nefinalizate din /boot.

  3. Rulați comanda de curățare a pachetelor incomplete:

    Bash

    # Dintr-un mediu chroot:
apt-get clean
apt-get autoremove
dpkg --configure -a

4. Măsuri de prevenție

  • Evitați umplerea partiției /boot: Configurați sistemul să păstreze doar 2-3 imagini de kernel (utilizați opțiuni de curățare automată precum Purgeremovedupes sau installonly_limit în managerul de pachete).

  • Nu opriți forțat calculatorul în timpul actualizărilor: Închiderea alimentării în timp ce se execută comenzi de tip update-initramfs sau dracut va deteriora garantat fișierele de boot.

  • Folosiți surse de alimentare neîntreruptibile (UPS): Pe servere de producție, întreruperile bruște de curent sunt principala cauză a coruperii procesului init și a sistemului de fișiere.

[mai mult...]