Archives For Scheduled Tasks

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!

Lenovo Service Bridge è un piccolo software scritto in Microsoft .NET, aiuta l’utente a scaricare contemporaneamente più driver precedentemente selezionati dal sito web ufficiale di Lenovo. È abbastanza comodo anche se ricco di pecche, una tra tutte l’impossibilità di verificare l’avanzamento del download dei dati richiesti, ma anche il fatto che rimanga attivo anche quando non richiesto (viene richiamato a ogni avvio del sistema). Se lo si disinstalla, può capitare di ritrovarsi un errore a ogni successivo avvio di Windows, questo:

L'errore di Lenovo Service Bridge a ogni avvio di Windows

In maniera del tutto logica, sono andato a controllare il registro di sistema per verificare se ci fosse il processo tra le voci in avvio automatico (HKLM\Software\Microsoft\Windows\CurrentVersion\Run e HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce, ma anche le equivalenti sotto HKCU), ma nulla da fare. Ho dato un’occhiata alla più vecchia cartella “Esecuzione automatica” di Windows, ma l’esito è rimasto invariato. Ho trovato poi la soluzione (effettivamente banale, ma non ci avevo pensato su due piedi) sul forum ufficiale di Lenovo, il colpevole si trova nel task scheduler di sistema.

Da StartEsegui (o l’equivalente tasto Windows + R su Windows 10), scrivi control schedtasks e premi invio. Nel pannello appena comparso troverai una cartella Lenovo (sulla sinistra), la quale conterrà un’ulteriore cartella chiamata Lenovo Service Bridge. Fai un clic con il tasto destro sull’unica attività che contiene (quella nel box di destra) e seleziona Eliminazione. A questo punto fai un ulteriore clic con il tasto destro sull’intera cartella Lenovo Service Bridge e scegli Elimina cartella.

L'errore di Lenovo Service Bridge a ogni avvio di Windows 1

Ora non dovresti più avere problemi al successivo avvio del sistema.

fonte: forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/Uninstall-Lenovo-Service-Bridge-on-my-T420/m-p/2175307#M102859

Condividi l'articolo con i tuoi contatti:

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!

Non so se si può parlare di una vera e propria nuova versione. Cambia poco rispetto alla precedente, ma stavolta si può scegliere di controllare lo stato di lock out di un utente direttamente proponendolo da riga di comando, così da poter utilizzare lo stesso identico script e clonare facilmente l’operazione pianificata, così da monitorare contemporaneamente più utenti.

Powershell: LockoutAD.ps1, utente a riga di comando

Cosa cambia quindi rispetto al precedente articolo? Presto detto:

#-----------------------------------------------#
#   ACCOUNT DA MONITORARE:                      #
    Param( 
        [Parameter(Position=0, Mandatory=$false, ValueFromPipeline=$true)] 
        [string] $AccountMonitor
    )
#-----------------------------------------------#

Questo, al posto del precedente $AccountMonitor = 'ACCOUNT_AD', permetterà di richiamare lo script in maniera tale da passargli l’account direttamente dal prompt della PowerShell: .\LockoutAD.ps1 ACCOUNT_AD

Chiaramente, per evitare che ci si dimentichi di specificare l’utente, basterà specificare un valore di default che lo script adotterà nel caso in cui non ci siano parametri, qualcosa del tipo:

 if ([string]::IsNullOrEmpty($AccountMonitor)) { $AccountMonitor = 'ACCOUNT_AD' }

così da tutelare una corretta esecuzione del codice. Questa istruzione andrebbe messa chiaramente dopo il catch del parametro da riga di comando, ma prima di lasciar fare la ricerca dell’evento 4771 (o 4740, in base a ciò che si desidera monitorare).

Tutto il resto può rimanere invariato. Se si intende fare un test di funzionamento senza allertare troppi indirizzi di posta elettronica, si potrà clonare la riga del Send-MailMessage assicurandosi di essere unici destinatari (commentando quella che include quindi eventuali CC o BCC), per poi tornare alla normalità quando si è sicuri che tutto fili liscio.

Magari, in una prossima pillola, ti mostrerò come arricchire ulteriormente lo script, prevedendo uno sblocco automatico dell’utenza di dominio bloccata, così che tu possa analizzare con un attimo più di calma cosa è accaduto e nel frattempo l’utente non si accorga di nulla (o quasi).

A proposito di EventLog e PowerShell

Ho modificato il comportamento dello script perché ho avuto la necessità di clonare l’operazione schedulata sul server di dominio così da tenere d’occhio un differente utente. Per poter approfondire il motivo dei lock di quest’ultimo, ho utilizzato PowerShell per filtrare più rapidamente il log degli eventi di sicurezza, generalmente molto nutrito e che mette un attimo in difficoltà la GUI accessibile tramite Visualizzatore degli Eventi. Per questo motivo ho cercato informazioni in merito e trovato alcuni interessanti spunti su serverfault.com/questions/584309/powershell-and-using-get-eventlog.

