mercoledì 20 aprile 2011

Upgrading to VMware Data Recovery 1.2.1

Fonte : VMware Data Recovery 1.2.1 Release Notes

Download : VMware Data Recovery 1.2.1

Previous Data Recovery installations are likely to have existing restore points that should be preserved. To ensure these restore points are preserved, it is important to use the following processes described in this section.

Begin the upgrade process by installing the latest Data Recovery plug-in for the vSphere client.

To install the latest Data Recovery plug-in

  1. Close the vSphere Client.
  2. Use the Add or Remove Programs item in the Control Panel to uninstall any previous versions of theVMware Data Recovery plug-in.
  3. Start the latest Data Recovery plug-in Windows Installer File (.msi) to install the Data Recovery plug-in.

Next you must deploy the new Data Recovery appliance without deleting existing restore points. If the destination volume for the deduplication store is a virtual disk, do not to delete the appliance. Deleting the appliance deletes the disks connected to the appliance. This would cause the backup data stored in the deduplication store to be deleted. To avoid such an issue, complete the following procedure:

To upgrade Data Recovery appliances with virtual disks or RDMs

  1. IMPORTANT: Before upgrading to VMware Data Recovery 1.2.1, make sure all operations in your current environment have completed before shutting down and performing the upgrade. If an integrity check or reclaim operation is running, allow the operation to complete. Do not CANCEL these operations.
  2. When no operations are running, unmount the destination disk and shut down the Data Recovery appliance.
  3. If you want to save the original Data Recovery appliance, rename it in some way. For example, you might rename an appliance called VMware Data Recovery to VMware Data Recovery - OLD.
  4. Deploy the new appliance.
  5. Use the datastore browser to move the disk containing the deduplication store to the same location as the new appliance.
  6. Edit the settings of the new appliance:
    1. Choose a Add > Hard Disk.
    2. Choose Use an Existing Virtual Disk
    3. Browse to the data store and select the virtual disk which is connected to the older appliance as destination.
    4. Choose the SCSI address.
    5. Choose Finish.
  7. Power on the new appliance.
  8. Edit the settings of the older appliance:
    1. Choose the hard disk which is used to store deduplication store.
    2. Select Remove, leave default option for remove from virtual machine. DO NOT select remove from virtual machine and delete files from the disk.
    3. Click OK.
  9. Configure networking on the new appliance.
  10. Use the Data Recovery vSphere plug-in to connect to the backup appliance.
  11. Complete the getting started wizard. Note that you should mount the desired disk, but do not format it. Formatting the disk will erase all deduplication store data. The disk to be used may not display the expected name, but the proper name will be displayed after the wizard is completed.
  12. You are prompted to restore the configuration from the deduplication store. Select Yes if you want to restore the jobs and backup events and history.
  13. The client disconnects from the appliance after the configuration is restored and then reestablishes the connection. This may take several minutes.
  14. Once the client reconnects, check to see if a Reclaim or Integrity check operation has started. If so, STOP the operation.
  15. Immediately click Configure > Destinations and perform an integrity check on all mounted destinations.
  16. Verify the backup job configuration.
  17. Remove the older VMware Data Recovery appliance from the inventory.

Note that damaged restore points may cause the upgrade to fail. If you receive the message "Could not restore the Data Recovery appliance configuration" re-add the destination to the original Data Recovery appliance and then run an integrity check to clean up any damaged restore points. After the integrity check completes successfully, repeat the upgrade process.

martedì 19 aprile 2011

server SSH su Windows 2008

  1. Scaricare ed installare copssh - OpenSSH for Windows
  2. Aggiungere gli utenti abilitati al pannello di copssh

  3. Consentire agli utenti (solo se non administrators) l'accesso locale

lunedì 18 aprile 2011

Ripristino partizione di boot di Windows 7

Il comando per ripristinare una partizione di boot di Windows 7 danneggiata :

bootsect /nt60 SYS /mbr

Fonte ed istruzioni dettagliate: www.sevenforums.com

martedì 22 febbraio 2011

Musica per le mie orecchie....


Chi non ha avuto a che fare con l'ignobile Hp Colorado......

lunedì 24 gennaio 2011

Rimuovere la password del BIOS (Samsung e non solo)

La password di accesso al BIOS e quella per lo sblocco del HDD possono essere ricavata a partire dall'id che compare dopo 3 immissioni errate:

A questo indirizzo è possibile scaricare dei generatori di password per diversi produttori. Dopo aver scompattato l'archivio compresso è sufficiente avviare l'eseguibile ed inserire l'id:


mercoledì 27 ottobre 2010

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

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.