Tag Archive - Windows

PowerPoint è diventato instabile? Colpa della vostra presentazione.

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

Mi sono dimenticato di conservare uno screenshot del problema sul PC dell’utente che lo ha lamentato ma di certo non potrete fare a meno di sorridere quando PowerPoint vi chiederà di salvare il vostro lavoro perché in pericolo a causa di instabilità del programma stesso, manco fosse un anziano signore con problemi di deambulazione (e questo no, non fa solitamente sorridere perché sia chiaro).

In realtà l’anomalia c’è sul serio e nasce dalla vostra presentazione all’interno della quale ci sono probabilmente elementi che mettono in difficoltà il programma di Microsoft. Magari caricamenti di dati da più fonti all’interno della rete casalinga o aziendale o chissà cosa.

Si risolve facilmente. Basterà infatti lanciare PowerPoint in modalità provvisoria (vi basterà tenere premuto il CTRL sulla tastiera mentre si fa doppio clic sull’icona di PowerPoint per lanciarlo da Desktop o singolo clic nel caso in si voglia utilizzare la voce nel menu di Start) e ricopiare i contenuti della presentazione originale all’interno di un nuovo progetto, come suggerito nel forum di Microsoft: social.technet.microsoft.com/Forums/office/en-US/93cef5fc-7cf6-449b-b570-1af0afd72121/unstable-error-?forum=officeitpro

Quel particolare nella frase di risoluzione “Some of our customers solve the issue by deleting and Excel inserted pie chart. Just check if it helps you.” è maledettamente veritiero, anche nel caso del mio utente la colpa era di alcuni elementi che venivano caricati da fogli Excel sulla rete aziendale. Una volta copiati e incollati come immagini il problema non si è più ripresentato.

Modifica in bulk di collegamenti a cartelle di rete (Batch e VBScript)

Uno di quei lavori che se doveste fare a mano per ciascun client dell’azienda vi ritrovereste ad andare in pensione prima di aver terminato l’intervento. Dato un numero non meglio definito di collegamenti a cartelle di rete tipicamente salvati sul Desktop utente, occorrerà modificare il puntamento da $vecchioserver a $nuovoserver. Un lavoro banale se fatto a mano da ciascun utente ma spesso -sfortunatamente- chiedere queste cose all’utente finale è un po’ come spostare una montagna a mani nude.

Ho cercato online qualcosa dalla quale partire e ho trovato ancora una volta una via di fuga tramite VBScript, pressoché perfetta per questo caso. Il codice VBS originale è di Rob Dunn (sei un santo, ragazzo, un vero santo) e lo trovate all’indirizzo community.spiceworks.com/scripts/show/298-change-shortcut-lnk-target-paths-in-bulk. Io l’ho leggermente modificato per accettare dei parametri dall’esterno (così sarà facilmente richiamabile da file batch, nel mio specifico caso al logon di un utente al dominio). Ne ho forzato la modalità “silent” per evitare che chieda qualsiasi cosa all’utente (e ho anche rimosso le parti di codice che se ne occupano nello script originale, ndr) ed evitare in ultimo che venga mostrato il log delle operazioni che rimarrà comunque disponibile sul client in %TEMP%\BulkShortcut.htm.

Ho caricato lo script modificato e i richiami in batch su Github e trovate il tutto qui: gist.github.com/gioxx/11403345.

Giusto per capirci: una volta caricato il VBS su un server accessibile per i vostri utenti vi basterà richiamarlo tramite una semplice riga nel netlogon:


cscript \\%USERDNSDOMAIN%\netlogon\scripts\BulkShortcut.vbs //B "\\SERVER1\" "\\SERVER3\shared\"

Questo permetterà al VBScript di prendere tutti i collegamenti sul Desktop analizzandoli e cercando quelli che puntano attualmente su SERVER1 per modificarli e farli puntare a SERVER3. Occhio, il VBScript potrebbe accettare un terzo parametro. Dopo cosa cercare e come modificarlo potreste specificare anche la directory all’interno della quale fare il lavoro, nel caso in cui non sia il Desktop la vostra casa base. Potreste quindi lanciare un ipotetico:


cscript \\%USERDNSDOMAIN%\netlogon\scripts\BulkShortcut.vbs //B "\\SERVER1\" "\\SERVER3\shared\" "C:\Temp"

Che forzerà così l’operazione in C:\Temp contrariamente a quanto stabilito di default all’interno del codice.

Il lavoro è molto rapido e completamente invisibile agli occhi dell’utente che potrà quindi fare clic sulle icone che ha lasciato l’ultima volta sul suo Desktop senza accorgersi che queste puntano altrove.

Office 365: impostare il Never Expire sulle password utenti

E’ sicuramente una pratica poco consigliata e molto poco sicura ma sfortunatamente dipende dalle esigenze e dalla capacità delle persone dell’azienda. Potreste dover andare incontro alla richiesta di modificare la scadenza password di ciascun utente creato in Office 365, farlo da GUI è da escludere a priori (non è fattibile se ho ben visto dalle opzioni a disposizioni ma soprattutto replicate voi la stessa azione a mano per centinaia di utenti), va usata la Powershell e basta un semplice script per applicare la modifica a ciascun account, variando il parametro –PasswordNeverExpires a “$True”.

Una volta connessi alla propria “console” potrete lanciare il comando chiedendo però la selezione di tutti gli utenti registrati (dovrete aiutarvi con il pipe, sempre utile per incastrare un’istruzione dopo l’altra):

