@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.

Quick update since we’re going into the weekend. Network team has confirmed the need for a IP helper to reach the separate VLAN. Will update further on Monday when the change is made. Thanks again for the assist @Wayne-Workman

We do that with a GPO. Even with groups from a trusted domain.

@Wayne-Workman I’m using Trunk, so the group policy method is perfect! Feel free to post the script for the older versions, if other people stumble across this thread.

@Arrowhead-IT Removing the IP_ was exactly the fix. My printer mapped successfully both ways, locally, and via my samba share. This is good stuff.

@apathetic_admin I’m not sure if this helps you or not but creating TCP/IP definitions has been successful for me. The Samba directions via the Wiki were pretty straight forward. I really didn’t like the idea of placing a ton of printer drivers locally on my “master” images, so the Samba share worked great.

Thank you both for the quick responses. 🙂 Very much appreciated.