Nello specifico, ho filtrato direttamente gli eventi 4740 e 4771 protagonisti dello script, includendo inoltre lo specifico nome utente problematico, tramite una semplice query di questo tipo:

Get-EventLog Security 4771,4740

Che, per filtrare esclusivamente un utente, diventerà:

Get-EventLog Security 4740,4771 -after ((get-date).addDays(-1)) | Where-Object {$_.message -match "NOMEUTENTE"}

Permettendoti così di ottenere a video uno storico completo dell’attività dell’utente specifico, anche quando si tratta di tentativi di accesso molto vecchi (dipende poi dalla quantità di log che tiene il server secondo impostazioni del suo amministratore), ignorando quindi il mio -Newest 1 che nello script permette di prendere in esame solo l’ultimo dei tentativi errati (quello in realtà relativo al blocco dell’account in LDAP).

Buon lavoro!

immagine featured: PowerShell Magazine

Condividi l'articolo con i tuoi contatti:

Avere un server WSUS in azienda aiuta gli amministratori a risparmiare principalmente preziosa banda, e gestire al meglio il rilascio degli aggiornamenti sui client all’interno della stessa rete, fare report, ritirare un fix (KB) in caso di un errore Microsoft (già successo in passato, ogni tanto può capitare). Una mano santa e bla, bla, bla. Ora che il cappello è stato scritto e abbiamo saltato i convenevoli, possiamo parlare del succo della questione e di questo articolo, si parla di pulizia (del WSUS), semplice manutenzione ordinaria! ;-)

WSUS: schedulare la pulizia ordinaria (PowerShell)

Si parte dal presupposto che l’operazione permessa dal software Microsoft vada già più che bene. Sto parlando di quella che puoi lanciare manualmente dalla console andando in OptionsServer Cleanup Wizard. In base alle risorse messe a disposizione della tua macchina WSUS, tale operazione potrebbe non essere necessaria per mesi, per poi diventare la tua migliore amica quando ti ritroverai con il disco dati (dedicato alle patch del WSUS) arrivato ormai a tappo.

Un documento di Technet viene in aiuto del malcapitato di turno, suggerendo un intervento via PowerShell, alla quale ci si può affidare per risparmiare tempo e imprecazioni. Il comando è quello di Invoke-WsusServerCleanup, descritto qui. L’unico pre-requisito è quello di andare a sbloccare l’esecuzione di script non firmati, realizzati tipicamente da te (o da me), cosa alla quale sei abituato sul tuo portatile di lavoro per gestire Exchange in Cloud, un po’ meno forse sul server 2012 R2 dove gira WSUS. Apri quindi PowerShell ed esegui:

Set-ExecutionPolicy Unrestricted

Una volta confermato, sei pronto per salvare il seguente codice in un file PS1 che dovrai poi caricare in una cartella del tuo server:

$logfile="C:\Scripts\WSUS-Cleanup-Log.log"

$ErrorActionPreference="SilentlyContinue"
Stop-Transcript | out-null
$ErrorActionPreference = "Continue"
Start-Transcript -path $logfile
$Error.Clear()

Write-Output "$((get-date).ToLongTimeString()) $server - WSUS Cleanup starting..."
Invoke-WsusServerCleanup -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates
Write-Output "$((get-date).ToLongTimeString()) $server - WSUS Cleanup complete."

Stop-Transcript
$emailbody = Get-Content $logfile | Out-String
$emailsubject = "WSUS cleanup report on $Env:ComputerName"
if ($error -ne $null){ $emailsubject = "WSUS cleanup report ERROR on $Env:ComputerName"}

Send-MailMessage `
    -From "Script WSUS-Clean <wsus@domain.tld>" `
    -To "Gruppo Alert WSUS <wsusalert@domain.tld>"`
    -Subject "$emailsubject" `
    -Body "$emailbody" `
    -SmtpServer "smtp.domain.tld"
    
# Examples:
#  -From "$env:COMPUTERNAME-alert@domain.tld" `
#  -To "Gruppo Alert WSUS <wsusalert@emmelibri.it>", "Altro Admin <altroadmin@domain.tld>"`

Non si tratta di farina del mio sacco, mi sono limitato a modificare lo script proposto sul blog di “BrianCanFixIT“, un lavoro assolutamente perfetto per l’esigenza, che aggiunge qualche piccolo dettaglio molto comodo alla già comune e conosciuta stringa relativa all’Invoke-WsusServerCleanup.