Get-MsolUser -All | Set-MsolUser –PasswordNeverExpires $True

Più utenti avrete, più questo comando richiederà minuti di elaborazione. Con il verbose attivo noterete una trafila di account processati che perderanno così la loro scadenza password:

Lo script inserito all’interno del mio toolbox è un pelo più complesso e permette di verificare lo stato della variabile sugli account o esportare il tutto su file CSV / HTML / ecc. Lo trovate nel Wiki all’indirizzo public.gfsolone.com/wiki/doku.php?id=o365:passwdneverexpire.

Adobe Flash Player: aggiornamento in batch della versione 13

Flash Player (AdobeUpdater)Nuovo giro di aggiornamenti per Adobe che da qualche tempo ha cominciato la distribuzione della versione 13 di Flash sia ActiveX che plugin per altri browser.Ho quindi provveduto ad aggiornare il codice del tool e caricare online la nuova versione del Flash Player Updater. Scusate per il ritardo ma mille altri impegni ne hanno rallentato l’uscita ;-)

Non è cambiato nulla rispetto all’ultima volta, tranne che -ovviamente- il “13” all’interno degli URL che richiamano gli ultimi pacchetti di installazione per Internet Explorer e per gli altri browser in circolazione. Rimane quindi valida la discussione del forum Adobe dove si parlava dell’argomento: forums.adobe.com/message/3967370 e questo è il codice aggiornato:


wget http://download.macromedia.com/get/flashplayer/current/licensing/win/install_flash_player_13_active_x.exe
wget http://download.macromedia.com/get/flashplayer/current/licensing/win/install_flash_player_13_plugin.exe
start "Installazione Flash Player ActiveX" /wait install_flash_player_13_active_x.exe -install
start "Installazione Flash Player Plugin" /wait install_flash_player_13_plugin.exe -install
del /S /Q install_flash_player_13_active_x.exe
del /S /Q install_flash_player_13_plugin.exe

Lo stesso codice è disponibile come al solito nel Wiki all’indirizzo public.gfsolone.com/wiki/doku.php?id=batch:flashupdater. Il batch fa parte di un pacchetto eseguibile unico che contiene al suo interno anche il wget.exe. Lanciandolo come amministratore farà tutto automaticamente assicurandosi di forzare la chiusura di eventuali browser rimasti aperti (il controllo viene effettuato per Internet Explorer, Firefox, Opera e Chrome).

Voi come sempre potrete scaricare il pacchetto eseguibile di aggiornamento direttamente dall’URL:

app.box.com/s/5f24bphcc3fqw82rscr8

Buon lavoro :-)

PowerShell: connettersi con utente e password già stabiliti

Lo so che vi ho già spiegato come ci si connette alla PowerShell, ma è anche vero che farlo spesso nell’arco di una giornata lavorativa potrebbe seriamente mettere alla prova la pazienza del dover inserire ogni volta la propria password, nello script suggerito infatti vi ho detto che basta mettere un “-credential mario.rossi@dominio.tld” per mostrare il popup dove inserire solo la password, e se si automatizzasse anche questa operazione saltando direttamente nella console comandi?

Fattibile, tramite un file testuale che contiene la nostra password ovviamente criptata precedentemente. L’operazione è semplice e subito dopo vi basterà modificare lo script originale suggerito nel mio precedente articolo a riguardo per poter immediatamente lavorare in PowerShell sul vostro Exchange, ecco come fare.

Criptazione della password

La prima operazione da eseguire è salvare la vostra password criptata all’interno di un file testuale che terrete poi nel disco fisso della vostra macchina (o dove preferite) così da farlo raggiungere facilmente dallo script ps1 di collegamento. Per farlo aprite PowerShell e digitate il comando:

$credential = Get-Credential -credential mario.rossi@dominio.tld
$credential.Password | ConvertFrom-SecureString | Set-Content c:\pshell\password.txt

Manco a dirlo dovrete cambiare quel “mario.rossi@dominio.tld” con un account amministratore dell’Exchange e quel C:\pshell\ecc. con una cartella realmente esistente dove salvare il file “password.txt” che potrà poi essere utilizzato in seguito.

Modifica dello script di collegamento

A questo punto bisognerà dire allo script di collegamento di utilizzare un utente preciso e la password nel file appena salvato. Ecco il risultato ritoccato:

$User = "mario.rossi@dominio.tld"
$PWord = Get-Content C:\pshell\password.txt | ConvertTo-SecureString
$Credential = New-Object –TypeName System.Management.Automation.PSCredential –ArgumentList $User, $PWord
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $Credential -Authentication Basic -AllowRedirection
Import-PSSession $Session

Dovrete toccare solo due variabili, ancora una volta si tratta dell’account amministrativo (veri variabile $User) e la posizione del file con la password (vedi $PWord). Eseguendo lo script da PowerShell, a meno di errori, questo si autenticherà immediatamente alla vostra console senza alcun intervento da parte vostra. Potrete ora lanciare i comandi che vi interessano senza più dover inserire utente e password :-)

Anche in questo caso occorrerà ricordarsi di chiudere la sessione (Remove-PSSession) al termine del lavoro e pure stavolta vi ho modificato il documento Wiki così da poter scaricare facilmente il ps1 già pronto (public.gfsolone.com/wiki/doku.php?id=o365:pshellconnect) ;-)

Page 3 of 40«12345»...Last »