Archives For Microsoft Windows 2012

Di NotifyKace ne abbiamo già parlato un paio di volte in passato. Tutto è nato da una migrazione dell’appliance e relativa necessità di verificare che gli agent fossero correttamente installati e comunicanti con essa. Nel frattempo NotifyKace è cresciuto, si è evoluto e ha dato maggiori informazioni, permettendomi anche di richiamarlo facilmente in fase di login al dominio (inizialmente) o GPO (oggi). Ti racconto le ultime novità introdotte, così che anche tu possa sostituirlo a quello che forse hai in uso attualmente, ammesso che calzi a pennello la nuova soluzione adottata.

Kace: una rispolverata a NotifyKace.vbs (0.5) e uso delle GPO

Parti dalle basi

Se non hai idea di cosa sto parlando, ti invito a leggere l’articolo originale scritto un anno fa circa, è ancora valido e ti insegna alcuni trucchi per gestire i tuoi agenti Quest Kace, tutto sommato è ciò su cui baso lo sviluppo di NotifyKace:

Kace: un alert in caso di client mancante o inventario troppo vecchio

Ciò detto

Si può passare alla nuova versione dello script VBS, arrivata alla 0.5, che integra una funzione per l’invio della mail di allerta, un nuovo controllo riguardo l’esistenza del database di inventario e la rimozione delle esclusioni hostname perché oggi, a differenza di ieri, uso una GPO per arrivare direttamente sulle macchine interessate, lo script non viene quindi eseguito su endpoint che non devono avere l’agente Quest a bordo.

Il tutto si traduce con questo:

Della GPO per l’esecuzione programmata ne parliamo tra poco, nel frattempo i passaggi che più possono interessarti sono quelli relativi all’invio della comunicazione (a mezzo a posta elettronica), ora eseguito tramite funzione dedicata Call MailtoKacelog(Destination, DestinationCC, DestinationBCC, MailBody, Subject) e la verifica dell’esistenza del file di inventario (che puoi rinominare temporaneamente per verificare che lo script funzioni in maniera corretta):

'Test esistenza %ProgramData%\Quest\Kace\kinventory.db
If (oFSO.FileExists(sDirectoryPath & "\kinventory.db")) Then
'MsgBox("Debug: kinventory.db found " & strComputerName)

Il MsgBox commentato è lasciato lì volutamente nel caso in cui tu volessi vedere a video un popup di debug a conferma dell’esistenza del file; in uno script di produzione non ha invece senso lasciarlo senza commento. Ciò detto, null’altro cambia ma rimane più snello e pulito, con il rilevamento di indirizzo IP e ulteriori dettagli integrati nella funzione di MailtoKacelog.

Esecuzione programmata

Che poi è un po’ il succo del discorso che più cambia rispetto al passato. L’evoluzione della verifica consiste nella sua “rimozione” dalla fase di login, portandola invece all’interno dell’Utilità di pianificazione di Windows. L’operazione è costituita da due passaggi: il primo ti permetterà di copiare il file dello script all’interno dei tuoi PC, il secondo consisterà nell’inserimento dell’operazione programmata, che potrà essere poi eseguita secondo tue esigenze.

Copia del file

Crea una nuova GPO (o modificane una esistente che riguarda Kace) e naviga in Computer ConfigurationPreferences Windows SettingsFiles → Aggiungi un file da copiare sulla destinazione (che equivale al PC raggiunto dalla GPO), è qui che dovrai dirgli dove andare a recuperare il file VBS e in che cartella finale copiarlo. Ti propongo il riassunto catturato dalla GPO che stiamo attualmente utilizzando:

Kace: una rispolverata a NotifyKace.vbs (0.5) e uso delle GPO 1

Il file NotifyKace.vbs si trova in una share di rete raggiungibile da ogni nostro PC, verrà quindi copiato all’interno della cartella %ProgramData%\Quest, destinazione già presente sulle macchine proprio perché creata e quotidianamente utilizzata dall’agente Quest. Da qui si potrà certamente eseguire manualmente il controllo, oppure procedere con la seconda parte, quella della programmazione dell’operazione automatica.

Operazione programmata tramite Utilità di pianificazione

La seconda parte della GPO è quella che puoi creare e mettere in funzione navigando Computer ConfigurationPreferences Windows SettingsControl Panel SettingsScheduled Tasks → Crea un nuovo Scheduled Task (At least Windows 7) chiamato come meglio credi (nel mio caso è KACE check) e fagli eseguire un programma, puntandolo ovviamente a %ProgramData%\Quest\NotifyKace.vbs con i privilegi elevati e l’attivazione quotidiana all’orario che preferisci (nel mio caso le 12:00):

Kace: una rispolverata a NotifyKace.vbs (0.5) e uso delle GPO 2

In conclusione

Salvo errori, la configurazione del tuo nuovo controllo è terminata. Applica la GPO alle unità organizzative che contengono i PC del tuo dominio, attendi quindi che questa si propaghi e che inizi a svolgere il suo mestiere. Fai qualche test su macchine non in produzione, accertati che tutto funzioni correttamente, gioca con il file di inventario (magari rinominandolo in modo da non farlo rilevare al VBS e farti inviare così la mail di allerta per database non trovato), poi procedi con tutto il resto del parco macchine.

In caso di dubbi o anomalie, l’area commenti è a tua totale disposizione.

Buon lavoro :-)

Condividi l'articolo con i tuoi contatti:

ServiceDesk Plus, come tanti altri software (Microsoft Windows ne è un esempio comune e pratico), permette di effettuare rollback di versione nel caso in cui qualcosa vada storto o non convinca gli utilizzatori post-upgrade. L’operazione viene permessa tramite la finestra dell’Update Manager, la medesima che utilizzi per installare un Service Pack di programma, basta dare un’occhiata alla parte bassa della finestra, solitamente “lasciata lì e ignorata”:

ServiceDesk: recuperare lo spazio disco occupato dagli aggiornamenti

Selezionando un SP e facendo clic su Uninstall… potrai tornare indietro alla versione interessata, e fin qui tutto bene (dirai). Se la tua intenzione è invece quella di fare pulizia perché gli aggiornamenti funzionano correttamente, sappi che puoi recuperare lo spazio occupato da quelle patch in qualsiasi momento, semplicemente andando a cancellare i file che si trovano nella cartella ManageEngine\ServiceDesk\Patch (all’interno del disco fisso di installazione del programma). Puoi fare pulizia completa, ciò non impatterà ServiceDesk Plus, che non dovrà neanche essere fermato:

ServiceDesk: recuperare lo spazio disco occupato dagli aggiornamenti 1

La questione è stata discussa più volte all’interno del forum della Community, ti basta una ricerca per arrivare a molteplici risultati simili a questo (vecchissimo, ma ancora valido): pitstop.manageengine.com/portal/community/topic/safe-to-delete-servicedesk-patch-folder-18-10-2012.

Buon lavoro.

×

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:

Per chi non dovesse utilizzare sistemi server in inglese, l’icona “This PC” altro non è che “Questo computer“. Questa, in via ufficiale, la si può far comparire sul Desktop solo utilizzando il ruolo “Desktop Experience” che puoi aggiungere dal Server Manager. In realtà non è proprio così, funziona un po’ come già spiegato in passato per il CleanMgr non a bordo sistema in maniera predefinita. Anche stavolta un semplice trucco ti permetterà di raggiungere l’obiettivo senza necessità di portarti dietro null’altro.

Win10Clean.ps1: uno script PowerShell per fare pulizia su Windows 10 1

Windows 2012 R2

Testato su Windows 2012 R2, il metodo deve funzionare senza problemi anche su Windows 2012. Apri un Prompt dei Comandi o, se preferisci, anche solo un Run (tasto Windows + R), quindi utilizza questo comando per far comparire la finestra che ti permetterà di selezionare le icone da visualizzare sul Desktop:

"%Systemroot%\system32\rundll32.exe" shell32.dll,Control_RunDLL desk.cpl,,0

A questo punto il risultato dovrebbe essere questo:

Windows 2012 R2: mostrare l'icona This PC senza Desktop Experience 1

Ti basterà selezionare le icone desiderate e confermare con OK.

Buon lavoro :-)


fonte: social.technet.microsoft.com/Forums/windowsserver/en-US/ae462bce-1c71-4a36-a0ce-1ef4ad0bc31e/how-to-show-computer-on-desktop?forum=winserver8gen, intervento di GC-Tech.

×

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:

Un dominio contenente più unità organizzative, può avere necessità di creare gruppi di sicurezza con all’interno tutti gli utenti di una specifica OU. Per farlo, esiste il classico metodo manuale della ricerca * all’interno della OU → Seleziona tutti → Aggiungi a un gruppo, in alternativa torna utile la PowerShell e qualche riga di codice che ho recuperato da una vecchia discussione su ServerFault.

Creare un gruppo di Active Directory partendo da una OU

Si tratta infatti di un codice molto banale da comprendere e modificare per le proprie esigenze, utile anche per eliminare persone (avviandolo altre volte nel corso del tempo, non necessariamente in maniera manuale) che in quella OU non esistono più, ma che essendoci state in passato erano state precedentemente inserite all’interno del gruppo di sicurezza.

Spiego rapidamente cosa c’è da ritoccare:

  • $groupname (riga 2): dovrai dichiarare il nome del gruppo al quale aggiungere gli utenti della OU mantenendo gli apici e inserendo al loro interno il percorso completo del gruppo (CN/OU/DC).
  • $users (riga 3): modifica anche stavolta ciò che c’è tra gli apici posti dopo il -SearchBase, dichiarando il nome della OU dalla quale prelevare tutti gli utenti presenti nel momento in cui lanci lo script di PowerShell (OU/DC).
  • riga 11: copia dalla riga 3 ciò che hai appena modificato e incollalo tra gli apici che trovi subito dopo il -notlike. Questa condizione servirà a confrontare gli utenti presenti nel gruppo con quelli nella OU. Nel caso in cui un utente non faccia più parte della OU, verrà rimosso anche dal gruppo.

Lo script, che dovrà essere eseguito con diritti amministrativi sul Domain Controller di interesse, non fornisce alcun output di conferma a video. Una volta lanciato svolge il suo mestiere e tu potrai verificare l’effettiva buona riuscita andando ad aprire il gruppo che dovrà essere popolato partendo dalla OU.

Escludere gli utenti disabilitati

Se vuoi, puoi modificare il primo filtro di ricerca (quello relativo a $users) affinché vengano lasciati fuori gli utenti disabilitati. Si va quindi ad agire sulla riga 3:

$users = Get-ADUser -Filter * -SearchBase "OU=Contoso,OU=Utenti,DC=contoso,DC=local"

mettendo al posto dell’asterisco la specifica che permette di catturare solo gli utenti abilitati in dominio, ottenendo così:

$users = Get-ADUser -Filter {Enabled -eq $true} -SearchBase "OU=Contoso,OU=Utenti,DC=contoso,DC=local"

Schedulazione della modifica del gruppo

Rimane sempre valida la possibilità di richiamare uno script di PowerShell passando per le Operazioni Schedulate di Windows, così da mantenere il gruppo di sicurezza sempre aggiornato, in base a chi si trova all’interno della OU interessata. Per farlo, ti basterà creare una nuova attività di base e specificare il minimo indispensabile (riporto le voci in inglese qui di seguito, utilizzo la medesima lingua che generalmente si usa per i Windows Server installati in azienda):

  • Action: Start a program
  • Program/script: C:\Windows\system32\windowspowershell\v1.0\powershell.exe
  • Add arguments (optional): -command C:\scripts\Gruppo_dipendenti.ps1

(dove C:\scripts\Gruppo_dipendenti.ps1 dovrà essere modificato con la reale posizione e nome file assegnato allo script di PowerShell).

Il tutto è stato testato con successo su Windows Server 2012 R2. Per dubbi o suggerimenti, l’area commenti è a tua totale disposizione :-)

Buon lavoro!

Condividi l'articolo con i tuoi contatti:

Ciao. Ti sei ritrovato davanti all’errore “psql: FATAL: no pg_hba.conf entry for host “::1”, user “postgres”, database “servicedesk”,SSL off” mentre cercavi di collegarti via prompt al database del tuo ServiceDesk Plus? Anche io. Poi ho scoperto che si tratta di un errore riconosciuto da documentazione ufficiale, e che ti basta modificare un file di configurazione per poter tornare sulla retta via.

ServiceDesk: Error While connecting postgresDB

Di come collegarti via prompt al database del tuo software di supporto te ne avevo già parlato qui:

ServiceDesk: jespa.log sempre più grande?

Per risolvere il problema che ho riportato in apertura “pillola” devi invece ritoccare il file pg_hba.conf che trovi sotto ManageEngine\ServiceDesk\pgsql\data, andando a togliere il cancelletto di commento in corrispondenza dei valori specificati sotto la riga # IPv6 local connections.

La situazione che dovresti trovare è teoricamente questa:

# IPv6 local connections:
#host all all ::1/128 trust

Tu dovrai trasformarla in questa:

# IPv6 local connections:
host all all ::1/128 trust

Salva il file e riprova a connetterti al database, non dovresti ora riscontrare ostacoli.

È tutto spiegato qui: kbase.servicedeskplusmsp.com/troubleshooting/2014/02/28/error-while-connecting-postgresdb.

Buon lavoro!

×

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: