Product Keys & Machine/User SIDs

Discussion:

(too old to reply)

Java Jive

2024-05-15 18:17:27 UTC

I've been searching for an answer to this question on & off since last
night ...

Is a Windows PC's machine SID (which also forms the user account SIDs up
until the final hyphen) cryptographically derived from the
installation's Product Key? Or, to put it another way, if I change the
product key on a PC, will the user SIDs change as a result, and so
require changing the permissions on the user profiles and maybe elsewhere?

I think and hope that the answer is no, but does anyone know for sure?

I want to know this because I've had two old Dell Precision M6300
laptops go down, both through dead video cards - annoying but in their
defence they were very old machines - and have replaced them with
M6700s. I've just realised that the latter both have W7 Pro OEM product
keys on stickers in the battery bay, so that gives me the option of
adapting my W7 build for them, and then upgrading them to Win 10 Pro to
give me two more licences for the latter. However, as the build I want
to adapt is an Ultimate build, I will have to downgrade it by a
procedure I've outlined before here when I did it successfully for the
Home Premium build for the laptop I'm typing this on. That effort,
though it worked pretty well, was rather sledgehammer like, and this
time I'd like to try and be at least a little more surgical in my
approach, hence the need for the above information.

--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Paul

2024-05-15 19:27:03 UTC

Permalink

I've been searching for an answer to this question on & off since last night ...
Is a Windows PC's machine SID (which also forms the user account SIDs up until the final hyphen) cryptographically derived from the installation's Product Key? Or, to put it another way, if I change the product key on a PC, will the user SIDs change as a result, and so require changing the permissions on the user profiles and maybe elsewhere?
I think and hope that the answer is no, but does anyone know for sure?
I want to know this because I've had two old Dell Precision M6300 laptops go down, both through dead video cards - annoying but in their defence they were very old machines - and have replaced them with M6700s. I've just realised that the latter both have W7 Pro OEM product keys on stickers in the battery bay, so that gives me the option of adapting my W7 build for them, and then upgrading them to Win 10 Pro to give me two more licences for the latter. However, as the build I want to adapt is an Ultimate build, I will have to downgrade it by a procedure I've outlined before here when I did it successfully for the Home Premium build for the laptop I'm typing this on. That effort, though it worked pretty well, was rather sledgehammer like, and this time I'd like to try and be at least a little more surgical in my approach, hence the need for the above information.

I don't think there is any reason for the SID scheme to care
about anything around it. It's intended as a self-consistent
scheme for controlling access to files. If you keep "clean installing"
over and over again, the SID root value is going to be different
each time. And yes, this might mean needing implicit Takeown
green-bar to proceed to give you access if you "clean install"
and the SID string changes. If you had a partition called "Data"
for example, and the owner was "Java" 111111111-222222222-333333333-1000
then the next time C: receives a clean install, the current
administrator might be 444444444-555555555-666666666-500 and
the user might be 444444444-555555555-666666666-1002 depending
on the order accounts were added. And that's no longer a match
for 111111111-222222222-333333333-1000 . An implicit Takeown
changes the ownership of Data, to two owners.

111111111-222222222-333333333-1000 <=== OS (new clean install) doesn't know who this is. Not in table.
444444444-555555555-666666666-1002 <=== OS now recognizes this number as "Java". We access "Data" via this one.

But the SID within C: , the files in say System32 are marked
for administrator or SYSTEM or whatever, and the values
line up well enough that the symbolic identifier "administrator"
or administrator group, the OS would still be able to figure
that out. As it is internally consistent with how things
were stamped at install time. But any foreign disks or partitions,
those may be using identifiers from somewhere else, and maybe
only their numerical nature is on display. As the local OS cannot
know the text strings a foreign OS is using.

The behavior might well be different in a Domain, where the authentication
is centralized and the identity of the accounts is sorta "known everywhere
within the domain". That's different than home computing, where the
environment is an "approximation of a domain", and only roughly
looks like there is some order to the chaos. You can have "Java"
account on two machines, but they don't have the same SID numeric value.
And as long as the Java account belongs to Administrator Group,
there's a good chance the machine will just do an implicit Takeown,
which takes some number of seconds to scan the whole tree.

Paul

Java Jive

2024-05-17 16:32:44 UTC

Permalink

Post by Paul

I've been searching for an answer to this question on & off since last night ...
Is a Windows PC's machine SID (which also forms the user account SIDs up until the final hyphen) cryptographically derived from the installation's Product Key? Or, to put it another way, if I change the product key on a PC, will the user SIDs change as a result, and so require changing the permissions on the user profiles and maybe elsewhere?
I think and hope that the answer is no, but does anyone know for sure?
I want to know this because I've had two old Dell Precision M6300 laptops go down, both through dead video cards - annoying but in their defence they were very old machines - and have replaced them with M6700s. I've just realised that the latter both have W7 Pro OEM product keys on stickers in the battery bay, so that gives me the option of adapting my W7 build for them, and then upgrading them to Win 10 Pro to give me two more licences for the latter. However, as the build I want to adapt is an Ultimate build, I will have to downgrade it by a procedure I've outlined before here when I did it successfully for the Home Premium build for the laptop I'm typing this on. That effort, though it worked pretty well, was rather sledgehammer like, and this time I'd like to try and be at least a little more surgical in my approach, hence the need for the above information.

I don't think there is any reason for the SID scheme to care
about anything around it. It's intended as a self-consistent
scheme for controlling access to files. If you keep "clean installing"
over and over again, the SID root value is going to be different
each time. And yes, this might mean needing implicit Takeown
green-bar to proceed to give you access if you "clean install"
and the SID string changes. If you had a partition called "Data"
for example, and the owner was "Java" 111111111-222222222-333333333-1000
then the next time C: receives a clean install, the current
administrator might be 444444444-555555555-666666666-500 and
the user might be 444444444-555555555-666666666-1002 depending
on the order accounts were added. And that's no longer a match
for 111111111-222222222-333333333-1000 . An implicit Takeown
changes the ownership of Data, to two owners.
111111111-222222222-333333333-1000 <=== OS (new clean install) doesn't know who this is. Not in table.
444444444-555555555-666666666-1002 <=== OS now recognizes this number as "Java". We access "Data" via this one.
But the SID within C: , the files in say System32 are marked
for administrator or SYSTEM or whatever, and the values
line up well enough that the symbolic identifier "administrator"
or administrator group, the OS would still be able to figure
that out. As it is internally consistent with how things
were stamped at install time. But any foreign disks or partitions,
those may be using identifiers from somewhere else, and maybe
only their numerical nature is on display. As the local OS cannot
know the text strings a foreign OS is using.
The behavior might well be different in a Domain, where the authentication
is centralized and the identity of the accounts is sorta "known everywhere
within the domain". That's different than home computing, where the
environment is an "approximation of a domain", and only roughly
looks like there is some order to the chaos. You can have "Java"
account on two machines, but they don't have the same SID numeric value.
And as long as the Java account belongs to Administrator Group,
there's a good chance the machine will just do an implicit Takeown,
which takes some number of seconds to scan the whole tree.

Apologies for not replying sooner, as I was busy doing the job, and
thanks for your detailed comments above. I think I can now absolutely
confirm that the Machine and User SIDs are not cryptographically derived
from the product key or similar, because I've completed this plan
successfully, have compare the User SIDs before and after, and they're
exactly the same, whereas the Product Key has changed. Here's how I
accomplished it ...

NOTE: These instructions were updated from my original method to
downgrade Windows 7 Ultimate to Windows 7 Home Premium, and therefore
refer throughout to Home Premium as the desired destination build, but
in fact on this occasion I was downgrading to Professional, as there are
Product Keys for that on each of the two PCs concerned.

0) Optionally, but advisedly, using an imaging program of your choice,
backup the target Ultimate system disk/partition - which is assumed to
have all device drivers and updates installed and be working, except for
activation, on the intended target PC.

1) On a spare HD in the intended target PC, create a vanilla Home
Premium build with all devices recognised and all updates installed.

2) Mount both the target Ultimate disk (U) and the new Home Premium (H)
disk as extra disks in another working windows system, which for
preference should NOT be the intended target system. To help avoid
confusion, you could give them drive letters U: and H: respectively.

3) If you haven't already on the individual builds when creating them,
you will probably need to select each in turn and give 'Administrators'
ownership throughout each of the two Windows directory heirarchies ...
H:\Windows
U:\Windows
... which you can do from Explorer by <rt-clicking> each in turn, and
choosing Properties, Security, Advanced, Owner, Edit. Probably also you
will have to grant Administrators Full access throughout both
heirarchies by running a command prompt as administrator and giving the
commands ...
icacls H:\Windows\*.* /C /Q /L /T /grant Administrators:F
icacls U:\Windows\*.* /C /Q /L /T /grant Administrators:F

4) Temporarily rename H:\Windows\System32\config to, say, 'configHP'.

5) Going back to the administrator command prompt, copy HP over U by
giving the command ...
xcopy /c /y /b /h /r /e /d H:\Windows\*.* U:\Windows\*.*
... ensure particularly that the branding sub-folder contents have
copied properly. Then remove surplus Ultimate files from U: by ...
for /d /r U:\Windows %A in (*ultimate*.*) do @if not exist "H:%~pnxA"
rd/s/q "%A"
for /r U:\Windows %A in (*ultimate*.*) do @if not exist "H:%~pnxA" del "%A"
... ensuring particularly that ...
"U:\Windows\Ultimate.xml"
... is renamed or deleted.

6) Rename H:\Windows\System32\configHP back to 'config'.

7) On the computer acting as host for these steps, run Regedit.

8) Still in Regedit, select 'HKEY_LOCAL_MACHINE', choose File, Load
hive, and load ...
U:\Windows\System32\configHP\SOFTWARE
(note 'configHP', *NOT* 'config')
... giving a suitable key name for the hive, say, 'U2HP'.

9) Navigate to the following keys, and export each of them saving them
with suitable filenames in somewhere convenient, possibly configHP ...
HKLM\U2HP\Microsoft\Internet Explorer\Registration
HKLM\U2HP\Microsoft\Windows\CurrentVersion\Component Based Servicing
HKLM\U2HP\Microsoft\Windows\CurrentVersion\SideBySide
HKLM\U2HP\Microsoft\WindowsNT
HKLM\U2HP\Wow6432Node\Microsoft\Windows NT\CurrentVersion
... then edit the last two as follows, when done you may have to save
them as ANSI text rather than Unicode to have Registry Editor accept them:
HKLM\U2HP\Microsoft\WindowsNT
Leaving the values in the parent key unchanged, remove all the subkeys
EXCEPT ...
HKLM\U2HP\Microsoft\Windows NT\CurrentVersion\DefaultProductKey
HKLM\U2HP\Wow6432Node\Microsoft\Windows NT\CurrentVersion
Leaving the values in the parent key unchanged, remove all the subkeys.

10) Select HKLM\U2HP and choose File, Unload hive.

11) Repeat step 8 to load the corresponding Ultimate hive from:
U:\Windows\System32\config\SOFTWARE
(it really is 'config' this time)
... being sure to give *exactly* the same key name as above, 'U2HP'

12) Import the registry files saved and edited as above in step 9. For
the Component Based Servicing key, you will have to give Administrators
both Ownership and Full Access of the destination Ultimate key and
replicate this down the sub-heirarchy.

13) Repeat step 10 to unload the hive.

If you are confident of having done everything correctly, delete now, or
else rename and some time in the future delete ...

14) The file (this file must not exist when you next reboot):
U:\Windows\Ultimate.xml

15) The directory:
U:\Windows\System32\spp\tokens\skus\Security-SPP-Component-SKU-Ultimate

16) The directory:
U:\Windows\System32\configHP

