Archives For Controllo remoto

Ovvero: come sopperire a una mancanza banale del software che a oggi non permette di fare pulizia di quei software non più in giro, ma ancora presenti nel database, un po’ in barba a ciò che è invece possibile fare attraverso il MIA nella schermata relativa ai dispositivi registrati.

NotifyKace.vbs: nuova versione per gli agenti 8

Ammettilo: lo hai fatto almeno una volta nella tua vita, sei andato nella schermata software, li hai messi in ordine per numero di installazioni e hai cominciato a selezionare i checkbox lateralmente per poi andare a cancellarli dal database della tua appliance. L’ho fatto anche io, la cosa ha funzionato così per un paio di volte, poi mi ha stancato perché, nonostante le prime pagine fossero tutte a quantità 0, le altre contenevano un misto dal quale non volevo eliminare le voci con qualche installazione ancora presente nella rete controllata. Per questo motivo ho cercato una soluzione ufficiale che a quanto pare non c’è, passeggiando poi per un viale work-around che funziona egregiamente.

Per filtrare i software con zero installazioni in rete client gestita ti basterà andare in InventorySoftware, fare clic su Advanced Search e inserire questi parametri di ricerca:

  • File Size → = → 0
  • Devices → does not contain → (lascia vuoto l’ultimo box)
  • (opzionale) Publisher → does not contain → (compila con ciò che ti interessa)

Prima ti mostro la schermata catturata dal Kace che gestisco, poi ti spiego il perché dell’opzionale e del valore “GSolone” che ho assegnato nella mia ricerca:

Kace: filtrare facilmente i software con 0 installazioni

L’opzionale è presto detto, ci sono alcuni software “Home Made” che mi permettono di generare delle Custom Inventory Rules o di prevedere comportamenti di Kace che rispettano alcune procedure stabilite dal nostro team IT, talvolta potrebbe capitare di avere 0 dispositivi associati a quei Custom Software, vorrei evitare di perderli in qualche pulizia manuale alla quale non si pone sufficiente attenzione. Questo per dire che anche nel tuo caso puoi fare delle eccezioni da non far finire nel calderone, basando una parte di ricerca avanzata su un parametro ben preciso.

Scopo del gioco è quello di salvare la ricerca avanzata per poterla ripescare facilmente in seguito, per passare lì di tanto in tanto e fare piazza pulita di ciò che non ti interessa realmente più.

Buon lavoro!


Credits: itninja.com/question/k1000-kace-cleaning-up-software-inventory

Condividi l'articolo con i tuoi contatti:

TeamViewer è uno strumento tutto sommato fantastico e universalmente riconosciuto per essere un giusto partner nell’assistenza remota verso PC diversamente non raggiungibili. In passato brillante per il suo modo di saltare a piè pari le limitazioni imposte dai firewall o dai NAT di rete, oggi cerca di fare bella mostra di sé per alcune finezze e servizi accessori (come la giovane assistenza remota su iOS 11+) che conquistano altre fette di mercato.

Kace: TeamViewer Remote Host Switch 3

TeamViewer è anche lo strumento utilizzato per fare assistenza remota in ufficio e, nel corso del tempo, ho costruito una serie di script che mi hanno facilitato la vita nella gestione delle sue autorizzazioni e comportamenti. Attivazione o disattivazione del popup di conferma al collegamento da parte dell’utente finale, blocco o sblocco (quindi disattivazione o attivazione) della creazione password a video (quella specificata sotto il tuo ID), possibilità di inibire il collegamento via internet lasciando solo quello da rete locale. Un piccolo coltellino svizzero in VBS, da richiamare comodamente da riga di comando in base alle esigenze.

Qualche giorno fa ho “tradotto” uno di quegli script in istruzioni per Kace. In particolare parlo dello script che abilita o disabilita l’accesso con conferma al TeamViewer di qualsiasi macchina (x86/x64) controllata all’interno del dominio / parco macchine gestito da Kace. Se la conferma di accesso è abilitata la disabilita, diversamente la abilita.

Lo script

