As for the rest, as long as it works in your organization there is no need to change because of what some dude on the internet says. From personal experience continuing to update a single golden image renders the image very messy and a bit bloated over time. But if it works for you, then there is no need to change.

Don’t get me wrong- I know that’s not an optimal way to work long term and we’re working on other solutions. I’m not disagreeing with that, I just don’t think there’s an actual problem with the MFT specifically. I’m not an expert on imaging or NTSF by any means though, so I could be wrong. I’m not trying to be hostile, I just want to understand since the MFT seems well below normal tolerance for Windows.

As for the rest, as long as it works in your organization there is no need to change because of what some dude on the internet says. From personal experience continuing to update a single golden image renders the image very messy and a bit bloated over time. But if it works for you, then there is no need to change.

Don’t get me wrong- I know that’s not an optimal way to work long term and we’re working on other solutions. I’m not disagreeing with that, I just don’t think there’s an actual problem with the MFT specifically. I’m not an expert on imaging or NTSF by any means though, so I could be wrong. I’m not trying to be hostile, I just want to understand since the MFT seems well below normal tolerance for Windows.

@george1421 we’re hoping to go to AutoPilot soon, so if we’re going to have to find another solution that’s likely to be it. Sysprep is good for like 1000 captures on modern versions of Windows afaik, the only failures we’ve had are from some MS store issues that were easily resolved.

Yes, I changed the padding to 7% and it captured without issues. I know you’re saying it’s not a true fix for the disk, but based upon my Windows knowledge and the research I’ve done today, there appear to be zero issues with the disk. The MFT is a perfectly normal size (rather small, even). Every screenshot of anyone, anywhere using NSFTInfo shows MFT at “100%” but that doesn’t seem to be a true figure. Try running it on a Windows machine of your own, I’d wager it will show 100%.

@george1421 Additionally, there seem to be other instances of this happening with FOG. I guess I’ll try this solution now, though this is still quite concerning.

@george1421 Furthermore, after additional research it seems this makes even less sense. The actual size of the MFT is only 600 MB and it seems from research that it always shows as “100%” when you run these kinds of commands. 600 MB is actually quite small for an MFT on a modern machine.

The only way this makes sense is if FOG messed something up shrinking partitions, which seems to be exactly what happened. There’s well over 200 GB free on this image. Based on everything I’ve found this is an issue with FOG, no the computer’s MFT.

Unfortunately this is an issue because of the way you manage your golden image.

Can you expand upon this? This seems to suggest that we’re doing something wrong, but if so I’ve no idea what it is.

I ran that check and the MFT is indeed at 100%. The changes we make on the image are minor- just Windows updates and very infrequent updates to the handful of apps we have installed; do you have any idea what our mistake is that could be causing this? It seemed to me very much like it happened when FOG started resizing the image the first time. None of our other images have this problem.

Hey everyone,

Getting a little desperate here. I’ve tried to recapture our normal image 3 times now. It’s the same computer, we just log into it, run Windows Updates, update any apps etc., and then capture about once a month.

Today every time I try to capture it throws an error and fails, and on top of that it then wouldn’t start up after that one time. Had to connect a recovery disk to repair the MBR. Seems to be some problem with FOG trying to resize the disk. The only thing I did different today from normal was doing Disk Cleanup to hopefully shrink the image a little. Just restarting the computer shows everything is working just fine in Windows.

Now, I’m getting errors like this every time I try to capture (see attached image). It seems to be choking on resizing. One time the resize test failed, another time it started resizing and then failed.

Trying to upload a picture to this site is failing and so is attaching it here, so here’s an image link: https://ibb.co/grQCt9g

Any help would be much appreciated, I’m on a deadline and I have no idea why this is just falling apart on me.

@george1421 Thanks again for the help. This is probably where I’ll have to put a pin in this for now, because we restored the original sever and the duplicate server has been shut down for the time being. Hopefully we can circle back around to it soon, though.

@george1421 Sorry if I’m a bit slow replying but I’m going to try to stay on this. Stuff has gone off the deep end here this week so I’m being pulled in a dozen directions.

The VM is set bridged according to my networking guy.

Is pcap something like wireshark?

@sebastian-roth Checking on that now. The weird thing is, it works on the other vlan fine. It’s only after cloning it to the new one that it broke. Either way they should still be using the same DHCP server.

Both vlans in the same cluster, hosted in the same building.

@george1421 According to my network guy:

It's Windows DHCP on a Windows 10 server on a VM.