17) Eject the two disks from the temporary host system, and load the
Ultimate disk back in its intended target PC.

18) Boot the target PC, which may take significantly longer than usual,
as Windows tries to work out what happened. Quite likely it will slow
to a crawl, restrict usability, and prompt you for authentication as
soon as the log on process completes at the pace of a snail drowning in
treacle, at which point you may authenticate using your Home Premium
disk key, and then restart to regain full functionality.

--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Java Jive

2024-05-18 10:54:47 UTC

Permalink

Oops ... A significant typo, see below ...

Post by Java Jive
NOTE: These instructions were updated from my original method to
downgrade Windows 7 Ultimate to Windows 7 Home Premium, and therefore
refer throughout to Home Premium as the desired destination build, but
in fact on this occasion I was downgrading to Professional, as there are
Product Keys for that on each of the two PCs concerned.
0)    Optionally, but advisedly, using an imaging program of your
choice, backup the target Ultimate system disk/partition - which is
assumed to have all device drivers and updates installed and be working,
except for activation, on the intended target PC.
1)    On a spare HD in the intended target PC, create a vanilla Home
Premium build with all devices recognised and all updates installed.
2)    Mount both the target Ultimate disk (U) and the new Home Premium
(H) disk as extra disks in another working windows system, which for
preference should NOT be the intended target system. To help avoid
confusion, you could give them drive letters U: and H: respectively.
3)    If you haven't already on the individual builds when creating
them, you will probably need to select each in turn and give
'Administrators' ownership throughout each of the two Windows directory
heirarchies ...
    H:\Windows
    U:\Windows
.... which you can do from Explorer by <rt-clicking> each in turn, and
choosing Properties, Security, Advanced, Owner, Edit. Probably also you
will have to grant Administrators Full access throughout both
heirarchies by running a command prompt as administrator and giving the
commands ...
    icacls H:\Windows\*.* /C /Q /L /T /grant Administrators:F
    icacls U:\Windows\*.* /C /Q /L /T /grant Administrators:F
4)    Temporarily rename H:\Windows\System32\config to, say, 'configHP'.
5)    Going back to the administrator command prompt, copy HP over U by
giving the command ...
    xcopy /c /y /b /h /r /e /d H:\Windows\*.* U:\Windows\*.*
.... ensure particularly that the branding sub-folder contents have
copied properly. Then remove surplus Ultimate files from U: by ...
"H:%~pnxA" rd/s/q "%A"
del "%A"
.... ensuring particularly that ...
    "U:\Windows\Ultimate.xml"
.... is renamed or deleted.
6)    Rename H:\Windows\System32\configHP back to 'config'.
7)    On the computer acting as host for these steps, run Regedit.
8)    Still in Regedit, select 'HKEY_LOCAL_MACHINE', choose File, Load
hive, and load ...
    U:\Windows\System32\configHP\SOFTWARE
    (note 'configHP', *NOT* 'config')
.... giving a suitable key name for the hive, say, 'U2HP'.
9)    Navigate to the following keys, and export each of them saving
them with suitable filenames in somewhere convenient, possibly configHP ...
    HKLM\U2HP\Microsoft\Internet Explorer\Registration
    HKLM\U2HP\Microsoft\Windows\CurrentVersion\Component Based Servicing
    HKLM\U2HP\Microsoft\Windows\CurrentVersion\SideBySide
    HKLM\U2HP\Microsoft\WindowsNT

... \CurrentVersion

Post by Java Jive
HKLM\U2HP\Wow6432Node\Microsoft\Windows NT\CurrentVersion
.... then edit the last two as follows, when done you may have to save
HKLM\U2HP\Microsoft\WindowsNT

... \CurrentVersion

Post by Java Jive
        Leaving the values in the parent key unchanged, remove all the
subkeys EXCEPT ...
        HKLM\U2HP\Microsoft\Windows NT\CurrentVersion\DefaultProductKey
    HKLM\U2HP\Wow6432Node\Microsoft\Windows NT\CurrentVersion
        Leaving the values in the parent key unchanged, remove all the
subkeys.
10)    Select HKLM\U2HP and choose File, Unload hive.
    U:\Windows\System32\config\SOFTWARE
    (it really is 'config' this time)
.... being sure to give *exactly* the same key name as above, 'U2HP'
12)    Import the registry files saved and edited as above in step 9.
For the Component Based Servicing key, you will have to give
Administrators both Ownership and Full Access of the destination
Ultimate key and replicate this down the sub-heirarchy.
13)    Repeat step 10 to unload the hive.
If you are confident of having done everything correctly, delete now, or
else rename and some time in the future delete ...
    U:\Windows\Ultimate.xml
    U:\Windows\System32\spp\tokens\skus\Security-SPP-Component-SKU-Ultimate
    U:\Windows\System32\configHP
17)    Eject the two disks from the temporary host system, and load the
Ultimate disk back in its intended target PC.
18)    Boot the target PC, which may take significantly longer than
usual, as Windows tries to work out what happened. Quite likely it will
slow to a crawl, restrict usability, and prompt you for authentication
as soon as the log on process completes at the pace of a snail drowning
in treacle, at which point you may authenticate using your Home Premium
disk key, and then restart to regain full functionality.

Sorry about the typos and oversights, I don't think there are any more
significant ones.

--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Java Jive

2024-05-18 17:17:14 UTC

Permalink

On 18/05/2024 11:54, Java Jive wrote:

As the instructions are quite long, and haven't changed since my last
amendment, I'll top post this update ...

I've now completed the upgrade to Win 10 Pro 22H2 without problem, and
can confirm some points.

1) The resulting Windows 10 Pro build is authenticated.

2) In the instructions appended below, I mention for the Windows NT
registry dump removing all the subkeys *EXCEPT* the Default Product Key,
and I now realise this was the correct thing to do, because it seems to
be tied to the particular version of Windows, and so would be expected
to be, and in fact were, different between Windows 7 Ultimate which was
the starting build and Windows 7 Professional which was the intended
final build, so copying the key in from the Professional build was the
correct thing to do.

