JOB – Technical Operations Engineer @Xogito
Cei de la Xogito isi cauta un coleg pe un post full time, long term si remote. Daca doriti sa aflati mai multe detalii si eventual sa aplicati puteti accesa linkurile de mai jos:
https://hire.withgoogle.com/public/jobs/xogitocom/view/P_AAAAAACAAADBD2s14FKZKz
Pun si job descriptionul mai jos:
Technical Operations Engineer
- Technical Operations
- Remote
Purpose of the Role
You will participate in all aspects of the new projects implementation including infrastructure design, server’s configurations, documentation, and deployment. Other part of your primary responsibilities is Windows system administration and ability to handle on-call duties on weekly rotation.
Duties and Responsibilities
- Architect, implement and support high traffic cloud based scalable web solutions for high profile US companies
- Oversee planned operations and deployment activities, as well as preventive maintenance
- Work closely with clients to understand their mission and needs
- Work closely with product development teams in the design and implementation of the systems
- Leverage and pioneer industry best practices
- Handling support related production incidents observing SLAs
- Provide 24/7 coverage
- Keep the business operational
- Deep understanding and appreciation for process and documentation outside of the technical aspects
Required Experience & Knowledge
- Senior level of experience in designing, implementing and supporting very complex server infrastructure environments
- Working knowledge of Microsoft Azure is essential
- Experience working with Windows-based application environments is required
- Familiarity with .NET web technologies, MS SQL Server, IIS, Web services and Windows Services
- Experience working with a multi-site Windows AD environment, including replication and integrated DNS
- Considerable knowledge and experience in implementing, providing ongoing support and maintenance for server storage environments
- Experience with high traffic scalable sites a big plus
Skills and Attributes
- Experience with activities for business-critical systems
- Strong problem solving and debugging skills
- Understands and accepts the corporate business process flow
- Excellent teamwork skills
Required Education & Qualifications
- Bachelor’s or Master’s degree in Computer Science or relevant specialty
- Fluent English both verbal and written
- Any IT certification would be considered a plus
Migrating and merging users with ADMT using an include file
Cand vine vorba de o migrare facuta cu bani putini, ADMT este cam singurul tool care ne poate ajuta. Dar de multe ori este destul de rigid si imi pare rau ca Microsoft nu a mai investit ceva resurse pentru a-l dezvolta (tot ce au facut a fost sa il updateze pentru a functiona cu ultimele versiuni de Windows).
Dar sa revenim la subiectul din titlu. Cand avem de migrat multi useri si nu dorim sa ii selectam de mana din GUI, sau dorim sa automatizam intregul proces (ADMT poate fi folosit si din linie de comanda) atunci va trebui sa folosim un include file. Fisierul trebuie sa fie in format CSV (poate avea orice extensie) si sa arate cam asa:
Numele coloanei trebuie sa fie Sourcename si pe fiecare linie sa fie numele userului din domeniul sursa. Atentie, este vorba de atributul name si nu samaccountname. In exemplul de mai sus, numele userului ce urmeaza a fi migrat este SOURCEUSR.
Dupa care in wizard trebuie doar sa specificati ca veti folosi un input file.
Tot acest fisier este folositor atunci cand doriti sa faceti rename la conturi (ca sa respectati un name standard din domeniul target) sau sa faceti merge la conturi cu nume diferit.
Sa luam cazul cand conturile utilizatorilor exista in amble domenii si va trebui facut merge pentru a adauga SID-ul din domeniul vechi in atributul sIDHistory. Fisierul de import va arata cam asa:
Nota: documentatia pentru fisierul de import poate fi gasita aici dar daca veti folosi TargetSAM, atunci atributul name al userului destinatie va fi redenumit la name-ul din sursa. Asa ca cel mai bine se pare ca este sa folosim TargetName. Si daca vrei ca singura informatie updatata sa fie SIDHistory, atunci trebuie sa folositi optiunile din imaginile de mai jos si sa faceti exclude la celelalte atribute:
In felul acesta, singura informatie updatata in target va fi SIDHistory iar contul destinatie isi va pastra numele.
Mai multe detalii despre include file gasiti aici:
https://technet.microsoft.com/en-us/library/cc974420(v=ws.10).aspx
How to access a variable property inside a double-quoted string
Azi m-am gandit sa explic cazul in care vrei sa folosesti proprietatea unui obiect direct in interiorul unui string.
Sa luam de exemplu cazul in care stocam continutul lui Get-AdUser intr-o variabila
$objUser = Get-ADUser aungureanu
Iar acum vrem sa folosim o proprietate a acestui obiect in interiorul unui string. In mod normal ar trebui sa mai folosim inca o variabila intermediara pentru a stoca acea proprietate.
$objSID = $objUser.SID
Iar apoi sa folosim noua variabila direct in string:
Dar ca un shortcut, putem accesa direct proprietatea dorita, fara a mai folosi aceasta variabila intermediara. trucul este sa punem totul intr-o expresie folosind paranteze si sa tratam toata expresia ca o variabila cu $, adica $($object.property).
Powershell SIDHistory Module and Domain Local Groups
Acum mult timp am scris cate ceva legat de SIDWalker, un tool din Resource Kit-ul de Windows 2003, foarte folositor pe vremuri in diverse scenarii de migrare. Dar tool-ul nu a mai fost updatat de foarte mult timp si inlocuitorul a fost modulul Powershell SIDHistory pe care il gasiti in link-ul de mai jos:
https://gallery.technet.microsoft.com/scriptcenter/PowerShell-Module-for-08769c67
Mi-ar fi greu sa descriu acum tot ce se poate face cu comenzile incluse in acest modul, insa va pot spune ca sunt foarte folositoare atunci cand vreti sa translatati permisiuni pe file system in diverse scenarii de migrare.
Una din comenzile din modul se numeste Export-SIDMappingCustom si permite crearea unui fisier ce va mapa obiecte din domeniul sursa cu obiecte din domeniul target pe baza unui atribut comun (ca exemplu sa zicem samaccountname). Fisierul CSV produs, poate fi folosit mai apot ca sa rulati Convert-SIDHistoryNTFS pe un file sistem si sa faca replace sau add la permisiuni pe baza informatiilor din acel fisier.
Dar daca folositi DomainLocalGroup ca parametru la Export-SIDMappingCustom o sa aveti surpriza sa obtineti doar niste fisiere goale. In caz ca se intampla asa ceva verificati fisierul SIDHistory.psm1 si urmatoarea sectiune:
In caz ca grup type pentru DomainLocalGroup este –2147483643, modificati in –2147483644 ca in imaginea de mai sus.
Mai jos o sa pun si link-urile catre seria originala de articole a lui Ashley McGlone, creatorul acestui modul:
- Using PowerShell to resolve Token Size issues caused by SID history
Prior to starting the module development this post explained the background of token size issues as related to SID history. I provided the basic SID history query that we use to produce the report and some great links for more information on token size. - Do Over: SID History One-Liner
As a follow up to the Token Size post I re-wrote the SID history report query as a one-liner. - PowerShell: SID Walker, Texas Ranger (Part 1)
This time we looked at Get-ACL and parsing SDDL strings, a warm up for the next post. - PowerShell: SID Walker, Texas Ranger (Part 2)
Next I wrote a function to swap SID history entries in ACLs/ACEs. This compensates for a gap in the ADMT, because it cannot migrate SID history for file shares hosted on a NAS. - PowerShell: SID Walker, Texas Ranger (Part 3): Exporting Domain SIDs and Trusts
Looking at raw SIDs in a report is not very friendly, so I wrote a function that translates domain SIDs into domain names. This makes the SID history report more meaningful when you can see the name of the domain from whence they came. Enumerating all forest trusts and their domain SIDs required using some .NET ninja skills. - How To Remove SID History With PowerShell
To round out the functions I provided Get-SIDHistory and Remove-SIDHistory, emphasizing that this is the LAST step in the process. I leveraged the previous domain SID function to even give us the ability to remove SID history selectively by old domain name.
https://blogs.technet.microsoft.com/ashleymcglone/tag/sidhistory/
Topologies for Azure AD Connect
Articolul din link-ul de mai jos mi se pare una din cele mai bune documentatii cu scenariile posibile pentru Azure AD Connect:
New path for Nano server
Conform Petri se pare ca Microsoft a decis ca Nano server sa fie utilizat exclusiv pentru containere:
https://www.petri.com/microsoft-defines-new-path-nano-server-server-core
Oricum eu am fost multa vreme sceptic si inca sunt si cu Server core, asa ca nu as fi recomandat Nano server pentru roluri de infrastructura nimanui.
Acum sper sa vad si ceva oficial pe tema asta ca in afara de screenshot-ul de pe Petri nu am vazut nimic oficial.
Forcing Garbage Collector from Powershell
In ultimele zile am lucrat cu ceva importuri de fisiere text fiarte mari din Powershell, iar memoria de pe statia de unde lucram era destul de limitata. Si am cam observat ca memoria folosita nu era eliberata imediat dupa ce incheiam taskurile.
Dar am descoperit ca pot sa apelez manual Garbage Collector-ul din .Net folosind[GC]::Collect() sau [System.gc}::Collect()
Alte cateva exemple si variante de a elibera memoria nefolosita gasiti in link-ul de mai jos:
http://horizontal-logic.blogspot.ro/2012/08/clearing-up-variables-and-memory-in.html
PS: Metoda poate fi folosita si in interiorul scripurilor ce ruleaza pe intervale mari de timp atunci cand GC-ul nu actioneaza la timp.
Process large CSV file from Powershell
Lucrul cu fisiere mari de tip CSV in Powershell s-a dovedit a fi un cosmar de multe ori. In special datorita faptului ca folosind Import-CSV aducem tot fisierul in memorie. Si daca avem de lucru cu fisiere de cativa GB atunci putem sa crash-uim foarte usor sistemul de pe care lucram.
Cautand o varianta pe internet sa citesc fisierul linie cu linie am gasit varianta sa folosesc [System.IO.File]::ReadLines descrisa pe aici.
foreach ($line in [System.IO.File]::ReadLines($filename)) { # do something with $line }
Dar nu am mai ajuns pana acolo pentru ca am descoperit ca si folosind Get-Content pot sa citesc fisierul linie cu linie. Exista si parametrul –ReadCount dar nu este nevoie de el, pentru ca by default Get-Content trimite prin pipeline linie cu linie. Toata chestia e sa nu ai dupa pipeline ceva ce stocheaza tot ce vine prin pipeline in memorie din nou.
Insa nu este tot. Nu poti trimite output-ul catre Import-CSV pentru ca acesta nu accepta decat path catre un fisier. Asa ca a fost nevoie sa folosesc ConvertFrom-Csv.
Get-Content .\mytestfile.csv | ConvertFrom-Csv
Iar output-ul dat mai departe de aceasta comanda poate fi prelucrat foarte usor cu Where-Object aka ?
Get-Content .\mytestfile.csv | ConvertFrom-Csv | ? {$_.Name –like ‘something*’}
Iar de aici putem insirui si alte conditii cu Where-Object sau sa folosim Select-Object pentru a selecta doar campurile dorite iar la final sa trimitem totul catre Export-Csv:
Get-Content .\mytestfile.csv | ConvertFrom-Csv | ? {$_.Name –like ‘something*’} |Export-Csv .\final.csv
How to record everything you do in Powershell
Comanda Start-Transcript poate fi folosita pentru a comanda pornirea unui transcript in sesiunea curenta powershell si este o metoda foarte buna de a loga toate actiunile pe care le faceti pe un sistem din powershell.
Pornita fara nici un parametru, comanda Start-Transcript va incepe logarea tuturor comenzilor si a outputlui din sesiunea curenta intr-un fisier text pe care il va salva in My Documents.
Dar indicat ar fi sa avem acest transcript activ de fiecare data si fara sa rulam noi de mana Start-Transcript. Iar aici intervin profilele din powershell.
Sunt sase tipuri de profile, toate descrise aici:
Din ce avem acolo, cea mai simpla solutie ar fi sa folosim $PsHome\Profile.ps1 si de regula locatia corespunde cu C:\Windows\System32\WindowsPowerShell\v1.0\Profile.ps1.
By default nu exista nici un profil creat asa ca va trebui sa creati de mana fisierul Profile.ps1 si sa adaugati comanda Strat-Transcript:
Start-Transcript -path (“$env:temp\PowershellTranscript”+ (get-date -format ddmmyyHHmm)+”.txt”) -force -noclobber
In exemplul de mai sus am setat locatia in folderul temp din profilul meu, dar atentie ca pentru fiecare sesiune nou deschisa de Powershell, se va crea un fisier nou si avand in vedere ca si output-ul comenzilor este capturat, in cazul in care exista foarte multa activitate vor fi generate destul de multe date. Pe sistemul meu de test, o singura deschidere de Powershell ISE genereaza un fisier de 135Kb (motivul … get-command, get-module la fiecare pornire a Powershell ISE).
Oricum solutia poate fi customizata foarte usor si este ideala pentru servere sau statii de lucru folosite pentru administrare.
Documentatia o gasiti aici:
https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.host/start-transcript
PS: Daca vreti sa aveti si un timestamp al comenzilor, exista paramentrul
-IncludeInvocationHeader
Copy the last powershell command to clipboard
Sunt situatii in care am testat o comanda in Powershell si dorim sa o copiem pentru a fi trimisa unui coleg sau pentru a fi pusa intr-un script. Iar cand este foarte lunga, a face select si copy/paste e un proces destul de lent. Solutia este sa folosim history-ul din Powershell (Get-History aka R) si comanda Clip.
(Get-History)[-1].CommandLine | Clip
In exemplul de mai sus a folosit Get-History cu proprietatea CommandLine si am redirectat totul catre comanda Clip.
Sau pe versiunile mai noi de Powershell (cred ca incepand cu v5) puteti folosi Set-Clipboard:
PS: si Start-Transcript este o solutie, doar sa il aveti activat la inceputul sesiunii.