Managing local accounts in Windows 2016 & Windows 10

Un lucru nou pe care l-am observat testand Windows 2016, au fost comenzile Powershell pentru lucrul cu conturi de useri si grupuri locale.

Daca pana acum trebuia sa facem tot felul de artificii folosind WMI sau ADSI, sau mai recent sa importam module PS custom, acum exista ceva builtin.

Ce este ciudat deocamdata, este ca eu am gasit comenzile doar pe Windows 2016 si Windows 10 Aniversary Edition (ambele cu WMF 5.1; pentru restul este inca in preview). Documentatia spune ca ar trebui sa avem comenzile by default in Powershell 5.0, insa pe un server cu Windows 2012 R2 si Powershell 5.0 instalat eu nu le-am gasit.

Ruland Get-command -Module Microsoft.PowerShell.LocalAccounts, putem obtine lista cu noile comenzi:

Add-LocalGroupMember
Disable-LocalUser
Enable-LocalUser
Get-LocalGroup
Get-LocalGroupMember
Get-LocalUser
New-LocalGroup
New-LocalUser
Remove-LocalGroup
Remove-LocalGroupMember
Remove-LocalUser
Rename-LocalGroup
Rename-LocalUser
Set-LocalGroup
Set-LocalUser

Din ce am testat eu pana acum, puteti face cam tot ce este disponibil si in GUI si fara prea mari batai de cap. Probabil ca era momentul pentru asa ceva pentru a mai usura lucrul cu sistemele fara GUI, mai ales ca acum avem si Nano server.

Totusi as vrea sa le vad portate si pe sistemele de operare mai vechi. Dar poate cand WMF 5.1 o sa fie disponibil in versiune finala si pentru ele.

Troubleshooting AD Powershell queries: server has returned the following error – invalid enumeration context

I’ve seen a lot on the web about the error in the title (server has returned the following error – invalid enumeration context) and the reason I am writing about this is because there is a lot of confusion about this.

You might see this error when you try to query AD from powershell (get-aduser, get-adcomputer, etc) and the query is taking a long time to finish.

+ FullyQualifiedErrorId : The server has returned the following error: invalid enumeration context.,Microsoft.ActiveDirectory.Management.Commands.GetADUser

But if you pay attention you’ll notice the error comes up exactly after 30 minutes of script execution.

Why’s that? Simple, because somewhere there’s a timeout in Active Directory Web Services.

If you’ll go and read the documentation for AD WS you’ll notice a parameter named MaxEnumContextExpiration which is set by default to 30 minutes.

From the documentation:

In ADWS, there are a number of configuration parameters that determine how ADWS in Windows Server 2008 R2 handles the traffic that administrators generate. Administrators can manage AD DS domains, AD LDS instances, and Active Directory Database Mounting Tool instances by using applications such as the Active Directory module or Active Directory Administrative Center. These configuration parameters are stored in the Microsoft.ActiveDirectory.WebServices.exe.config file, under %WINDIR%\ADWS directory.

You can adjust these configuration parameters by editing the Microsoft.ActiveDirectory.WebServices.exe.config file to accommodate traffic that is directed at the ADWS service in their Active Directory environments. Any changes that you make to the ADWS configuration parameters on a given domain controller affect only the ADWS service that is running on this particular domain controller. In other words, changes that you make to the Microsoft.ActiveDirectory.WebServices.exe.config file on a domain controller in a given domain or forest do not replicate to other domain controllers in this domain or forest.

MaxEnumContextExpiration parameter description: Specifies the maximum allowed time period during which the ADWS service processes and retrieves the results of a query request from a client computer.

I’ve seen several recommendations to change –ResultPageSize & –ResultSetSize in order to fix this error. Although by changing those might improve the performance a little bit, if the query still takes more than 30 minutes, you’ll get the same error. Those two are still important. Why? Because you’ll need to optimize your query and make it faster.

So here’s your options:

1. Try with –ResultPageSize & –ResultSetSize and see if you can make it faster.

2. Go and change Microsoft.ActiveDirectory.WebServices.exe.config and increase MaxEnumContextExpiration

3. Improve your query so it will return fewer objects so it can take less than 30 minutes. (Example: return only active objects)

4. Sometimes there’s a lot of processing time spent on the client side. Think about all the pipelines in your one liner command. Change your code to retrieve everything in a local variable in memory if possible and then query that locally.

5. Use something else than AD Powershell Cmdlets. Maybe the Quest ones or directly from .Net. And remember there’s always VBScript.

How to bypass Powershell execution policy

Restrictiile pe execution policy din powershell nu au fost niciodata gandite ca un mod absolut de a bloca rularea scripturilor. Este mai mult ca o protectie si pentru end user si pentru administratori de a nu rula ceva accidental.

Si chiar daca pentru a seta execution policy pe Unrestricted cere drept de admin:

Asta nu inseamna ca e nevoie de drepturi administrative ca sa rulezi un script.

Cel mai simplu workaround in caz ca nu aveti drepturi de administrator sau nu doriti sa modificati configuratia este sa faceti bypass la aceasta protectie doar pentru sesiunea respectiva:

Comanda necesara este Set-ExecutionPolicy Bypass Process, si va afecta doar sesiunea powershell curenta.

La fel puteti rula si Set-ExecutionPolicy Unrestricted –Scope CurrentUser

Dar asta va afecta intreg profilul utilzatorului.

PS: Puteti face oricand reset setand execution policy pe Undefined.

Keep Your Hard Drive – Dell Warranty Service

In mod normal, cand se strica un hard disk si furnizorul iti aduce unul nou, il ia la schimb pe cel vechi. Dar atunci cand lucrezi cu date sensibile e de preferat ca disk-ul defect sa ramana tot in posesia ta.

Pentru cine nu stia, exista optiuni in contractele de service pentru un astfel de scenariu si anuleaza necesitatea de a returna hard diskul defect.

https://www.dell.com/en-us/work/learn/keep-your-hard-drive

Time Improvements in Windows Server 2016

Iata ca dupa multi ani au aparut ceva schimbari in serviciul de timp de pe Windows. Si sunt majore din punct de vedere al acuratetii timpului. O scurta prezentare a noutatilor le gasiti un prezentarea de mai jos de pe Channel9:

https://aka.ms/WS2016TimeVideo

Avand in vedere tendinta recenta de a virtualiza aproape tot, se vedea nevoia unor update-uri in acest serviciu si poate si a unor recomandari mai recente, updatate la ultimele scenarii. Incepand cu Windows 2016 si Windows 10 Anniversary Edition, Microsoft se lauda ca aceste sisteme pot sa mentina timpul cu o acuratete de 1ms fata de o sursa stabila si acurata (o sursa de tip Stratum 1).

Discutam de 1ms, ceea ce este enorm, avand in vedere problemele vazute pana acum cu timpul pe sistemele Windows. Daca discutam si de sistemele virtualizate, acolo era o nebunie si mai mare. Serverele cu Windows isi sincronizau timpul cu domain cotnrollerele cand si cand iar daca hostul pe care rulau era foarte aglomerat, atunci ceasul o lua razna si daca nu monitorizai foarte atent infrastructura te trezeai cu o gramada de probleme pe cap.

Tin sa mentionez ca decalajul de timp acceptat de Kerberos by default este de 5 minute, asa ca unii admini poate nu au avut mari probleme. Dar sunt anumite domenii (in special financiar) unde reglemantarile impun o acuratete a sistemelor intre 1 si 50ms.

O comparatie intre setarile default de pe Windows 2016/10 se poate vedea in imaginea de mai jos:

 

Si inca o veste buna este ca exista deja un guideline despre cum sa imbunatatesti time sync-ul pe Windows 2012R2 si 2008R2:

Mixed OS Environments (Win2012R2 and Win2008R2)