Ti basterà ritoccare le informazioni che riguardano il server SMTP (per l’invio dei log dell’operazione) e -se vuoi- modificare le operazioni eseguite da PowerShell, quindi salvare lo script e preparare un’operazione schedulata che lo lancerà una volta a settimana, o al mese se preferisci, lo scopo del gioco è quello di tenere un server WSUS in forma, funzionante e pulito da file non più utili che occupano inutilmente spazio su disco.

Se non sai come fare, ti rimando a una semplice guida pubblicata su SpiceWorks: community.spiceworks.com/how_to/17736-run-powershell-scripts-from-task-scheduler. Ti riepilogo cosa c’è da sapere (quindi fare sul tuo server):

  • Crea una nuova operazione semplice, una di quelle che esegue un programma.
  • Ricorda di specificare l’intervallo di esecuzione dell’operazione (settimanale, scegli il giorno e l’ora).
  • Il programma sarà Powershell.exe (il sistema sa già dove andarlo a trovare), negli Arguments dovrai specificare la posizione dello script e -per mera sicurezza- il bypass della policy di esecuzione script di PowerShell, ottenendo quindi qualcosa di simile a -ExecutionPolicy Bypass C:\Script\WSUSClean.ps1 (partendo dal presupposto che WSUSClean.ps1 sia il tuo script PowerShell contenente il codice sopra pubblicato e che tu lo abbia salvato in C:\Script).
  • Lo script da utilizzare questa volta, non prevede parametri, non è necessario quindi specificare null’altro e ti basterà completare la configurazione e ricordarti di aprire le opzioni dell’operazione schedulata al termine. Una volta fatto, modifica il tipo di privilegio di esecuzione specificando che si tratta di un’operazione da eseguire a prescindere che qualcuno sia collegato alla macchina e che servono privilegi elevati.

Ti verrà richiesto di inserire la password dell’account amministrativo che lancerà l’operazione, e se non avrai commesso alcun errore tutto filerà liscio già alla prima occasione. Se vuoi puoi forzare l’esecuzione dell’operazione per assicurarti che tutto vada bene, al termine dovresti ricevere una mail contenente il log delle operazioni.

Enjoy.

La pulizia passa anche per SQL

Update

Aprile 2017: Si è reso necessario aggiornare l’articolo perché, in effetti, avevo lasciato in disparte il database del WSUS, cosa che in realtà è meglio non fare per evitare di lasciare sporco le tabelle utilizzate dal software, andando così a occupare dello spazio inutile che può essere recuperato ogni volta che si lascia intervenire lo script di PowerShell. Ecco quindi come fondere le due cose insieme con un ulteriore script (stavolta di SQL) e una piccola modifica al PowerShell (che ne permetterà l’integrazione).

Si perché in realtà, dopo aver messo in moto e lasciato a lavorare lo script di PowerShell per il clean delle patch non più utili, ci si accorge che nel database si vanno a lasciare delle voci anch’esse non più utili, orfane di ciò che non esiste più. Per portare a termine un lavoro più completo, ti basterà salvare questo script nella stessa cartella dove risiede l’altro di PowerShell:

Update

Maggio 2017: Nuovo giro, nuovo aggiornamento. Per evitare possibili problemi, ho modificato lo script SQL forzandolo a puntare al database SUSDB, utilizzato per contenere i dati di WSUS. Grazie a Daniel per avermi segnalato la modifica, utile per chi non ha quell’unico database sulla macchina 2012 R2 destinata a fare da servizio WSUS.

A questo punto, modifica lo script PowerShell che già avevi messo in funzione e inserisci la stringa:

sqlcmd -i C:\Scripts\db_maint.sql -S \\.\pipe\MICROSOFT##WID\tsql\query

prima dello Stop-Transcript. Occhio però: modifica la cartella dove pescare lo script se nel tuo caso è differente (cambia quindi C:\Scripts in qualcosa che riflette l’attuale posizionamento del file sul tuo server!). A questo punto PowerShell si occuperà di fare pulizia delle patch e del database di WSUS, in un colpo solo. Tu riceverai il solito log delle operazioni che ora conterrà anche le informazioni di pulizia del database :-)

Condividi l'articolo con i tuoi contatti:

Powershell_512px-GWallFaccio riferimento a un vecchio articolo datato 2014, nel quale vi parlavo di uno script PS1 che avevo lasciato su un Domain Controller della rete per verificare l’utilizzo di una password errata per un determinato account di dominio. Quello script mi è tornato utile ancora una volta e oggi vi propongo il suo ultimo aggiornamento, in grado di monitorare il blocco dell’account di Active Directory, con conseguente mail di allerta a 3 diversi indirizzi di posta (mio e di due colleghi, in CC).

L’originale è ancora disponibile:

Powershell: Account di dominio bloccato o utilizzo di password errata? Mandami una mail con l’evento!

Cosa è cambiato?

