I would firstly strongly recommend upgrading to trunk. It includes the latest version of ipxe which alone could fix the issue.
But I have a few other ideas from my tests of difficult networks that I’ve gotten FOG working on.

So if I understand correctly you already have reserved ips on your windows dhcp for the hosts you are testing. Does FOG also have a reserved IP address in the dhcp? Something I’ve had good luck with is giving FOG a reservation on the DHCP server (On the same subnet as the computers it’s imaging, even if you have seperate subnets for servers and workstations) and a DNS entry too and then set option 66 with the FQDN (Fully Qualified Domain Name/Hostname.domain). This could be part of the issue here, but since you’re getting as far as you are it probably isn’t, but it could help since it may help the with getting the dhcp address.

So in summary of that idea

• Give FOG a dhcp reservation
• Give FOG a dns reservation
• Set Option 66 to hostname

Now A separate idea, even though you do have the dhcp method working. If it continues to give you grief you can give proxy dhcp via dnsmasq a try. I’ve had luck with it in environments that don’t like being edited. You typically don’t want to use poth the dhcp option and dnsmasq, however in some harder to modify network configurations, it is helpful to have both running. But I’ve also seen where one breaks the other, so just be aware of that when trying. So if you try this method, I would try unsetting option 66 and 67. And if it doesn’t work try setting the options again.

I put some information about configuring dnsmasq in a post in this thread
https://forums.fogproject.org/topic/6262/tftp-problems/43

There is also more information in the wiki
https://wiki.fogproject.org/wiki/index.php/ProxyDHCP_/dnsmasq-_DRAFT
https://wiki.fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/Using_FOG_with_no_DHCP_server

Hopefully that’s helpful in some way.

@Wayne-Workman said:

Let me know if you’d like to try it out.

Let me help here, you want to try it out.
You can probably get windows 10 imaging working on the older version of FOG, but if you want everything to work flawlessly, you’re going to need to update, and it’s pretty darn easy.

Here are some posts to help out

https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk
https://forums.fogproject.org/topic/6331/automating-git-updates-for-fog
https://forums.fogproject.org/topic/6010/msi-silent-install/2
https://forums.fogproject.org/topic/4250/new-client-progress

@anthonyglamis @Wayne-Workman speaks the truth.
I would just add that there is a setting called FOG_FTP_IMAGE_SIZE in fog configuration → Fog Settings → General Settings
that you can enable. The size that says 0.0 is likely image size on client. If you enable FOG_FTP_IMAGE_SIZE then you will also see the compressed image size on the FOG server which I think will automatically update, but it might also need to be deployed first.

I just like being able to see both sizes.

@Wayne-Workman I just noticed that I missed this post, it was when I was on vacation. This hasn’t actually been a problem on this new network as much. If it happens to me again I’ll come back here or make a new post with the fog.log on anything having trouble.

@Wayne-Workman I see that now, You posted while I was writing my post so I didn’t see that. I got distracted whilst writing it.

So you can do these things in the gui with much ease. I’m guessing you’re trying to write a script of some sort to automate it further?
If you run a debug session then you can run any of those commands on the computer you’re imaging with things like fog.wipe and fog.download.

Since the actions you make in the gui are essentially doing things in the database, I suppose that it would be possible to manually edit the database with a script to queue the actions you want on the computers you want. But I don’t know the database well enough to help much more than point you in that direction.

What exactly are you trying to do though? You can set up cron style jobs in the gui if you are trying to just have wipes and restores done regularly, you could set that up in the gui without custom code. Just select cron style deployment when you queue a job in the gui.

Hopefully that’s helpful in some way.

@Wayne-Workman said:

@Arrowhead-IT said:

Just make new images in the fog gui with the same settings and point them to the file names and they should work. Does that make sense?

People always mess that up.

Do I sound full of myself if I say that I never messed that up? Because well, I never messed that up. It just kinda worked as it should anytime I’ve done that.

@anthonyglamis said:

I created those images in the previous fog version so is this a bug or am I not capturing the image correctly?
Also I deleted those images (Dell3450, LenovoE430) however they are still on my linux box, can I get those back into the fog server?

If they are still in the /images folder then yes. If they are in a different machine, still yes, just transfer the files to the new fog server /images folder.

Just make new images in the fog gui with the same settings and point them to the file names and they should work. Does that make sense?

@anthonyglamis So what is the current status? Did the new image upload and download successfully? Is AD working like magic with the new version?

@anthonyglamis Fogcrypt is essentially obsolete, yes. You can still put the fogcrypt output into the legacy input but I find the new auto-encrypt to work better. But yes I’m pretty sure that the fogcrypt tool is still there

I hadn’t noticed that the hashes were different before, so I checked mine and they are different. I haven’t had any problems though, so I would say it shouldn’t be an issue.