I believe this because using Product Key Finder on the original Win 10
Pro that came on the PC and comparing it with my build resulting from
using the label on the PC to authenticate Win 7 Pro and then upgrading
to Win 10 Pro, the Default Product Key is the same, but the others are
different.

3) So hopefully also this means that I have indeed succeeded in freeing
up the originally supplied Windows 10 Pro key to use elsewhere.

Post by Java Jive
Oops ... A significant typo, see below ...

Post by Java Jive
NOTE: These instructions were updated from my original method to
downgrade Windows 7 Ultimate to Windows 7 Home Premium, and therefore
refer throughout to Home Premium as the desired destination build, but
in fact on this occasion I was downgrading to Professional, as there
are Product Keys for that on each of the two PCs concerned.
0)    Optionally, but advisedly, using an imaging program of your
choice, backup the target Ultimate system disk/partition - which is
assumed to have all device drivers and updates installed and be
working, except for activation, on the intended target PC.
1)    On a spare HD in the intended target PC, create a vanilla Home
Premium build with all devices recognised and all updates installed.
2)    Mount both the target Ultimate disk (U) and the new Home Premium
(H) disk as extra disks in another working windows system, which for
preference should NOT be the intended target system. To help avoid
confusion, you could give them drive letters U: and H: respectively.
3)    If you haven't already on the individual builds when creating
them, you will probably need to select each in turn and give
'Administrators' ownership throughout each of the two Windows
directory heirarchies ...
     H:\Windows
     U:\Windows
.... which you can do from Explorer by <rt-clicking> each in turn, and
choosing Properties, Security, Advanced, Owner, Edit. Probably also
you will have to grant Administrators Full access throughout both
heirarchies by running a command prompt as administrator and giving
the commands ...
     icacls H:\Windows\*.* /C /Q /L /T /grant Administrators:F
     icacls U:\Windows\*.* /C /Q /L /T /grant Administrators:F
4)    Temporarily rename H:\Windows\System32\config to, say, 'configHP'.
5)    Going back to the administrator command prompt, copy HP over U
by giving the command ...
     xcopy /c /y /b /h /r /e /d H:\Windows\*.* U:\Windows\*.*
.... ensure particularly that the branding sub-folder contents have
copied properly. Then remove surplus Ultimate files from U: by ...
"H:%~pnxA" rd/s/q "%A"
"H:%~pnxA" del "%A"
.... ensuring particularly that ...
     "U:\Windows\Ultimate.xml"
.... is renamed or deleted.
6)    Rename H:\Windows\System32\configHP back to 'config'.
7)    On the computer acting as host for these steps, run Regedit.
8)    Still in Regedit, select 'HKEY_LOCAL_MACHINE', choose File, Load
hive, and load ...
     U:\Windows\System32\configHP\SOFTWARE
     (note 'configHP', *NOT* 'config')
.... giving a suitable key name for the hive, say, 'U2HP'.
9)    Navigate to the following keys, and export each of them saving
them with suitable filenames in somewhere convenient, possibly configHP ...
     HKLM\U2HP\Microsoft\Internet Explorer\Registration
     HKLM\U2HP\Microsoft\Windows\CurrentVersion\Component Based Servicing
     HKLM\U2HP\Microsoft\Windows\CurrentVersion\SideBySide
     HKLM\U2HP\Microsoft\WindowsNT

.... \CurrentVersion

Post by Java Jive
HKLM\U2HP\Wow6432Node\Microsoft\Windows NT\CurrentVersion
.... then edit the last two as follows, when done you may have to save
HKLM\U2HP\Microsoft\WindowsNT

.... \CurrentVersion

Post by Java Jive
         Leaving the values in the parent key unchanged, remove all
the subkeys EXCEPT ...
         HKLM\U2HP\Microsoft\Windows NT\CurrentVersion\DefaultProductKey
     HKLM\U2HP\Wow6432Node\Microsoft\Windows NT\CurrentVersion
         Leaving the values in the parent key unchanged, remove all
the subkeys.
10)    Select HKLM\U2HP and choose File, Unload hive.
     U:\Windows\System32\config\SOFTWARE
     (it really is 'config' this time)
.... being sure to give *exactly* the same key name as above, 'U2HP'
12)    Import the registry files saved and edited as above in step 9.
For the Component Based Servicing key, you will have to give
Administrators both Ownership and Full Access of the destination
Ultimate key and replicate this down the sub-heirarchy.
13)    Repeat step 10 to unload the hive.
If you are confident of having done everything correctly, delete now,
or else rename and some time in the future delete ...
     U:\Windows\Ultimate.xml
     U:\Windows\System32\spp\tokens\skus\Security-SPP-Component-SKU-Ultimate
     U:\Windows\System32\configHP
17)    Eject the two disks from the temporary host system, and load
the Ultimate disk back in its intended target PC.
18)    Boot the target PC, which may take significantly longer than
usual, as Windows tries to work out what happened. Quite likely it
will slow to a crawl, restrict usability, and prompt you for
authentication as soon as the log on process completes at the pace of
a snail drowning in treacle, at which point you may authenticate using
your Home Premium disk key, and then restart to regain full
functionality.

Sorry about the typos and oversights, I don't think there are any more
significant ones.

--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Java Jive

2024-05-22 14:24:14 UTC

Permalink

Post by Java Jive
I've been searching for an answer to this question on & off since last
night ...
Is a Windows PC's machine SID (which also forms the user account SIDs up
until the final hyphen) cryptographically derived from the
installation's Product Key? Or, to put it another way, if I change the
product key on a PC, will the user SIDs change as a result, and so
require changing the permissions on the user profiles and maybe elsewhere?
I think and hope that the answer is no, but does anyone know for sure?
I want to know this because I've had two old Dell Precision M6300
laptops go down, both through dead video cards - annoying but in their
defence they were very old machines - and have replaced them with
M6700s. I've just realised that the latter both have W7 Pro OEM product
keys on stickers in the battery bay, so that gives me the option of
adapting my W7 build for them, and then upgrading them to Win 10 Pro to
give me two more licences for the latter. However, as the build I want
to adapt is an Ultimate build, I will have to downgrade it by a
procedure I've outlined before here when I did it successfully for the
Home Premium build for the laptop I'm typing this on. That effort,
though it worked pretty well, was rather sledgehammer like, and this
time I'd like to try and be at least a little more surgical in my
approach, hence the need for the above information.

