Kaseya Community

Get the *Correct* windows product key

  • Procedure WindowsProductKeyUpdate.xml

    I was recently dealing with an issue where I needed to get the windows product key from a system before I could reload it, and ran into the issue where Kaseya is reporting the windows product key as all B's, as documented here: https://helpdesk.kaseya.com/entries/36551976-Some-License-Keys-reported-in-Audit-appear-as-BBBBB-BBBBB-

    Doing a quick bit of research what I found is *actually* the most likely case with this is that the algorithm that Kaseya uses to pull the windows product key at least just isn't looking in the right place anymore.  It's not a "permissions" issue as this KB article would seem to indicate.

    To avoid this in the future I put together a powershell script that is basically borrowing code from a couple of differnet sources online, one for the old "32 bit" key location and one for the "new" 64 bit key location.  I basically have it run looking for the "old" key location first, and if it returns all B's then you run again looking in the "new" location.

    To make this script work you must first add the customer SystemInfo column named WindowsProductKey.  To do this go to the Audit tab, select SystemInfo and click the "New Custom Field" button in the right hand panel. 

    Then import this Proceedure and run it on all of your machines showing the incorrect windows product key and you'll have the correct one populated to the new Systeminfo column.  You'll also need to rename the attached .txt file to .ps1 and upload it to your managed files.  You should then correct the file path in the script to use the file you uploaded.

    Hopefully someone else will find this useful as well at least until Kaseya straightens out their license auditing functions.

    The powershell script will be attached in the first comment...



    Couldn't attach both files.
    [edited by: Jonathan at 8:20 AM (GMT -8) on Feb 12, 2014]
  • WindowsProductKey.txt

    Here is the powershell script.

  • Nice work, Jonathan, and thanks for posting this. The key that your script returns for my system shows up in the VSA under "Agent" - "Audit Information" - "Software Licenses" as the Product Key for "Internet Explorer".  Very strange.

  • Yeah the key that shows up for IE on any system will typically be the same as the windows product key.  It is a bit strange if your windows product key was showing as all B's in the Software licensing, and IE was showing the correct product key though... I can't say that I've personally seen that situation.  Usually they are either both identical, with both of them having either the correct product key or all B's.

  • Well, thank you again. It was very nice work.

  • Nice share Jonathan, another good example of a customer knowing more about the product than the people who are suppose to support it.

    This is definitely something Kaseya could incorporate into the product to make our lives easier and the Bs product code reported is nothing new. I have seen Microsoft doing this for some time now especially with Enterprise products. I can remember running into this issue with Produkey and Magic Jellybean Keyfinder in my days before I started using Kaseya.



    typo
    [edited by: HardKnoX at 11:54 AM (GMT -8) on Feb 17, 2014]
  • The same goes for Office 2010 and 2013. I recently created a blog post about that over at my company site: upstream.se/.../audit-ms-office-2010-and-2013-license-keys-right-way

  • I love creating custom scripts, fields, and processes to get information that the product should already be capable of. While this fix sounds like it works, I refuse to rely on scheduled scripts for things such as licensing. Then when the script isn't ran on something and I have 5 people asking me if this data is correct and then refusing to believe the work I produce, it's all on me. No thanks. Fix the product.

  • Dantheman

    I refuse to rely on scheduled scripts for things such as licensing. Then when the script isn't ran on something and I have 5 people asking me if this data is correct and then refusing to believe the work I produce, it's all on me

    The scripted auditing we can do is no less or more reliable than the built in ones and the Kaseya audits are scheduled procedures too.

  • I have a bunch of stuff setup for Exchange servers, so that I can keep track of their versions. I know what that's like. I recently got my company away from using scripts and custom fields to get MS Office software information because there were always inconsistencies. The data is right there in the Audit tab too, so we've done better lately, but now there is issues with getting the newer Office and Windows keys. While the provided fix sounds like it works for just product keys, that is just another can of worms I get to explain to 5 people every 30 days. All these nuances and duct taped processes make me weary. Do you think this will be fixed in a coming update?

  • I try and keep my expectations about anything Kaseya low so that I don't get disappointed and speaking from past experience and from what I have seen with recent events and the KB article related to this issue I would say Kaseya does not care about this else they would have done a better job on investigating and resolving this issue.

  • I agree with HardKnoX. Don't get me wrong, the Kaseya VSA helps me with a lot of stuff but I've learned that instead of battling the many limitations and idiosyncrasies of the Kaseya system I'm far better off and way ahead scripting my own solutions to use with Kaseya whenever possible. For example, that goofy "Log Parser". That's why postings such as Jonathon's script here are so helpful and appreciated.

  • It's pretty bad when you post fixes to a product that you pay for, on their forums, and they don't even fix it. I guess it's not as bad as the backup software forum I post on. Every single reply and new thread there must be approved by a mod...

  • Is this any better with v8?

  • The script seems to have worked fine, but I am seeing machines at different sites with the same key. What causes this? I do not think the key reported is correct.



    sp
    [edited by: Dantheman at 9:33 AM (GMT -7) on Apr 17, 2015]