Archives For Operazioni Pianificate

Quando hai bisogno dell’Utilità di pianificazione di Windows e questa decide che non è d’accordo con il farsi utilizzare, hai un problema. Sì perché quell’utilità gestisce ogni attività che viene fatta partire in maniera autonoma dal sistema (processi impostati direttamente da Windows o da un prodotto di terza parte), e che non serve a nulla se non funziona. Mi sono accorto che il mio Task Scheduler aveva qualche problemino solo quando l’ho aperto per verificare perché un processo non fosse partito nell’ultima settimana:

Windows 10 e Task Scheduler danneggiato: come risolvere 1

Provando ad approfondire e leggendo quindi i dettagli dell’errore, la situazione non migliora affatto, tutt’altro:

Windows 10 e Task Scheduler danneggiato: come risolvere

È per questo motivo che ho deciso di informarmi sul web per capire se altri come me avessero avuto prima questo tipo di problemi. Ho trovato diverse lamentele e qualche possibile soluzione, ma solo una ha realmente risolto l’arcano e mi ha permesso di tornare in possesso della console delle operazioni programmate. La colpa era di un paio di voci che non sono riuscito a ricollegare ai relativi job (poco importa, se me ne accorgerò in futuro sarà mia cura rimetterli in piedi), e di una “CreateChoiceProcessTask” che mi ha portato sulla giusta via della risoluzione.

Il problema viene generalmente rilevato su Windows 8 e superiori, Windows 10 compreso. Mi è bastato gironzolare ancora un po’ per arrivare a un progetto di CodePlex chiamato Repair Tasks: repairtasks.codeplex.com. Piccola utility gratuita e immediatamente utilizzabile senza installazione, è stato un giusto toccasana che ho voluto salvare anche nel mio spazio su box.com in vista della chiusura di CodePlex, puoi trovarla quindi anche all’indirizzo app.box.com/s/yi1g04ccquyytov7fm0g3j27r8myr7tz.

Una volta lanciata, falle fare uno Scan dei tuoi processi e dei possibili problemi, probabilmente vedrai comparirne qualcuno come nel mio caso:

Windows 10 e Task Scheduler danneggiato: come risolvere 2

Nonostante esista la possibilità di selezionare e riparare gli errori, probabilmente questo non ti porterà all’uscita del tunnel e quindi alla risoluzione del problema. Non ti abbattere. Seleziona uno a uno i processi problematici e fai clic su “Unplug Task“. Questo permetterà a te di sganciarli dall’Utilità di pianificazione, e a Windows di darti nuovamente accesso completo alla console. Da qui potrai finalmente modificare i job schedulati e lanciarne di manuali per riprendere le attività precedentemente non andate a buon fine (perché mai partite!).

Cos’altro c’è da sapere

Che in caso di emergenza, il Registro di Windows può darti accesso alle tue schedulazioni navigando la chiave di registro:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\

e che se anche tu utilizzi SyncBack, dovrai dare un’occhiata a questo loro documento di Knowledge Base per riprendere completo possesso della situazione e delle tue pianificazioni (apparentemente non più gestibili o cancellabili).

Buon lavoro!

Condividi l'articolo con i tuoi contatti:

Prima dell’aggiornamento a Windows 10, avevo uno o due processi programmati che mi mostravano a video un semplice messaggio di testo, un promemoria in alcune giornate ben precise, a orario precedentemente stabilito. Con l’ultima versione del sistema operativo di casa Microsoft questo non è più possibile, non con la stessa immediatezza almeno, poiché tale funzione è stata deprecata.

Chiaramente esiste il modo di aggirare l’ostacolo, si può passare da PowerShell e da fondamenti di Visual Basic. Un risultato esteticamente molto meno accattivante,ma che ti permette di portare a casa ciò che prima avevi.

Windows 10 e i messaggi "Deprecati" del Task Scheduler, come risolvere

Per poter aprire una finestra contenente il messaggio “promemoria“, il codice PowerShell è il seguente:

