@george1421 Even though the machine “seems” to be connected to the domain after reimage, I always remove and readd the machine to the domain.

On my current “problem” I had to use the manual complete reset method to get Windows Update working again. And I’m still not sure because it’s “Checking for Updates” on 2 years worth of updates.

@Wayne-Workman: Fog version 1.2.0. Linux CentOS 6.7 server, Windows 7 SP1 Workstation clients.

@MRCUR: I am using WSUS. But, points at george1421. Each Workstation image will only be restored to that Workstation with a new same model hard drive. The impression I always got was that sysprep wasn’t necessary in my case.

You can do it manually for now. You CANNOT use the new inits with 1.2.0, if you download those and place them, no imaging will work at all. Just try the new kernel and keep a copy of your old kernel incase it bombs. Link here for steps:
https://wiki.fogproject.org/wiki/index.php?title=Kernel_Update

Make sure you pay attention to the old file name before moving it - I think 1.2.0 was 32 bit. The kernel bit has to match the init bit.

@Tom-Elliott Thanks Tom. I’m not really sure what the issue was with Centos 6.7. Iptables was disabled, SELinux was disabled. It didn’t throw any specific error messages and nothing in any of the logs caught my eye.

Either way, Wayne’s suggestion to move to CentOS 7 worked and I now have the trunk up and running. Thanks for the help folks!

@Tom-Elliott

Fixed in r5767. Thanks

cross linking post same issue, by same OP: https://forums.fogproject.org/topic/7926/fog-won-t-finish-capturing-a-windows-10-image

Upgraded from v1.12 and not all storage nodes were up or had the correct id/password combination. Removing old storage and fixing credentials fixed this. In the previous version snapins did not validate the fog user.

That’s good news. That video pretty much answered all my questions. Thanks a bunch.

@plegrand
No worries!

@Joe-Schmitt

Makes sense, and I had suspected as much.

Thanks!

PS snapin if anyone needs it.

Start-Transcript -path c:\SnapinLogs\CleanupUpdaterLog.log $strFileName="c:\program" If (Test-Path $strFileName){ Remove-Item $strFileName } Stop-Transcript

This is because 1.2.0 had no support for windows 10 as it didn’t exist during 1.2.0’s release. The only way, that I’m aware of, to get Windows 10 to image is to use Multipart Non-resizable. That said, Trunk versions of fog will run without much issue.

@RobTitian16 Just seems to have been a slow network day I guess as it’s running through fine now at 3GB/min 🙂

@Tom-Elliott

Ok, so I changed the storage group for my snapins from my QNAP to default and now it worked.
Thanks for the help!

@jide Sounds like you’re using dnsmasq? In such case, you can turn off DHCP on the fog server (if you want), and turn it back on for the ISP box (if you want) and just roll with dnsmasq.

Glad you got it working.

@mmethe Image size on the server is determined with FTP.

If you’re referring to image size on the client, this is updated each time you capture or deploy an image and is merely an informational piece in the DB that will not affect deployment.

Confirm that it works in GIT 8259.

@foggee There are mixed thoughts about the best version of Ubuntu. IMO, I’d go with 16. There are special steps that need included (search the forums for “Ubuntu 16”), but after that it’s good to go. Ubuntu 14 will work without modification.

You do not need to install 1.2.0. You can go straight to trunk.

@Sebastian-Roth
I’m off until Monday. Unfortunately, I had to deploy that laptop without imaging. I’ll have more to do though. I may be able to grab it later and continue testing. Thanks for the help!!

Cheers,

Joe Gill

@Joe-Schmitt said in Trunk 5735 PC doesnt restart after joining the domain.:

This issue has been addressed in v0.11.2. Please test when you get a chance.

The Update worked for me Joe, Thanks!

@Tom-Elliott

This resolved our issues. Thank you for the great support. I now have a working FOG server again; now on trunk. I hope this makes our upgrades to Windows 10 Edu easier over summer break.

Thanks, again!

@bmaster001 said:

So you guys have plenty of time to think about this weird piece of hardware, and I’ll get back to this thread when we have more devices to play with!

I don’t think we are able to push this anywhere without having the hardware around or someone like you who are willing to test things out.