@fry_p Excellent job. What you posted is exactly what I would have had you do.

Just keep in mind that this is only likely to work with the exact sub-model, the one you said: Surface Pro 4 1724

For future readers, all that’s needed to make a vendor class for other sub models is a packet capture posted here on the forums, or analyzed by yourself. Simply look at the device’s DHCP Discover packet, inside option 60 you’ll find the vendor class identifier.

@Wayne-Workman using FOG 1.2.0, however after uploading the image a second time everything is now working correctly.

Cheers

@phishphan said in HP ZBOOK15U G3 - Host Registration Problem:

I ask because once I have my captured image I move it to another drive for archival.

You should automate that with a cron task and scp or rsync.

@Wayne-Workman Ok.

That what i did and then i re-ran the installer and it worked. Thank You!!

@Tom-Elliott said in Upload Task: Updating database... failed. FTP problems:

@zachu THe reason the path is specified (not allowing slashes) is because it can give access to other parts of the filesystem. This doesn’t mean it WILL happen, but from a security perspective what’s to ensure you don’t write a specific file or overwrite the root folder? I know there’s some other obfuscated methods of protection here, but let’s just imagine, you decide to put the image path be be as /images/../../../../bin/init or /images/../../../../usr/bin/init or some other binary name.
While technically it shouldn’t be possible, with the wrong setup it is a possibility. Now your fog server will likely work for a while. Then start having some funny issues.

I perfectly understand why it’s like this. I was more like toying with different ways to go around the problem I had. I’m ok with the way it works now.

The Wiki is perfectly accurate. You would, essentially, change the images location to go from /images to /images/newdisk. No where in the wiki article, from what I’ve skimmed through, would state that you are placing the image on the disk in the way you originally described. Changing the way move_upload is not quite that simple.

Oh right, I think I then read too far there between the lines. With the guide on the wiki article’s last lines, it’s meant to move all your images under the “newdisk”, not just one or part of them. I get it now 🙂

Changing the way move_upload is not quite that simple.

Yeah, I glanced just quickly at the codebase there and realized that it isn’t just a minor change, but I think it is doable still. All the needed actions are moving (renaming) and deleting files and folders, just as it is done now. Now it’s really simple and pretty when you can just move the whole directory instead of doing multiple actions to the files.

Would you accept a pull request of changing the move_upload process, if I find time to put it together? I’m not making any promises, but just thinking about it. I’ve never really contributed to an open source project but I might have the skills to put that one together. But if it fights the way you want it to work, then I wont bother 🙂

I really thank you for your time!

Btw, I settled for a process that I just move the image files to the dedicated HDD always after upload. It’ll do now, since it’s only temporary 🙂

For future readers:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_NFS

@Joe-Gill Well, I suppose the first thing to try is this group that failed - but by itself, without other multi-cast tasks running. See what happens.

Since this issue isn’t really related to FOG, I’ll mark it as solved.

OK reinstalled the FOG sever again (over itself) and everything seems to have ironed itself out. I had to basically install it twice. But everything seems golden. Back to Windows 10 on a Surface image. Thank you guys.

I also added it to the wiki.
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Hosts_think_they_are_not_registered_.2F_can.27t_register_.2F_other_weirdness

@spetzmax

We are requesting that all community members who have Surface Pros to please do a packet capture, to capture the DHCP conversation the client sends out at boot time via the ethernet dock, and upload the capture here. The intent is to gather more information about the Surface Pro, so fog can better support network booting it.

Thanks,
Wayne

@Scott-Adams

We are requesting that all community members who have Surface Pros to please do a packet capture, to capture the DHCP conversation the client sends out at boot time via the ethernet dock, and upload the capture here. The intent is to gather more information about the Surface Pro, so fog can better support network booting it.

Thanks,
Wayne

@dustindizzle11

We are requesting that all community members who have Surface Pros to please do a packet capture, to capture the DHCP conversation the client sends out at boot time via the ethernet dock, and upload the capture here. The intent is to gather more information about the Surface Pro, so fog can better support network booting it.

Thanks,
Wayne

@Tom-Elliott
Yeah that makes since. I just rem there being an issue with the resizable option with ntfs at one time. And the fixed size worked better or was more stable. I don’t remember exactly and I’ve slept alot since then. Old habits I suppose.

Thanks.
Jason

@x23piracy It updates the next time the image is used. Regardless of capture or deploy.

@Towndrunk said in Windows 10 Domain Issue:

I imaged a computer that was activated and on the domain. After applying that imaged to another computer it says that is on the domain when I log in locally, however there is no trust relationship.

If your image is already joined to the domain, you will have nothing but problems, and major ones at that. There is no imaging solution made by anyone that would suggest taking an image from a domain-bound computer. They all suggest exactly the opposite, take an image of an un-bound system.

@Tom-Elliott said in Fog Trunk Autologging Out Immediately:

I did not update the text because I think it’s simpler to enter values in the form of “720 minutes” vs having users run calculations on their own (no offense anybody).

That said, I was unaware the logout time was being done in seconds and not performing the calculation as it had under the legacy client. (Oversight I suppose, for that i’m sorry).

This has been patched and pushed though. Thanks for letting us know.

I agree wholeheartedly and I can confirm that this is now working as it should on the latest 1.3.0-RC2 version.

thanks!

Thanks for all the help. You pointed me in the right direction and the problems have been resolved.

I always booted our Mac Minis with ipxe.efi. Just try different ones and see which one is working for you…

@george1421
and it works! Thanks very much , 4.1.2 did the trick 🙂