Paul wrote:
Robert in CA wrote:
I put #3 hd in the 8500 and restarted it to insert the Rescue CD
but it would not read the CD and I tried several times. It just goes
straight to the login and then I got this.
https://postimg.cc/8fJxW3wz
Then after pressing enter/escape it finally went to the desktop. We
need to resolved this invalid install issue. As you saw for yourself'
the 8500 is licensed so I don't know why I'm getting this or why the
external HD are messing up when it was fine or why the Rescue CD
doesn't load.
The external hd case had no issues on the 780 but I replaced
everything including the hd and it still won't fucntion yet the Mrimg
hd and flask key do?
At present #3 is on the 8500 and I'll leave it here for the time being
until I hear back from you.
Robert
I discussed one obscure reason for Not Genuine, and that is
if the time clock is off by large amounts, from the correct time.
There is a second thing that might be playing a part.
You changed the BIOS CMOS battery, the CR2032.
The SATA port could have been set to AHCI or RAID, in the BIOS,
before the battery change.
Maybe the XPS 8500 shipped with the setting at RAID, the 1TB
drive was set up as a "RAID Ready" volume by Dell. I don't
know if RAID is a build-to-order option for your machine or not.
If it was, the 1TB drive could have RAID metadata loaded in the
last track of the drive. This is a special area, that is
inaccessible to Macrium.
OK.
1) I don't really know why it's not genuine.
2) I don't know of, or see a reason why, a RAID issue
would upset it. You did get it to boot, so it can't
be that far from correct.
3) What I'm trying to avoid here, is going in circles.
(Like having one disk Not Genuine, then a second disk
Not Genuine, and so on. Don't want this.) This means,
ideally, I'd like to understand what tipped it over.
But the powers that be, don't make this easy. They will
give error codes for things like "you didn't have permissions
to check this problem" or the like, error codes ending in 5.
But for the information that counts, they're not going
to give it to you.
We can do things, to "try to make it activate", but again,
this is Whack-A-Mole. If you just flail about, that's not
progress that's happening.
The advice here, is sound, as far as it goes.
https://www.dell.com/support/kbdoc/e...genuine-issues
Time and date not correct on the system,
or time zone not matching actual location.
All required Windows Updates not installed
(most recent Daylight Savings Time patch).
Software or driver corruption of the OS
Viruses and malware
Note: This article supplies only ONE possible solution to a
specific WGA issue where the BIOS flag has been set, it
does not apply to all WGA issues. === True enough...
...
rename tokens.dat tokens.bar === cmd.exe, elevated to administrator
slui They include steps for stopping
... sppsvc, which would otherwise protect
tokens.dat from changes.
To me, just running "slui" as Administrator
should be enough. If tokens.dat is not valid,
why would it keep the file around ???
As long as you're booting #3 without the original 1TB
in the machine, there should not be a "spread" of
the issue from one disk to the next. There *can*
be a spread, if a license key is installed too many
times, which I presume also involves counting
the number of times a user uses "slui".
The theory was, that Royalty OEM OSes should not be
quite as ticklish when it comes to counting "slui"
invocations. That's because SLIC activated OSes
should "auto-activate" - the determination should
be do-able using local information. It's not the
same as COA key validation, where the key must be
sent off to the server.
*******
Summary:
Since #3 is in the machine right now, you might
as well Administrator "slui" test it, and reboot to
give it a trial. You can use "slmgr /dlv" to check
license status, or mgadiag (the command you tested
the other day and pressed the "Copy" button)
is an alternative. You can issue commands like that
from an Administrator Command Prompt.
Now, if this doesn't work out, I don't know what to
try next...
Paul