In questi giorni si sta verificando sempre più frequentemente l’errore che non permette la connessione via RDP ai PC e alle Virtual Machine dovuto al CredSSP.
Questo si verifica quando c’è un disallineamento fra le ultime patch di sicurezza tra il client RDP e il PC/VM:
Online troviamo molte soluzioni, ad esempio qui è possibile vedere come creare una local policy nel client per bypassare l’errore dovuto al fatto che il server non ha la patch installata o come modificare la chiave di registro. Una volta effettuato le variazioni, il consiglio è di connettersi al PC/VM ed installare la patch per poi risistemare le impostazioni sul client per garantire la sicurezza.
Ma se volessi sfruttare le capacità di Azure per aggiornare la patch sulle VM, potrei sfuttare l’Update Management.
L’Update Management abilita la gestione degli aggiornamenti sulla VM ed è possibile visualizzarne lo stato e schedulare gli aggiornamenti senza entrare all’interno della VM.
Un esempio:
nella VM sopra possiamo vedere che nel riquadro rosso è presente l’aggiornamento non installato che genera l’errore con CredSSP.
E’ possibile quindi da Azure, associando alla VM un’account di Automation, gestire gli aggiornamenti e schedulare aggiornamenti o “una tantum” o “pianificati”
E’ possibile quindi schedulare un aggiornamento sulla VM o sulle VM che vogliamo patchare con la KB4103723 che ci risolverà l’errore in oggetto ed aspettare il termine dell’aggiornamento per connettersi in RDP in tutta sicurezza.
Buon aggiornamento!
1Chi l’ha detto che il ’17 porta sfortuna? Oggi, 1° Gennaio 2017 mi è arrivata LA mail per eccellenza, quella della nomina a Microsoft MVP per la categoria Microsoft Azure!
E’ veramente un’emozione indescrivibile e un onore entrare a far parte di questo gruppo!
Un enorme GRAZIE alla mia Famiglia che mi permettere di investire tempo nelle mie passioni, ai miei compagni di avventura di DotNetToscana, a Cristina e a tutte le persone che hanno permesso che ciò divenisse realta!
E’ online il Podcast sui Microsoft Cognitive Services dove io, Marco Minerva e Marco Dal Pino facciamo una breve panoramica del servizio disponibile su Microsoft Azure in preview.
Durante il webcast parliamo anche del progetto open su GitHub See4Me raggiungibile all’indirizzo https://github.com/DotNetToscana/See4Me
Ecco l’indirizzo del Podcast http://www.dotnetpodcast.com/show/card/119
Grazie a tutto lo staff di DotNetPodcast per l’opportunità!
Ho avuto l’onore di vedere pubblicato un mio blog post sul Blog del team di Microsoft MSDN Italia!
Lo scorso 26 Settembre ho avuto il piacere di partecipare alla WEC, Web European Software.
Una sessione per me molto interessante è stata quella di Vito Flavio Lorusso, Technical Evangelist @Microsoft, dal titolo “Video from newbie to ninja“, di cui potete trovare le slide a questo link e che ringrazio.
Da acerbo conoscitore degli Azure Media Services ho deciso di approfondire il talk e di crearmi un mio portale dove poter distribuire video.
Per illustrarvi le procedure ho deciso di semplificare molto lo scenario proposto durante il talk: non ho sviluppato la parte di upload del video ma l’ho demandata totalmente al tool Azure Media Service Explorer e ho creato una pagina HTML per distribuire il video caricato. Questo passaggio servirà per testare le qualità e le capacità della piattaforma Azure.
Vediamo quindi i passaggi che ho fatto:
Questo articolo è il continuo (scontato 🙂 ) del precedente articolo, ovvero Azure Automation – Spengiamo le nostre VM.
Potrebbe verificarsi infatti il caso che dobbiamo accendere autonomamente una VM o più VM, questo per attività schedulate o semplicemente per accendere prima una VM di sviluppo per far sì che il dev non perda tempo nella procedura di startup della VM.
Ho riproposto il link all’articolo precedente perché possiamo riprendere le fasi lì descritte fino alla creazione di un nuovo RunBook, che stavolta chiameremo Avvia-VM.
Lo script che propongo è questo:
workflow Avvia-VM { Param ( [parameter(Mandatory=$true)] [String] $VMName, [parameter(Mandatory=$true)] [String] $ServiceName ) $subscriptionName = Get-AutomationVariable -Name "SubscriptionName" $subscriptionID = Get-AutomationVariable -Name "SubscriptionID" $certificateName = Get-AutomationVariable -Name "CertificateName" $certificate = Get-AutomationCertificate -Name $certificateName Set-AzureSubscription -SubscriptionName $subscriptionName -SubscriptionId $subscriptionID -Certificate $certificate Select-AzureSubscription $subscriptionName $thisdow = ( get-date ).DayOfWeek.value__ if(($thisdow -gt 0) -and ($thisdow -lt 6) ) #only from monday to friday { $vm = Get-AzureVM -Name $VMName -ServiceName $ServiceName if($vm) { # Possible values are: Running, Suspended, RunningTransitioning, SuspendedTransitioning, Starting, Suspending, Deploying, Deleting Write-Output "VM " + $VMName + " InstanceStatus " + $vm.InstanceStatus if ( ($vm.InstanceStatus -eq 'StoppedVM') -or ($vm.InstanceStatus -eq 'StoppedDeallocated') ) { Write-Output "Startup VM " + $VMName Start-AzureVM -Name $VMName -ServiceName $ServiceName } } else { Write-Output "VM non trovata" } } }
Come potete notare, le differenze con l’articolo precedente sono:
Ora non mi resta che schedulare questo RunBook per ogni VM che voglio accendere, specificando quindi i parametri: Una volta pubblicato il RunBook, è necessario cliccare su “Pianifica”
e inserire i dati: Il nome della pianificazione, l’orario (ad esempio alle 08:00) di ogni giorno.
Visto che il nostro RunBook ha dei parametri (VmName e ServiceName), sarà possibile inserire i valori desiderati:
Da ora in poi il nostro RunBook sarà schedulato!
Se dalla finestra del RunBook cliccate su “Processi”, potrete vedere uno storico delle esecuzioni. Di ogni esecuzione potrete vedere l’esito (Stato) ed eventualmente l’output del processo.
Buon avvio delle VM da Azure Automation 🙂
Da qualche mese nell’azienda per quale lavoro, ovvero Vivido, abbiamo migrato tutti gli ambienti di sviluppo su Microsoft Azure.
L’Hybrid Cloud conta attualmente circa 30 VM con ambienti di sviluppo (SO Windows 8.1 o 10, Visual Studio 2015 o Eclipse a seconda dei linguaggi di sviluppo) e sono assegnate ai singoli dipendenti.
L’operatività iniziale è quella che, non appena arrivato in ufficio, ogni sviluppatore acceda al portale Portale Azure con le proprie credenziali, si avvii la VM che più gli interessa (un dev può avere anche una VM per ambiente di sviluppo) e si colleghi una volta avviato via RDP. Una volta terminato il lavoro la vm deve essere spenta e deallocata: visto che il cloud ha un costo in base alle ore di effettivo utilizzo delle componenti, se la VM viene spenta non ci sono costi (fatta eccezione per lo storage che la VM occupa).
Facendo un rapido calcolo, prendendo dal calcolatore prezzi di Microsoft Azure il costo di una VM A3 (Area Europa Occidentale, Tipo Windows, Piano Standard) per un mese è di circa 226€*.
Ti chiederai: Cosa hanno a che fare le lasagne con l’informatica?
E’ quello che mi son chiesto anche io anni fa, in terza superiore all’ITI Leonardo Da Vinci alla prima lezione di “Informatica”, materia che avevo in quel momento tanto agognato di studiare.
Il mio allora professore di laboratorio informatico, in un’aula piena di Intel 286, iniziò una breve introduzione a quel che ci aspettava e ci propose, come compito a casa, di scrivere un algoritmo su come si preparano le lasagne.
Algoritmo? Lasagne? E i PC quando s’accendono? Quando si impara a spippolare? Quando è che potrò sentire la musica della pressione dei tasti? Quando è che potrò vedere un prompt di Dos?