L’ID dell’evento sotto monitor, come prima cosa: si tratta del 4740 e l’operazione pianificata si crea ancora alla stessa identica maniera, con l’eccezione del richiamo al prompt di PowerShell che ora utilizzo in maniera classica, passandogli poi parametri da riga di comando che vanno a richiamare il nuovo script:

Nel nuovo script è poi cambiato il testo della segnalazione che arriverà a mezzo mail, la parte commentata (per darle un aspetto migliore, nulla più) e il modo di inviare la mail ai destinatari, che mi permette così di utilizzare anche il -CC e la priorità (-Priority). Già messo alla prova, non fallisce un colpo, permettendo di diventare assolutamente reattivi nei confronti del monitorato “ACCOUNT_AD” (da modificare con l’utente che volete realmente tenere sotto controllo).

Come già detto, l’operazione pianificata sul server riguarderà l’evento 4740, il quale lancerà PowerShell passandogli come parametro lo script che nel frattempo avrete salvato in una cartella sul server (nel mio caso, C:\Script):

Ricordate che, in tutto questo, sarà necessario che la macchina sulla quale farete girare il file PS1 abbia la policy di esecuzione script non firmati, basterà lanciare (da PowerShell):

Set-ExecutionPolicy Unrestricted

e confermare la scelta quando vi verrà chiesto a video.

Con una ulteriore modifica, si potrebbe chiedere allo script di sbloccarlo automaticamente dopo un certo intervallo di tempo. Non l’ho volutamente ancora sviluppato perché non è la richiesta ricevuta, ma nessuno impedisce a voi di completare il quadro (e poi magari toccherà anche a me, probabilmente vi basterà attendere) :-)

Condividi l'articolo con i tuoi contatti:

Powershell_512px-GWallMagari non ve ne frega nulla ma io intanto prendo “appunti pubblici” (quelli che tra qualche tempo mi toccherà venire a rileggere per ripetere il trucco su una diversa macchina) :-) Vi è mai capitato di avere a che fare con account di dominio creati per puro servizio? Quegli account che stanno in piedi per tenere viva una macchina, un processo, qualcosa di assolutamente limitato per il quale non sprecare certo il vostro account o un amministratore di dominio. A me si: una banale copia (robocopy) da eseguire con un’utenza specifica autorizzata a leggere / scrivere su due domini differenti.

Fino ad oggi ho utilizzato (e vi ho spiegato un po’) la PowerShell per utilizzare al meglio il servizio Office 365 e l’amministrazione di Exchange Online ma questa in realtà può essere utilizzata (ovviamente) per fare molto altro, compreso il monitoraggio di un account utente che nel caso in cui si blocchi per troppi tentativi di password (o altro motivo non meglio specificato) può tempestivamente avvisarmi tramite mail al mio account di posta aziendale.

È un trucco relativamente semplice che si ottiene con due mosse: un’apposita operazione schedulata che parte quando viene rilevato un codice evento preciso di sistema e uno script PowerShell che ne raccoglie le informazioni e le invia (come già detto) tramite posta elettronica appoggiandosi ad un SMTP interno che non richiede autenticazione. Questo lo script che ho pubblicato su Gist:

L’operazione schedulata viene eseguita ogni volta che nel sistema si genera un errore 4771 (autenticazione non andata a buon fine) e viene chiaramente demandata ad uno dei domain controller (uno qualsiasi) del dominio dove ho creato l’utenza da tenere sotto monitor:

Operazione schedulata su evento 4771

Se quell’evento viene tracciato dall’event viewer (Visualizzatore Eventi, nei Windows in italiano) partirà allora il mio script in PowerShell (richiamando il programma PowerShell.exe e passandogli come parametro la posizione del file LockoutAD.ps1 che sarà stato precedentemente salvato sul sistema):

Operazione schedulata - Powershell

Il parametro passato completo (non visibile in immagine) è un semplice -nologo -File “C:\Scripts\LockoutAD.ps1” (completo di virgolette, occhio) dove chiaramente quel C:\Scripts andrà sostituito con la reale posizione all’interno della vostra macchina / server. L’operazione andrà eseguita con privilegi elevati (si modifica il tutto dalla scheda General dell’operazione schedulata, ndr) anche nel caso in cui non ci sia nessuno collegato sulla macchina.

Il lavoro è terminato. Potete verificarne la validità e la corretta messa in produzione sbagliando volutamente la password dell’utente tenuto sotto monitor, lanciando un prompt dei comandi di test o semplicemente provando a fare login su qualsiasi macchina in dominio. Ringrazio entrambe le fonti dalle quali è partito tutto: blogs.technet.com/b/heyscriptingguy/archive/2009/04/07/how-can-i-query-event-logs-to-discover-active-directory-information.aspx e community.spiceworks.com/how_to/show/11824-email-account-lock-out-notification.

Condividi l'articolo con i tuoi contatti: