Linux: Monitorare la velocità di clock dei core del processore

Per monitorare costantemente la velocità di clock dei core del processore basta lanciare, da una finestra Terminale, il comando

watch -n0.2 grep -e MHz -e processor /proc/cpuinfo

FIG 1 - Clock dei core della CPU

MS Outlook: Impedire la connessione di file PST

Per evitare che gli utenti possano collegare un file .pst ad Outlook, aggiungere la voce di registro DisablePST e impostare il valore su 1 procedendo come indicato di seguito:

• Avviare l'Editor del registro di sistema (WIN+R e digitare regedit seguito da invio); 
• Posizionarsi sulla seguente chiave di registro
  HKEY_CURRENT_USER\Software\Microsoft\Office\xx.0\Outlook
  dove al posto xx.0 va indicata la versione di Office (ad es. 15.0 per Office 2013, 16.0 per Office 2016 e 2019);
• Creare un nuovo valore DWORD (32 bit) e rinominarlo in DisablePST;
• Fare clic con il pulsante destro del mouse sulla voce di registro DisablePST creata e selezionare Modifica;
• Nella casella di Dati valore, digitare 1 e selezionare OK;
  La voce di registro DisablePST può essere impostata sui seguenti valori:
  0 - Gli utenti possono aggiungere file .pst. Questo è il valore predefinito.
  1 - Gli utenti non possono aggiungere file .pst. I file .pst collegati ad Outlook prima dell'aggiunta di questo valore di registro, non verranno disconnessi e resteranno configurati in Outlook. Non sarà possibile aggiungere nuovi file .pst.
  2 Gli utenti possono aggiungere solo file .pst di condivisione esclusiva, come i file .pst di SharePoint.
  

  

  FIG 1 - Outlook DisablePST

  
  

DisablePST può essere impostato anche tramite policy, in tal caso il valore verrà creato al seguente percorso nel registro di sistema:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\xx.0\Outlook

Windows Server: Ruoli FSMO in Active Directory

Qualsiasi controller di dominio autorevole (DC) in Active Directory (AD) può eseguire la creazione, l'aggiornamento e la cancellazione degli oggetti. Questo è possibile perché ogni DC (tranne quelli di sola lettura) mantiene una copia scrivibile della partizione del proprio dominio. Una volta che una modifica viene applicata, essa viene automaticamente comunicata agli altri DC attraverso un processo chiamato replica multi-master. Questo comportamento consente alla maggior parte delle operazioni di essere elaborate in modo affidabile da più controller di dominio fornendo alti livelli di ridondanza, disponibilità e accessibilità in Active Directory.

Tuttavia ci sono alcune operazioni sensibili la cui esecuzione è limitata ad uno specifico controller di dominio, in questi casi Active Directory indirizza tali operazioni a server con una serie speciali di ruoli. Microsoft chiama tali ruoli "ruoli operativi" ma sono più comunemente noti con il loro nome originale: ruoli FSMO (Flexible Single Master Operator).

In Active Directory sono presenti 5 ruoli FSMO assegnati a uno o più controller di dominio:

• Schema Master
• Domain Naming Master
• Infrastructure Master
• Relative ID (RID) Master
• PDC Emulator

Schema Master 

Schema Master (o Master dello schema) è un ruolo FSMO di livello enterprise. In una foresta Active Directory esiste un solo Schema Master. Il Domain Controller in Active Directory che ricopre il ruolo di Schema Master è l'unico DC, all'interno della foresta, che contiene una partizione di schema scrivibile e controlla tutti gli aggiornamenti e le modifiche dello schema. Di conseguenza per aggiornare lo schema di una foresta, è necessario avere accesso allo Schema Master. Esempi di azioni che aggiornano lo schema sono l'innalzamento del livello funzionale della foresta e l'aggiornamento del sistema operativo di un DC a una versione superiore a quella presente nella foresta.

Se il Domain Controller con il ruolo di Schema Master dovesse andare offline, l'impatto immediato sarà minimo o nullo. Infatti, a meno che non siano necessarie modifiche allo schema, il ruolo può rimanere offline senza effetti rilevanti. Se il Domain Controller con il ruolo di Schema Master non può essere riportato online è possibile trasferire il ruolo ad altro Domain Controller.

Domain Naming Master

Domain Naming Master (Master per la denominazione dei domini) è un ruolo FSMO di livello enterprise. Nell'intera foresta può essere presente un solo master per la denominazione dei domini. Il controller di dominio master per la denominazione dei domini è l'unico controller di dominio, in una foresta Active Directory, in grado di aggiungere e rimuovere domini nella foresta. Nel caso in cui il Domain Controller che ricopre tale ruolo dovesse andare offline, l'impatto operativo sarebbe minimo o nullo, poiché l'aggiunta e la rimozione di domini e partizioni sono operazioni eseguite di rado e sono raramente critiche dal punto di vista temporale.

Infrastructure Master

L'Infrastructure Master (Master dell'infrastruttura) è un ruolo a livello di dominio; in ogni dominio può essere presente un solo controller di dominio che funge da master dell'infrastruttura. Il master dell'infrastruttura sincronizza gli oggetti con i server del catalogo globale (global catalog) ed è responsabile dell'aggiornamento dei riferimenti da oggetti nel relativo dominio a oggetti in altri domini. L'Infrastructure Master confronta i propri dati con quelli di un server del catalogo globale e riceve dal server del catalogo globale tutti i dati non presenti nel proprio database. Se tutti i DC di un dominio sono anche server del catalogo globale, tutti i DC disporranno di informazioni aggiornate (supponendo che la replica sia funzionale). In questo scenario, la posizione del ruolo Infrastructure Master è irrilevante, poiché non ha alcun lavoro da svolgere.

Il ruolo Infrastructure Master è anche responsabile della gestione degli oggetti fantasma. Gli oggetti fantasma sono utilizzati per tracciare e gestire i riferimenti persistenti agli oggetti eliminati e agli attributi con valore di collegamento che si riferiscono a oggetti in un altro dominio della foresta (ad esempio, un gruppo di sicurezza del dominio locale con un utente membro di un altro dominio).

Il ruolo può essere installato su qualsiasi controller di dominio in un dominio. Nel caso in cui la foresta Active Directory includa DC che non siano global catalog allora il ruolo va installato su uno di questi DC. La perdita del DC che possiede il ruolo di Infrastructure Master sarà probabilmente percepita solo dagli amministratori e potrà essere tollerata per un periodo prolungato. Sebbene la sua assenza comporti la mancata risoluzione corretta dei nomi dei collegamenti di oggetti cross-domain, la capacità di utilizzare le appartenenze di gruppo cross-domain non sarà compromessa.

RID Master

Il Relative Identifier Master (RID Master) è un ruolo a livello di dominio; in ogni dominio può essere presente un solo controller di dominio che funge da RID Master. Il RID Master è responsabile dell'elaborazione delle richieste del pool RID da tutti i controller di dominio in un determinato dominio. I pool di RID sono costituiti da un intervallo contiguo univoco di RID, che vengono utilizzati durante la creazione dell'oggetto per generare l'identificativo di sicurezza (SID) unico del nuovo oggetto. Il RID Master è anche responsabile dello spostamento degli oggetti da un dominio all'altro all'interno della foresta.

La perdita del RID Master di un dominio finirà per causare l'impossibilità di creare nuovi oggetti nel dominio, man mano che i pool di RID nei DC rimanenti si esauriscono. Sebbene possa sembrare che l'indisponibilità del DC che detiene il ruolo di RID Master possa causare un'interruzione significativa dell'operatività, negli ambienti maturi l'impatto è solitamente tollerabile per un periodo di tempo considerevole, a causa di un volume relativamente basso di eventi di creazione di oggetti.

PDC Emulator

L'emulatore del controller di dominio primario (PDC Emulator o PDCE) è un ruolo a livello di dominio; può essere presente un solo controller di dominio che funge da master dell'emulatore PDC in ogni dominio della foresta. L'emulatore PDC è un controller di dominio che si annuncia come controller di dominio primario (PDC) per workstation, server membri e controller di dominio che eseguono versioni precedenti di Windows. L'emulatore PDC controlla l'autenticazione all'interno di un dominio, sia Kerberos v5 che NTLM. Quando un utente cambia la password, la modifica viene elaborata dall'emulatore PDC. 

PDC Emulator è responsabile di diverse operazioni cruciali:

Retrocompatibilità. Il PDCE imita il comportamento single-master di un controller di dominio primario di Windows NT. Per risolvere i problemi di retrocompatibilità, il PDCE si registra come DC di destinazione per le applicazioni legacy che eseguono operazioni scrivibili e per alcuni strumenti amministrativi che non conoscono il comportamento multi-master dei DC di Active Directory.

Sincronizzazione dell'ora. Ogni PDCE funge da sorgente temporale master all'interno del proprio dominio. Il PDCE nel dominio radice della foresta funge da server NTP (Network Time Protocol) preferito nella foresta. Il PDCE di ogni altro dominio della foresta sincronizza il suo orologio con il PDCE radice della foresta; i DC non PDCE sincronizzano i loro orologi con il PDCE del loro dominio e gli host collegati al dominio sincronizzano i loro orologi con il DC preferito. Un esempio dell'importanza della sincronizzazione temporale è l'autenticazione Kerberos: l'autenticazione Kerberos fallisce se la differenza tra l'orologio di un host richiedente e l'orologio del DC di autenticazione supera il massimo specificato (5 minuti per impostazione predefinita); questo aiuta a contrastare alcune attività dannose, come gli attacchi replay.

Aggiornamenti delle password. Quando le password di computer e utenti vengono modificate o reimpostate da un controller di dominio non PDCE, l'aggiornamento impegnato viene immediatamente replicato al PDCE del dominio. Se un account tenta di autenticarsi in un DC che non ha ancora ricevuto una modifica recente della password tramite la replica programmata, la richiesta viene passata al PDCE del dominio, che la elabora e indica al DC richiedente di accettarla o rifiutarla. Questo comportamento garantisce che le password possano essere elaborate in modo affidabile anche se le modifiche recenti non si sono propagate completamente attraverso la replica programmata. Il PDCE è anche responsabile dell'elaborazione dei blocchi degli account, poiché tutte le autenticazioni di password fallite vengono passate al PDCE.

Aggiornamenti dei Criteri di gruppo. Tutti gli aggiornamenti degli oggetti Criteri di gruppo (GPO) sono assegnate al PDCE del dominio. In questo modo si evitano i conflitti di versione che potrebbero verificarsi se una GPO venisse modificata su due DC nello stesso momento.

File system distribuito. Per impostazione predefinita, i server root del file system distribuito (DFS) richiedono periodicamente informazioni aggiornate sullo spazio dei nomi DFS al PDCE. Sebbene questo comportamento possa causare colli di bottiglia nelle risorse, l'attivazione del parametro Dfsutil.exe Root Scalability consentirà ai server root DFS di richiedere gli aggiornamenti dal DC più vicino.

Il PDCE deve essere collocato su un DC ad alta accessibilità, ben collegato e ad alte prestazioni. La perdita del DC che possiede il ruolo PDC Emulator può avere un impatto immediato e significativo sulle operazioni.

Identificare i DC con ruoli FSMO

Per identificare i controller di dominio con ruolo FSMO è possibile procedere tramite il prompt dei comandi o tramite PowerShell.

Dal prompt dei comandi è possibile eseguire il comando

netdom query fsmo /domain:<DomainName>

Ad esempio

netdom query fsmo /domain:mycompany.local

FIG 1 - Visualizzare i server DC con ruoli FSMO da prompt dei comandi

Da PowerShell il comando da eseguire è

(Get-ADForest).Domains | ForEach-Object{Get-ADDomainController -Server $_ -Filter {OperationMasterRoles -like "*"}} | Select-Object Domain, HostName, OperationMasterRoles

FIG 2 - Visualizzare i server DC con ruoli FSMO da PowerShell

PowerShell: Convertire gli ID delle lingue in nomi estesi

Per visualizzare gli ID delle lingue installate nel sistema è possibile procedere tramite PowerShell con comandi del tipo 

 $os = Get-CIMInstance -ClassName Win32_OperatingSystem  
 $os.MUILanguages   

Tali comandi restituiscono l'elenco degli ID relativi ai pacchetti di lingue installate nel sistema operativo come mostrato in FIG 1.

