I’m publishing some of the scripts I have written for VMM. These are each based on specific customer asks or conversations that lead me to go sleepless in trying to solve the problems myself. I am very interested in your feedback, especially if you would like to offer a change to improve efficiency or effectiveness.
Special thank you to Rajesh Ravindranath who helped me out a lot with this script.
This post is a double-hitter. I am posting two versions of the same script.
VMM is a fairly passive management tool. On a regular cycle, or due to specific events, VMM collects data about the objects it is managing. This includes things like files in the library, virtual machines, hosts, clusters, and information about the VMM server itself. The problem is if you open the Hyper-V Console or Failover Cluster console directly and make changes, or manually copy files to the Library via Windows Explorer, you must wait for VMM to update before your changes would be reflected. In most cases, this is a non-issue because the cycles are short but when doing a lot of work and making quick changes outside VMM I decided I needed a script that would just tell VMM to go update NOW!
I ended up implementing this in two flavors, “Quick” and “Full”. The issue causing me to fork the road is synchronous vs. asynchronous handling of each refresh job. If you enumerate everything VMM knows about and tell them each to refresh asynchronously (everyone update right now, don’t wait for your neighbor to complete) then some jobs will be unable to complete because the objects are part of some of other object. An example would be refreshing VMs while the host where they reside is refreshing, or refreshing a host that is part of a cluster that is already updating. I have even encountered conflicts between two concurrently updating hosts that share some configuration details.
The workaround is one script that process every single object VMM knows about and synchronously refresh each of them one at a time. As you can imagine, this process is very thorough but it takes a lot of time. The second script updates just the library and cluster and runs asynchronously. Even in our environment, a 6 node cluster (soon to be 8) with 3 library servers, running Quick brings the console up to speed in short order.
In each of the scripts for this series, I have noted any manually assigned variables at the top of the script just under the header. For this script you will want to update your VMM server name.
In each of the scripts for this series, I have added a line to load the VMM snap-in. This way it can be run from any machine, including a workstation, where the VMM console is installed by right clicking on the file and choosing “run”. If you run the script from within VMM you will get a few lines of error text that the snap-in is already loaded. You can either ignore this, or comment out the line if it bothers you.
Simple is good. As always, I ignore the snap-in error when running from console. The script returns each VM name and the location for the conflicting file.
disclaimer: this script is not supported in any way. I have posted the code rather than the .ps1 file so that you can review it, modify it to make it your own, and test it before trusting it in a production environment. now this is your code, I am not responsible for its use.