Office 2016 key scanning

[tmittelstaedt]

Hi All,

I have the latest version of Lansweeper running, it has no problems finding OEM/retail MS Office Home & Business 2016 installations. However, it does not appear to be able to gather the product keys.

Now, BEFORE you start sending me to the newbie links, I HAVE read:

https://www.lansweeper.com/kb/133/software-installations-vs.-software-license-keys.html
https://www.lansweeper.com/kb/132/viewing-and-scanning-software-license-keys.html

and finally:

https://www.lansweeper.com/kb/78/microsoft-office-2013-serial-number-scanning.html

I am perfectly well aware that with Office 2016 installations Microsoft does NOT store the product key in the Registry.

BUT - Microsoft DOES store PART of the key on the machine! Specifically the last 5 digits - there is a discussion about how to run cscript to retrieve them here:

https://community.spiceworks.com/topic/426126-how-find-office-2013-product-key?page=1

It would be VERY COOL for this to be added as a new feature in Lansweeper. While you might not think it to be much value the issue is that NOW, Microsoft requires all OEM/Retail Office 2016 installations to be registered into a Microsoft account - thus you can retrieve your keys that way - but there's no way to know which key is in use on which machine.

Thanks!

[CyberCitizen]

I don't think this is something for Lansweeper but more of a Microsoft issue.

While yes you can do it with Lansweeper, I know alot of companies that would not be happy installing an inventory system that starts running scripts on remote machines.

Lansweeper is designed to be an agentless inventory system and it does this by calling on the running processes of the machines such as wmi.

When you start having it run scripts remotely on machines there are alot more issues that can occur.

While I would love for the new product keys to be recorded in Lansweeper, I don't believe LS should be executing scripts by default.

I ended up creating a deployment package that saves the results to a shared network drive with the hostname as the filename.

[WaldoIT]

CyberCitizen wrote:

I ended up creating a deployment package that saves the results to a shared network drive with the hostname as the filename.

If you're still around and see this, can you enlighten others as to what you did? Is it something shareable, at least the basic instructions of how you got from idea to implementation?

[CyberCitizen]

WaldoIT wrote:

CyberCitizen wrote:

I ended up creating a deployment package that saves the results to a shared network drive with the hostname as the filename.

If you're still around and see this, can you enlighten others as to what you did? Is it something shareable, at least the basic instructions of how you got from idea to implementation?

Sorry I missed the reply about this one.

The script below was what I ran.

cmd /c cscript "C:\Program Files (x86)\Microsoft Office\Office16\ospp.vbs" /dstatus > C:\Temp\LicenseStatus.txt

Note you could save this to a network share with the computer name by changing the filename to %COMPUTERNAME%, but I save it locally and then just check the C$ share.

[emoya]

CyberCitizen wrote:
I don't think this is something for Lansweeper but more of a Microsoft issue.

While yes you can do it with Lansweeper, I know alot of companies that would not be happy installing an inventory system that starts running scripts on remote machines.

Lansweeper is designed to be an agentless inventory system and it does this by calling on the running processes of the machines such as wmi.

When you start having it run scripts remotely on machines there are alot more issues that can occur.

While I would love for the new product keys to be recorded in Lansweeper, I don't believe LS should be executing scripts by default.

I ended up creating a deployment package that saves the results to a shared network drive with the hostname as the filename.

Would you mind sharing that deployment package?? It'd be seriously useful to my team currently. I'd appreciate it.

[davidc]

This is not a new post, but is a much needed feature and is long overdue for Lansweeper to restore.

This should not be overly difficult to code into Lansweeper. All you have to do is remotely call "cscript", pipe back the results, and do some string handling / searching. It might be a special bit of code for a singular product-line, but it's a product line used by a LOT OF PEOPLE.

Forcing SysAdmins to roll our own solutions with powershell / GPO / etc... this is not what we pay for Lansweeper for.