FIG 1 - ID Lingue installate

L'output del comando restituisce un dato di tipo stringa pertanto, per convertire gli ID nei nomi estesi di lingua e paese, basterà eseguire il cast in un oggetto CultureInfo. Ad esempio:

 $os = Get-CIMInstance -ClassName Win32_OperatingSystem  
 [CultureInfo[]]$os.MUILanguages  

In questo modo avremo in output maggiori informazioni tra cui anche il nome esteso della lingua e del paese.

FIG 2 - Cast da stringa a CultureInfo

Windows: Disattivare la protezione in tempo reale dell'Antivirus Microsoft Defender

In alcuni casi può essere utile disattivare, temporaneamente, la protezione in tempo reale dell'Antivirus Microsoft Defender, ad esempio quando un file viene riconosciuto come falso positivo ma di cui siamo certi della sua provenienza.

Nell'articolo PowerShell: Disattivare la protezione in tempo reale dell'Antivirus Microsoft Defender è stato mostrato come eseguire tale operazione tramite PowerShell. Per eseguire la stessa operazione tramite GUI i passaggi da seguire sono i seguenti:

• Accedere alle Impostazioni di Windows (tramite la combinazione di tasti WIN + I);
• Cliccare su Aggiornamento e Sicurezza;
  

  

  FIG 1 - Impostazioni

  
  
  
• Selezionare la sezione Sicurezza di Windows quindi cliccare su Apri sicurezza di Windows;
  

  

  FIG 2 - Sicurezza di Windows

  
  
• Cliccare su Protezione da Virus e minacce;
  

  

  FIG 3 - Sicurezza in breve

  
  
• Cliccare sul link Gestisci impostazioni;
  

  

  FIG 4 - Protezione da virus e minacce, Gestisci impostazioni

  
  
• Disattivare l'opzione Protezione in tempo reale tramite l'apposito slider.
  
  

  

  FIG 5 - Impostazioni di Protezione da virus e minacce

  
  

Windows: Winget package manager

Winget è il package manager che Microsoft ha integrato nei suoi sistemi operativi (Windows 10 e Windows 11). La sua interfaccia a riga di comando, che può scoraggiare gli utenti meno esperti, consente di utilizzarlo per la creazione di script di installazione, per importare/esportare la lista dei software installati nel sistema e aggiornare tutti i programmi presenti con un solo comando.

Winget utilizza un’architettura flessibile che offre il supporto anche a sorgenti multiple in maniera analoga a quanto accade nei package manager in ambiente Linux. I repository possono essere integrati in un unico archivio locale e ciò rappresenta una funzionalità molto utile in ambito enterprise per garantire il controllo sulla distribuzione e aggiornamento dei software.

Per visualizzare un elenco dei comandi e opzioni disponibili del package manager, basta eseguire, da una finestra PowerShell, il comando

Winget

FIG 1 - Winget

Per visualizzare la versione di winget installata

Winget -v

FIG 2 - Versione di Winget

Per ricercare un applicazione nel repository il comando sarà simile a

winget search <appname>

ad esempio per ricercare le applicazioni acrobat il comando sarà

Winget search acrobat

quando si usa il comando per la prima volta bisogna accettare le condizioni dei contratti (FIG 3) per poter procedere.

FIG 3 - Termini di utilizzo msstore

Il motore di ricerca integrato in Winget analizza tutti i metadati di ciascun elemento (non solo il nome dell'app ma anche l'ID ed altre informazioni aggiuntive). Se da un lato questo garantisce di visualizzare un'elenco il più esaustivo possibile dall'altro potrebbe mettere in difficoltà l'utente meno esperto che non sa quale software scegliere tra quelli proposti. Ad esempio possono essere proposti più versioni del software oppure possono esserci software presenti sia all'interno del repository principale di Winget che nel Microsoft Store. 

FIG 4 - Ricerca applicazioni nei repository

Per limitare la ricerca ad un solo repository si può utilizzare l'opzione -s e specificando il repository desiderato (winget o msstore)

winget search acrobat -s winget

FIG 5 - Winget, limitare la ricerca ad un solo repository

Per ottenere maggiori informazioni su il pacchetto si può utilizzare il comando show seguito dal nome del pacchetto o il suo ID (generalmente si utilizza quest'ultimo in quanto consente di specificare con precisione il pacchetto di proprio interesse)

winget show  Adobe.Acrobat.Reader.64-bit

FIG 6 - Winget, visualizzare maggiori informazioni su un pacchetto

Per l'installazione del software si utilizza il comando install ad es.

winget install --id Adobe.Acrobat.Reader.64-bit

winget install 7zip -s winget

FIG 7 - Winget install

Winget scarica e installa per default la versione più recente del software indicato. L'elenco delle versioni disponibili può essere visualizzato aggiungendo il parametro --versions alla fine del comando

winget show 7zip -s winget --versions

FIG 8 - Winget, visualizzare le versioni disponibili di un software

Il parametro -v utilizzato insieme al comando install, consente di specificare la versione del software da installare.

winget install 7zip -s winget -v 21.06

Il comando install supporta l'argomento -i (oppure -interactive)che richiama la modalità di installazione interattiva e l'argomento -h (oppure -silent) che procede con l'installazione senza visualizzare alcuna interfaccia all'utente

Tramite l'argomento --location è possibile indicare il percorso in cui installare il software tuttavia tale funzione dipende dalle opzioni offerte da ogni specifico installer (winget install <app> --location C:\CartellaPersonale).

Con il comando

Winget list

verrà restituito l’elenco completo dei programmi installati in formato testuale. Nell'elenco sono inclusi anche i software che non sono presenti nei repository di Winget e, nel caso in cui il package manager rilevi la presenza di pacchetti più aggiornati rispetto a quelli installati in locale, segnala le nuove versioni in una colonna separata all'interno dell'elenco.

FIG 9 - Winget, elenco programmi installati

L'elenco dei soli pacchetti aggiornabili può essere ottenuto con il comando

Winget upgrade

FIG 10 - Winget upgrade

L'opzione --all, utilizzata con il comando upgrade, consente di aggiornare in un unica operazione tutti i software installati (ad eccezione dei software che non sono presenti nei repository di Winget)

Winget upgrade --all

La procedura di disinstallazione è altrettando semplice e viene utilizzato il comando uninstall. Con il seguente comando

winget uninstall 7zip 

si avvia la procedura di disinstallazione del software specificato.

L'argomento -v consente di specificare la versione del software da disinstallare (utile nel caso in cui siano installate più versioni di uno stesso software)

Come per l'installazione, anche in questo caso è supportato l'argomento -i che richiama la disinstallazione interattiva e l'argomento -h che, invece, avvia la disinstallazione in modalità silente.

Winget può essere difficile da approcciare ma esistono diversi strumenti che vengono in aiuto dell'utente:

• Archivio dei pacchetti online 
  L'archivio dei pacchetti online è accessibile all’indirizzo https://winget.run. Il sito consente di effettuare ricerche nell’archivio dei software e ottenere righe di comando di installazione da copiare e incollare nel terminale.
  

  

  FIG 11 - winget.run

  
  
• Interfaccia grafica WingetUI 
  Si tratta di un vero e proprio front-end nativo di Winget disponibile su Github all’indirizzo https://github.com/martinet101/WingetUI. L'interfaccia è molto intuitiva e divisa in sezioni: Discover Software elenca i pacchetti disponibili, che possono essere filtrati tramite la casella di ricerca in alto a sinistra. Software updates mostra i pacchetti aggiornabili, mentre Installed application propone una lista che comprende tutti i software installati nel sistema.
  

  

  FIG 12 - WingetUI

  
  

Configurazione Winget

La configurazione predefinita del Windows Package Manager Winget può essere modificata agendo sul file settings.json (il file si trova in %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\).

Per visualizzare e modificare il file JSON basta lanciare il comando

Winget settings

Se sul pc non è presente alcun software per la gestione dei file con estensione JSON, è possibile utilizzare un qualunque editor di testo (come ad esempio Blocco Note).

Per un elenco aggiornato delle impostazioni si può consultare la pagina https://aka.ms/winget-settings.

Source

All'interno del blocco Source è possibile specificare, attraverso autoUpdateIntervalInMinutes, ogni quanto tempo controllare gli aggiornamenti di una sorgente. Ad autoUpdateIntervalInMinutes, va assegnato un numero intero positivo che rappresenta l'intervallo di aggiornamento in minuti (di default 5). Assegnando zero il controllo degli aggiornamenti di una sorgente viene disabilitato. 

   "source": {  
     "autoUpdateIntervalInMinutes": 3  
   },  

La sorgente può essere aggiornata manualmente con il comando

winget source update

Visual

Le impostazioni del blocco Visual riguardano la modalità di visualizzazione degli elementi di Winget.

   "visual": {  
     "progressBar": "accent"  
   },  

Tramite progressBar è possibile specificare il colore della barra di avanzamento visualizzata da Winget. I valori accettati sono:

• accent (default)
• retro
• rainbow

InstallBehavior

La sezione installBehavior è forse quella più interessante in quanto permette la modifica del comportamento predefinito dell'installazione e dell'aggiornamento dei pacchetti.

- disableInstallNotes

Con disableInstallNotes è possibile abilitare/disabilitare la visualizzazione delle note di installazione dopo un'installazione riuscita. L'impostazione predefinita è false.

   "installBehavior": {  
     "disableInstallNotes": true  
   },  

- defaultInstallRoot

Con defaultInstallRoot è possibile specificare il percorso di installazione di pacchetto (se il pacchetto ne richiede uno durante l'installazione). Può essere sovrascritto dal parametro --location. Questa impostazione viene utilizzata solo quando il manifest di un pacchetto include InstallLocationRequired e il percorso effettivo si ottiene aggiungendo l'ID del pacchetto alla radice.

   "installBehavior": {  
     "defaultInstallRoot": "C:\installRoot"  
   },       

- portablePackageUserRoot

L'impostazione portablePackageUserRoot influisce sulla directory principale predefinita in cui vengono installati i pacchetti in ambito Utente. Questa impostazione si applica solo ai pacchetti di tipo portable installer. L'impostazione predefinita è %LOCALAPPDATA%/Microsoft/WinGet/Packages/. Il valore del path va specificato come percorso assoluto.

   "installBehavior": {  
     "portablePackageUserRoot": "C:/Users/FooBar/Packages"  
   },  

- Preferences e Requirements

Alcune impostazioni sono duplicate per Preferences e Requirements. Tramite Preferences viene influenzato l'ordinamento delle varie opzioni disponibili quando si sceglie quella su cui agire. Ad esempio, l'ambito predefinito per l'installazione dei pacchetti è quello dell'utente corrente, ma se non si tratta di un'opzione disponibile, verrà scelto un installatore a livello di macchina. I Requirements filtrano le opzioni. Si tratta di requisiti quindi se non rispettati l'installazione non verrà portata a termine. Nell'esempio precedente, un Requirements relativo all'ambito dell'utente non avrebbe prodotto alcun installatore applicabile ma un errore.

Scope permette di specificare se il pacchetto deve essere installato per l'utente corrente o per l'intera macchina. Il parametro corrispondente è --scope e utilizza gli stessi valori (user o machine).

   "installBehavior": {  
     "preferences": {  
       "scope": "user"  
     }  
   },  

Con Locale è possibile specificare le impostazioni locali da usare. Il parametro corrispondente è --locale e utilizza il tag di lingua bcp47

   "installBehavior": {  
     "preferences": {  
       "locale": [ "en-US", "fr-FR" ]  
     }  
   },  

Architectures seleziona l'architettura da installare. ll parametro corrispondente è --architecture. Da notare che è possibile selezionare solo le architetture compatibili con il sistema in uso.

   "installBehavior": {  
     "preferences": {  
       "architectures": ["x64", "arm64"]  
     }  
   },  

UninstallBehavior

Le impostazioni di uninstallBehavior influenzano il comportamento predefinito della disinstallazione (se applicabile) dei pacchetti.

- PurgePortablePackage 

PurgePortablePackage influenza il comportamento predefinito per la disinstallazione di un pacchetto portable. Se impostato su true, la disinstallazione rimuoverà tutti i file e le directory rilevanti per il pacchetto. Questa impostazione si applica solo ai pacchetti con il tipo di installatore portable. Se il valore non è impostato o non è valido, l'impostazione predefinita è false.

   "uninstallBehavior": {  
     "purgePortablePackage": true  
   },  

Telemetry

Le impostazioni di telemetria controllano se Winget scrive eventi ETW che possono essere inviati a Microsoft su un'installazione predefinita di Windows.

   "telemetry": {  
     "disable": true  
   },  

Se impostata su true, l'impostazione telemetry.disable impedisce la scrittura di qualsiasi evento da parte del programma.

Logging

Le impostazioni di log controllano il livello di dettaglio dei file di log. Il parametro --verbose-logs annulla questa impostazione e crea sempre un log verboso. Il valore predefinito è info se il valore non è impostato o non è valido.

   "logging": {  
     "level": ["verbose", "info", "warning", "error", "critical"]  
   },  

Network

Le impostazioni network influenzano il modo in cui Winget utilizza la rete per recuperare pacchetti e metadati.

L'impostazione downloader controlla il codice utilizzato  durante il download dei pacchetti. I valori accettati sono:

• default, che può essere una qualsiasi delle opzioni in base alla nostra determinazione;
• wininet usa le API WinINet;
• do usa il servizio Delivery Optimization.

L'impostazione doProgressTimeoutInSeconds aggiorna il numero di secondi da attendere in assenza di avanzamento prima del fallback. Il numero predefinito di secondi è 60, il minimo è 1 e il massimo è 600.

   "network": {  
     "downloader": "do",  
     "doProgressTimeoutInSeconds": 60  
   }  

Interactivity

Le impostazioni Interactivity controllano se Winget può mostrare messaggi interattivi durante l'esecuzione. Si noti che questo si riferisce solo ai prompt mostrati da Winget stesso e non a quelli mostrati dai programmi di installazione dei pacchetti.

  "interactivity": {  
     "disable": true  
   },  

Se impostata a true, l'impostazione interactivity.disable impedisce la visualizzazione di qualsiasi richiesta interattiva.

ExperimentalFeatures

Le impostazioni di experimentalFeatures riguardano la configurazione di queste funzioni "sperimentali". In questo nodo è possibile abilitare singole funzioni. L'esempio seguente mostra un esempio di funzionalità sperimentali.

   "experimentalFeatures": {  
     "experimentalCmd": true,  
     "experimentalArg": false  
   },  

- zipInstall

Questa funzione consente a Windows Package Manager di installare da un file zip. È possibile attivare la funzione come mostrato di seguito.

   "experimentalFeatures": {  
     "zipInstall": true  
   },  

- directMSI

Questa funzione consente al gestore di pacchetti di Windows di installare direttamente i pacchetti MSI con le API MSI anziché tramite msiexec. Si noti che quando si utilizza l'installazione silenziosa questa funzione è già attiva. È possibile attivare la funzione come mostrato di seguito.   

   "experimentalFeatures": {  
     "directMSI": true  
   },  

- openLogsArgument

Questa funzione consente a Windows Package Manager di aprire la cartella dei log predefinita dopo l'esecuzione, passando l'argomento --open-logs con qualsiasi comando. È possibile attivare la funzione come mostrato di seguito.

   "experimentalFeatures": {  
     "openLogsArgument": true  
   },  

- dependencies

La funzione sperimentale Dependencies mostra, per ora,  solo le informazioni sulle dipendenze dei pacchetti. È possibile attivare la funzione come mostrato di seguito.

  "experimentalFeatures": {  
     "dependencies": true  
   },  
     

PowerShell: Esportare l'elenco dei software installati

Per esportare l'elenco dei software installati in un file csv è possibile utilizzare il seguente script PowerShell

 $paths = 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*','HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'  
 Get-ItemProperty $paths | Select-Object DisplayName, Publisher, DisplayVersion, InstallDate, UninstallString | Sort-Object DisplayName | Export-Csv C:\temp\ElencoSoftware.csv  

Ovviamente al posto di C:\temp\ElencoSoftware.csv va specificato il percorso e il nome del file csv in cui si intende esportare l'elenco.

L'elenco mostra il Display Name del software, l'autore, la versione, la data di installazione e l'eventuale stringa da utilizzare per la disinstallazione.

FIG 1 - Elenco Software installati