VAMT is a free Microsoft tool that helps companies manage Vista activation using MAKs (Multiple Activation Key). It is also useful for organizations working with KMS. VAMT has four core features: Status Collection and Reporting, MAK management, MAK Independent Activation, and MAK Proxy Activation. In this post, I'll only cover the first two features. I'll write about MAK Independent Key Activation and MAK Proxy Activation soon.
- Pip install Boto3 - Thu, Mar 24 2022
- Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022
- Automatically mount an NVMe EBS volume in an EC2 Linux instance using fstab - Mon, Feb 21 2022
The installation of VAMT is very easy. All you have to do is to run the MSI. The good news is that contrary to KMS, VAMT has an easy-to-use graphical user interface. At first, I tried the MAK management features. This function tells you how many remaining activations a MAK key still has. VAMT retrieves this information from Microsoft Volume Licensing. However, you have to add your MAKs first manually.
VAMT offers three ways of collecting Vista machines in your network: by IP address, thru search in Active Directory and thru search in a Workgroup. With the first option, you have to specify IP addresses, manually. VAMT will group them in a container. I followed the manual line by line, but in my test VAMT always failed to collect the status of my test computers with the error code 0x80070005.
After a while, I figured out that UAC (User Account Control) is the reason. According to the manual, a registry key (LocalAccountTokenFilterPolicy) must be created to enable remote administrative actions under UAC. In my view, it is very strange that one has to mess with the registry on all client machines to work with VAMT if you are not using Active Directory. However, in my test adding the registry key didn't solve the UAC problem. It is only after I disabled UAC altogether, that VAMT was able to collect the activation status.
I, then, installed VAMT on a member server of a Windows domain. In theory, VAMT should gather the computer names from Active Directory. This way, you don't have to add all your clients, manually. But whenever I added client computers using the AD option, I got an error message with the error code 0x8007003A. I, then, installed VAMT on a domain controller. The error message was the same there.
VAMT has a funny feature which allows you to look up the error codes. I wonder why the error message doesn't simply deliver the explanation for the error code. Anyway, this error code look up didn't work either. The error code tool displayed another error message: Access denied. Maybe, Microsoft should offer yet another tool which looks up the error messages of the error code look up function?
I couldn't believe that Microsoft delivered such an important tool with so many bugs. So I gave VAMT another chance. In the tests, described above, I always used virtual machines under VMware Workstation. This time, I installed VAMT on a physical Windows Server 2003 SP1, et voilà, it was able to gather all Vista machines in our Windows domain thru Active Directory. I also was able to collect the licensing information without disabling UAC on the Vista clients.
At least, I had my first sense of achievement. VAMT listed only the Vistas machines in our domain, i.e. all other Windows versions were excluded. You can group computers in containers. For this, you have to specify a string as filter for the computer name. VAMT will then only retrieve those computers from AD which contain this string. This, certainly, is a very strange way to group computers. Why isn't VAMT able to list AD containers?
After collecting all Vista machines, VAMT will retrieve their licensing status by connecting to them thru WMI (Windows Management Instrumentation). You can do this for each computer individually or for a computer group. If you have Vista's firewall enabled, you have to allow WMI inbound connections. You can do this manually by enabling the corresponding exception in the Control Panel Firewall configuration tool or by using Group Policy.
The retrieval process is relatively slow. If a computer isn't online, then VAMT will wait for several seconds. Since VAMT contacts all computers of the selected group simultaneously this might not be a big problem, though.
VAMT displays information like the key type, license status, grace expiration date, installation ID and pending conformation ID. However, it collects many more information which is stored in an XML file for further processing.
VAMT groups computers automatically according to their licensing status. This helps you to find computers which were not yet activated. VAMT knows seven states: Initial-out-of-box (OOB), Grace (newly installed Vista machines, not yet activated), Licensed (activated by KMS or MAK), Non-Genuine Grace (validation failed), Out of Tolerance (computers with too many hardware changes or KMS clients that have not renewed their activation in 180 days), Unlicensed (computers in Reduced Functionality Mode (RFM)), Non-Volume Computers (Vista machines not supporting volume activation).
All in all, VAMT worked reliably on my physical server. I don't know why it didn't work on my virtual test server, though. It is certainly possible that I made a mistake or perhaps there is something wrong in my testing environment. It is also possible that VAMT simply doesn't work in virtual environments or maybe it is still buggy. Please, let me know if you were more successful in using VAMT under VMware.
VAMT is certainly a very useful tool. This is especially true for the features which help you activate Vista machines in your network. I'll write about them soon in another post.
Subscribe to 4sysops newsletter!
Please, also check out the Related section below for other articles in my series about Vista activation.
Want to write for 4sysops? We are looking for new authors.
KMS it is not supported to run in virtual machines. Soo i assume that VAMT also wont work in virtual server. I assume that this is by design.
Just tried with the latest VAMT on VMware and found the same errors as reported above.
I have KMS and VAMT running successfully in a VM
VMware host is an ESX3i Server
Windows 2008 Server (x86) running KMS_C_Channel
VAMT 1.1 x86