Eseguito come Local System, si basa su due Task, si tratta rispettivamente di quello per un sistema installato a 64 bit, l’altro a 32. Basta controllare se esiste una chiave di registro partendo dalle voci di registro x64 (le Wow6432Node) e variare un valore in base alla condizione attuale, quindi passare al Task 2 nel caso si avesse a che fare con un Windows x86, a 32 bit.

Ti riporto qui di seguito i passaggi che ho salvato nel mio script.

Task 1

Verify

Verifica che la chiave di registro HKLM\SOFTWARE\Wow6432Node\TeamViewer\AccessControl esista, e che il valore AC_Server_AccessControlType sia impostato a 3 (il popup di conferma al collegamento remoto, che compare a video dell’utente finale quando ci si è autenticati dall’altro lato), tradotto quindi con:

Verify that HKLM\SOFTWARE\Wow6432Node\TeamViewer\AccessControl!AC_Server_AccessControlType is equal to “3”

Kace: TeamViewer Remote Host Switch

On Success

In caso di successo, dovrai terminare il processo relativo al servizio di TeamViewer, il client di TeamViewer stesso e modificare quel valore di chiave prima di poter riavviare il servizio di TeamViewer. Tradotto, si ottiene quindi:

Kill the process “TeamViewer_Service.exe”
Kill the process “TeamViewer.exe”
Set “HKLM\SOFTWARE\Wow6432Node\TeamViewer\AccessControl!AC_Server_AccessControlType” to “0”
Restart service “TeamViewer”

Dove lo 0 equivale a un lasciapassare che non richiede conferma alcuna da parte dell’utente finale, in pratica si va a emulare quella condizione di limbo (che permette la connessione senza conferma) di quando ci si trova nella schermata di login di Windows (CTRL+ALT+CANC).

Remediation

La Remediation serve come faultback, permettendoti quindi di riportare la situazione allo stadio precedente, perché il primo passaggio (quello di Verify, nda) ha evidentemente rilevato che il valore di AC_Server_AccessControlType era impostato su qualcosa di diverso dal 3. Quindi non farai altro che terminare il processo relativo al servizio di TeamViewer, il client di TeamViewer stesso e ritoccare quel valore di chiave prima di poter riavviare il servizio dell’applicazione. Traduco:

Kill the process “TeamViewer_Service.exe”
Kill the process “TeamViewer.exe”
Set “HKLM\SOFTWARE\Wow6432Node\TeamViewer\AccessControl!AC_Server_AccessControlType” to “3”
Restart service “TeamViewer”

Kace: TeamViewer Remote Host Switch 1

La procedura su sistemi a 64 bit è completa. Salvo errori, questa parte sarà già funzionante, a prescindere dallo stato d’uscita dello script in console (potrebbe anche dirti di aver fallito, ma mente, dall’altro lato la modifica è stata eseguita e potrai metterla subito alla prova).

Task 2

Verify

Non pensare che io lo faccia apposta, ma nulla cambia rispetto a prima. Il Task 2 serve esclusivamente nel caso in cui il primo fallisca, perché evidentemente non ci si trova davanti a una installazione di Windows a 64 bit. Questo primo passaggio pensa perciò a verificare che la chiave di registro HKLM\SOFTWARE\TeamViewer\AccessControl esista, e che il valore AC_Server_AccessControlType sia impostato a 3 (il popup di conferma al collegamento remoto, che compare a video dell’utente finale quando ci si è autenticati dall’altro lato), tradotto quindi con:

Verify that “HKLM\SOFTWARE\TeamViewer\AccessControl!AC_Server_AccessControlType” is equal to “3”

On Success

Anche in questo caso, se la ricerca ha successo, dovrai terminare il processo relativo al servizio di TeamViewer, il client di TeamViewer stesso e modificare quel valore di chiave prima di poter riavviare il servizio di TeamViewer. Tradotto, si ottiene quindi:

Kill the process “TeamViewer_Service.exe”
Kill the process “TeamViewer.exe”
Set “HKLM\SOFTWARE\TeamViewer\AccessControl!AC_Server_AccessControlType” to “0”
Restart service “TeamViewer”

Remediation

