how to detect host id of a computer using excel

[isabelle]

i don't agree, simply connect a modulo on the cpu of motherboard and
record anything else, but it is not vba, so ...

isabelle

Le 2013-01-05 22:47, CellShocked a écrit :

 

[Ron Rosenfeld]

After serious thinking Ron Rosenfeld wrote :

Interesting that this is the stored value. Obviously this is different
than what's returned in a commercial unit. For example, I find it
typical of clone machines released by Gateway to return an empty
string. Your case is a new one for me!<g>

Doing a little more digging, using CPUID PC Wizard 2012, I note that my BIOS information does, indeed, contain an entry termed "Motherboard ID". However, as I wrote before, that is NOT what is returned by your code. It is obviously accessible, since PC Wizard accesses it, but I don't know how to approach this in VBA.

 

[Ron Rosenfeld]

After serious thinking Ron Rosenfeld wrote :

Interesting that this is the stored value. Obviously this is different
than what's returned in a commercial unit. For example, I find it
typical of clone machines released by Gateway to return an empty
string. Your case is a new one for me!<g>

Some interesting further investigation, the significance of which I have no idea.
PCWizard returns the following in the "Mainboard" section:

----------------------------------------------

Manufacturer : To Be Filled By O.E.M.

Product : To Be Filled By O.E.M.
Version : To Be Filled By O.E.M.
Serial Number : To Be Filled By O.E.M.
Unique ID : 00020003-00040005-00060007-00080009
SKU : To Be Filled By O.E.M.
Family : To Be Filled By O.E.M.
Start mode : Power Switch
OEM #1 : To Be Filled By O.E.M.
Intrusion detected : Unspecified

Mainboard : ASRock Z77 Extreme6

Manufacturer : ASRock
Product : Z77 Extreme6
Version : Unspecified
Serial Number : Unspecified
Support MP : Yes, 4 CPU(s)
Version MPS : 1.4
Manufacturer : To Be Filled By O.E.M.
Type : Desktop
Version : To Be Filled By O.E.M.
Serial Number : To Be Filled By O.E.M.
Asset : To Be Filled By O.E.M.
--------------------------------------------
So there does seem to be a UUID associated with this system.

In the original version of your Get_BIOSserialNum function, if I examine vBIOS in the Watch window and look at Qualifiers_ Item 4, I see, (in part):
: Name : "UUID"
: Value : "{8502C4E1-5FBB-11D2-AAC1-006008C78BC7}"
I don't really know what this represents.

If I modify your Get_BIOSserialNum function to look at Win32_ComputerSystemProduct, then the UUID returned is similar but not identical to that returned by PC Wizard:
vbios.UUID --> 03000200-0400-0500-0006-000700080009

Thoughts?

 

[Ron Rosenfeld]

In the original version of your Get_BIOSserialNum function, if I examine vBIOS in the Watch window and look at Qualifiers_ Item 4, I see, (in part):
: Name : "UUID"
: Value : "{8502C4E1-5FBB-11D2-AAC1-006008C78BC7}"
I don't really know what this represents.

Hmmm. I doubt that UUID represents a machine specific value, because the identical UUID appears in an example here: http://include.wutils.com/wmi/ROOT\...ftwareElement/CIM_BIOSElement/Win32_BIOS.html

 

[Chairman Meow]

Hmmm. I doubt that UUID represents a machine specific value, because
the identical UUID appears in an example here:

http://include.wutils.com/wmi/ROOT\...ftwareElement/CIM_BIOSElement/Win32_BIOS.html


They have not implemented these things for a while. There must be some
way for a John Doe OEM Machne maker who buys Joe Bloe MOBO maker's cheap
run MOBO series in M quantities to go in and set these parameters.

I'd bet the main drawback is that each BIOS chip would have to be
individually burned with a unique code block, as opposed to mass burning
a bank of BIOS chips all at one time with the same code. But a modern
flash chip could do both. Burn the base code, and update the S/N later.
but that STILL requires individual chip attention and handling, as well
as the tracking aspect imposed on the maker.

 

[GS]

CellShocked laid this down on his screen :

CellShocked explained :