So, as previously described, two different Dell Precision M6700s with
two different OEM Windows 7 Professional Product Key stickers. Both
loaded with the downgraded Ultimate to Professional build, both
authenticated as per their respective stickers. Both then upgraded to
Windows 10 Professional, both authenticated, BUT ...

According to Product Key Scanner, both have IDENTICAL Windows 10 Product
Keys. How can this happen, and should I be concerned?

--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Paul

2024-05-22 14:58:52 UTC

Permalink

Both then upgraded to Windows 10 Professional, both authenticated, BUT ... <=== this is the key to the issue
According to Product Key Scanner, both have IDENTICAL Windows 10 Product Keys.
How can this happen, and should I be concerned?

Not only are they identical Product Keys, they're not even valid product keys.
The real key information is stored on the Microsoft server.
If you install the OS and try and use the "dummy" key value you
just collected, it's not useful for any purpose.

# Check your keys against this list.
# Bogus keys, as placeholders, by Microsoft. These strings are not "re-usable".

VK7JG-NPHTM-C97JM-9MPGT-3V66T (Windows 10 Professional) <--- X79 (my Test Machine)
YTMG3-N6DKC-DKB77-7M9GH-8HVX7 (Windows 10 Home - multi language) <--- the gutless laptop!
BT79Q-G7N6G-PGBYW-4YWX6-6F4BT (Windows 10 Home - single language)

I've seen the "3V66T" a lot here, via one experiment or another.
I don't type it in. The OS fills it in, when it consults the
Microsoft server and sends the machine hash as an ID to the server.

Paul

Java Jive

2024-05-22 16:00:20 UTC

Permalink

Post by Paul

Not only are they identical Product Keys, they're not even valid product keys.
The real key information is stored on the Microsoft server.
If you install the OS and try and use the "dummy" key value you
just collected, it's not useful for any purpose.
# Check your keys against this list.
# Bogus keys, as placeholders, by Microsoft. These strings are not "re-usable".
VK7JG-NPHTM-C97JM-9MPGT-3V66T (Windows 10 Professional) <--- X79 (my Test Machine)
YTMG3-N6DKC-DKB77-7M9GH-8HVX7 (Windows 10 Home - multi language) <--- the gutless laptop!
BT79Q-G7N6G-PGBYW-4YWX6-6F4BT (Windows 10 Home - single language)
I've seen the "3V66T" a lot here, via one experiment or another.
I don't type it in. The OS fills it in, when it consults the
Microsoft server and sends the machine hash as an ID to the server.

My duplicate keys are not any of those in your list. They begin:
NF6HC-...

--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Java Jive

2024-05-22 16:30:00 UTC

Permalink

Post by Paul

Both then upgraded to Windows 10 Professional, both authenticated,
BUT ... <=== this is the key to the issue
According to Product Key Scanner, both have IDENTICAL Windows 10 Product Keys.
How can this happen, and should I be concerned?

Not only are they identical Product Keys, they're not even valid product keys.
The real key information is stored on the Microsoft server.
If you install the OS and try and use the "dummy" key value you
just collected, it's not useful for any purpose.
   # Check your keys against this list.
   # Bogus keys, as placeholders, by Microsoft. These strings are not
"re-usable".
   VK7JG-NPHTM-C97JM-9MPGT-3V66T (Windows 10 Professional)
<--- X79 (my Test Machine)
   YTMG3-N6DKC-DKB77-7M9GH-8HVX7 (Windows 10 Home - multi language)
<--- the gutless laptop!
   BT79Q-G7N6G-PGBYW-4YWX6-6F4BT (Windows 10 Home - single language)
I've seen the "3V66T" a lot here, via one experiment or another.
I don't type it in. The OS fills it in, when it consults the
Microsoft server and sends the machine hash as an ID to the server.

NF6HC-...

However, the Win 10 Pro build upgraded directly from the Win 7 Ultimate
build, whose own product key came from its DVD, does have the same
product key as the first in your list.

--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Paul

2024-05-22 17:34:48 UTC

Permalink

Post by Paul

Not only are they identical Product Keys, they're not even valid product keys.
The real key information is stored on the Microsoft server.
If you install the OS and try and use the "dummy" key value you
just collected, it's not useful for any purpose.
   # Check your keys against this list.
   # Bogus keys, as placeholders, by Microsoft. These strings are not "re-usable".
   VK7JG-NPHTM-C97JM-9MPGT-3V66T (Windows 10 Professional)             <--- X79 (my Test Machine)
   YTMG3-N6DKC-DKB77-7M9GH-8HVX7 (Windows 10 Home - multi language)    <--- the gutless laptop!
   BT79Q-G7N6G-PGBYW-4YWX6-6F4BT (Windows 10 Home - single language)
I've seen the "3V66T" a lot here, via one experiment or another.
I don't type it in. The OS fills it in, when it consults the
Microsoft server and sends the machine hash as an ID to the server.

NF6HC-...

However, the Win 10 Pro build upgraded directly from the Win 7 Ultimate build, whose own product key came from its DVD, does have the same product key as the first in your list.

Yeah, the W7->W10 upgrades should be in the list.

Your NF6HC might be a "real" key, a purchased key for installation
on a brand new PC.

I wish I had something to offer, which would accept a key and
tell you what kind of key it was, but unfortunately there is
no evidence of an (external) tool for the job. Microsoft
likely has such a tool inside, but they don't want to give
people any sort of tool that "vets" keys. We could really use
that for verifying the $20 copies of Windows.

