Getting a list of network mapped drives based on the network path

In exemplul de astazi o sa iau ca task listarea maparilor in retea catre un anumit server. Operatiunea asta ne poate ajuta sa identificam la nivelul unui client, daca are mapari facute catre un anumit file server.

Optiunile ar fi sa folosim WMI si clasa WIN32_LogicalDisk sau direct Get-PSDrive. Daca rulam Get-PSDrive obtinem ceva de genul:

Si as vrea sa filtrez si sa mi se returneze doar drive-ul X: care mapeaza catre un anumit file server. Iar asta o facem folosind comanda: gwmi win32_logicaldisk |? {$_providername –match “server”}.

Sau daca folosim Get-PSDrive va trebui sa filtram dupa DisplayRoot, chiar daca proprietatea afisata se numeste doar Root:

Get-PSDrive |? {$displayroot –match “server”}

In cazul migrarii unui file server putem folosi tehnica asta pentru a identifica unde se foloseste vechiul nume si eventual il putem modifica.

NTFS: the case when Deny permissions don’t apply

Cand setezi Deny de fiecare data esti intampinat cu urmatorul avertisment. Si e bine ca apare, ca de multe ori poti sa iti tai singur accesul.

Dar exista si un caz cand Deny nu este chiar atat de puternic. Cand Deny este mostenit de la un obiect parinte, si adaugam dreptul explicit de Allow pe obiectul in cauza, atunci dreptul setat explicit castiga (chiar daca prin combinarea drepturilor avem un Deny).

Iar documentatia spune fix la fel:

• Inherited Deny permissions do not prevent access to an object if the object has an explicit Allow permission entry.
• Explicit permissions take precedence over inherited permissions, even inherited Deny permissions.

https://technet.microsoft.com/en-us/library/cc783530(v=ws.10).aspx

And another way on how to identify and list network mapped drives in Powershell

Pe tema asta am mai scris de nu stiu cate ori dar de fiecare data mai gasesc cate ceva nou. Incercasem sa evit pana acum sa folosesc Get-WmiObject dar se pare ca e o varianta mai buna decat Get-PSDrive.

Si iata de ce. Cu Get-WmiObject –Class Win32_logicaldisk mai obtii o proprietate numita DriveType si in functie de asta poti filtra dupa mapari in retea:

Get-WmiObject -Class Win32_logicaldisk -Filter "DriveType = ‘4’"

PS: DriveType 3 e pentru disk local iar 2 pentru removable.

Searching Active Directory from Powershell without using the AD module

Cu modulul Active Directory poti cauta foarte usor obiecte si genera tot felul de rapoarte. Dar sunt suficiente cazuri cand nu vrei sa le folosesti. Cateodata se intampla sa te lovesti de o limitare a comenzilor sau AD Web services, performanta, sau bug-uri. Sau pur si simplu o sa rulezi scriptul pe o masina ce nu are modulul AD instalat. Si atunci e bine sa stii ca mai exista si alte variante.

Una dintre ele este ADSI si este foarte simplu de folosit. Iata un exemplu mai jos:

$search = [adsisearcher]"(&(ObjectCategory=Person)(ObjectClass=User)(cn=test*))"
$users = $search.FindAll()
Write-Host "Found $($users.Count) objects"
If ($users.count -gt 0)
{
    foreach($user in $users)
    {
        $user.Properties[‘SamAccountName’]
    }
}

Iata si rezultatul rularii acestei portiuni de cod:

PS: Se poate si prin DirectorySearcher .Net Class.

Access Based Enumeration (ABE) and Windows 10

In postul precedent am scris despre ceva legat de permisiuni si am mentionat si Access Based Enumeration (ABE). ABE este o functionalitate a Windows-ului ce face ca un server ce share-uieste foldere/fisiere sa arate clientului doar resursele la care acesta are acces.

Si cum in articolul precedent am mentionat cazul in care nu este dat dreptul “Read Permissions”, ABE o sa impiedice listarea folderelor/fisierelor pe care clientul nu are acest drept.

Din Windows Server, poti activa/dezactiva ABE simplu din Server Manager si proprietati pe share.

In schimb daca ai Windows 10 si il folosesti sa dai share la resurse in retea, eu personal nu am gasit de unde poti face lucrul asta din interfata. Asa ca trecem la Powershell si modulul SMBShare.

Cu Get-SmbShare putem afla detalii despre un share (chiar si unul default gen C$).

Dar parca nu e suficient. Asa ca incercam sa includem toate proprietatile folosind FL *.

Iar aici ne intereseaza proprietatea FolderEnumerationMode. Cand e pe AccessBased inseamna ca ABE este activat. Cand e pe Unrestricted e dezactivat.

Ca sa dezactivam ABE folosim Set-SmbShare -FolderEnumerationMode Unrestricted:

Este nevoie sa rulati comanda dintr-un shell cu drepturi elevate sau cu UAC dezactivat (nerecomandat).

PS: comenzile astea pot fi folosite la fel si pe Windows Server.

Granting list folder contents only in Windows/NTFS

Sa setezi in Windows permisiuni ca cineva sa poata vedea lista fisierelor dar sa nu poata accesa continutul e destul de tricky. Unii ar spune chiar ca nu se poate. Dar se poate. In felul asta poti da permisiunea de list folder contents si apoi drepturi depline de read pe un anumit fisier. E de preferat totusi sa ocoliti scenariile astea si sa setati permisiunile la nivel de folder.

Drepturile necesare le vedeti in imaginea de mai jos:

Important este sa nu dati dreptul “Read permissions”. Prin acest drept se controleaza accesul la ACL si daca nu il ai nu poti deschide fisierul dar il poti vedea.  Avantajul este ca se aplica si pe foldere si pe fisiere. Pe cand combinatia ListFolder/ReadData e diferita: Read Data se aplica pe fisiere iar List Folder pe foldere. Deci daca activezi List Folder automat dai drept de read pe fisiere. Solutia e sa controlezi prin Read Permissions. Sau bineinteles sa te duci sa faci modificari la nivel de fisier.

Cu drepturile astea date am facut un test pe un user (ce este chiar admin pe masina locala) si care are doar drepturile din imaginea de mai sus. Pot sa listez fisierele din folder, dar cand incerc sa deschis un fisier iata ce se intampla:

Testul meu a fost unul local. Daca incercati sa faceti acest lucru pe un share cu ABE activat (Access Based Enumeration) nu o sa vedeti deloc fisierele/folderele pentru care nu aveti Read Permission. Asa ca varianta ar fi sa dezactivati ABE.

Adding–WhatIf and–Confirm to your Powershell scripts

Recent am avut de facut un script ce modifica informatii din Active Directory, si printre mecanismele de protectie am adaugat si WhatIf. Dar intr-un mod primitiv. Am pus o gramada de If/Else si am rulat comenzile din interiorul scriptului cu WhatIf.

Dupa ce am terminat scriptul am aflat si eu ca puteam implementa WhatIf si Confirm la nivel de script sau functie doar printr-o simpla delcaratie.

Simpla adaugare la inceputul scriptului a urmatoarelor:

[CmdletBinding(SupportsShouldProcess)]

Param()

Va implementa suportul pentru WhatIf si Confirm.

Ruland scriptul cu parametrul –WhatIf va face ca fiecare comanda din script ce implementeaza WhatIf sa ruleze in acest mod. Fara a mai pune o gramada de If/Else si alt cod redundant.

Ceva mai detaliat gasiti si aici: https://blogs.technet.microsoft.com/poshchap/2014/10/24/scripting-tips-and-tricks-cmdletbinding/

Iar daca vreti sa verificati in interiorul scriptului daca s-a folosit parametrul WhatIf puteti verifica variabila $WhatIfPreference. Un exemplu mai jos:

If ($WhatIfPreference)
{
    Write-Host "Script is running in WhatIf mode." -ForegroundColor yellow -BackgroundColor Black
}

Basic version control for your enterprise powershell scripts

In lumea celor ce scriu cod in mod profesional, version control e ceva uzual si pentru care exista solutii. In schimb pentru cei care nu scriem cod zi de zi sunt momente cand e dificil sa gestionam versiunile scripturilor.

Scenariul e de genul: am scris un script care in spate executa cateva actiuni si care a ajuns sa fie distribuit mai multor sysadmini din organizatie. Scriptul ajunge sa fie stocat pe un share, cateodata chiar distribuit pe email si in final ajunge pe desktop-ul unui sysadmin sau poate si pe un server de unde il ruleaza.

Intre timp cel ce l-a scris a mai adaugat cate ceva la script sau poate a corectat un bug. Cum putem sa facem in asa fel ca cel ce ruleaza scriptul sa fie informat ca exista o versiune mai recenta si sa o downloadeze dintr-un repository central?

