Thursday, July 25, 2013

Disabling the BIN save state file on Hyper-V

This is a follow-up to my post:

Over time I have seen lots of posts from folks wanting to turn this off.

Well, that became possible with Hyper-V 2012. And actually is totally hidden, you might not know you are turning it off.

First, on the previous post I mentioned why the BIN (as I refer to them as the save state file) exist in the first place.

So, what if you turn them off?

Well, you turn them off and you lose the protection they offer. The safety net if you like. Think about that, consider the risk.  I did my job and warned you.

Before we jump in and disable it let's look at the settings option related to it first.

Per this post by Ben Armstrong this is rather simple;

Set-VM -AutomaticStopAction Save

This is the default and what you get without thinking. The safety net is on.

Set-VM -AutomaticStopAction ShutDown

This will cause Hyper-V to attempt clean shut down of the VM or click it off if it can't

Set-VM -AutomaticStopAction TurnOff

This will just click off your VMs, and give you that wonderful "why did I not shutdown cleanly" dialog later on.

According to Ben’s post; if you set either ShutDown or TurnOff, Hyper-V no longer creates the BIN file as a placeholder.

Now, if you take a snapshot of a running VM, you get one as a part of the snapshot (it is the actual saved memory state, not a placeholder). But it won't be there from the moment you turn on your VM.

In case you didn’t know how to use Set-VM: Get-VM –Name “Foo” | Set-VM –AutomaticStopAction ShutDown


Now, what if you want something a bit more useful, or you have bunches of VMs?

If you are using SCVMM:

Import-Module virtualmachinemanager

$prefix = Read-Host "Enter prefix to search on"

$vms = get-scvirtualmachine | where {$ -match $Prefix}