*******

OK, a Google got me a hit.

"NOTE

These are NOT product / license keys that are valid for Windows activation.
These keys only select the edition of Windows to install during setup,
but they do not activate or license the installation.
"

https://gist.github.com/rvrsh3ll/0810c6ed60e44cf7932e4fbae25880df

Default Product Keys for OEM Activation 3.0

Windows 10 Pro NF6HC-QH89W-F8WYV-WWXV4-WFG6P

Paul

Frank Slootweg

2024-05-22 18:42:02 UTC

Permalink

Paul <***@needed.invalid> wrote:
[...]

Post by Paul
Yeah, the W7->W10 upgrades should be in the list.
Your NF6HC might be a "real" key, a purchased key for installation
on a brand new PC.
I wish I had something to offer, which would accept a key and
tell you what kind of key it was, but unfortunately there is
no evidence of an (external) tool for the job. Microsoft
likely has such a tool inside, but they don't want to give
people any sort of tool that "vets" keys. We could really use
that for verifying the $20 copies of Windows.

I have the ShowKeyPlus app [1] and that correctly identified the keys
you posted, i.e. what ShowKeyPlus says, matches what you said.

[...]

[1] 'ShowKeyPlus'
<https://apps.microsoft.com/store/detail/showkeyplus/9PKVZCPRX9NV>
There are versions for Windows 11, 10, 7, WinPE and XP:
<https://www.techspot.com/downloads/7129-showkeyplus.html>

Java Jive

2024-05-23 18:25:32 UTC

Permalink

Post by Frank Slootweg
[1] 'ShowKeyPlus'
<https://apps.microsoft.com/store/detail/showkeyplus/9PKVZCPRX9NV>
<https://www.techspot.com/downloads/7129-showkeyplus.html>

Thanks for that, though the version I downloaded from the above didn't
work on W7. I downloaded a more successful version from here:

https://github.com/Superfly-Inc/ShowKeyPlus/releases/tag/ShowKeyPlus7060

Its results were quite interesting ...

First, this PC, a Dell Inspiron 15RSE 7520 bought new from Dell and
originally supplied with a version of Windows 8 which I disliked so much
[1] that about a week after it arrived I rang Dell and asked for a
Windows 7 DVD. It is still running Windows 7 Home Premium, as I haven't
yet managed to adapt its Windows 10 upgrade build to be sufficiently
'civilised' to keep my blood pressure within safe limits [2]. The build
was created by downgrading in the manner described upthread an Ultimate
build authenticated by the key that came with its DVD, this build being
authenticated by the key that came with the Dell OEM Windows 7 Home
Premium DVD.

Installed Key: [Correct Home Premium key off the Dell OEM W7HP DVD]
Original Key: [Still remembers the W7 Ultimate key from its DVD!]
Original Edition: Windows 7 Ultimate Retail
OEM Key: [Key for original W8 as supplied, probably from BIOS]
OEM Edition: Win 8 RTM Core OEM:DM

The slightly worrying thing there is that somehow it found out that this
was originally an Ultimate build. I wonder how? It didn't manage this
for the recent two such adaptations/downgrades, which I cover next ...

The 2 Dell Precision M6700s recently installed with W7 downgraded from
Ultimate to Professional, as described upthread, and authenticated using
the OEM W7 Pro Product Key stickers in their battery compartments, then
each upgraded to W10Pro.

Windows 7:

Product Name: Windows 7 Professional
Version: 7601.24546 (64-bit OS)
Product ID: 00371-OEM-9320914-77297
Installed Key: [Correct OEM Win 7 Pro key from the sticker]
OEM Key: Windows 7 OEM marker present in firmware

That's all there is. Unlike the above PC, no mention of either build
being derived from Ultimate. Perhaps this time round I did a better job?

Windows 10:

Product Name: Windows 10 Pro
Version: 19041.4412 (64-bit OS)
Product ID: 00330-50000-00000-AAOEM
Installed Key: NF6HC-QH89W-F8WYV-WWXV4-WFG6P
OEM Key: Windows 7 OEM marker present in firmware

Finally, the W7 Ultimate build, authenticated by its DVD key, as
upgraded to Win 10 Pro:

Product Name: Windows 10 Pro
Version: 19041.4412 (64-bit OS)
Product ID: 00330-80000-00000-AA123
Installed Key: VK7JG-NPHTM-C97JM-9MPGT-3V66T
OEM Key: Windows 7 OEM marker present in firmware

[1] Particularly the W8 so-called 'charms' - a marketing misnomer if
ever there was one. Every time I moved the mouse towards a corner, say
to click on something in the System Tray, some other bloody thing would
pop up and get in the way of what I was trying to do.

[2] Today yet another absolutely typical example. As sometimes when I
find a useful utility, I decided to put the executable of ShowKeyPlus in
a folder I created ...
C:\Programs\Utilities
... and a link to it in the Start Menu.

I signed on as an Administrator, so Windows 7 raised no complaints about
either action.

Surprisingly, Windows 10 allowed me to copy in the program without
complaint, which one would have thought was the more important thing to
prevent, but could I merely make the shortcut to it? No, it was more
than the job's worth nanny's life and very existence was worth, so, even
as an Administrator, I had to create it on the Desktop instead, whence I
simply moved it into the Start Menu as originally intended, accompanied
by a bleating warning from the job's worth nanny which I overrode.

Similarly, I like to adapt the properties of shortcuts launching command
consoles to put them in particular places, usually the bottom left-hand
corner of the desktop. There was never any problem doing this under any
previous version of Windows, but, even signed on as Administrator,
Windows 10 won't let me save the changes, I have to save them elsewhere
and then move them back into their original places, each time
accompanied by a job's worth nanny message demanding to know if I really
want to do this.

WTF is actually *achieved* by such bloody-minded obstructivism in
Windows 10? SFA except being so exasperatingly annoying that it's
making me, each time I try to use it, more and more inclined simply to
disable as much of its so-called 'protections' as possible; in other
words, completely contrary to the presumed intent of making the system
more secure, it is forcing me to make it less secure, who knows possibly
even less secure than previous versions of Windows, simply to be able to
use it in a normal hassle-free way.

The way that Microsoft have near totally emasculated both the
Administrator account and, particularly, the Administrators group in
Windows 10 is an exercise in absurd futility. They ought to be renamed
MicrosoftMinion and MicrosoftMinions, so nobody can be left in any doubt
as to what actually they now are.

--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Paul

2024-05-24 00:37:55 UTC

Permalink

The way that Microsoft have near totally emasculated both the Administrator account and,
particularly, the Administrators group in Windows 10 is an exercise in absurd futility.
They ought to be renamed MicrosoftMinion and MicrosoftMinions, so nobody can be left
in any doubt as to what actually they now are.

I can "see" your blood pressure level from here :-)

Paul

Char Jackson

2024-05-24 05:28:23 UTC

Permalink

Post by Java Jive

Post by Frank Slootweg
[1] 'ShowKeyPlus'
<https://apps.microsoft.com/store/detail/showkeyplus/9PKVZCPRX9NV>
<https://www.techspot.com/downloads/7129-showkeyplus.html>

Thanks for that, though the version I downloaded from the above didn't
https://github.com/Superfly-Inc/ShowKeyPlus/releases/tag/ShowKeyPlus7060
Its results were quite interesting ...
First, this PC, a Dell Inspiron 15RSE 7520 bought new from Dell and
originally supplied with a version of Windows 8 which I disliked so much
[1] that about a week after it arrived I rang Dell and asked for a
Windows 7 DVD. It is still running Windows 7 Home Premium, as I haven't
yet managed to adapt its Windows 10 upgrade build to be sufficiently
'civilised' to keep my blood pressure within safe limits [2]. The build
was created by downgrading in the manner described upthread an Ultimate
build authenticated by the key that came with its DVD, this build being
authenticated by the key that came with the Dell OEM Windows 7 Home
Premium DVD.
Installed Key: [Correct Home Premium key off the Dell OEM W7HP DVD]
Original Key: [Still remembers the W7 Ultimate key from its DVD!]
Original Edition: Windows 7 Ultimate Retail
OEM Key: [Key for original W8 as supplied, probably from BIOS]
OEM Edition: Win 8 RTM Core OEM:DM
The slightly worrying thing there is that somehow it found out that this
was originally an Ultimate build. I wonder how? It didn't manage this
for the recent two such adaptations/downgrades, which I cover next ...
The 2 Dell Precision M6700s recently installed with W7 downgraded from
Ultimate to Professional, as described upthread, and authenticated using
the OEM W7 Pro Product Key stickers in their battery compartments, then
each upgraded to W10Pro.
Product Name: Windows 7 Professional
Version: 7601.24546 (64-bit OS)
Product ID: 00371-OEM-9320914-77297
Installed Key: [Correct OEM Win 7 Pro key from the sticker]
OEM Key: Windows 7 OEM marker present in firmware
That's all there is. Unlike the above PC, no mention of either build
being derived from Ultimate. Perhaps this time round I did a better job?
Product Name: Windows 10 Pro
Version: 19041.4412 (64-bit OS)
Product ID: 00330-50000-00000-AAOEM
Installed Key: NF6HC-QH89W-F8WYV-WWXV4-WFG6P
OEM Key: Windows 7 OEM marker present in firmware
Finally, the W7 Ultimate build, authenticated by its DVD key, as
Product Name: Windows 10 Pro
Version: 19041.4412 (64-bit OS)
Product ID: 00330-80000-00000-AA123
Installed Key: VK7JG-NPHTM-C97JM-9MPGT-3V66T
OEM Key: Windows 7 OEM marker present in firmware

It might be interesting, with all of this talk about Product Keys, to run the
built-in command for displaying the original product key. I'm not sure if this
works on 7, but it does work on 8, 10, and 11.

In an elevated command prompt:
wmic path SoftwareLicensingService get OA3xOriginalProductKey

The output should be the original Product Key. I wonder if the results would
match what was shown by ShowKeyPlus.

<snip>

Char Jackson

2024-05-24 05:33:08 UTC

Permalink

Post by Char Jackson

Post by Java Jive

Post by Frank Slootweg
[1] 'ShowKeyPlus'
<https://apps.microsoft.com/store/detail/showkeyplus/9PKVZCPRX9NV>
<https://www.techspot.com/downloads/7129-showkeyplus.html>

It might be interesting, with all of this talk about Product Keys, to run the
built-in command for displaying the original product key. I'm not sure if this
works on 7, but it does work on 8, 10, and 11.
wmic path SoftwareLicensingService get OA3xOriginalProductKey
The output should be the original Product Key. I wonder if the results would
match what was shown by ShowKeyPlus.
<snip>

I meant to add the Powershell equivalent: (all on one line)