I due parametri che il file PS1 si aspetta serviranno a specificare il titolo della finestra e il contenuto del messaggio che comparirà a video. Il tutto è chiaramente fattibile anche con un file VBScript, se lo preferisci. Se vuoi scaricare il file PS1 riportato sopra fai clic con il tasto destro sulla voce view raw (in basso a destra nel box) e scegli di salvare la destinazione con nome. Io ho adottato questa soluzione che in realtà nasce da un thread nel forum di WindowsSecrets.

Cerca l’attività nelle operazioni pianificate di Windows, modificala e vai a togliere l’azione (quella che mostrava il messaggio), anche perché provando a riattivarla o modificarla otterrai un errore a video:

A questo punto dovrai avviare un programma, dargli in pasto l’eseguibile di PowerShell (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe) e specificare un argomento unico che vada a pescare il file PS1 precedentemente salvato, passando a quest’ultimo il titolo e il messaggio da mostrare a video, per esempio:

Windows 10 e i messaggi "Deprecati" del Task Scheduler, come risolvere 3

Nel mio caso, la riga dell’argomento contiene:

C:\Documenti\Script\ShowReminder.ps1 -MsgTitle 'Reminder' -MsgText 'Ciao, ricordati di fare il report'

dove il parametro MsgTitle corrisponde (ovviamente) al titolo del popup che ti comparirà a video, e MsgText il contenuto del corpo, il messaggio vero e proprio. Salva quanto modificato. Se serve, modifica ora e giorno di esecuzione, quindi salva tutto quanto per evitare di perdere quanto fatto fino a ora.

Lancia manualmente l’operazione schedulata per verificare che tutto funzioni regolarmente, salvo errori sei a posto e hai trovato il giusto escamotage per risolvere il tuo problema.

Cheers.

 

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:

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:

Che nulla ha a che fare con il titolo realizzato da Ubisoft ma che comunque “fa brodo“. Lo scenario è sicuramente fuori dal normale ma non improbabile da trovare in giro. Una postazione collegata in WiFi un po’ distante dal router perde di tanto in tanto la connessione (va in hang o addirittura non si ricollega in automatico nonostante le impostazioni corrette in Windows), le cause sono disparate (no, non c’entra la copertura di rete), basta semplicemente riavviare la scheda WiFi per veder ripartire tutto. Sapete che è possibile farlo tramite batch? Il funzionamento è estremamente semplice, qui di seguito il passo-passo.

WatchDog: tenere d'occhio e resettare (quando serve) la propria connessione 1

Prima di partire occorre conoscere il nome assegnato alla propria scheda di rete, quello che tipicamente è impostato a “Connessione alla rete locale (LAN)” in Windows e che nell’immagine qui di seguito io ho rinominato per comodità “eth0” (collegamento con cavo) e “WiFi0” (collegamento wireless):

WatchDog: tenere d'occhio e resettare (quando serve) la propria connessione 2

Lo script pensato e realizzato non fa altro che appoggiarsi ad una delle interfacce di rete da voi stabilita, lanciare un semplice ping (ho scelto il DNS primario di Google viste le rapidissime risposte che questo fornisce) e, nel caso in cui la destinazione non risponda, disattivare e riattivare dopo qualche secondo la scheda di rete, il tutto tenendo traccia delle operazioni eseguite in un piccolo file di log che potrete poi in seguito andare a consultare. Quest’ultimo viene sovrascritto ogni volta che lo script parte così da non crescere a dismisura (considerando che nel mio caso lo script viene eseguito una volta ogni 2 minuti!).

Inutile dire che se la destinazione è raggiungibile lo script lascia tutto com’è e niente verrà riavviato.

Tradotto in codice batch, questo è il risultato (in coda vi spiego qualche dettaglio in più):

@echo off
cls
set INTERFACCIA="wifi0"
set TIMEOUT=10
set IP=8.8.8.8
set LOG="blackhole.log"

echo Arf Arf!

echo %DATE% %TIME:~0,8%: Verifica connessione
echo Interfacce registrate sulla macchina
netsh interface show interface

echo %DATE% %TIME:~0,8%: Verifica connessione > %LOG%
echo Interfacce registrate sulla macchina >> %LOG%
netsh interface show interface >> %LOG%

:Verify
REM Tentativo di connessione a Google (IP), in caso di errore riavvio la scheda di rete.
ping -n %TIMEOUT% -w 1000 -l 0 %IP%
if %errorlevel% EQU 0 goto :OutOfThere

:rebootConnection
echo %DATE% %TIME:~0,8%: Connessione fallita. Tento il riavvio della scheda %INTERFACCIA% ..
echo %DATE% %TIME:~0,8%: Connessione fallita. Tento il riavvio della scheda %INTERFACCIA% .. >> %LOG%
netsh interface set interface %INTERFACCIA% disable
netsh interface set interface %INTERFACCIA% enable

echo %DATE% %TIME:~0,8%~: Ritento connessione, attendere ..
echo %DATE% %TIME:~0,8%: Ritento connessione, attendere .. >> %LOG%
goto Verify

:OutOfThere
echo;
echo %DATE% %TIME:~0,8%: Ultima connessione riuscita.
echo %DATE% %TIME:~0,8%: Ultima connessione riuscita. >> %LOG%
echo; >> %LOG%

:VerifyTViewer
echo;
sc query "TeamViewer" | findstr /I "RUNNING"
if %errorlevel% NEQ 0 sc start "TeamViewer"

Vi prego di stendere un velo di comprensione sull’ “Arf Arf” che fa molto cagnolino all’ingresso, ogni tanto gli porto anche il biscottino per ringraziarlo. Ora però diamo un’occhiata a quello che c’è da sapere:

  • INTERFACCIA: è la scheda di rete da riavviare nel caso in cui il ping non vada a buon fine, occhio al nome, dovete riportare quello esatto, tenerlo tra le virgolette e copiare eventuali parentesi tonde e simili.
  • TIMEOUT: il numero di ping da tentare prima di dichiarare sconfitta e riavviare la scheda di rete, nel mio caso (lo stesso che consiglio a voi) è impostato su 10.
  • IP: l’IP di destinazione da pingare. Come già detto qualche riga più sopra ho voluto utilizzare il DNS primario di Google, voi potete cambiarlo e scegliere altro, in base a preferenza / esigenza.
  • LOG: il file dove andare a scrivere ciò che accade.

Il resto dello script non va toccato, va già bene così. Bisognerà solo fare in modo che questo si attivi in automatico, argomento del prossimo paragrafo.

Al termine dello script c’è un’ulteriore query per verificare che TeamViewer sia attivato perché è lo strumento di controllo remoto installato sul PC. Nel caso in cui non lo fosse, lo script provvederà all’avvio (o almeno ci proverà, salvo errori del programma che sono da analizzare in un secondo momento).

Avvio automatico dello script

Passaggio che possiamo portare a termine tramite il solito Scheduler di Windows. Start / Esegui / “control schedtasks” (seguito da invio, ndr) ed eccoci in console pronti per creare una nuova operazione “di base”. Io ho programmato l’avvio di un programma (il file batch, ovviamente) ogni 2 minuti, ogni giorno, vita natural durante. Il tutto eseguito indipendentemente dalla connessione dell’utente al sistema ma soprattutto con privilegi elevati (quindi amministrativi, con password salvata nello scheduler, altrimenti non potrà mai partire correttamente):

WatchDog: tenere d'occhio e resettare (quando serve) la propria connessione 3

WatchDog: tenere d'occhio e resettare (quando serve) la propria connessione 4

WatchDog: tenere d'occhio e resettare (quando serve) la propria connessione 5

Salvo errori lo script farà il suo lavoro, la postazione sarà in grado autonomamente di riavviare la sua connessione verso il router così da rendersi raggiungibile anche in caso di problemi (risolvibili in questa maniera, ovviamente, tutto ciò esula manco a dirlo dal fatto che la connettività non dia problema alcuno verso internet o il router non faccia scherzi).

Condividi l'articolo con i tuoi contatti: