Archives For Operazioni Pianificate

C’è un vecchio ma sempre funzionante Windows 7 con Microsoft Office 365 ProPlus a bordo (quindi in versione 2016/2019 in base al ramo d’aggiornamento scelto, NdR) che dallo scorso agosto mostra di tanto in tanto un errore relativo a Microsoft Office SDX Helper, un processo che parte dall’applicazione sdxhelper.exe e che smette di funzionare rompendo le scatole all’utilizzatore che se lo ritrova davanti ripetutamente, con la sola possibilità di cercare una soluzione o chiudere quel messaggio.

Microsoft sdx helper stopped working

Microsoft Office SDX Helper

The Microsoft Office SDXHelper is connected to a secure download manager, which is used to download/update Microsoft Office (fonte). La verità è che per scaricare o aggiornare Microsoft Office basta e avanza il Click2Run e seppur questo non dovesse svegliarsi quando necessario, basterà andare manualmente nelle opzioni Account di una qualsiasi applicazione di Office installata su Windows per far partire il controllo degli aggiornamenti e scaricarli se presenti.

Il processo di SDX Helper ha cominciato ad andare in crash in seguito agli aggiornamenti di Windows 7 lo scorso agosto e – chi prima, chi dopo – una marea di utenti hanno cominciato a lamentare lo stesso identico problema di crash che si risolve esclusivamente riparando in maniera completa l’installazione di Microsoft Office (da Pannello di controllo). Nel caso in cui però tu non possa fare questa operazione nel momento in cui l’utente lamenta l’anomalia dovrai necessariamente metterci una pezza in attesa di definitiva risoluzione. Per farlo ti basterà bloccare due operazioni pianificate che Office crea autonomamente su Windows.

Due i comandi necessari da eseguire da Prompt e un invio, null’altro:

Attento però: entrambe le operazioni verranno riattivate da Microsoft Office quando questo si accorgerà che saranno disabilitate (fa un check di tanto in tanto), è per questo motivo che ti invito a salvare quelle due righe di codice poco sopra in un file batch (.bat) che potrai far eseguire alle operazioni pianificate di Windows ogni 6 ore. Se invece hai tempo e modo di intervenire subito sul problema ti basterà riparare completamente l’installazione di Microsoft Office (non la riparazione in locale rapida, ti servirà quella completa da far eseguire scaricando il necessario dai server Microsoft, quindi la online).

Buon lavoro 😉


Ringraziamenti vari:
social.technet.microsoft.com/Forums/office/en-US/742ac3af-c1dc-4c72-ae4c-46864fef3160/quotsdx-helper-stopped-workingquot-on-all-win7office365-clients?forum=Office2016ITPro
superuser.com/questions/1492414/microsoft-sdx-helper-stopped-working-with-office-365-and-windows-7
× Le pillole del Dr.Mario

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"!
Condividi l'articolo con i tuoi contatti:

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:

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

× Le pillole del Dr.Mario

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"!
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: