La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo documento viene descritto come controllare la funzionalità Cisco Secure Endpoint Identity Persistence.
Persistenza identità è una funzionalità che consente di mantenere un registro eventi coerente negli ambienti virtuali o quando viene ricreata l'immagine dei computer. È possibile associare un connettore a un indirizzo MAC o a un nome host in modo che non venga creato un nuovo record del connettore ogni volta che viene avviata una nuova sessione virtuale o che viene ricreata l'immagine di un computer. Questa funzione è progettata specificamente per ambienti VM e Lab non persistenti. Il metodo consigliato è nomehost in tutta l'azienda e abilitare la funzionalità nei criteri in cui si desidera sincronizzare le identità.
Cisco raccomanda la conoscenza dei seguenti argomenti:
La persistenza delle identità è una funzionalità degli endpoint sicuri che consente di identificare gli endpoint sicuri al momento della registrazione iniziale del connettore e di confrontarli con le voci note in precedenza in base a parametri di identità quali l'indirizzo MAC o il nome host per il connettore specifico. L'implementazione di questa funzione non solo contribuisce a mantenere un numero di licenze corretto, ma soprattutto consente di tenere traccia in modo corretto dei dati cronologici sui sistemi non persistenti.
L'utilizzo più comune per la persistenza delle identità nelle distribuzioni virtuali è la distribuzione VDI (Virtual Desktop Infrastructure) non persistente. Gli ambienti desktop host VDI vengono implementati su richiesta o necessità dell'utente finale. tra cui VMware, Citrix, AWS AMI Golden Image Deployment e così via.
La VDI persistente, chiamata anche 'VDI stateful', è una configurazione in cui il desktop di ogni singolo utente è personalizzabile in modo esclusivo e "persistente" da una sessione all'altra. Questo tipo di distribuzione virtuale non richiede la funzionalità di persistenza delle identità, in quanto queste macchine sono progettate per non essere sottoposte regolarmente a re-imaging.
Come per tutto il software che potrebbe interagire con le prestazioni dell'endpoint sicuro, le applicazioni desktop virtuali devono essere valutate per eventuali esclusioni al fine di ottimizzare le funzionalità e ridurre al minimo l'impatto.
Per la distribuzione di Identity Persistence sui computer fisici degli endpoint sicuri possono essere applicati due scenari:
Trovare gli UUID duplicati: https://github.com/CiscoSecurity/amp-04-find-duplicate-guids
Esistono alcune istanze comuni che possono causare la visualizzazione di duplicati nella parte finale:
1. Se sono stati seguiti questi passaggi mentre il pool VDI:
2. L'utente distribuisce l'immagine finale originale con Persistenza identità abilitata nel criterio in un gruppo e quindi sposta un endpoint in un altro gruppo dal portale degli endpoint protetti. Il record originale viene quindi inserito nel gruppo "spostato in", ma vengono create nuove copie nel gruppo originale quando le VM vengono nuovamente immesse/reinstallate.
Nota: non si tratta di un elenco esaustivo di scenari che potrebbero causare duplicati, ma alcuni dei più comuni.
Un'implementazione non corretta di Identity Persistence può causare i seguenti problemi/sintomi:
Distribuzione manuale con Persistenza identità abilitata nel criterio.
- Se si distribuisce l'endpoint manualmente tramite l'opzione della riga di comando con Persistenza identità già abilitata nel criterio e successivamente si disinstalla l'endpoint e si prova a reinstallare con un pacchetto di un gruppo o di un criterio diverso, l'endpoint tornerà automaticamente al criterio originale.
- Output dei log SFC che mostrano l'opzione di criterio in modo autonomo con 1-10 sec
(167656, +0 ms) Dec 14 11:37:17 [1308]: Util::VerifyOsVersion: ret 0
(167656, +0 ms) Dec 14 11:37:17 [1308]: ERROR: ETWEnableConfiguration::IsETWEnabled: ETW not initialized due to incompatibile OS
(167656, +0 ms) Dec 14 11:37:17 [1308]: UiPublisher::PublishPolicyInfo: Name -UTMB-WinServer-Protect Serial 819 << ---------------------- Freshly Installed
(167656, +0 ms) Dec 14 11:37:17 [1308]: UiPublisher::PublishLastPolicyUpdateTime: Publish Last Policy Update time 1670439264
(167656, +0 ms) Dec 14 11:37:17 [1308]: UiPublisher::PublishAgentVersion: Agent Version 7.5.7.21234
(167656, +0 ms) Dec 14 11:37:17 [1308]: HeartBeat::PolicyNotifyCallback: EXIT
(167656, +0 ms) Dec 14 11:37:17 [1308]: AmpkitRegistrationHandler::PolicyCallback: EXIT (0)
.
.
.
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitRegistrationHandler::UpdateConfiguration: Enter
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitRegistrationHandler::UpdateConfiguration: Aborting - not registered
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitRegistrationHandler::ConnectionStateChanged: Starting Proxy Discovery
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendPolicyReloaded sending policy reloaded to UI. ui.data.policy.policyName -UTMB-WinServer-Audit << --------- Auto Switch to Old Policy
(173125, +0 ms) Dec 14 11:37:22 [4704]: PipeSend: sending message to user interface: 28, id: 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendStatus: notifying UI: No Product
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendStatus: notifying UI: No Product
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendStatus: notifying UI: No Product
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendStatus : engine1 (0, 0), engine2 (0, 0)
(173125, +0 ms) Dec 14 11:37:22 [4704]: PipeSend: sending message to user interface: 1, id: 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiStatusHandler::ConnectionStateChangedState: 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiPublisher::PublishConnectionStatus: State 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpApiServer.cpp:AmpApiServer::PublishScanAvailable:223: Cloud connection status 0, Tetra Available 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitProxyHelper::LoadProxyFromConfig: Enter
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitProxyHelper::LoadProxyFromConfig proxy server is NULL
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitProxyHelper::LoadProxyFromConfig: Direct connection detected
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitProxyHelper::LoadProxyFromConfig: Exit(1)
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiAgentGuidUpdater::ConnectionStateChanged
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiAgentGuidUpdater::RefreshAgentGuidUi: Agent GUID: e1a756e2-65ab-4cd6-a886-ff826d74f05d
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiPublisher::PublishAgentGuid: Agent GUID did not change (e1a756e2-65ab-4cd6-a886-ff826d74f05d)
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitSubscriptionThread::NotificationWorker: Waiting on queue
L'altro effetto collaterale se si prova a installare un connettore che appartiene a un gruppo diverso. Nel portale verrà visualizzato che il connettore è assegnato al gruppo corretto ma con criteri originali "errati"
Ciò è dovuto al funzionamento di Identity Persistence (ID SYNC).
Senza ID SYNC una volta che il connettore è stato disinstallato completamente o utilizzando l'opzione della riga di comando re-register. In caso di disinstallazione o di semplice GUID del nuovo connettore, in caso di comando di nuova registrazione, verranno visualizzati la nuova data di creazione e il GUID del connettore. Tuttavia, con ID SYNC che non è possibile, ID SYNC viene sovrascritto con il GUID e la DATA precedenti. È così che si sincronizza l'host.
Se il problema si verifica, è necessario implementare la correzione tramite la modifica dei criteri. È necessario spostare gli endpoint interessati di nuovo nel gruppo o nei criteri originali e verificare che i criteri siano sincronizzati. Spostare quindi gli endpoint nel gruppo o nei criteri desiderati
Se si utilizzano volumi di applicazioni per l'infrastruttura VDI, è consigliabile apportare le modifiche di configurazione alla configurazione di snapvol.cfg
Queste esclusioni devono essere implementate nel file snapvol.cfg:
Percorsi:
Chiavi del Registro di sistema:
Sui sistemi x64, aggiungere quanto segue:
Riferimenti:
Di seguito sono riportate alcune delle procedure ottimali da seguire quando si implementa Identity Persistence sul portale degli endpoint sicuri:
1. Si consiglia di utilizzare criteri/gruppi separati per gli endpoint di persistenza dell'identità per semplificare la segregazione.
2. Se si intende utilizzare l'isolamento degli endpoint e implementare l'azione Sposta computer in gruppo in caso di compromissione. Il gruppo di destinazione deve inoltre avere la persistenza delle identità abilitata e deve essere utilizzato solo per i computer VDI.
3. Non è consigliabile abilitare la persistenza delle identità nel gruppo/criterio predefinito per le impostazioni dell'organizzazione, a meno che non sia stata abilitata l'opzione Persistenza delle identità in tutti i criteri con l'opzione In tutta l'organizzazione come ambito delle impostazioni.
Per distribuire il connettore di endpoint sicuro con persistenza dell'identità, eseguire la procedura seguente:
Passaggio 1. Applicare ai criteri l'impostazione di Persistenza identità desiderata:
Test - 123
È possibile scegliere tra cinque opzioni.
in tutti i criteri dell'organizzazione con Sincronizzazione identità impostata su un valore diverso da Nessuno. Il Connettore può aggiornare i propri criteri in modo che riflettano l'installazione precedente, se diversa da quella nuova.
Nota: se si sceglie di utilizzare Persistenza identità, Cisco consiglia di utilizzare Per nome host in Business o Policy. Un computer ha un nome host ma può avere più indirizzi MAC e molte VM clonano gli indirizzi MAC.
Passaggio 2. Scaricare Secure Endpoint Connector.
Passaggio 3. Distribuire il connettore agli endpoint.
Nota: selezionare il programma di installazione ridistribuibile. Si tratta di un file di circa 57 MB (le dimensioni possono variare a seconda delle versioni più recenti) che contiene i programmi di installazione a 32 e a 64 bit. Per installare il connettore su più computer, è possibile inserire il file in una condivisione di rete o inserirlo in tutti i computer. Il programma di installazione contiene un file policy.xml utilizzato come file di configurazione per l'installazione.
Quando si crea un'immagine finale da utilizzare per il processo di duplicazione di VDI, attenersi alle linee guida sulle procedure ottimali riportate nel documento del fornitore (VMware, Citrix, AWS, Azure e così via).
Ad esempio, VMware Golden Image Process: https://docs.vmware.com/en/VMware-Horizon/2106/virtual-desktops/GUID-D9C46AEF-1C41-4711-BF9E-84362EBE6ABF.html.
Una volta identificato il VMware, il processo di composizione AWS riavvia le VM clonate (VM figlio) più volte prima della finalizzazione della configurazione della VM, causando problemi con il processo di registrazione degli endpoint sicuri, in quanto attualmente alle VM clonate (VM figlio) non sono stati assegnati i nomi host finali/corretti e ciò fa sì che le VM clonate (VM figlio) utilizzino il nome host dell'immagine dorata e si registrino nel cloud di endpoint sicuri. Questo interrompe il processo di duplicazione e causa problemi.
Questo non è un problema con il processo di connessione dell'endpoint sicuro, ma è incompatibile con il processo di duplicazione e con la registrazione dell'endpoint sicuro. Per prevenire questo problema, abbiamo identificato alcune modifiche da implementare nel processo di duplicazione che aiutano a risolvere questi problemi.
Queste sono le modifiche che devono essere implementate sulla VM Golden Image prima che l'immagine venga bloccata per essere duplicata
1. Utilizzare sempre il flag Goldenimage sull'immagine dorata al momento dell'installazione di Secure Endpoint.
2. Implementare la sezione Golden Image Setup Script e la sezione Golden Image Startup Script per trovare gli script che consentirebbero di attivare il servizio Endpoint solo quando viene implementato un nome host finale nelle VM clonate (VM figlio). Per ulteriori informazioni, fare riferimento alla sezione Problemi di duplicazione orizzonte VMware.
Quando si utilizza il programma di installazione, il flag da utilizzare per le immagini dorate è /goldenimage 1.
Il flag golden image impedisce l'avvio e la registrazione del connettore sull'immagine di base. All'avvio successivo dell'immagine, il connettore si trova nello stato funzionale in cui è stato configurato dal criterio assegnato.
Per informazioni su altri contrassegni, è possibile utilizzare, vedere questo articolo.
Quando si utilizza il programma di installazione, il nuovo flag da utilizzare per le immagini golden è /goldenimage [1|0]
0 - Valore predefinito - questo valore non attiva l'opzione golden image e funziona come se il programma di installazione fosse stato eseguito senza l'opzione. Non ignorare la registrazione iniziale del connettore e l'avvio durante l'installazione.
C:\> CiscoInstaller_goldenimage.exe /R /S /goldenimage 0 [other options…]
1 - Installare come immagine dorata. Si tratta dell'opzione tipica utilizzata con il contrassegno ed è l'unico utilizzo previsto. Ignora la registrazione iniziale del connettore e l'avvio durante l'installazione.
C:\> CiscoInstaller_goldenimage.exe /R /S /goldenimage 1 [other flags here…]
È buona norma installare l'ultimo connettore per la preparazione dell'immagine dorata.
Utilizzare il flag /goldenimage 1 per indicare all'installatore che si tratta di una distribuzione di immagini dorate.
C:\> CiscoInstaller_goldenimage.exe /R /S /goldenimage 1
3. Implementare la logica dello script (se necessario) come descritto di seguito
4. Completare l'installazione
5. Bloccare l'immagine dorata
Dopo l'installazione delle applicazioni, il sistema viene preparato e Secure Endpoint viene installato con/goldenimageflag, l'host è pronto per essere bloccato e distribuito. Una volta avviato l'host clonato, Secure Endpoint si avvia e si registra nel cloud. Non sono necessarie ulteriori azioni per la configurazione del connettore a meno che non si desideri apportare modifiche al criterio o all'host. Se vengono apportate modifiche dopo che l'immagine finale ha completato la registrazione, è necessario riavviare il processo. L'indicatore impedisce l'avvio e la registrazione del connettore sull'immagine di base. Al successivo avvio dell'immagine, il connettore sarà nello stato funzionale in cui è stato configurato dal criterio assegnato.
Nota: se l'immagine dorata viene registrata su Secure Endpoint Cloud prima di poter bloccare la VM, si consiglia di disinstallare e reinstallare Secure Endpoint sulla VM dell'immagine dorata e quindi bloccare nuovamente la VM per evitare problemi di registrazione e duplicazione del connettore. Non è consigliabile modificare i valori del Registro di sistema per Secure Endpoint durante il processo di disinstallazione.
Sono disponibili due opzioni quando è necessario aggiornare un'immagine dorata per mantenere un connettore non registrato.
Processo consigliato
Processo alternativo
Questa sezione è costituita dai frammenti di codice che supportano il processo Golden Image e consentono di evitare duplicati dei connettori durante l'implementazione di Identity Persistence.
Il primo script, 'Setup', viene eseguito sull'immagine d'oro prima di clonarla. Deve essere eseguito manualmente solo una volta. Il suo scopo principale è quello di stabilire configurazioni iniziali che consentano il corretto funzionamento del seguente script sulle macchine virtuali clonate. Queste configurazioni includono:
rem Turn AMP to manual start
sc config CiscoAMP start=demand
rem Add host name to a system variable that we can check on startup
setx -m AMP_GOLD_HOST %COMPUTERNAME%
rem Add the startup script to the startup scripts
rem /rp password when there is a password
schtasks /create /tn "Startamp" /tr "C:\Users\XXXXXX\Desktop\VMWareHorizonAMPStartup.bat" /sc onstart /rl highest /np
Il codice dello script di installazione è molto semplice:
Riga 2: modifica il tipo di avvio del servizio di protezione dal malware in manuale.
Riga 5: crea una nuova variabile di ambiente denominata "AMP_GOLD_HOST" in cui salva il nome host del computer corrente.
Riga 9: crea un'attività pianificata denominata "Startamp" che esegue lo script di avvio specificato durante l'avvio del sistema con i privilegi più elevati, senza richiedere una password.
Il secondo script, 'Avvio', viene eseguito a ogni avvio del sistema nelle macchine virtuali clonate. Il suo scopo principale è quello di controllare se la macchina attuale ha il nome host dell'immagine d'oro:
echo "Current hostname: %COMPUTERNAME% vs %AMP_GOLD_HOST%"
if "%COMPUTERNAME%" == "%AMP_GOLD_HOST%" ( goto same ) else ( goto notsame )
:same
rem Do nothing as we are still the golden image name
goto exit
:notsame
rem Turn AMP to autostart
sc config CiscoAMP start=auto
rem Turn on AMP
sc start CiscoAMP
rem Remove environment variable
REG delete "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /F /V AMP_GOLD_HOST
schtasks /delete /tn Startamp
goto exit
:exit
Riga 2: confronta il nome host corrente con il valore "AMP_GOLD_HOST" memorizzato; se sono uguali, lo script passa alla "stessa" etichetta, altrimenti passa all'etichetta "non uguale".
Riga 4-6: quando viene raggiunta la "stessa" etichetta, la sceneggiatura non fa nulla poiché è ancora l'immagine d'oro e procede verso l'etichetta di "uscita".
Riga 8-16: se viene raggiunta l'etichetta "notsame", lo script esegue le azioni seguenti:
Nota: gli script contenuti in questo documento non sono ufficialmente supportati da TAC.
Nota: questi due script consentono l'avvio del servizio Cisco AMP in ambienti di macchine virtuali clonati. Configurando correttamente l'immagine Golden e utilizzando gli script di avvio, garantisce che Cisco Secure Endpoint venga eseguito su tutte le macchine virtuali clonate con la configurazione corretta.
Questa soluzione è costituita da uno script di installazione eseguito sull'immagine finale prima della clonazione e da uno script di avvio eseguito su ogni macchina virtuale clonata durante l'avvio del sistema. L'obiettivo principale di questi script è quello di garantire la corretta configurazione del servizio, riducendo al contempo gli interventi manuali. Questi due script consentono l'avvio del servizio Cisco Secure Endpoint in ambienti di macchine virtuali clonati. Configurando correttamente l'immagine Golden e utilizzando gli script di avvio, garantisce che il connettore Cisco Secure Endpoint venga eseguito su tutte le macchine virtuali clonate con la configurazione corretta
Fare riferimento alle sezioni Golden Image Setup Script Code e Golden Image Startup Script Code per il codice di script richiesto per l'implementazione di Golden Image su AWS Workspace.
Dopo aver eseguito lo script di installazione, è possibile verificare che le modifiche alla configurazione siano state distribuite correttamente.
Poiché questa azione è stata eseguita sull'immagine finale, tutte le nuove istanze avranno questa configurazione ed eseguiranno lo script di avvio all'avvio.
Con VMware Horizon, siamo stati in grado di identificare che le macchine virtuali secondarie, quando vengono create, vengono riavviate più volte come parte del processo di composizione di Horizon. Ciò causa problemi quando i servizi endpoint protetti vengono abilitati quando le VM figlio non sono pronte (non dispongono del nome NetBios finale/corretto). In questo modo, si creano ulteriori problemi con l'endpoint sicuro che diventano confusi e quindi il processo si interrompe. Per evitare di incorrere in questo problema, abbiamo trovato una soluzione per questa incompatibilità con Horizon Process che prevede l'implementazione degli script allegati sulla VM Golden Image e l'utilizzo della funzionalità di script post-sincronizzazione per VMware Horizon: https://docs.vmware.com/en/VMware-Horizon/2103/published-desktops-applications.pdf.
Di seguito sono riportati alcuni esempi di script.
Selezione di "Pool di desktop automatico"
Fare riferimento a: https://docs.vmware.com/en/VMware-Horizon/2106/virtual-desktops/GUID-6C3AB7F3-0BCF-4423-8418-30CA19CFC8FC.html
Selezione di "Cloni istantanei"
Fare riferimento a: https://docs.vmware.com/en/VMware-Horizon-7/7.13/virtual-desktops/GUID-D7C0150E-18CE-4012-944D-4E9AF5B28347.html
Selezione del tipo "Mobile"
Fare riferimento a: https://docs.vmware.com/en/VMware-Horizon-Cloud-Service-on-IBM-Cloud/21.1/horizoncloudhosted.deploy/GUID-34C260C7-A63E-452E-88E9-6AB63DEBB416.html
Nomi pool di desktop
Modello di denominazione orizzonte VMware: https://docs.vmware.com/en/VMware-Horizon/2103/virtual-desktops/GUID-26AD6C7D-553A-46CB-B8B3-DA3F6958CD9C.html
Immagine d'oro: questa è l'immagine d'oro effettiva VM.
Istantanea: questa è l'immagine che si desidera utilizzare per distribuire la VM figlio. Questo è il valore che viene aggiornato quando si aggiorna l'Immagine d'oro con qualsiasi modifica. Le altre sono alcune delle impostazioni specifiche dell'ambiente VMware.
7. Come accennato in precedenza, il Passaggio 10. nella procedura guidata è il punto in cui è stato impostato il percorso dello script.
8. Una volta completata e inoltrata, VMware Horizon inizia la composizione e le VM figlio vengono create.
Nota: per informazioni su questi passaggi, consultare la guida di VMware, che tuttavia è di immediata comprensione.
È possibile rimuovere le voci duplicate del connettore in alcuni modi:
1. Utilizzare la funzione di rimozione automatica sul portale degli endpoint sicuri per rimuovere le voci duplicate (inattive):
Questa impostazione è disponibile in Amministrazione > Impostazioni organizzazione
La Soglia computer inattivo consente di specificare per quanti giorni un connettore può passare senza effettuare il check-in nel cloud Cisco prima di essere rimosso dall'elenco della pagina Gestione computer. L'impostazione predefinita è 90 giorni. I computer inattivi verranno rimossi solo dall'elenco e tutti gli eventi generati rimarranno nell'organizzazione dell'endpoint sicuro. Il computer verrà nuovamente visualizzato nell'elenco se il connettore viene nuovamente archiviato.
2. Utilizzare i workflow di orchestrazione disponibili: https://ciscosecurity.github.io/sxo-05-security-workflows/workflows/secure-endpoint/0056-remove-inactive-endpoints
3. Utilizzare lo script disponibile esternamente per rimuovere gli UUID obsoleti/obsoleti: https://github.com/CiscoSecurity/amp-04-delete-stale-guids
Revisione | Data di pubblicazione | Commenti |
---|---|---|
7.0 |
08-Dec-2023 |
Aggiorna a script immagine dorata |
6.0 |
28-Jun-2022 |
È stata aggiornata una delle schermate di Horizon |
5.0 |
23-Feb-2022 |
Aggiunta della configurazione del file snapvol |
4.0 |
17-Nov-2021 |
Aggiornate le informazioni sugli script batch |
3.0 |
10-Nov-2021 |
Script inclusi nel corpo del documento. |
2.0 |
10-Nov-2021 |
Release iniziale |
1.0 |
10-Nov-2021 |
Versione iniziale |