Con la Remedetion chiudi il cerchio e anche le operazioni di ambo i Task, riportando la situazione a quella considerata standard, prevedendo che sia l’utente a darti l’autorizzazione al collegamento al suo PC, senza che tu possa entrarci senza controllo alcuno:

Kill the process “TeamViewer_Service.exe”
Kill the process “TeamViewer.exe”
Set “HKLM\SOFTWARE\TeamViewer\AccessControl!AC_Server_AccessControlType” to “3"
Restart service “TeamViewer”

Lo script è utile per casi di emergenza nel caso in cui tu stia lavorando sul PC dell’utente senza presidio dall’altro lato (tipicamente quando ti lascia a fare il tuo lavoro e si allontana per una pausa, un tempo variabile non sempre ben definito), e tu ne perda il controllo per un qualsivoglia motivo, chiudendoti quindi la porta alle spalle (e senza le chiavi di casa). Non andrebbe mai utilizzato come passe-partout all’insaputa dell’utente.

Buon lavoro.

Condividi l'articolo con i tuoi contatti:

No, non lo faccio apposta a parlare di sistemi *VNC ultimamente, è che capitano problemi quotidianamente e uso (ormai dovreste saperlo) il blog come blocco appunti per avere dei promemoria sempre disponibili un domani, nel caso in cui dovessi dimenticarmi la soluzione ai problemi risolti e necessitassi di perdere poco tempo per cercarla nuovamente sulla rete :P

Problematica: su una macchina è stato disinstallato RealVNC4 (apparentemente in modo corretto) ed è ora presente un UltraVNC che non funziona affatto bene, questo perché collegandosi alla macchina dovrebbe richiedere le credenziali di dominio (autenticazione tramite MS-LOGON quindi) ma in realtà propone il solo campo password, chiaramente lasciando “spiazzato” chi si collega e non sa che password inserire.

Dopo qualche test ho scoperto l’arcano mistero, più semplice di quello che avevo inizialmente previsto ma infame al punto giusto da non venire in mente immediatamente …

Nonostante l’installazione di UltraVNC fosse stata fatta correttamente e fosse presente “uvnc_server” tra i servizi della macchina, RealVNC4 aveva “lasciato a marcire” il suo winvnc.exe che prevaleva sull’ultimo arrivato. Risultato? La password richiesta era quella impostata nel vecchio VNC. Ecco la schermata dei servizi:

clicca sull’immagine per ingrandire

Dopo aver disabilitato il servizio tutto è tornato alla normalità. Ecco perché ho prontamente cercato la sintassi per eliminare un servizio direttamente da DOS, questo è il documento:

theeldergeek.com/add_a_service_in_windows_xp.htm

e questo il risultato dalla finestra DOS chiaramente lanciata in modalità amministrativa:

Microsoft Windows XP [Versione 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>sc delete WinVNC4
[SC] DeleteService SUCCESS

C:\WINDOWS\system32>

Visibile anche a video dato che viene immediatamente dato errore sul servizio che si stava osservando:

clicca sull’immagine per ingrandire

Potete ora tornare al vostro lavoro senza imprecare ulteriormente, il problema è risolto e non necessita di alcun riavvio per permettervi il collegamento ad UltraVNC Server :-)

Cheers.

Condividi l'articolo con i tuoi contatti:

Ricordate il post riguardante la migrazione di massa verso UltraVNC? Ho avuto modo di notare un comportamento anomalo da un cliente. Il concetto si riassume in: “Winvnc.exe va in crash ogni qual volta si tenta di aprire una finestra di Explorer” (non il browser, l’esplora risorse di Windows ;)) … nella casistica migliore si otteneva un freeze della finestra client per poi subire il “Socket error” nel caso in cui si tentasse la riconnessione.

Provate ad immaginare la felicità dell’utente ogni qual volta c’era da avviare un PsKill da remoto per buttare giù i processi appesi di winvnc.exe nell’attesa di avviarne uno nuovo funzionante …

Tentando di non migrare più postazioni possibili (dove ho appositamente lasciato RealVNC 4 o UltraVNC 1.0.2) e tenendo sotto costante controllo il forum di UltraVNC sono arrivato a testare il server (ed il viewer) della versione 1.0.6.0, non ancora ufficialmente rilasciata (quindi, prendetela come un “as-is” senza troppe garanzie, personalmente posso dirvi che funziona correttamente).

