Spostare un client di Symantec EndPoint Protection da un gruppo ad un altro o da non gestito a gestito

Per spostare un client di Symantec EndPoint Protection da un gruppo ad un altro senza reinstallarlo possiamo usare l'utility SylinkDrop contenuta nella directory ..\Tools\NoSupport\SylinkDrop del cd d'installazione di SEP.

Innanzitutto è necessario esportare la politica di comunicazione dal nuovo gruppo del nuovo server di gestione:

1. Aprire la console di management di SEP ed esportare le impostazioni di comunicazione del gruppo;

2. Spostarsi sul pc da migrare; dall'utility SylinkDrop.exe , selezionare il file xml contenente la politica da importare;

Se il client è autogestito, è sufficiente importare le impostazioni di comunicazione. Aprire il client di SEP, e dal menù "Guida e supporto" selezionare "Risoluzione dei problemi". Quindi selezionare "importa" dalla sezione "Impostazioni di comunicazione" e scegliere il file xml esportato in precedenza dalla console manager di SEP.

Approfondimenti : Supporto Symantec

Apertura lenta di Symantec Backup Exec System Recovery

La console di gestione di Symantec Backup Exec System Recovery non permette di impostare un server proxy per il rilevamento del ThreatCon.

Se per navigare nella vostra rete aziendale si usa un proxy non trasparente è necessario disattivare il rilevamento dello stato del ThreatCon:

1. Chiudere l'interfaccia grafica
2. Editare il file UserPreferences.xml in "C:\Users\utente\AppData\Roaming\Symantec\Backup Exec System Recovery" (Windows 7/2008) oppure "c:\Documents and Settings\utente\Application Data\Symantec\Backup Exec System Recovery" (Win XP)
3. Impostare a "false" la variabile "ShowThreatCon"

In alternativa aggiungere una eccezione al proxy aziendale sul sito: http://securityresponse.symantec.com

Fonte: KB Symantec

Storage iSCSI bloccato e nodi vSphere disconnessi

Si è bloccato uno storage iSCSI (in questo caso un Buffalo) ed i nodi vSphere sono andati in panne? Le vm attive continuavano a funzionare regolarmente ma non è possibile raggiungere con l’infrastructure client i nodi e dal vcenter risultano disconnessi.

Una volta riavviata lo storage iSCSI potrebbe essere necessario rieseguire un rescan dello stesso dagli hypervisor:

Dalla console SSH:

# esxcfg-mpath –l

Si ottiene la lista dei vmhba. Qualcosa del genere:

Device Display Name: IET iSCSI Disk (t10.945445000000000000000000100000000000000020000000030323431453235324633354)

Adapter: vmhba34 Channel: 0 Target: 0 LUN: 0

Adapter Identifier: iqn.1998-01.com.vmware:vSphere01-1f93b11d

Target Identifier:

Plugin: NMP

State: dead

Transport: iscsi

Una volta individuato l’hba morto eseguire il rescan:

# esxcfg-rescan vmhba34

Device Display Name: IET iSCSI Disk (t10.945445000000000000000000100000000000000020000000030323431453235324633364)

Adapter: vmhba34 Channel: 0 Target: 2 LUN: 0

Adapter Identifier: iqn.1998-01.com.vmware:vSphere01-1f93b11d

Target Identifier: 00023d000001,iqn.2004-08.jp.buffalo:iSCSI-CB-02-0024A525B63F:iSCSI-CB02,t,1

Plugin: NMP

State: active

Transport: iscsi

A questo punto dovremmo riuscire a collegarci al singolo nodo con il vic altrimenti potrebbe essere necessario riavviare i servizi di management (Se sono state impostate opzioni di avvio/spegnimento automatico delle vm il riavvio dei servizi di management ne provoca l’arresto)

# service mgmt-vmware restart

# service vmware-vpxa restart

Una volta collegati al vic, se le vm rimangono inaccessibili, avviare un rescan degli hba per rieseguire il mount dei volumi vmfs

A partire da esx 4 update 1 è possibile applicare un workaround che dovrebbe minimizzare l’impatto di un hba morto sull’infratruttura.