Utilizzo di Karspesky SVM e Vshield Endpoint per client vdi citrix o view

Con la versione 5 di vsphere, vmware anche nelle versioni Enterprise Plus NON INCLUDE la versione 5 di Vshield.

In pratica nel boundle è incluso una versione “thiny” di vshield (infatti è la 1.0) che non include le novità introdotte nella nuoa versione del prodotto tra vui il vshield endpoint, prodotto veramente utile in architetture antivirus dedicate al vdi.

Vshield endpoint infatti permette di attivare la funzionalità avanzata di ESXi 5 che, comunicando con driver aggiuntivi installati sui tools delle vm windows, fà da tramite con appliance virtuali di terze parti (esempio Karsperky Security for virtualization).

A cosa serve? In pratica i client vdi non hanno nessun agent antivirus installato e non devono più aggiornare le definizioni antivirus poichè pensa a tutto l’appliance Karspesky SVM che comunica con le vm tramite i vmtool (in realtà tramite il vshield endpoint thin agent).

Una cosa grandiosa per i motivi che di certo capirete benissimo e che non stò qui a spiegarvi.

Costo orientativo:

pacchetto da 25vm = circa 1500$ (vmware vshield endpoint)

antivirus per ogni vm = circa 10$  ( Karsperky Security for virtualization Desktop European Edition)

Facendo un esempio di 100 client vdi, si spenderebbe di antivirus (di listino) sui 7000$…che facilmente si andrebbe a negoziare a 4000/5000 euro.

APC UPS segnala sempre un runtime basso nonostante la sostituzione delle batterie e/o della management card

Esiste un algoritmo interno del “sistema operativo” di APC che fà sì che nonostante venga sostituito il pacco batterie, non viene aggiornato il valore relativo alla età del pacco stesso. Siccome le batterie sono materiali di consumo, il runtime è calcolato tenendo presente sia la capacità che l’età. Per ripristinare l’età corretta và effettuata spesso una procedura manuale che riporto tradotta tramite google al volo (per le nostre APC il valore da impostare per un pacco batteria nuovo è 7F):

GUIDA ALLA CONFIGURAZIONE DEL KMS (Microsoft Key Management Service)

Introduzione

Il KMS è un sistema client/server che permette l’attivazione automatica di tutte le copie Volume Licensing della rete locale. Una macchina chiamata “KMS host” gestirà localmente le richieste e attiverà tutti i “KMS client” che ne faranno richiesta. Il KMS host può configurato su un sistema operativo Windows Seven, Server 2008 o Server 2003 ma in quest’ultimo caso andrà aggiunto il componente KMS reperibile sul sito: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=4766

Il procedimento per creare questa infrastruttura è molto semplice, in quanto basta promuovere una macchina a “server KMS” installando la chiave KMS che si trova sul sito VLSC. I client KMS sono in grado di trovare il server KMS in maniera autonoma tramite una risoluzione DNS. I client KMS sono tutti i sistemi operativi in versione Volume Licensing.

Rimuovere il limite di una singola sessione in RDP con Windows 2008

In Windows 2008 di default non è più possibile avere due sessioni desktop remoto attive in contemporanea, per ripristinare questa possibilità impostare  la policy sottostante su “Disabled”:

Restrict Remote Desktop Services users to a single remote session

Questa impostazione è disponibile in:

Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections

ESXi ed IBM : boot from iSCSI lun

Le seguenti indicazioni sono valide dalla versione 4.1 di ESXi in poi che supporta il boot from iSCSI lun.

Fondamentalmente il consiglio principale è di aggiornare il firmware del bios del vostro server/lama IBM alla ultima versione accertandovi che sia supportato il boot from iscsi.

Dopodichè potete configurare nel bios in modalità legacy support la parte network, ricordando che viene usato un mac address “reale” per ogni scheda di rete fisica ed uno “virtuale” per ogni iscsi initiator su quella stessa scheda di rete.

Questo significa che in una configurazione base occorre  lavorare sulla prima nic fisica nel bios.

DR tool virtual appliance

BETA TEST VERSION RELEASE #2 READY – NOW!
(resolved window-freeze issue and added “stop it” button in test process)

ENJOY IT.

Procedura TEST DR con Site Recovery Manager per mission critical applications: Cluster Microsoft per MS SQL

Alquanto laborioso è testare il Vostro ambiente Cluster Microsoft in ambito di DR anche se su VMWare e Netapp. Sicuramente è più facile testarne la funzionalità relizzando un vero recovery per motivi legati principalemente alle vlan ed alle raggiungibilità dei dns per i servizi. Inoltre se avete introdotto Site Recovery Manager successivamente all’esistenza del vostro cluster, non avrete implementato e migrato a soluzioni tipo Snapmanager per SQL…che vi faciliterebbe nella mappatura delle LUN dei volumi RDM.

La condizione in esame è che voi abbiate le LUN snapmirrorate ma non il volume vmfs dei pointer vmware alle LUN stesse (tanto è inutile mirrorarlo poichè le signatures delle LUN cambiano da un sito all’altro).

Premesso quanto sopra, ecco come testare senza un vero recovery il tutto.