While a pure Windows Server 2016 Domain environment is required for the best accuracy, there are still benefits in a mixed environment. Deploying Windows Server 2016 Hyper-V in a Windows 2012 domain will benefit the guests because of the improvements we mentioned above, but only if the guests are also Windows Server 2016. A Windows Server 2016 PDC, will be able to deliver more accurate time because of the improved algorithms it will be a more stable source. As replacing your PDC might not be an option, you can instead add a Windows Server 2016 DC with the GTIMESERV roll set which would be an upgrade in accuracy for your domain. A Windows Server 2016 DC can deliver better time to downstream time clients, however, it’s only as good as its source NTP time.

Also as stated above, the clock polling and refresh frequencies have been modified with Windows Server 2016. These can be changed manually to your down-level DCs or applied via group policy. While we haven’t tested these configurations, they should behave well in Win2008R2 and Win2012R2 and deliver some benefits.

Versions before Windows Server 2016 had a multiple issues keeping accurate time keeping which resulted in the system time drifting immediately after an adjustment was made. Because of this, obtaining time samples from an accurate NTP source frequently and conditioning the local clock with the data leads to smaller drift in their system clocks in the intra-sampling period, resulting in better time keeping on down-level OS versions. The best observed accuracy was approximately 5 ms when a Windows Server 2012R2 NTP Client, configured with the high-accuracy settings, synchronized its time from an accurate Windows 2016 NTP server.

Textul de mai sus spune ca se poate obtine o acuratete de 5ms pe 2012 si 2008 ceea ce mi se pare extraordinar.

In documentatia oficiala din link-ul de mai jos, gasiti mult mai multe explicatii, exemple si recomandari pentru a imbunatati time sync-ul pe sistemele Windows.

https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-ds/get-started/windows-time-service/windows-2016-accurate-time

Citrix Receiver Clean-Up utility

Utilitarul din titlu m-a ajutat in cateva cazuri de upgrade cand nici macar nu mai puteam face uninstall la vechea versiune.

http://support.citrix.com/article/CTX137494

Powershell on Linux

Powershell pe Linux clar va schimba multe iar MS va fi vazut in cu totul alta lumina.

https://azure.microsoft.com/en-us/blog/powershell-is-open-sourced-and-is-available-on-linux/

PS: de fapt portarea .Net pe Linux este baza si de aici vor urma multe altele.

Extrasphere tools

Tocmai am dat peste un tool ce pare interesant si ce permite storage migration pe ESXi fara vCenter.

Tool-ul l-am descoperit citind despre el pe un site de renume in virtualizare (vladan.fr) dar chiar si asa ceva imi pare dubios. Odata ca dupa ce a fost anuntat prima data pe vladan.fr s-a descoperit ca avea un troian in el; doi, e facut cu Unity (cine naiba face asa ceva in Unity);trei, e scris de niste rusi ce la contact au o adresa de mail pe gmail.

Si exista varianta pentru Windows, Android si MacOS.

Daca totusi aveti curaj: http://www.extrasphere.ru/#!download/c1df1

How to restore deleted user accounts and their group memberships in Active Directory – Pre W2K8 version

Am dat de foarte multe scenarii unde s-au facut modificari “accidentale” si toata lumea credea ca acel AD Recycle Bin o sa ii ajute. Pai daca nu a fost activat, atunci nu are cum sa te ajute.

In cazul asta tot variantele folosite in trecut trebuiesc folosite:

https://support.microsoft.com/en-us/kb/840001

A trecut atat de mult timp de cand nu am mai facut un Authoritative Restore incat acum mi se pare ceva super complicat.

Asa ca activati Recycle Bin si uitati complet de procedurile astea.

PS: iar daca nu aveti backup, se poate si cu object reanimation – https://blogs.technet.microsoft.com/asiasupp/2006/12/14/using-adrestore-tool-to-restore-deleted-objects/

SID Filtering and Well Known Groups over PIM Trust

Looks like the update that allows the use of built in groups (Domain Admins, Administrators, etc) over the PIM trust has finally arrived:

https://support.microsoft.com/en-us/kb/3155495

For those that don’t know, the well known accounts are always filtered over forest trusts. But in case you implement the new bastion forest model you’ll need that security feature disabled.