Sincer nu e nimic nou sau complex in toata chestia asta, ci doar mai mult un sfat despre cum ai putea sa implementezi o solutie basic la aceasta problema.

Asa ca in opinia mea cea mai simpla varianta ar fi ca scriptul sa verifice o locatie accesibila de peste tot din companie. Se poate face si web based, dar cum discutam de ceva foarte simplu si in contextul unui sysadmin care part time mai face si cate un script cel mai simplu ar fi ca versiunea curenta sa fie stocata ca si valoare numerica intr-un fisier text stocat intr-un share.

Folosim Get-Content ca sa citim continutul fisierului text. In cel mai simplu scenariu, fisierul va contine doar o valoare numerica. Putem sa complicam lucrurile si sa tinem mai multe valori in acest fisier si pe baza lor sa luam decizii, dar va las pe voi sa va imaginati scenarii.

$currentversion = Get-Content \\Server\Share\appcurrentversion.txt

In script va exista si o variabila $ScriptVersion ce va tine versiunea scriptului. Dupa ce citim $currentversion din retea, trebuie doar sa comparam valorile cu ceva de genul:

$scriptversion -le $currentversion

Luand exemplul de mai sus, daca valoarea stocata in script $scriptversion e mai mica decat cea din retea $currentversion putem lua anumite decizii, gen sa terminam executia scriptului sau sa il lasam sa continue dar sa informam uitilizatorul ca exista o versiune mai noua si sa ii spunem de unde sa o ia.

Logica asta o putem pune foarte usor intr-o functie pe care mai apoi sa o portam la toate scripturile ce vor fi distribuite in companie.

Different ways to check for remotely open files

Sunt foarte multe cazuri cand doresti sa verifici daca anumite fisiere sunt deschise de catre un client remote, si cel mai bun exemplu ar fi atunci cand se pregateste o operatiune de mentananta a unui server. Pot fi si alte scenarii dar nu intram in detalii. Mai bine sa vedem care sunt metodele prin care detectam cine acceseaza fisiere de pe serverul nostru.

Cea mai simpla metoda si cea mai cunoscuta este prin consola Computer management:

Nota:In Windows 2008 R2 trebuie sa va duceti in Share and storage management si din Actions sa selectati Open Files.

Lucrurile astea merg foarte simplu atunci cand ai un singur server si nu e nevoie sa colectezi date sau sa automatizezi niste taskuri.

Exista totusi metode (cam obscure zic eu) prin care poti sa afli informatiile astea din linie de comanda.

Prima varianta ce imi vine in minte ar fi NET FILES:

Urmatoarea varianta ar fi cu OPENFILES (vine cu Windows-ul):

Avantajul lui OPENFILES este ca poate interoga servere remote si poate exporta informatiile in CSV (deci puteti colecta informatiile de pe mai multe servere iar apoi le puteti consolida).

Mai mult decat atat, OPENFILES poate afisa si fisierele deschise local (trebuie activat inainte cu OPENFILES /LOCAL ON iar serverul trebuie rebootat; poate afecta performanta serverului; util doar in anumite scenarii de troubleshooting):

Nota: daca vreti sa vedeti ce fisiere sunt deschise local va recomand sa folositi mai bine Handle sau Process Explorer.

Iar ultima varianta ce imi vine acum in minte este Get-SmbOpenFile (cred ca minimul disponibil este Windows 2012 R2 sau Windows 8.1):

Nota: A nu se confunda cu Get-SMBConnection ce enumera doar sesiunile.

De retinut ca toate variantele din linie de comanda enumerate mai sus au nevoie de drepturi elevate de admin.

Probabil ca mai sunt si alte metode, dar acestea imi sunt cunoscute mie si suficiente pentru a-mi face treaba.

Check if a specific Hotfix is installed via Powershell

Sa verifici daca un sistem are un anumit hotfix instalat este super simplu in Powershell. Comanda ce ne ajuta este Get-Hotfix:

Iar daca folosim Sort putem vedea si ordinea in care au fost instalate update-urile:

Si este destul de flexibila sa ne ajute sa cautam un anumit update. De exemplu ca sa verificam daca update-ul KB4074588 a fost instalat, rulam Get-Hotfix KB4074588:

Cu parametrul –Computername putem interoga si sisteme remote:

Personal mi se pare cel mai rapid si simplu mod de a verifica daca un sistem are un anumit hotfix instalat.