(Get-WmiObject -query 'select * from
SoftwareLicensingService').OA3xOriginalProductKey

Java Jive

2024-05-24 08:12:55 UTC

Permalink

Post by Char Jackson
(Get-WmiObject -query 'select * from
SoftwareLicensingService').OA3xOriginalProductKey

No dice on W7 HP or W10 Pro:

D:\Temp>wmic path SoftwareLicensingService get OA3xOriginalProductKey
Node - CHARLES-I
ERROR:
Description = Invalid query

D:\Temp>powershell (Get-WmiObject -query 'select * from
SoftwareLicensingService').OA3xOriginalProductKey

D:\Temp>

C:\>wmic path SoftwareLicensingService get OA3xOriginalProductKey
OA3xOriginalProductKey

C:\>powershell (Get-WmiObject -query 'select * from
SoftwareLicensingService').OA3xOriginalProductKey

C:\>

--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Char Jackson

2024-05-24 16:18:15 UTC

Permalink

Post by Java Jive

Post by Char Jackson
(Get-WmiObject -query 'select * from
SoftwareLicensingService').OA3xOriginalProductKey

D:\Temp>wmic path SoftwareLicensingService get OA3xOriginalProductKey
Node - CHARLES-I
Description = Invalid query
D:\Temp>powershell (Get-WmiObject -query 'select * from
SoftwareLicensingService').OA3xOriginalProductKey
D:\Temp>
C:\>wmic path SoftwareLicensingService get OA3xOriginalProductKey
OA3xOriginalProductKey
C:\>powershell (Get-WmiObject -query 'select * from
SoftwareLicensingService').OA3xOriginalProductKey
C:\>

I understand why it didn't work on Win 7, but it works (both forms of the
command) on Win 10 for me, as well as Win 8. Google says it also works on Win
11, but I don't have a suitable VM for that here. I'm not sure why it didn't
work for you on Win 10 but thanks for indulging me.

J. P. Gilliver

2024-05-24 05:38:43 UTC

Permalink

In message <***@4ax.com> at Fri, 24 May
2024 00:28:23, Char Jackson <***@none.invalid> writes
[]

Post by Char Jackson
It might be interesting, with all of this talk about Product Keys, to run the
built-in command for displaying the original product key. I'm not sure if this
works on 7, but it does work on 8, 10, and 11.
wmic path SoftwareLicensingService get OA3xOriginalProductKey
The output should be the original Product Key. I wonder if the results would
match what was shown by ShowKeyPlus.
<snip>

I just tried, in both normal and administrator command prompt (W7 HP
32), and got:

Node - STONE-PC
ERROR:
Description = Invalid query

(STONE-PC is the "name" of the PC; stone is the make, and the shop that
sold it to me presumably just used that as the name when installing W7.
I had never heard of the make, but it seems to be a good machine.)

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)***@T+H+Sh0!:`)DNAf

"Bother," said Pooh, as Eeyore sneezed the crack all over Owl.

Char Jackson

2024-05-24 16:13:45 UTC

Permalink

Post by J. P. Gilliver
[]

I just tried, in both normal and administrator command prompt (W7 HP
Node - STONE-PC
Description = Invalid query
(STONE-PC is the "name" of the PC; stone is the make, and the shop that
sold it to me presumably just used that as the name when installing W7.
I had never heard of the make, but it seems to be a good machine.)

Thanks, John. I sort of figured that Win 7 would be a no go.

I see that Frank verified that the built-in commands, or as some folks say, the
in-built commands, produce the same key as the ShowKeyPlus app, at least on
systems that support the commands.

Frank Slootweg

2024-05-24 13:41:18 UTC

Permalink

Char Jackson <***@none.invalid> wrote:
[...]

As the others had problems with the wmic command, I tried it on my
Windows 11 Home system and indeed both the wmic command and ShowKeyPlus
display the exact same key.

FYI, as Java Jive had problems with the Windows 7 version of
ShowKeyPlus on the techspot.com site, I used the version from the
Microsoft Store:

<https://apps.microsoft.com/store/detail/showkeyplus/9PKVZCPRX9NV>

Java Jive

2024-05-24 15:19:21 UTC

Permalink

Post by Frank Slootweg
[...]

As the others had problems with the wmic command, I tried it on my
Windows 11 Home system and indeed both the wmic command and ShowKeyPlus
display the exact same key.
FYI, as Java Jive had problems with the Windows 7 version of
ShowKeyPlus on the techspot.com site, I used the version from the
<https://apps.microsoft.com/store/detail/showkeyplus/9PKVZCPRX9NV>

The download link from the techspot.com took me to the Microsoft store,
so it was that version that wouldn't work for me, which may be the same
as you've just linked above. The version from the source that I linked
worked for both W7 & W10.

--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Java Jive

2024-05-23 00:54:44 UTC

Permalink

Post by Paul

Not only are they identical Product Keys, they're not even valid product keys.
The real key information is stored on the Microsoft server.
If you install the OS and try and use the "dummy" key value you
just collected, it's not useful for any purpose.
   # Check your keys against this list.
   # Bogus keys, as placeholders, by Microsoft. These strings are not "re-usable".
   VK7JG-NPHTM-C97JM-9MPGT-3V66T (Windows 10 Professional)             <--- X79 (my Test Machine)
   YTMG3-N6DKC-DKB77-7M9GH-8HVX7 (Windows 10 Home - multi language)    <--- the gutless laptop!
   BT79Q-G7N6G-PGBYW-4YWX6-6F4BT (Windows 10 Home - single language)
I've seen the "3V66T" a lot here, via one experiment or another.
I don't type it in. The OS fills it in, when it consults the
Microsoft server and sends the machine hash as an ID to the server.

NF6HC-...

However, the Win 10 Pro build upgraded directly from the Win 7 Ultimate build, whose own product key came from its DVD, does have the same product key as the first in your list.

Yeah, the W7->W10 upgrades should be in the list.
Your NF6HC might be a "real" key, a purchased key for installation
on a brand new PC.
I wish I had something to offer, which would accept a key and
tell you what kind of key it was, but unfortunately there is
no evidence of an (external) tool for the job. Microsoft
likely has such a tool inside, but they don't want to give
people any sort of tool that "vets" keys. We could really use
that for verifying the $20 copies of Windows.
*******
OK, a Google got me a hit.
"NOTE
These are NOT product / license keys that are valid for Windows activation.
These keys only select the edition of Windows to install during setup,
but they do not activate or license the installation.
"
https://gist.github.com/rvrsh3ll/0810c6ed60e44cf7932e4fbae25880df
Default Product Keys for OEM Activation 3.0
Windows 10 Pro NF6HC-QH89W-F8WYV-WWXV4-WFG6P

Yes, that's the one. However, the two installations are both
authenticated, at least for now and hopefully will remain so. I suppose
the only problem might arise if I need to re-install: putting in that
key would presumably allow the re-installation to proceed, and, once
complete, hopefully the server would remember either PC as being already
authorised.

--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk