It’s amazing how this is still broken by sysprep after so many years.

Try the guts of the script on an affected profile. It won’t hurt anything but might fix it.

rmdir /s /q "C:\Users\<name>\AppData\Local\Microsoft\Windows\WebCache"
del "C:\Users\<name>\AppData\Local\Microsoft\Windows\WebCacheLock.dat"

Sounds familiar. Are you using copyprofile=true in your sysprep?

I use the following in a vb script that runs from an auto-logged-on Administrator as it comes out of sysprep.

Sub sProfileFixes()
	' Clean up problems caused by using COPYPROFILE=TRUE
	Dim retry : retry = 0
	Do Until retry = 10
		If objFSO.FolderExists( "C:\Users\Default\AppData\Local\Microsoft\Windows\WebCache" ) Then
			On Error Resume Next
				Call objShell.Run( "cmd /c rmdir /s /q C:\Users\Default\AppData\Local\Microsoft\Windows\WebCache", 0, True )
			Err.Clear
			retry = retry + 1
		Else
			Exit Do
		End If
		Wscript.Sleep( 5000 )
	Loop
	If objFSO.FileExists( "C:\Users\Default\AppData\Local\Microsoft\Windows\WebCacheLock.dat" ) Then
		objFSO.DeleteFile "C:\Users\Default\AppData\Local\Microsoft\Windows\WebCacheLock.dat"
	End if
End Sub

@Tom-Elliott Okay, I’ll look into that.

Ultimately I’m looking for a best-effort recommended, second to last resort (reinstalling OS would be the last resort) solution that would tear down and pave over all that is FOG.

Sometimes tinkering, tweaking and forensic fixes just don’t do the job and you need other more drastic options in your troubleshooting arsenal; a FOG uninstaller.

But I don’t want to re-install the OS by remote. Not yet at least.

Re-installing FOG does not strip it from the server. It re-installs FOG.

It’s easy enough to yum remove virtually everything else. What about a solution for FOG and its tendrils?

You misunderstand. I’m exploring a “nuke it from orbit” solution. I want to tear the server down to its bones then build it back without physical intervention.

For one particular server I used the following.

# Remove FOG services
	rm /etc/init.d/FOGImageReplicator
	rm /etc/init.d/FOGMulticastManager
	rm /etc/init.d/FOGScheduler

# Delete FOG database
	mysql -u root -p
	<password>
	drop database fog;
	exit

# Remove FOG files
	rm -rf /var/www/fog
	rm -rf /var/www/html/fog 
	rm -rf /opt/fog
	rm -rf /opt/fog.old
	rm -rf /tftpboot
	rm -rf /opt/trunkgit
	rm -rf /opt/trunksvn

# Delete FOG system user
	userdel fog
	userdel fogproject

# Delete supportive systems
	yum -y remove php*
	yum -y remove httpd

# Clean & Update the OS
	yum clean all
	rm -rf /var/tmp/yum-administrator-PudGB
	rm -rf /var/cache/yum
	yum list iostat
	yum makecache
	yum grouplist
	yum grouplist hidden
	yum update -y

# Reboot to Commit
	reboot

This is a curious request I had to stop and think about. ReFS is not bootable, so it would never contain an OS, which defeats the primary purpose of using FOG.

I’m not a fan of multi-partition imaging, so I can’t say just how important this would be to FOG users in general.

Primarily I want to as it says, totally remove everything and anything that FOG has touched or used from the latest release 1.5.7 all the way back to at least 1.2.

Not that I’m giving up on FOG right now, but I have some legacy servers cruising for a bruising, and I want to be able to rebuild as cleanly as possible, by remote.

Then of course, comes the rebuild. Installing FOG is a cinch, but of course I need to re-install those OS elements affected, and I’d prefer to not have anything at all left from them that FOG may have touched … to totally remove any doubt that something, somewhere, may have been borked by FOG or the many versions installers over the years of revisions.

I’m interested in a CentOS 7 solution.

I recommend against using Ubuntu. CentOS 7.x is my friend for FOGing.

Things can break from time to time, and given the sheer variety of … variety, it’s good to know for testing purposes if there is a cutoff for how far back one can go for testing before you reach incompatibility.

That also goes for going forward, using for example a 1.4.4 system, how far up the food chain can one go with the kernels for testing?

What is the lowest version kernel that is compatible with 1.5.7 ?

@Quazz Oh you bet.

@Quazz Excellent. Thank you. I want to be able to roll back if necessary while I field test 1.5.7 in our all 1.4.4 environment.

Is it possible to install other versions 1.x of FOG other than the branches from the GIT pull?

  remotes/origin/db-security
  remotes/origin/dev-branch
  remotes/origin/feature-fog2-gui
  remotes/origin/fix-reports
  remotes/origin/master
  remotes/origin/unique-identifier
  remotes/origin/working
  remotes/origin/working-1.6

Inquiring minds want to know.

This is how I clean a Windows OS prior to capture.

@echo off
REM Cleanup_Mastering1.cmd is manually executed during the Windows mastering as Administrator in Audit Mode

REM Disk Cleanup with all options selected 
cleanmgr /verylowdisk

del /Q /F "C:\Windows\Temp\*.*"
del /Q /F /S "%LOCALAPPDATA%\temp\*.*"
del /Q /F /s "%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\*.*"

REM Delete Shadow Copies (Restore Points)
vssadmin delete shadows /all /quiet

REM Force chkdsk at next startup
echo y | chkdsk c: /offlinescanandfix

REM yes a second time
del /Q /F "C:\Windows\Temp\*.*"

REM Clear All Event Logs
for /f %%a in ('WEVTUTIL EL') do WEVTUTIL CL "%%a"

REM Restart!
shutdown -r -t 0

Notice the restart.

‘cleanmgr’ will pop up with a prompt… ‘OK’ it.

If you’ve allowed your system to retrieve and apply Windows Updates (don’t!) the ‘cleanmgr’ command will take a very long time; about an hour. You’re then better off manually deleting “C:\Windows\SoftwareDistribution” before this.

For comparison, my stuff running on Hyper-V 2019 host, although same stuff when I had it running on Hyper-2016.

My development server sitting right beside me.

• a desktop i7-7700
• 32 GB RAM
• onboard Intel 1 Gb NIC
• 256 GB NVMe boot drive
• 2 TB SATA-III SSD
• 2 TB 7200rpm SATA-III HDD
• running Server 2019 Standard with Hyper-V

The FOG server VM

• disk 1 = 20 GB .vhdx which is stored on the NVMe boot drive above.
• disk 2 = the 2 TB HDD above (for /images storage)
• Gen1 machine
• 2 GB Memory
• 4 virtual processors (marginal differences going higher, noticeable difference going lower)
• Network adapter (not LEGACY, connected to the onboard Intel 1 Gb NIC)
• running CentOS 7.x minimal
• 1.4.4 Fog Server
• bzimage/32 4.15.2

The VMs I use to build images are Gen1 or Gen2, and built on the 2 TB SSD.

Captures are saved to the 2 TB HDD.

Our field servers for deployment are ancient, 11year old Lenovo M58 with Pentium e2200 CPU, 2 GB memory, and 500-2000 GB HDD also running CentOS 7.x but on bare metal.

You really, really want to get off the legacy adapter, it’s only 100 Mb.

A Gen1 machine using Legacy Adapter maxes out at 100 Mb.

A Gen2 machine using the default `network adapter’ maxes out at the hosts’ max.

It sounds like you are creating and capturing on the same physical box to the same single physical drive.

You want to to create your VMs on one drive, while capturing to a different drive.

Also, you really want to use an SSD for your VM drive.

I’ve deployed to physical, Hyper-V and Vmware without issue.