How do I call this: (remember to paste it all back together right)

[[[[[[dotnet.loadAssembly @"System.Management.dll"
mc = dotNetObject "System.Management.ManagementClass" "Win64_Processor"
moc = dotNetClass "System.Management.ManagementObjectCollection"
moc = mc.GetInstances()
enumerator = moc.GetEnumerator()
while enumerator.MoveNext() do
(
mo = enumerator.current
append CPUID ( mo.Properties.Item["ProcessorId"].value )
)]]]]]]

This is dotnet code and so won't work with VBA. Use the code I posted
here earlier...

Your code? On a 64 bit system?
Yes!

And what about answering the question
where I asked just how to store that code in the excel VB editor (where)
and how to call it?

Store the code in a standard module, but remove the Private scope
keyword. Read my other replies for sample of how to use it.

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

 

[GS]

http://include.wutils.com/wmi/ROOT\...ftwareElement/CIM_BIOSElement/Win32_BIOS.html


They have not implemented these things for a while. There must be some
way for a John Doe OEM Machne maker who buys Joe Bloe MOBO maker's cheap
run MOBO series in M quantities to go in and set these parameters.

I'd bet the main drawback is that each BIOS chip would have to be
individually burned with a unique code block, as opposed to mass burning
a bank of BIOS chips all at one time with the same code. But a modern
flash chip could do both. Burn the base code, and update the S/N later.
but that STILL requires individual chip attention and handling, as well
as the tracking aspect imposed on the maker.

You hit the nail on the head! Good point. It also explains why some
clones don't have a BSN...

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

 

[Ron Rosenfeld]

They have not implemented these things for a while. There must be some
way for a John Doe OEM Machne maker who buys Joe Bloe MOBO maker's cheap
run MOBO series in M quantities to go in and set these parameters.

I'd bet the main drawback is that each BIOS chip would have to be
individually burned with a unique code block, as opposed to mass burning
a bank of BIOS chips all at one time with the same code. But a modern
flash chip could do both. Burn the base code, and update the S/N later.
but that STILL requires individual chip attention and handling, as well
as the tracking aspect imposed on the maker.

That explains a lot. Even the UUID can, according to some stuff I've read, change if the MB loses all power (including the battery backup).

I wonder how MS ties an installation to a particular motherboard? Do they use the machine GUID in the registry? Or something else?

 

[GS]

Ron,
In your case *you* are the manufacturer and so it's your responsibility
to provide the OEM values.<g>

There doesn't seem to be any -standard- as to the format of a BSN. For
example, my Dell Precision90 portable workstation (which is just a
Sherman tank version of a laptop) has this BSN: "570WHC1", which is
also its ServiceTag ID. The same holds true for my Dell Precision60
(older model of portable workstation laptop): "BPJQS51".

My Acer machines use a different format:
Acer Aspire One notebook: "LXPH10202693966A391601"
Acer TravelMate TimelineX: "LXV0603083103003EB2300"

So the format appears to be entirely the OEM's preference. I have other
BSNs from various makes/models which are different again than the
Dell/Acer examples.

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

 

[Chairman Meow]

That explains a lot. Even the UUID can, according to some stuff I've read, change if the MB loses all power (including the battery backup).

I wonder how MS ties an installation to a particular motherboard? Do they use the machine GUID in the registry? Or something else?

They use the HD UUID and whatever other HW UUIDs they can find and even
S/Ns that get extracted and published via vendor drivers in operation.

I have had to call them in the past after a HW change and rectify my
re-activation.

So, some "found and stored" s/N or ID figure(s) in the registry get
tested, and if they change, the activation gets negated. That way, they
do not have to do any specific phone-home type snooping. The machine has
the engine built in, and then they service the customer with the raised
flag when they call... if they call. Much less labor for them that way.

 

[GS]

Ron Rosenfeld expressed precisely :

That explains a lot. Even the UUID can, according to some stuff I've read,
change if the MB loses all power (including the battery backup).

I wonder how MS ties an installation to a particular motherboard? Do they
use the machine GUID in the registry? Or something else?

