The other day I was asked to collect some statistics on our Veeam Backup & Recovery server from as many VM Backup jobs as possible. The environment has roughly 70 scheduled jobs thats run either daily or weekly. After searching around a bit first I could not find any current solution or built in method to retrieve the info I needed to collect in a quick or automated way. First ideas were to either somehow grab the info via SQL queries from the Veeam database, or to rather take a sampling of 10-20 different types of jobs and their backup sessions over one normal incremental run day, and one normal full backup day (Manually collecting this data from email reports would be quite a slow process).
After browsing around the Veeam Community Forums I suddenly remembered that there was a PowerShell module that Veeam Include with B&R. I read the basic documentation and got acquainted with a few simple cmdlets. I wanted to build a report, that would loop through every single Veeam B&R Job we have, and grab data from the last 7 backup sessions of each (daily backups), therefore giving me a good idea of both full backup and incremental backup runs performance, times taken etc… My first attempt at a script got me almost all the way there (tried during spare time in my evenings!) – I was however having trouble matching backup session data with the right day’s backup file stats – sometimes the ordering was out, and I would get metrics back for a backup file that was not from the correct day. Before I was able to resolve this myself, help arrived from “ThomasMc” over at the Veeam Community Forums. (Thanks Thomas!) We got a script together that was able to match up sessions correctly. I then added a few more features, as well as some nice HTML formatting and the ability to grab statistics for all jobs instead of just one sample job. The resulting script gets the following info for you:
Index (1 = the last backup sesion, 2 = the day before that, etc)
Job Name
Start time of job
Stop time of job
File Name (Allows you to determine if the job was a full or incremental run)
Creation Time
Average Speed MB – average processing speed of the job
Duration – time the job took to complete
Result – Success/Warning/Failed (Failed is highlighted in red)
Here is an example of the report run on my Veeam Backup & Recovery Lab environment at home (Thanks to Veeam for the NFR licenses they gave out to VCPs earlier this year!)
[download id=”1″]
[download id=”8″]
So, to run the above script, launch a PowerShell session from within Veeam B&R (Tools -> PowerShell). This will make sure your PowerShell session launches with the Veeam Automation/PowerShell snapin. Execute the script and you’ll get an HTML file output to the root of your C:\ drive. By default, all jobs you have in Veeam will be detailed. If you wish to sample a specific job, or a job with a certain word/phrase in it, adjust the -match parameter for the Get-VBRJob cmdlet line near the top of the script. The default setting is an empty string – i.e. “”. To change how many sessions the the script fetches for each backup job, just change the “$sessionstofetch” variable defined at the top of the script.
I have added comments throughout the script for those interested in how it works. Lastly, you could also quite easily modify this script to e-mail you the report, or even run it as a scheduled task. Let me know if you need help doing this and I’ll gladly modify it as required.
vSphere 5.0 is a great step up in terms of new functionality and features from vSphere 4.1. VMware have introduced some awesome new features that are definitely worth making use of by getting your environment upgraded. A few that caught my eye are sDRS (Storage DRS), Storage vMotion of VMs with Snapshots, and of course the ability to now run those “monster” VMs (much larger VMs supported now).
Before you take the plunge and upgrade, I would recommend doing a good amount of reading best practises documentation and planning. I have linked to two very useful documents from VMware that will help with your planning. There is an upgrade checklist which you can work through systematically, as well as a best practises whitepaper which helps explain the process in good detail with some great screenshots. In my post I will be going through the process I followed to upgrade my lab environment from vSphere 4.1 to 5.0. As it is a lab environment, I didn’t do too much in terms of planning, but for production environments, this would be a good idea as it never hurts to be prepared.
As part of the process, I also set up a brand new VMware Update Manager server in a VM once my vCenter server was updated to 5.0 to aid upgrading my ESXi hosts from 4.1 to 5.0. I only have three virtualised ESXi hosts running in my lab cluster, so it would have been quicker to use the ISO and do them manually, but I wanted to go through the process myself as I don’t spend enough time on Update Manager in my work environment.
First of all, make sure you are running vCenter Server 4.0 or above. If you are, then chances are you’ll be running a 64bit OS. Just be sure to check though, as it is possible to run vCenter Server 4.0 on a 32bit OS. If you have vCenter Server running on a 64bit OS, then you are good to go, otherwise you’ll need to take a slightly more complicated route, which involves creating a new vCenter server on a 64bit OS, installing vCenter 5.0 and then migrating the existing database over to the new server. For specifics there is documentation on this process in the vSphere 5.0 Upgrade Guide from VMware.
Next up, check that the other minimum requirements are met; especially in terms of CPU and RAM.
Backup your existing vCenter database – this is clearly a very important step. Make sure you back up everything. Before I upgraded my lab, I took a backup of my vCenter SQL 2005 Express Database as well as my SSL certificates. The vCenter 5.0 upgrade wizard will remind you about this too. Keep your backups safe. For my lab vCenter database, I simply installed Microsoft SQL Server Management Studio Express (free) and used the backup option in there to backup the database as well all other SQL system databases just to be safe.
Also take a backup of your vpxd.cfg file. On a 2003 Server this would by default be located under %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\ or for a 2008 Server, it would by default be under C:\ProgramData\VMware\VMware VirtualCenter\
Now you should look at your Database options and upgrade path. Review the Prerequisites documentation in the Upgrade Guide for databases and ensure yours is supported. If it is not, then be sure to follow the correct procedure to migrate to a supported one.
Ensure your vCenter Server has a 64bit DSN – it will already have one if you are running vCenter Server 4.1 (as this is 64bit only) but could be different if you are still on vCenter 4.0.
If you are running a Microsoft SQL Database (as I am in my lab), ensure your System DSN under ODBC connections is using the SQL Native Client driver.
Ensure you have Microsoft .NET 3.5 SP1 and Windows Installer 4.5 or greater installed on your vCenter server.
If you already have a running vCenter 4.x deployment then you shouldn’t have too many more things to sort out, but a few other fairly obvious ones to check (taken from the Upgrade Checklist document I linked above) are:
Note down all your database login credentials and ensure the vCenter database login has db_owner permissions.
Make sure your current installation path of vCenter does not have any commas or periods in it. (I assume this can cause trouble for the upgrade!)
Ensure your vCenter Server name is not longer than 15 characters and is registered correctly with your AD Domain’s DNS.
Ensure all required ports in/out of the vCenter server are open.
Make sure any additional plug-ins you use for vCenter Server are compatible with 5.0 – also make sure you re-enable or reconfigure these post-upgrade.
Make sure you know the rest of your hardware is compatible with vSphere 5.0! i.e. check your ESX / ESXi hosts are compatible and there will be no issues there. You can use the vCenter Host Agent pre-upgrade checker utility included with the vCenter 5.0 installation media for this.
At this point, if you are happy to proceed and have your backups safe, load up the installation media for vCenter 5.0 and begin the installer. Start the installation wizard for vCenter 5.0 – this wizard does a great job of guiding you through the upgrade process and asking what configuration options you would like. They are fairly straight forward – choose as applicable to your installation. I have captured screenshots of the installer process I followed for my lab – most options for me were fine to leave on their defaults. See the following series of screenshots:
The main vCenter 5.0 Installation menu
After this wizard is completed the upgrade will begin. If applicable your vCenter database schema will also be upgraded and soon you’ll be up and running with vCenter 5.0. Note that this upgrade does require your vCenter service be down for the duration of the installer upgrade process – how long this is really depends on how big your vCenter DB is. My lab vCenter upgrade took about 25 minutes to run through, but its inventory is very small – for most production environments with up to 100 VMs or so I wouldn’t see this taking longer than 45-60 minutes in most cases, but remember its dependant on various other factors. Once the installer is finished, it would be a good idea to also update your vSphere client to access your vCenter server with – install the version that comes with your vCenter 5.0 installation media and login again. You should see your inventory as per usual and hopefully all will be well. One thing I noticed immediately following my upgrade was that I had an alert for my datastores – I blogged about this over here actually. This is only really applicable if you are running a lab environment (or small production) with only 1 or 2 shared datastores. Other than this, the rest of my VMs were all running happily on their respective ESXi hosts and everything else was just fine.
So coming up in Part 2, I will cover the next step in upgrading your environment to vSphere 5.0 – the ESX(i) hosts along with a couple of different methods of doing this. If there is anything that I have missed, or you have any tips or additional info, please feel free to update using the comments section.
The other day I needed to add three NFS datastores to a bunch vSphere ESX hosts in a specific cluster. Rather than go through each host in vCenter individually, adding the datastore using the Add Storage wizard, I thought I would script the process in PowerCLI and get it done in a more automated fashion. Using PowerCLI automation, this helped me save some time. I had about 7 ESX hosts to add the Datastores to, so doing this manually would have taken twice the time it took me to whip up this script and run it. Plus, this can be used in the future for other Datastores or other clusters by simply modifying the script and re-running it.
Here is the script:
# PowerCLI script to add NFS datastores to ESX/ESXi hosts in a specified Cluster
# Only does this to hosts marked as "Connected"
$hostsincluster = Get-Cluster "Cluster 1 - M" | Get-VMHost -State "Connected"
ForEach ($vmhost in $hostsincluster)
{
""
"Adding NFS Datastores to ESX host: $vmhost"
"-----------------"
"1st - MER001 - NAS-SATA-RAID6 (Veeam Backups)"
New-Datastore -VMHost $vmhost -Name "MER001 - NAS-SATA-RAID6 (Veeam Backups)" -Nfs -NfsHost 10.1.35.1 -Path /share/VeeamBackup01
"2nd - MER002 - NAS-SATA-RAID6 (ISOs)"
New-Datastore -VMHost $vmhost -Name "MER002 - NAS-SATA-RAID6 (ISOs)" -Nfs -NfsHost 10.1.35.1 -Path /share/Images01
"3rd - MER003 - NAS-SATA-RAID6 (XenStore01)"
New-Datastore -VMHost $vmhost -Name "MER003 - NAS-SATA-RAID6 (XenStore01)" -Nfs -NfsHost 10.1.35.1 -Path /share/XenStore01
}
"All Done. Check to ensure no errors were reported above."
So the script above looks for ESX or ESXi hosts in a specified cluster that are in a “Connected” state – i.e. they are not disconnected in vCenter (we wouldn’t want to try add Datastores to hosts that don’t exist!). So we use the Get-Cluster cmdlet to say we are only concerned with hosts in this particular cluster (specified by the “Cluster 1 – M” name in my case. Obviously change this to the name of your cluster you will be working with.) We then use Get-VMHost -State “Connected” to list all of the hosts in this cluster that are in a connected state. In my example I had 2 x ESX hosts that were in a disconnected state, and I didn’t want to include these, so this part worked nicely. This list of hosts in then assigned to the $hostsincluster variable. We then use the ForEach loop to iterate through each host in this list of hosts and do the bit in-between the curly brackets for each host.
In my case you may notice that I am adding Datastores from the same NFS (NAS) server. They are just being mounted to different paths on the server and being given different names. I had three Datastores to add, so therefore use the New-Datastore cmlet three times for each host. You will need to adjust this to your needs – maybe you just need to add one datastore to each host, therefore remove the two extra New-Datastore cmdlet parts. Also remember to adjust the -NfsHost and -Path sections to suit your own environment.
We could improve on the above script by making it more customisable for future / others to use. Lets give that a quick go then and use variables to define everything at the top of the script. This means that the variables can be changed at the top of script without worrying too much about reading through the whole script to check for things to change. We’ll also add a Connect-VIServer cmdlet in there in case you have not already connected to your vCenter server and authenticated in your PowerCLI session that is running the script.
# PowerCLI script to add NFS datastores to ESX/ESXi hosts in a specified Cluster
# Only does this to hosts marked as "Connected"
# Define our settings
$vcserver = "vcenter01"
$clustername = "Cluster 1 - M"
$nfshost = "10.1.35.1"
$nfspath1 = "/share/VeeamBackup01"
$nfspath2 = "/share/Images01"
$nfspath3 = "/share/XenStore01"
# Connect to vCenter server
Connect-VIServer $vcserver
# Do the work
$hostsincluster = Get-Cluster $clustername | Get-VMHost -State "Connected"
ForEach ($vmhost in $hostsincluster)
{
""
"Adding NFS Datastores to ESX host: $vmhost"
"-----------------"
"1st - MER001 - NAS-SATA-RAID6 (Veeam Backups)"
New-Datastore -VMHost $vmhost -Name "MER001 - NAS-SATA-RAID6 (Veeam Backups)" -Nfs -NfsHost $nfshost -Path $nfspath1
"2nd - MER002 - NAS-SATA-RAID6 (ISOs)"
New-Datastore -VMHost $vmhost -Name "MER002 - NAS-SATA-RAID6 (ISOs)" -Nfs -NfsHost $nfshost -Path $nfspath2
"3rd - MER003 - NAS-SATA-RAID6 (XenStore01)"
New-Datastore -VMHost $vmhost -Name "MER003 - NAS-SATA-RAID6 (XenStore01)" -Nfs -NfsHost $nfshost -Path $nfspath3
}
"All Done. Check to ensure no errors were reported above."
So as you can see we have now defined the name of the cluster, our NAS/NFS server and three paths to different NFS shares at the top of the script, then just referenced these variables later on in the script. This means we can now easily adjust the defined variables at the top of our script in the future to work with different clusters, NAS/NFS servers or paths. The output of your final script when run should give you a nice view of what has happened too. It will output that it is adding NFS Datastores to each host it iterates through, and if it comes across any errors those should be marked in red as PowerShell / PowerCLI normally would do, allowing you to amend or update any details as necessary. PS, don’t forget to change the name of each Datastore in the script to something of your own choice (it is the part after the -Name parameter in each New-Datastore line).
Here is the download for the full script (with latest improvements):
On my quest to learn more about PowerCLI, I have been playing around with some more cmdlets in my lab. As a simple task, I have figured out how to tell ESX or ESXi hosts to enter and exit maintenance mode. Here’s how we do this. First of all ensure you are connected to your vCenter server instance using Connect-VIServer ServerName.
So now that we know the basics of setting the state of a VMware host, how about we get slightly more technical and perform one of the above operations on a bunch of hosts in one go? Powershell / PowerCLI is all about automation after all! Note that in the following script, I have also include a simple “if / else” statement to prompt the user running the script manually as we are about to send all ESX(i) hosts into maintenance mode! Use this at your own risk of course, it is just for demonstration purposes. You may want to modify to select hosts to enter maintenance mode on certain criteria. For example, all hosts in a particular cluster, or all hosts with a certain property. Here is the script I would use to perform the operation on all the ESX(i) hosts found in vCenter:
$VCServer = “yourvcservername”
Connect-VIServer $VCServer
$confirm = Read-Host “Are you sure you want all hosts to enter maintenance mode? (type yes to continue) “
if ($confirm -eq "yes")
{
Get-VMHost | Set-VMHost -State "Maintenance"
}
else
{
"Script aborted (you didn't confirm by typing yes)"
}
Once the script is executed, you should get a progress indicator whilst hosts are being dealt with. Afterwards you’ll get some output from each host listing its relevant Connection Status and statistics. Like so:
In the above example, we set some variables, and use some basic logic checking with an IF ELSE statement and an equal to (-eq) operator. We also see how to perform a few operations on ESX or ESXi hosts. I hope this helps anyone starting out with PowerCLI. Please do leave any comments, suggestions or improvements in the comments section!
Exchange 2010 has definitely simplified the process of applying SSL certificates to your mail services such as Outlook Web Access/App and Exchange ActiveSync. No more muddling about with IIS is required and you can do everything via the Exchange Management Console (GUI) too. I’ll also list a cmdlet at the end for generating a CSR if you wish to go the Exchange Management Shell way.
Exchange Management Console steps:
Open the Management Console and from the summary / home tab click on “Manage databases”. Now on the list in the left of the Management Console, select “Server Configuration”, then in the list of Actions on the right look for “New Exchange Certificate” and select this.
A wizard will popup and you can begin setting up your new Certificate Signing Request (CSR). Fill in a Common / Friendly name for the certificate. I used the same name as would be used for the actual certificate itself so that I can easily identify it.
Continue the wizard. I won’t be using a wildcard certificate so I will leave the “Enable Wildcard Certificate” selection unchecked.
The next section allows you to select the services you want to use with your SSL / describe the Exchange configuration for the CSR that we are going to generate. Expand out the sections and you’ll see that some are pre-populated for you. Check over this information and tick any services that you want to use. I want this SSL certificate for Outlook Web App and Exchange ActiveSync for mobile devices, so I checked the options for “Outlook Web App is on the Internet” and “Exchange Active Sync is enabled”. In each of those cases, I entered the A name record for the services (The external name used to connect to the services) – i.e. mail.shogan.co.uk – this is important and it is what your SSL certificate will be securing, so double check that it is correct.
Continue by entering some administrative / contact details for your company, choosing a location to the save the CSR request file, then finishing the wizard off. Now, go to your SSL provider’s site and purchase a new SSL certificate. I am using a basic SSL123 certificate in this case from Thawte.
Go through the steps of purchasing the certificate, and you’ll get to a point where they ask you for the CSR – paste the exact text of your CSR generated in Exchange’s Management Console into the CSR text box on the website and get your certificate ordered. When it is approved and emailed back to you, save the .cer certificate file on your Exchange server.
Go back to the management console, select “Server Configuration”, select the certificate under the “Exchange Certificates” tab and in the Actions view on the side, select “Complete Pending Request”. Browse for the completed SSL certificate your certificate issuer sent you and finish by completing this wizard.
You now just need to highlight the certificate under “Exchange Certificates” once again, and under the “Actions” panel, click “Assign Services to Certificate”. In this wizard, select your relevant Exchange server name, then click next. On the next screen, select “Internet Information Services”, then “Next”. Check the summary page looks correct then finish the wizard.
Your SSL certificate should now be configured and ready for use. Browse to the URL of your Outlook Web App service via https. You should find that you don’t get a certificate warning, and clicking the security icon in your web browser to view the site certificate should show that it is valid and providing encryption.
Generate a CSR using the Exchange Management Shell.
You can also generate a CSR using the cmdlet below. Just substitute the relevant values with your own. Be sure you aren’t putting any incorrect values in when using this though as you don’t have a nice GUI to explain things to you as you do with the Exchange Management Shell.
The above cmdlet will save the CSR file to C:\mail_shogan_co_uk. You would then copy and paste the text of that file into your SSL certificate provider’s site as part of your SSL purchase process. The cmdlet uses some values that will need to be unique to your organisation – here are the value explanations of parts of the above cmdlet:
c = country code
s = city
l = province/state
o = organisation name
ou = organisational unit
cn = common name the SSL certificate is to be provided for
The cmdlet won’t give you any output if it works correctly, but you’ll be able to see the CSR in the Exchange Management Console if you refresh it at this stage.
That is basically it – the steps above should help you secure some Exchange services such as OWA or ActiveSync with an SSL certificate from a trusted authority.