Capita di avere la necessità di cancellare la history dei comandi Powershell inviati con un account. A noi, per esempio, è capitato quando abbiamo dovuto preparare dei template per le virtual machine dei nostri clienti ed era necessario attivare un software prima di completare il template.

Sfortunatamente questa attivazione avveniva per mezzo console e bisogna quindi inserire un comando con il codice di attivazione. Questo faceva si che il codice potesse poi essere visibile per gli utenti che usavano quel template che potevano accedere alla history semplicemente premendo PgUp. Se si cerca una soluzione si scopre che Powershell ha un comando per la cancellazione della history:

Clear-History

Tuttavia non tutti i comandi vengono rimossi. Alcuni vengono rimossi, altri no oppure proprio nessuno. Probabilmente non vengono rimosse le invocazioni di eseguibili e comandi esterni. Ad ogni modo, questo lascia la history, o parte di essa, disponibile per gli altri utenti.

C’è però un comando che consente di visualizzare quale sia il file in cui Powershell memorizza la history dell’utente:

PS C:\Users\Administrator> (Get-PSReadlineOption).HistorySavePath C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

Il file mostrato è quello della history. Basta quindi modificarl e rimuovere le righe che non si vogliono rendere disponibili per gli altri utenti.

Un trucco semplice ma rimane il mistero sul perché esista un comando dedicato che non funziona come ci si aspetterebbe.

Microsoft released Windows Server 2022 a few weeks ago. It did so earlier than expected, which is pretty odd, but it seems that the development of new features was already complete and mature so there was no point to wait a few months more. The last sentence pretty much explains the current status of Windows Server: so few changes, albeit interesting ones, that the product can be released months earlier than planned and without much fanfare.

While generally speaking the development of new features and functionalities for server applications mostly moved out of the base operating system and while we can also concede that Windows Server has many features at the OS level so it is difficult to design new ones, the fact each new release of Windows Server keeps bringing few new features is definitely because of Microsoft errors. Server applications today are either simple, think about a website or a Web application, or complicated. In the latter case, you generally think about microservices, Kubernetes and so on.

So we might say that since a few years Windows Server became more a tool to build base infrastructures than the base for new applications. That means that you usually install something on top of Windows Server to manage and deploy applications and you don’t usually rely on OS services only to develop your application. It is safe to say that it is a common scenario because Linux too is experiencing the same transformation.

However, Microsoft could have responded to Linux popularity by upping the ante and push more innovation into Windows Server and they didn’t.

Windows Server 2022 – continued fragmentation

The new Windows Server version has some nice and neat features. Besides a better Kubernetes compatibility, which is basically mandatory today, it features and big work to improve security. Credit where is due. That improves a lot both standalone servers security but it is also a fundamental improvement when deploying clusters, the famous infrastructures.

Other improvements include TLS 1.3 enabled by default and a few improvements around SMB, all of them improve security.

There would be other two important features to mention, one of them would be very important, but surprise: they won’t be available to all customers but only to those using Azure. At least for now.

Microsoft introduced Windows Server Datacenter: Azure Edition, another attempt to fragment Windows Server but the first one to draw a line between “standard” Windows Server and Azure versions. And we cannot welcome this kind of behavior because it basically starts to leave non-Azure Windows Server installations behind in an attempt to force Windows customers to move to Azure. Quite frankly, this is indecent especially when you factor how much Windows Server costs when compared to its competitor.

Features that Microsoft is withholding from its non-Azure customers are very important.

First, there is the much awaited hot-patching, that is a way to patch Windows without rebooting. Microsoft aims to use hot-patching especially for security patches and it would be a very ground-breaking innovation when considering how many emergency updates are needed [...]

Avevamo capito prima di procederre cosa fosse successo alle due macchine ma quella spiegazione è fuori dall’obbiettivo di questo post che si incentra su come poter recuperare velocemente da quella situazione.

Qualche giorno fa abbiamo riscontrato uno strano problema su un paio di server dopo avere aggiornato gli agent di Acronis. La console non consentirva più l’esecuzione del piano di backup, sia in modo automatico che manuale, segnalando che l’agent non era più registrato. Sembrava molto strano visto che avevamo effettuato aggiornamenti degli agent diverse volte in passato senza riscontrare alcun problema ma questa volta gli agent non riuscivano più a registrarsi.

In realtà nello stesso ciclo di aggiornamenti avevamo avuto altri due problemi su macchine Linux ma questi erano spariti riavviando i due server. Inoltre, avevamo notato che i due server che presentavano questo problema erano installazioni di Windows Server Core che ospitavano SQL Server. Abbiamo quindi deciso di registrare nuovamente gli agent manualmente ma sorprendentemente non era possibile perchè l’agent si lamentava del fatto che il certificato dell’endpoint non fosse valido. Anzi, in maniera più specifica, che la Certification Authority fosse sconosciuta.

Quei due server funzionavano correttamente prima dell’aggiornamento e, cosa ancora più strana, sembrava che non fossimo in grado di registrare gli agent nemmeno usando l’endpoint di Acronis invece che il nostro endpoint specifico. Stesso errore. Se era possibile, anche se improbabile, che il nostro endpoint usasse un certificato che causava problemi – anche se funzionava correttamente con le altre macchine e nei browser – non era possibile che ci fosse qualche problema con quello di Acronis.

Aggiornamento autorità di root

