vSphere inventory in visionApp

We’re using the tool visionApp ASG Remote Desktop in order to manage our RDP/ICA/SSH connections. It’s a handy tab remote connection tools used to connect to several server types (ESXi, Linux, Windows, …), and a free edition is available (limited, but free :p).

It’s just missing right now a synchronizing tool for vSphere inventory (in order to have vSphere inventory item in visionApp treeview). So we decided to make our own with the help of PowerCLI of course !

Here is a PowerCLI script that will create 2 *.csv files (one for ESXi hosts and one for virtual machines), with 2 parameters :

  • HostCSVFile : filepath for ESXi hosts csv export
  • VMCSVFile : filepath for virtual machines csv export

Both parameters are independant, you can use them as you wish, individually (in order to export only ESXi hosts or virtual machines) or together (in order to export both)

.\ESX4VRD.ps1 -HostCSVFile C:\Host.csv
 .\ESX4VRD.ps1 -VMCSVFile C:\VM.csv
 .\ESX4VRD.ps1 -HostCSVFile C:\Host.csv -VMCSVFile C:\VM.csv

Then you’ll just have to import theses files into visionApp to get back the same inventory than vSphere in the treeview :

You can download the script here : esx4vrd.ps1

vSphere 5.0 Hardening Guide

security

Yesterday was released the first draft for the vSphere 5 hardening guide listing best practices regarding security for your favorite hypervisor.

The final version will be available in the middle of May, and this draft will be used to allow community to give their feedback :

This is the public draft of the vSphere 5.0 Security Hardening Guide.  It is being posted to this Community in order to provide early access to interested parties, and to gather feedback.  The final version will be made available approximately in the middle of May.

If you usually read theses guides (which are very nice information source, we encourage you to read the previous ones if you didn’t already have), this time the guide will be available through an Excel sheet with 5 tabs instead of a regular PDF file :

  1. Intro
  2. VM
  3. ESXi
  4. Network
  5. vCenter

The Excel sheet is very handy for sorting but we rather regret the PDF file for a good coach read at night :p

There is also a release of a second Excel sheet with the comparison between 4.1 and 5.0 version, in order to see what has evolved (very handy) :

The 2 guides are available here :

Mass disabling vMotion

For our new memento post, during a fully messed-up mastered maintenance operation from our beloved network team, we had access problems on our platform within and between VLANs which had the effect that some ESXi servers could not communicate with each other randomly …

In order to avoid all vMotion tasks going wild, it could be useful sometime to just postpone the automated scheduling provided by DRS.

As usual, a little PowerCLI OneLiner will be handy :

$modifiedClusters = Get-Cluster | ?{ $_.DrsAutomationLevel -eq "FullyAutomated" } | Set-Cluster -DrsAutomationLevel PartiallyAutomated -Confirm:$false

And if you want to put back the parameter to FulyAutomated :

$modifiedClusters | Set-Cluster -DrsAutomationLevel FullyAutomated -Confirm:$false

If you have some specific cluster configurations (other than FullyAutomated), you can use the Cluster Profile script from our frenchy zozor (available on : [PSH] Cluster Profiles) in order to put all configuration back (of course, after your network team have followed the Network for Dummies : 101 workshop)

vCenter 5.0 Update 1 and service accounts

update50U1_serviceaccount_feat

As we explained in a previous post (vSphere 5.0 Update 1 is out), the 5.0 Update 1 is available for vCenter and ESXi (among others).

We had to deal with some issue updating our homelab. In fact, the update process went smooth and finished well, everything worked fine, except we saw a lot of strange information messages on our syslog server from the SQL :

We were glad to noticed them, because they were just INFO message, not even ERROR or WARNING … We can retrieve the same messages from the SQL server in Application Events logs :

What’s weird is that the vCenter Windows service already ran with an Active Directory service account, and the messages user were the computer name  DOMAIN\VC01$ …

After doing some tests in order to better understand what was producing theses messages (thanks to SQL Profiler by the way), we figured out it was the TOMCAT service (Windows service : VMware VirtualCenter Management Webservices) which generated theses denied access logs.

Once it was identified, we’re able to change the logon information for this service in order to set up the same account as the vCenter service. After restarting the Windows service, there is no longer any error information message :

So we read again the Update Release Note in order to find any explanation for this behavior, but so far we didn’t get any…

Page 1 sur 2212345…1020…Dernière page »