@Tom-Elliott Version 7007

If i save the username as test\test it works on the first pass. I am not sure if this changes anything but i was setting the user/password at the global level. and the group level I never set it at the host level. I would also get it to work once then image the system and after the image it would begin failing.

@GreenItSolutions Does the disk actually have an OS installed on it? What format is the system booting in? EFI, BIOS, some alternate config I’m completely unaware of?

@GreenItSolutions Great to hear that it’s working with a dump switch. Please let us know when you find the solution and explain it here for other people who might run into the same issue… Thanks in advance!

So this problem definitely relates to a windows xp to windows 10 file transfer issue and is nothing to do with fog.
From what I found here http://helpdeskgeek.com/office-tips/fix-office-2010-cannot-verify-license-error-message/
I discovered that the file tokens.dat is indeed a part of activation.
If you happen to have a similar problem…

stop the service osppsvc
Delete or rename tokens.dat and cache.dat found at C:\ProgramData\Microsoft\OfficeSoftwareProtectionPlatform
Start the service osppsvc
Open any office program and let it do the self repair

This also fixes the problem of the office installer autoclosing when trying to repair or uninstall.

No worries with the trunk build either. I can say you will need the trunk build if you have newer hardware and/or you have to deal with gpt hard drives or uefi bios. All require the latest trunk version to work.

There are still being reports of bugs in the trunk build. Once reported they are fixed quite quickly. The point being you may need to update your fog server often until the developers get into the release candidate stage of deployment.

I can say from personal experience win10 with BIOS and MBR disks deploy without issue.

@Sebastian-Roth that registry key is perfectly fine. The reason it looks like it’s missing a backslash is because of a bug in the registry handler logging mechanism in pre-0.9.12. But even if it was missing that slash, that registry key will not affect anything of importance

ALSO, I’d like to introduce some terminology I’ve coined. 🙂

CUNU - Computer that the User has Never Used before…

Example - “This is a CUNU login, that’s why this is happening.”

and of course, the opposite…

Non-CUNU - Computer that the user has used before.

@mlnancejr8808 Hmmm… interesting. But if that is what it takes then I think you are on your way. You now have a solid image that will support your fleet with a common image. Well done!!

@Sebastian-Roth

it was just a problem with old datas in FOG directory ( C:\Program Files (x86)\FOG ), delete this folder before install the new one did the the trick.

@kevin-buckley said:

Do I need to add the HyperV VM drivers to the original PC before trying to restore to a hyper V VM?

I have to admit that I haven’t done this before but I’d guess you need to, yes!

@Jbob You sir just saved my sanity, that is exactly the problem.

@Wayne-Workman So in order for me to make an image that will work on both of these laptops I’ll have to start over and install all of the drivers for the new laptop on the computer that I’m taking the image of right? So technically once all those drivers are installed, I’ll capture the image and I should be able to deploy it to the other laptop right? Any additional steps or just install those drivers?

@Sebastian-Roth autologout on the legacy client also causes the “random” reboot. I’ll even guess the reboot actually happens every so many minutes like clock work after the user signs in.

The fog.log typically is very short in size and gets overwritten. It’s most likely the log had started over causing the lack of any other potentially relevant info being given to us.

Hello,

Sorry to reply only now.
I recreate a master and it works perfectly, thank you !

@Wayne-Workman I’ve found the solution late friday night. It wasn’t a FOG problem, but a Windows problem with the proxy settings. FOG seemed to be the only client that used that proxy setting so I found a way to disable it. The registry setting is:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings]
“ProxySettingsPerUser”=dword:00000000

This solves the problem for us, maybe it may come in handy for some other users of FOG.

Thank you all for the great support!

Stefan

@apathetic_admin Don’t beat yourself up over something you didn’t know. What’s important is you asked for help where you needed it - instead of just giving up or being too proud to ask for help.

Part of being good in I.T. / comp-sci is knowing where to get answers.

Oh wow…I originally asked the onsite tech to boot a client to see if he got the Fog boot menu…

…he was rebooting the storage node. Sigh…

Never mind, guys. Thanks anyway.

@Wayne-Workman I would love to 😃
However I would wait until I have finished my current project of using fog to upgrade all clients to windows 10 so that this method is more thoroughly tested first.
It’s tested, but not thorough and I will likely make some changes to my image prep script along the way. Then making it a wiki article will pretty much be copy paste from my documentation on the work project. Should be done by the end of next month, hopefully sooner, but I’m anticipating more troubles.

@davido38 FYI on that script - it will only remove the apps for the logged in user. There are two different AppX commands for removing from the current user’s profile and removing the app from the machine so it’s never reinstalled for any user.

Remove-AppXPackage = removes app for current user

Remove-AppXProvisionedPackage -Online = removing the app from the machine so it’s not reinstalled

I use these two commands before sysprepping:

Get-AppXPackage -AllUsers | Remove-AppXPackage
Get-AppXProvisionedPackage -Online | Remove-AppXProvisionedPackage -Online

@it_man The svn build is where you need to be if you want UEFI support. While uefi support was in 1.2.0 it worked marginally well (sporadic at best). There has been great efforts to get the uefi/gpt issues ironed out with the recent push of uefi only systems that just hit the market.

If you can tolerate a little instability the trunk has many new features you could take advantage of. If you detect a bug in the trunk build it is usually fixed in 2 days or less.