# cambio di programma

A monte c’era una richiesta più complessa dell’ultima volta. Lo script andrà inserito al logon, tra una mappatura di disco di rete ed una stampante per capirci, ciò vuol dire che dovrà essere capace di confrontare la versione del PC con quella sul server e decidere di aggiornare solo nel caso in cui quest’ultima sia più recente della prima controllata. Per questo motivo ho deciso di ricontrollare lo script, migliorarlo laddove fosse possibile e inserire il nuovo controllo a monte per abbandonare il batch nel caso in cui questo risulti “inutile“. Vediamo nello specifico le modifiche …

Il codice iniziale era stato pubblicato qui:

dev.gxware.org/?15

contrariamente al nuovo pubblicato invece su:

dev.gxware.org/?17

Il controllo che si occupa di confrontare la versione del server e –di conseguenza– decidere il da farsi è il seguente:

fc %programfiles%\UltraVNC\winvnc.exe \\NOME_FILESERVER\Install\Workstation\uvnc_silent\1060_pre\winvnc.exe > nul
IF ERRORLEVEL 1 goto STOPSERVIZI

fc” è un comando riconosciuto da DOS, la documentazione è disponibile a questo indirizzo:

computerhope.com/fchlp.htm

Permette di confrontare due file (qualsiasi) permettendomi così di capire se la versione del server è pari a quella della macchina locale e reagendo –di conseguenza– diversamente a seconda della risposta ottenuta. Il “goto STOPSERVIZI” viene infatti richiamato solo ed esclusivamente se il risultato del confronto dice che le versioni differiscono tra di loro.

L’altra modifica è presto detta / fatta, si tratta dell’installazione full di una versione 1.0.5.6 riconosciuta come stable dagli sviluppatori del tool di controllo remoto, alla quale verranno poi modificate “a cuore aperto” le versioni di server e client portandole sul ramo “pre” della prossima 1.0.6.0:

:INSTALL
echo.
echo *** Installazione nuova versione UltraVNC ***
echo.
if not exist %programfiles%\UltraVNC mkdir %programfiles%\UltraVNC\
copy \\NOME_FILESERVER\Install\Workstation\uvnc_silent\ultravnc.ini "%programfiles%\UltraVNC"
"\\NOME_FILESERVER\Install\Workstation\uvnc_silent\UltraVNC_1.0.5.6_Setup.exe" /verysilent /loadinf=\\NOME_FILESERVER\Install\Workstation\uvnc_silent\ultravnc.inf

echo.
echo *** Sovrascrittura con file pre-release 1060 ***
echo.
cd %programfiles%\UltraVNC
move winvnc.exe winvnc.exe.bak
move vncviewer.exe vncviewer.exe.bak
copy \\NOME_FILESERVER\Install\Workstation\uvnc_silent\1060_pre\winvnc.exe %programfiles%\UltraVNC\
copy \\NOME_FILESERVER\Install\Workstation\uvnc_silent\1060_pre\vncviewer.exe %programfiles%\UltraVNC\
cd \
cd %programfiles%\UltraVNC
start winvnc.exe
goto FINE

Chiaramente lo script verrà eseguito –ancora una volta– come amministratore di dominio, così che l’utente non debba “metterci mouse” durante il processo. Il file di configurazione gli verrà passato proprio come prima (in caso di nuova installazione o disinstallazione e passaggio a nuova versione) e ad installazione terminata sarà immediatamente possibile utilizzare il prodotto.

Stavolta non ho rilasciato il pacchetto completo e pronto da utilizzare, potete modificare il vecchio batch incollando il codice rilasciato in /dev e scaricare i file della 1.0.6.0 da questa discussione sul forum di UVNC.

Non mi resta che augurarvi buon lavoro :)

ancora una volta grazie a $cliente (lui sa chi) per avermi fatto divertire nella ricerca e nello sviluppo di soluzioni a lui adatte :)

Condividi l'articolo con i tuoi contatti: