Probably, but plenty of readers are like me and prefer the DIY methods. Plus, it never hurts to get the information out to people.
/rearm doesn't seem to push the Client Count up (remains the same count as before) Tested on Windows 2008 Server Standard R2 SP1, result might be different for Windows 8/2012
Sounds simple enough for me try. I've a test VM runinng Win7 Enterprise which uses MiniKMS. Could that be setup to use the KMS server everyday, maintaining the server count and keeping the VM active?
The easiest way to automate it would be to set up a Server Core VM stripped of everything, with an unattended answer file that automates OOBE and a scheduled task at bootup to activate, sysprep, shut down. Every time it boots it will activate with a new CMID and shut down again.
MS probably tried to combat artificial activation count through Hyper V VM's (just speculation). If you install your VM with a GVLK and try use snapshots, rearm and sysprep you will only get 2 activation counts (why I don't really care to waste time on) sysprep just adds more time to the cycle. This method just requires a boot not a reboot. You have 2 action to perform. Revert and Power up the Virtual Machine. There are no timing issues, when you notice the VM has finished, perform the 2 actions again and walk away. My VHD's are on SSD's and cycle in about 15sec. I have also tweaked by removing certain services etc but I don't like typing and thought that I would leave it up to the individual. I want to go on with analysis of the pre win8/server2008r2 KMS in the prospect that we could develop a Win7 client emulation to achieve the 25 activation count. If anyone has the source code for the original ZWT keygen lying around it would be a lot easier. I am also sure that I am going to win the Lotto this Friday.
Don't think /rearm is required given the fact the VM using unattended is calling sysprep before first boot (after installing hardware) When you first start a VM created with wim2vhd the hardware is being installed and after that the system requires a reboot, at exactly that moment close it and take snapshot. Everytime you start this snapshot a unique ID will be assigned. Code: Set-ExecutionPolicy RemoteSigned ApplySnapshotAndStartVM.ps1 Code: # Function for handling WMI jobs / return values Function ProcessResult($result, $successString, $failureString) { #Return success if the return value is "0" if ($result.ReturnValue -eq 0) {write-host $successString} #If the return value is not "0" or "4096" then the operation failed ElseIf ($result.ReturnValue -ne 4096) {write-host $failureString " Error value:" $result.ReturnValue} Else {#Get the job object $job=[WMI]$result.job #Provide updates if the jobstate is "3" (starting) or "4" (running) while ($job.JobState -eq 3 -or $job.JobState -eq 4) {write-host $job.PercentComplete "% complete" start-sleep 1 #Refresh the job object $job=[WMI]$result.job} #A jobstate of "7" means success if ($job.JobState -eq 7) {write-host $successString return $true} Else {write-host $failureString write-host "ErrorCode:" $job.ErrorCode write-host "ErrorDescription" $job.ErrorDescription return $false} } } # Define the Hyper-V Server to use $HyperVServer = "." # Define the virtual machine to use $VMName = "KMS_C_R2" # Define the name of the snapshot to apply $SnapshotName = "Firstboot" # Get the management service $VMMS = gwmi -namespace root\virtualization Msvm_VirtualSystemManagementService -computername $HyperVServer # Get the virtual machine object $VM = gwmi MSVM_ComputerSystem -filter "ElementName='$VMName'" -namespace "root\virtualization" -computername $HyperVServer # Find the snapshot that we want to apply $Snapshot = gwmi -Namespace root\virtualization -Query "Associators Of {$VM} Where AssocClass=Msvm_ElementSettingData ResultClass=Msvm_VirtualSystemSettingData" | where {$_.ElementName -eq $SnapshotName} | select -first 1 # Apply the snapshot $result = $VMMS.ApplyVirtualSystemSnapshot($VM, $Snapshot) # Check to make sure we succeeded $applySucceeded = ProcessResult $result "Snapshot applied." "Failed to apply snapshot." #Request a state change on the VM, 2 = Start VM $result = $VM.RequestStateChange(2) # Check to make sure we succeeded $startSucceeded = ProcessResult $result "VM started." "Failed to start VM."
The post I made was not related to yours, I just was typing it while you had already posted it. Yours should work fine if the snapshot is taken @ the right time and your VM can talk to the KMS Host (Networking etc.)
Ah, OK my fault Gonna test out if this really is working this evening, it should... but i haven't actually test it as i don't have access to my KMS from where i am right now
For some reason the client count doesn't go passed 10, recreating the vhd image doesn't change that... might be caused by the ComputerName or TCP/IP settings being indentical... puzzled
Change the mac address on the hyper-v VM and see if it pushes the count higher. That will eliminate any IP issues lol
I enabled NAT on the hyper-V host, no longer using static IP address assigned by unattended file... Hyper-V is setup to assign MAC address dynamically, IP address in client is assigned by DHCP (confirmed that it changes with every cycle) by using NAT translation setup on the Hyper-V host for the Hyper-V internal network. Strange thing is, when using the KMC_C_R2 package the client count increases with every cycle using NAT. Something fishy is going on here with the WIN 8/2012 KMS_C. Another thing to keep in mind, every cycle the Hyper-V guest activates fine, it is just the client count that doesn't go up
Unless it's not incrementing the client count because it realizes that the clients aren't staying online to keep requesting the activation so they actually get activated when the client count hits 25. I don't know, just a theory.
Maybe this quote from MS will help. I am still backtracking to explore how my simple process works as posted previously and the reasons for failure: "To reset the activation timer and to set a unique CMID, the Rearm process must run on the destination computer. This process is used to reset the activation state. In Windows, the Rearm process can be run by using one of the following two methods" ????Note "To reset the activation timer" Another issue is that the KMS Host is aware if the client is a VM, check your event details on your KMS Host. I am speculating that this then affects the generation of the Unique CMID "VM Info Client OS is running in a virtual machine 1" I have been trying to pinpoint if the failures to increase the activation count are by design. At this stage I can only say it has me confused. Time travel can never work. The snapshots in Hyper-V confuse me enough trying to keep track of when I'm @.