A GUID is not the same as a BSN. Most GUIDs are listed under
HKCR\CLSID, which is where I used to store app license info back when I
was using the Registry. (Now my stuff is 100% reg-free) It's quite
likely where MS puts stuff!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

 

[GS]

Chairman Meow explained on 06/01/2013 :

They use the HD UUID and whatever other HW UUIDs they can find and even
S/Ns that get extracted and published via vendor drivers in operation.

I have had to call them in the past after a HW change and rectify my
re-activation.

This is precisely why I use BSNs for locking my software to a machine.
Albeit that it only takes up 1 element in my 4 element MachineID, in
cases where there is no BSN I generate a SHA256 hash value in its
place.

What I'm saying here is that I don't rely on a BSN solely as a
MachineID because of the associated ambiguities. There's enough other
(unambiguous) system info that I use that I can afford to generate my
own BSN where/when necessary.

A license profile has 17 elements. MachineID is only 1 of those. Each
profile element can have as many item elements as I want! That should
give you some indication of the weighted value a BSN has overall!

So, some "found and stored" s/N or ID figure(s) in the registry get
tested, and if they change, the activation gets negated. That way, they
do not have to do any specific phone-home type snooping. The machine has
the engine built in, and then they service the customer with the raised
flag when they call... if they call. Much less labor for them that way.

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

 

[Chairman Meow]

Ron,
In your case *you* are the manufacturer and so it's your responsibility
to provide the OEM values.<g>

There doesn't seem to be any -standard- as to the format of a BSN. For
example, my Dell Precision90 portable workstation (which is just a
Sherman tank version of a laptop) has this BSN: "570WHC1", which is
also its ServiceTag ID. The same holds true for my Dell Precision60
(older model of portable workstation laptop): "BPJQS51".

My Acer machines use a different format:
Acer Aspire One notebook: "LXPH10202693966A391601"
Acer TravelMate TimelineX: "LXV0603083103003EB2300"

So the format appears to be entirely the OEM's preference. I have other
BSNs from various makes/models which are different again than the
Dell/Acer examples.

The figures are likely in the same places (require the same API calls
to retrieve), but are likely BIOS maker specific as to elements like
'field formatting' and the actual data string nomenclature.

Had CPU IDs from Intel not been so flatly rejected back in the 386
days, we would probably have more of a standard for the whole thing going
by now, certainly.

Oh, and remember how the "hard sectored floppy" idea almost killed
Broderbund at one point? I do.

 

[GS]

Chairman Meow wrote on 06/01/2013 :

The figures are likely in the same places (require the same API calls
to retrieve), but are likely BIOS maker specific as to elements like
'field formatting' and the actual data string nomenclature.

Had CPU IDs from Intel not been so flatly rejected back in the 386
days, we would probably have more of a standard for the whole thing going
by now, certainly.

Oh, and remember how the "hard sectored floppy" idea almost killed
Broderbund at one point? I do.

Though I've been using Excel since v4, I only started programming in
2003 via MS Office 2000 Developer Edition on a Win NT 2000 OS. That
means I wouldn't have a slightest clue as to what "hard sector floppy"
is!<g>

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

 

[Ron Rosenfeld]

In your case *you* are the manufacturer and so it's your responsibility
to provide the OEM values.<g>

And I might even do so, if there were some way to program the chip on the MB in my environment :-|

 

[Chairman Meow]

And I might even do so, if there were some way to program the chip on the MB in my environment :-|

You have to make your own custom J-TAG probe. ;-)

 

[Ron Rosenfeld]

You have to make your own custom J-TAG probe. ;-)

Oh, is that all?

 

[GS]

And I might even do so, if there were some way to program the chip on the MB
in my environment :-|

Perha[s you can check if the folks at SysInternals have a utility for
that!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

 

[Chairman Meow]

Oh, is that all?

No. Then, you must research the chip maker's data sheet to see how you
have to "hit it" with the programming routine.

 

[WoolyBully]

And I might even do so, if there were some way to program the chip on the MB in my environment :-|

I found this amazing 'gadget'. It has a lot of this info when explored
(info page scrolled).

http://addgadgets.com/all_cpu_meter/