VMware has rolled out a few updates this week with the release of vSphere 5.5 Update 1. The majority of the products involved all got some sort of bump/patch as well as the addition of VSAN. Not to be outdone, Alan and his team also released PowerCli 5.5 R2 (Build 1649237). It is wonderful to see grand improvements in a product I use everyday.
A full rundown of the new features and download link can be found here.
It just may be time to give a serious look at updating to PowerShell 4.0 as with this update, PowerCli is fully compatible. Time to start looking at other plugins as well and determine what dependencies might have issues.
Another one of the new features that caught my eye was this:
64 bit Support
The New/Set-OSCustomizationSpec cmdlets have been updated to work in 64-bit PowerShell and no longer require running in a 32-bit PowerShell environment.
This will help my VM Deployment script as you will now longer have to run in 32bit mode. I’ll be checking this out and updating shortly.
Home labs seem to be a hot topic recently so I thought I would share my setup and experience. Many people design their home labs in different ways. Some like to use server level equipment that resides on the HCL while others like myself prefer to keep a little change in the bank and go for more of a whitebox, desktop setup. The challenge with a whitebox setup is ensuring all of your components are going to work as expected with minimal fuss. Another difference in my setup is what I call the waterfall effect. In order to maximize the investment in multiple systems, I pass along the hardware down the chain. So what was my previous host, now becomes my desktop and my desktop moves down the line (whether it be used for a NAS, kids, etc). This allows me to refresh the host and cascade the hardware down the line.
A few posts back I described how you can document your Veeam backup job settings. This gives a great overview, especially if you have many jobs to keep track of. As I mentioned, I had found a few inconsistencies across jobs and in this post I’ll show how to update all jobs via a small script. You can imagine the time saved by not having to open each and every job, check the settings and update if needed.
Changing passwords is always one of those fun tasks for any admin. It becomes even more challenging when your a Windows admin over hundreds of individual servers that are not part of the same domain. Here’s my take on a PowerShell script to change the password of a local user on a remote system (or many remote systems), regardless of domain status.
A few months back I came across this article from Luca Dell’Oca – Check multiple job settings in Veeam Backup & Replication with Powershell. As he describes, this is a great way to get a good view of your backup jobs. When you have a few hands in the mix, over time with lots of jobs, human error is going to happen. A missed check box here, incorrect setting there. You’ll be surprised what you may find the first time you look. So I decided to finally take his advice and create a quick report that dumps the job details to a csv file.
Find the latest version here.
Here’s a PowerCLI script I have been playing with for a while that helps with deploying multiple VMs.
Highlights include deploying both Windows and Linux VMs via Customization Specification enabling the setting of hostname, IP address, etc. The script uses help from LucD to deploy using -RunAsync which speeds things up tremendously.
It’s a bit lengthy, with a rudimentary level of logging and error catching but has served me well.
Find the latest version here.
Here’s another case of taking a script that someone has shared and putting your personal tweaks into it.
If there was an area in which I wish Veeam would improve, it would be reporting. Though their answer is VeeamOne, it’s a bit much if you just want the additional backup reports. Fortunately this can be overcome with some creative Powershell. I started with a report called vPowerCLI v6 Army Report which can be found here. I had used this report for quite a while until v7 came along and broke a few items. I decided to take the opportunity to not only fix the issues (where I could) but also add some information to the report. I had also been looking at the SAMReports found here and decided to combine a few bits. Lastly, Tom Sightler had a post here that added the ability to report back VMs that had not been backed up within the given time frame – very nice. I can’t say enough about the original authors, without which, I never could have come up with such a report in the end.
This is something that has bugged me for a while. Though I absolutely love what Veeam brings to the table as far as a backup product is concerned, one issue I have observed in a (fairly) large environment was with the default log file location – you guessed it – C:\ProgramData\Veeam\Backup
There were times when I’ve witnessed over 40GB of log files filling up the C: drive. It becomes a chore to keep an eye on it and weed them down when needed. Though there were previously options to reduce the amount of log files kept, we have needed them for support purposes in the past so I was reluctant to trim them to tight.
Find the latest version here.
One of the best things about Powershell and the community is the ability to easily find what others have done and improve upon it or tweak it for your own needs. This was the case with a script I found in the Veeam forums a few months back to backup a single VM using Powershell. It worked great (with a minor issue described below) but unfortunately was broken after upgrading to v7. I was able to identify the issues causing it to fail but was not able to rectify them all. Back to the forums I went and with a little help from the folks at Veeam we were back in business.