This is likely my last blog for the year. At least right now I think that. But I wanted to get this done. This is the end of the PowerCLI Series – at least for now. As I find or hear about cool scripts I will share them. In particular, I will be sure to share the cool ones that I actually use. But I wanted to do something special for this article. I am going to help you get vCheck going. It is a little tricky but is very much worth it. But what is vCheck you ask? The original author is Alan Renouf and you can find his info about vCheck here. However, it is a PowerShell HTML framework script. The idea of this script framework is to provide you with an email report each morning just before you get into work, about the status of your environment. To see what the report looks like you can click here. Since it is a framework, you can add to it, for example if you have vCD in your environment you can add in a module so that the script will report on vCD as well. By default it is a vSphere script.
But lets make it work and that way you can see for yourself how useful it is to have it waiting for you before you get to work!
Things to do first
You can find the bits here. This is the download link on the GitHub vCheck page which is here. As well, you should have an AD account that will be able to execute this script, as well as look at event logs inside the OS of the vC. I am going to use a service account that has local admin rights on both boxes – where I execute the script, and the vC. I will mention that sometimes I have not had to enter this account and sometimes I do. You will still need it for the credentials for the scheduled task.
The real power of this script is to have it execute on a schedule. So we will not get the script working on our admin workstation but rather someplace where it can safely execute. In my lab that is one of my domain controllers. So that is where we are going to install it. I have to install PowerCLI and get that machine ready to use for this (if you need to than article 1 in this series can help). In the scripts folder you should extract the vCheck file you downloaded. For tidiness I suggest extracting it in a sub-folder of scripts called vcheck.
So now you have PowerCLI on your desktop or server that will host the execution of the script. You have a vcheck folder with the bits in it that is in the scripts folder.
The first thing we need to do is configure the script. So change to the folder that holds the vcheck.ps1 script. Now we configure it.
It is important to note you will be asked a lot of questions. In answering the questions you can keep the default, but you can also change it. If you are changing true to false, or false to true, make sure to write them as $true or $false. Even if you have successfully configured and used vCheck, you can always come back to configure it again.
Many of the parameters will need to be tweaked after you read the report over a few days. Before we move to schedule the report, execute it several times and check out the email or web page and make sure things are good. Things must work as expected now before we complicated things with scheduled execution.
Remove unnecessary plug-ins
There is things in the check that you don’t need. For me, the vSAN and SRM plug-ins we don’t need so we should remove them.
First we need to enable the removal. What you see below is dot space dot.
Next we need to see what plug-ins are installed.
Once you see the plug-ins that offend you, use their name in the following command.
You can see an example below:
Remove-vCheckPlugin “Site Recovery Manager – RPO Violations Report”
Note: I recently got errors about not able to establish secure connection when I did this and I solved it with Connect-VIServer -server fqdn. I also recently saw that the the remove did not work so make sure you confirm if it does or not.
Now that you have removed what you don’t need, you can confirm that with the following command before you move on.
Schedule the report
Now that the report is what you want to start with, we need to execute it on a schedule. Make sure you have manually executed the script so you can see the report so that you can configure it again if necessary. Scheduling the report is something I had trouble with the first few times, and some of us are from a time when the Task Scheduler did not work so well so I am going to provide additional detail and screenshots around this step.
Remember to have the service account handy.
- You will need to access the Task Scheduler. It is in the Admin Tools program group.
- You should now change to the Task Scheduler Library, and than select Create Task. See below what this should look like.
- Once you have started to create a task you should see something like below.
- The name and description are easy but I also point out in the screenshot where you can change the user for the execution of the task. Note the other security options I am using?
- On the next tab, Triggers, we need to set when this task should run. I like it running early before I get working. See below for how I configured mine.
- Now on the Actions tab, we need to create an action – Run a program, and point it at our vCheck.ps1 script. The command, and parameters are a bit complex.
Program / script
This will look something like the following screen.
- We should now change to the Settings tab, and there is not much to change there.
- We select the OK button and we now have a scheduled task. But, we are suspicious as IT people, so we need to make sure it runs as well as a task, as it did from the command line.
- If you right + click on the script you can get a Run option.
- To keep an eye on the task, you can use the Display Running Tasks. See below what that looks like.
- I do see in the Current Action column of the running task where it says powershell which is good.
- When it is complete, the display will say the task completed successfully. If it did not finish successfully confirm the command and parameter, as well as the account / password you used.
- It is very important to note that while the task may have completed successfully it does not mean the script did. This is why we test the script manually a few times. What you need to due now is check your email client and see if you did in fact receive the email. Double-check the time on the task complete and your email receive time. They should be similar. If you did not get the email, than you should execute the script manually again and make sure you get it. If you don’t double-check the SMTP settings when running the script with the -config.
- Now you need to test again. Wait until the schedule expires and confirm you got the email. It should work now just fine.
We should be good to expect morning emails with a snapshot of the virtual infrastructure. This vCheck script is pretty amazing but also pretty handy. We started this series with part 1 where you learned how to install and configure PowerCLI, than part 2 where we worked with a simple script, than in part 3 we worked with a more complex script, and finally we finished – for now – with this article on getting vCheck to work. So I think a realistic and useful series and I hope you agree. I will be sure to share scripts that are useful in the future.
Good luck with your PowerCLI adventures!
- 6/24/19 – the Remove-vCheckPlugin is not removing at this time. Not sure why but will try and figure it out.
- 6/23/19 – using the latest PowerShell, PowerCLI and vCheck 6.25 it wall worked. Also some grammar / spelling corrections too.
- 3/9/19 – using the latest PowerShell, latest PowerCLI, and vCheck 6.25 all worked good.
- 1/13/18 – using 6.5 of PowerCLI with latest PowerShell (5.1 I think) all worked good. Article is still good. vCheck was v6.25. Also added some info on removing plug-ins that are not necessary.
- 9/17/16 – I saw this most excellent article on making vCheck work by Rob that I need to make sure it was included. He provides a lot of additional information.
- 4/12/16 – I had troubles making vCheck v6.22 work with PowerCLI 6.3 R1 but it works fine with PowerCLI 6.0 R2. I also had to make a change (seen in this) to have it email me properly. But all else about it worked fine.
=== END ===