L’errore riportato dall’agent era abbastanza indicativo ma noi avevamo problemi a collegarci agli endpoint anche in modo standard, usando per esempio Powershell

Invoke-WebRequest -UseBasicParsing -Uri https://cloud.acronis.com

C’era sicuramente un problema con le connessioni SSL. Anche se PowerShell restituiva un errore generico sull’impossibilità di completare la connessione, l’agent di Acronis riportava un errore di molto più specifico per il quale abbiamo deciso di aggiornare i certificati di root sulla macchina:

md C:\Temp cd C:\Temp # Scarica TUTTI i certificati di root da Windows Update certutil.exe -generateSSTFromWU roots.sst # Importa TUTTI i certificati nello store delle autorità di root $sstContainer = (Get-ChildItem -Path C:\temp\roots.sst) $sstContainer | Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root

Dopo aver lanciato questo questi comandi sarà necessario riavviare la macchina per consentirle di ricaricare tutti i certificati.

Problemi di cifratura

Questo non ha risolto il problema di per sè. Quando la macchina è tornata online le connessioni agli endpoint di Acronis continuavano a non riuscire anche se con un errore diverso da parte dell’agent e lo stesso errore da parte di Powershell. Abbiamo quindi deciso di verificare meglio se fosse un problema di cifratura e di forzare le connessioni TLS1.2 in Powershell usando:

# Forza PowerShell ad usare TLS1.2 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Ovviamente devi ricordare di non chiudere la sessione o perderai l’impostazione effettuata e dovrai applicarla di nuovo. Un altro tentativo di connessione ai nostri endpoint e … bingo! Ora tutto funzionava correttamente!

PS C:\temp> Invoke-WebRequest -UseBasicParsing -Uri https://backup.vaisulweb.cloud [...]

At VaiSulWeb virtualization is so pervasive that basically there aren’t physical machines other than virtualization hosts or storage since about 2008 or 2009. That means about 10 years now. And counting. Microsoft Hyper-V served us very well and over time our reliance on that technology increased with happy results. It has been solid and consistent and allowed us to scale up more and more, adding new technologies and solutions and enabling us to virtualize roles and workloads that seemed a bit difficult to virtualize.

As many other providers, we recently started integrating AMD CPUs into our infrastructure, given the terrific advantages that those could bring to the datacenter especially for generic or mixed workloads. Only a subset of our infrastructure has been migrated to the new AMD servers but things got easier because of the many advantages that the Windows Server (+ Hyper-V) platform could provide and we carefully started to fill those hosts by migrating workloads. Results have been very pleasing.

Performance improvements and security

As we had planned, we immediately started benefiting of performance improvements. Not only CPU-bound tasks were faster but also I/O performance were terrific.

One of our goals was also to improve security by using AMD technologies that showed better resiliency when dealing with security issues when compared to Intel chipsets and CPUs and we were also prepared to face a few limitations. For example, Hyper-V isolated containers are not supported on non-Intel CPUs and thus cannot be used.

We started migrating our workloads to the new servers and Hyper-V functionalities like shared-nothing live migration and live migrations made the process quite easy and straightforward. In a few days about 80% of the target workloads have been migrated with minimal or no disruption at all. So far so good.

Unexpected crashes

Then something odd happened: one of the hosts started to crash. That was surely something we rarely faced in our 10+-years-long experience with Hyper-V but that specific host was crashing up to 2-3 times per day and while it usually was back online in about 2 minutes with all of its VMs restarted, the virtual machines that it was hosting were obviously also crashing causing downtimes. That was very surprising since similar machines (basically identical since they were using the same components) were not exhibiting any issue even after running for weeks in production and even more in our labs.

That machine had been running for days without issues then started crashing 2-3 times per day with no traceable pattern. Sometimes it could run for hours (10 or more) without issues, sometimes it was crashing two times in 15 minutes. Weird. And scary.

We decided to halt our migration to ensure that we didn’t miss any incompatibility between Windows Server 2019 and those AMD servers yet other servers were not having any issue and tracing back the issues we had, that specific machine had not been exhibiting issues for days before it started crashing so often.

Diagnosing the issues

The first thing that you might want to do in such cases is to ensure [...]

Con una mossa inusuale, Microsoft ha rilasciato una patch per Windows Server 2003 e Windows XP. Questi sistemi operativi sono considerati obsoleti da lungo tempo e di solito non ricevono aggiornamenti che non siano legati ad accordi speciali siglati con i clienti. Tuttavia anche in passato Microsoft ha rilasciato in via eccezionale aggiornamenti per Windows Server 2003 quando il ransomware WannaCry era all’apice della difusione e stava compromettendo diverse migliaia di macchine. Questa volta le correzioni riguardano Remote Desktop Protocol (RDP) e le vulnerabilità possono essere probabilmente mitigate attivando NLA, una configurazione che richiede l’autenticazione prima di effettuare la connessione alla macchina. Questo renderebbe probabilmente non efficace la vulnerabilità. L’attivazione di NLA è da tempo una configurazione raccomandata per tutti i sistemi Windows per limitare le possibilità di accessi non autorizzati e attacchi DDoS e si ritiene che la  maggior parte delle macchine oggi abbiano questa configurazione.

Gli utenti interessati che usino Windows Server 2003 o Windows XP possono nel frattempo installare l’aggiornamento visitando questa pagina per ottenere maggiori informazioni.