foreach ($vm in $vms) {
    # check if its status is clean in VMM, and clear it if not
    if ($vm.Status -eq "UpdateFailed") {Repair-SCVirtualMachine -VM $vm -Dismiss}
    if ($vm.VirtualMachineState -eq "Running") {Stop-SCVirtualMachine -VM $vm -Shutdown}

    # wait for the darn thing to cleanly shut down
    Do {Start-Sleep 30} until ($vm.VirtualMachineState -eq "PowerOff")
    if ($vm.StopAction -ne "ShutdownGuestOS"){Set-SCVirtualMachine -VM $vm -StopAction ShutdownGuestOS}

    if ($vm.StartAction -ne "TurnOnVMIfRunningWhenVSStopped"){Set-SCVirtualMachine -VM $vm -StartAction TurnOnVMIfRunningWhenVSStopped}


With the Hyper-V cmdlets the script would be changed very little.

If you are using Hyper-V cmdlets:

$prefix = Read-Host "Enter prefix to search on"

$vms = get-vm | where {$ -match $Prefix}

foreach ($vm in $vms) {
    if ($vm.State -eq "Running") {Stop-VM -VM $vm}

    # wait for the darn thing to cleanly shut down
    Do {Start-Sleep 30} until ($vm.State -eq "Off")
    if ($vm.AutomaticStopAction -ne "ShutDown"){vm | set-vm -AutomaticStopAction ShutDown}

    if ($vm.AutomaticStartAction -ne "StartIfRunning"){$vm | set-vm -AutomaticStartAction StartIfRunning}


SCVMM UR3 causes VMM Service to crash on Placement

I am sharing this because it burned me, and why should it burn anyone else.

This should have the sub-title of: “you need to read the release KB articles in deep detail” or “just don’t install Update Rollup 1 in the first place and you will be happier”.

I recently jumped straight into Update Rollup 3 for SCVMM 2012 SP1.  Because I had reported some bugs and the fixes were in there.

So, I downloaded the update rollup and I applied it to my VMM Console and to my VMM Server.

I then pushed out new agents to my remote Library Server and my Hyper-V Servers.  All was good.  Or so I thought.

I then deployed a Service Template.

During the time when SCVMM was sorting out where to place the VMs in my Service the VMM Service crashed.  Okay, so I tried again.  (not to expect a different result but to pay attention to figure out what was going wrong).

In the event log of the SCVMM Server I found the following message:

Log Name:      Application

Source:        Windows Error Reporting

Date:          7/24/2013 12:15:47 PM

Event ID:      1001

Task Category: None

Level:         Information

Keywords:      Classic

User:          N/A

Computer:      beSCVMM.brianeh.local


Fault bucket , type 0

Event Name: VMM20

Response: Not available

Cab Id: 0

Problem signature:

P1: vmmservice

P2: 3.1.6018.0

P3: Engine.Placement

P4: 3.1.6027.0

P5: M.V.E.P.C.VMDCConversionHelper.GetVMDCPrecheckResources

P6: System.MissingMethodException

P7: bf35




These files may be available here:

Analysis symbol:

Rechecking for solution: 0

Report Id: 711cf4e8-f495-11e2-9404-00155d289b00

Report Status: 262144

Hashed bucket:

Event Xml:

<Event xmlns="">


    <Provider Name="Windows Error Reporting" />

    <EventID Qualifiers="0">1001</EventID>




    <TimeCreated SystemTime="2013-07-24T19:15:47.000000000Z" />




    <Security />







    <Data>Not available</Data>











So, I removed UR3 (the VMM Server KB…510).  I removed the hosts and remote library server from vmm management and added them back.  I fixed up all of my templates (Export them and Import them do fix them quickly).

I opened a case.

In the end, what was the root problem?   I didn’t uninstall Update Rollup 1.


Come to find out, buried in the details of this KB: is the installation information that Update Rollup 1 for SCVMM should be uninstalled manually prior to installing Update Rollup 2 (or any following Update Rollup).

Personally, I never read that particular article prior to installing UR2.  So I never knew to install UR1.  And, it is highly unusual to have to manually uninstall an Update Rollup prior to adding a second.

So, I then uninstalled UR1.  I re-applied UR2.  Then I installed UR3.  And all was happy.

Now, one easy way to check for this: 

If you select About from the ribbon of the SCVMM console you will see a version.  If you have UR3 installed it should be 3.1.6027.0 

If you have UR2 installed it should be 3.1.6020.0 

If you never manually uninstalled UR1 it will remain at 3.1.6018.0 after applying UR2 or UR3.

The forgotten BIN element in Hyper-V Storage planning

This is an issue that VDI deployments always run in to.

The symptom is this:  I deployed bunches of VDI VMs.  Folks begin using them.  And a week goes by.  Suddenly I notice that most all the reserve storage that I had planned on is gone. 

I don’t have any snapshots happening.  I check that the backup software isn’t leaving weird VSS backups or temporary files lying around.  I even look for AVHDs (though I know there should not be any).

So what happened?

I go looking around and I see all these .BIN and .VSV files.

The VSV is a small placeholder.

However, the BIN is equal in size to the amount of RAM that the running VM is consuming.  If you have Dynamic Memory enabled, it equals the amount of Assigned Memory – so it changes.

Therefore, Dynamic Memory on, means that you design for the worst case scenario – calculate for the Maximum Memory setting of all the VMs stored on that particular LUN.

What this will cause you to do is:

  1. Realize the impact that this BIN file has on storage.
  2. Be smart about setting the Maximum Memory of your VMs.
  3. Understand the risk and accept the risk and push forward without making any considerations.

If you have read this far you might be thinking, What is this BIN file for anyway?

It is a safety net for your VM(s).

It is a placeholder that reserves storage on the file system, so that if the hypervisor needs to reboot, it can quickly dump the memory of your VM(s) to disk.

This does not help you if the hypervisor crashes due to something like a bad driver, this is Hyper-V being able to respond to something and save your VMs – Oh, such as when you run out of storage and it puts your VMs into a saved state.  That is one use.

Wednesday, July 24, 2013

Turn off SCVMM console auto logon

I am sure that everyone at some time has checked that little box on the SCVMM console during the prompt for credentials “Automatically connect with these settings”


Only at some time in the future to want to turn that off.

Well, it surely isn’t obvious how to uncheck that box. 

If you are super fast and you capture the window and attempt to click it, you will discover that the opportunity never exists.  It is grayed out, blocked.

If you go looking for ini files or .config files you will come up dry.  Anything in the user profile, again you are dry.

So, what is left?  The registry.

Here it is:

Under HKEY_CURRENT_USER\Software\Microsoft\Microsoft System Center Virtual Machine Manager Administrator Console\Settings\Shared in the registry you will find “autoConnect”

Simply modify that from “True” to “False” and you will once again be prompted for credentials.

Because who wants to logout and on to Windows as different users all the time just to act as different RBAC roles in SCVMM?

Not I.

And what if I want to have multiple consoles open, each as a different user.  I need to uncheck that for that case as well.

Wednesday, July 3, 2013

Importing a PFX file with PowerShell

The PFX format is great because it includes a certificate and the private key as a single package.

This lets you create a certificate on one machine and then replicate that around for a number of purposes.

Now, this is not the first PowerShell script that handles PFX files.  But one problem that I have found with many is that they are functions and can’t just run on their own and they don’t actually import the private key!

Here is a simple script that you can execute and it checks its execution location for any PFX files and prompts the person running the script for the password to the PFX file.

The assumption is that the PFX file needs to be in the LocalMachine Personal ( or Root) store.

"Looking for included *.pfx.."
$certFile = get-childitem | where {$_.Extension -match "pfx"}
if ($certFile -ne $NULL) {
    "Discovered a .pfx. Installing " + $certFile.Name + " in the LocalMachine\My certificate store.."
    $pfxPwd = Read-Host -Prompt "Please enter the password for your PFX file " -AsSecureString
    $pfxCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certFile.FullName, $pfxPwd, "Exportable,PersistKeySet")
    $store = get-item Cert:\LocalMachine\My


BTW – I have been sitting on this post for a really long time.  I just found it in my drafts.