@anthonyglamis 6038 is the latest version. That’s the git/svn revision number. It won’t say 1.3.0 until that version is officially released, so don’t worry about that.

For the image store corrupt error, did that go away after upgrading from 6032→6038?
If not check that image folder on the fog server with

ls /images/imageName 

and make sure there’s a d1.mbr or something of that sort.
Also make sure the permissions are correct on the image store

sudo chmod -R 775 /images

also what does /etc/exports say?

cat /etc/exports

@vbelous Yes, there are a million reasons to upgrade.

@anthonyglamis said:

Arrowhead,

I am wondering if this is a DNS issue? My host are all “unable to resolve”.

So the unable to resolve thing doesn’t necessarily affect the active directory issue, but it is something of a dns issue. For example, If your dns or perhaps dhcp server assigns hostnames to the computers based on ip address unless you reserve it in the server (It’s an issue I had at my last job where the university had a custom dhcp server that set the hostname based on the ip address unless you manually reserved by mac address, it was annoying). My point is they could relate, but I’ve seen the active directory join work even when the host isn’t showing as green/up in fog. So I would make sure everything else is right first before seeing if this is the cause. For example, does wake on lan work, because that only works if the host is down, because well it has to wake it from being off. Point is the ad join functionality doesn’t depend on the gui host up/down function in my experience.

Are you also setting the hosts to join the active directory in the gui, or are you doing it in the pxe imaging menu at the computer. Your configuration looks correct for the joining default settings. So as long as that user can join a computer to the domain and the hostname doesn’t already exist on the domain it should work. Just want to make sure you’re clicking the checkbox to tell the host to join the domain.

Also, is the latest fog client/service installed on the computer’s in question?
Also once that box is checked it typically just joins the domain right then restart and all. And if someone takes it off the domain it will just join right back again.

Hope that helps in some way

@vbelous said:

i’m taking for a previous user

I’m not sure what you mean by that

And since you have 7 and 8 images, are you running into some sort of trouble with uploading a windows 10 image or are you just worried that there’s no option to say an image is windows 10 in the older versions of fog. Setting it to windows 7 or 8 doesn’t change anything in the imaging process that I am aware of, it’s more for inventory and organization of the database as I understand it. Granted Windows 10 is an option in the latest trunks, so it doesn’t really matter.

Have you tried uploading a windows 10 image to your working image configurations for 7 and 8 and run into trouble?
Just trying to help you better here.

Since you’re very new to FOG server I feel the need to ask if you’ve been able to make images for windows 7 or 8?
Are you just new to FOG or are you new to imaging entirely?

Depending on what customizations you want to make, making an image for any version of windows isn’t all that different really.

What is your end goal here?

Just to answer some of your questions. The delayed task time thing is a bug that I have had too, haven’t actually found a solid fix for it. But with a little testing you can figure out how many hours it’s off and get delayed tasks working. However, this time issue doesn’t effect active directory joining.

Also the fog server not being on the domain is also not an issue. My fog server isn’t on the domain and the AD joining works no problem.

Can you show us a screenshot of the active directory default settings you have set in the fog gui?

@Tom-Elliott Great Success! It’s all good again.

@Lee-Rowlett I think you are somewhat correct there. In all my testing I found that it relates to when a user first logs in it installs all the metro apps for that user including cortana. And when you do a profile copy in the system advanced settings control panel it ends up copying some of those installed apps to the default profile which causes the installation of metro apps on a new profile to fail, but there’s no error because the installs think they succeed since the files are already there.
At least I think that has some to do with it. My new script system seems to work flawlessly and it is much easier than my old way of having to change the registry everytime and such.

I would still test your theory for you, just for funzies, but I don’t actually use an unattend.xml. I don’t like sysprep. It breaks my default profile sometimes, and I’ve seen it break other things and it forces you to go back to oobe which messes with my computer naming system. I’ve kinda found it to not be necessary. Yes it resets some security id’s for activation this and that but if you are using windows enterprise volume licensing, that doesn’t cause any problems. In windows 7 I figured out the registry key to change and then just re-inputting the windows key and reactivating gave it a new sid. Windows 8 and 10 just work without issue without doing that. As for drivers, I make my images on a vm so they’re already hardware independent and I use the terminal tool devcon (included in the windows wdk 8.1, I just copy the devcon.exe over to my image vm after installing the wdk on my workstation) to uninstall all the devices in the device manager before rebooting with devcon -r remove *
It goes through the uninstalling of devices much much faster than sysprep does too.

So thank you sir for your help, but I think I got it figured out.

@Arrowhead-IT I tried resizing the partition manually in windows to the smallest that windows would allow to shrink to see if it by chance would get past the resize test before resizing, but it didn’t work either. It was a long shot.

@Tom-Elliott Not quite working.
Got past the partition count but got a different error