Have you tried it with a different mechanical HDD? I’ve had hard drives fail right after chkdsk /F /V /R /X reported that there are no errors or bad sectors.

Nvm, I tried another kernel, Version : 4.1.2 and it worked.
Case closed

@Sebastian-Roth
Yes, very much under time pressure in the business at the moment… I had to rebuild another Fog server… and I uploaded my 2 main images onto it manually… so I didnt use any of the backup procedure.
This is all a consequence of being forced by company circumstances to run things into production without any testing time…
the joy of decisions being made above your head and you just being told to get on with it!

@dolf Perhaps this deserves a video.

@Wayne-Workman The problem has been solved. Thanks.

@mabarton I briefly went over this thread because it’s been a while. Have you individually tried every EFI exit type?

I’m on Ubuntu 14.04 though…
Anyway, it’s working with php5.

@Joe-Gill Great job. Boo @Microsoft. Booooo

@jayrob86 this is where it gets a bit complicated if you want to reverse engineer stuff.

The post download scripts are saved on the FOG server, but they are executed by the FOS engine (the linux operating system that captures and deploys images to the target computer).

So to answer your question, the function.sh script is in the init(s) (virtual hard drive that is downloaded to the client along with the kernel (bzImage) when pxe booting).

So you next question may be how can I peek into the inits? There is a wiki for that: https://wiki.fogproject.org/wiki/index.php?title=Modifying_the_Init_Image

The file is in /usr/share/lib/fog (or something like that, its in /usr/share…)

@Tom-Elliott Sorry for the delay - I am on an isolated network for my FOG Server - so right now only 3 machines in the FOG environment.

@Tom-Elliott All fixed and working thanks all can be marked as solved!

Personally, I would setup a test FOG environment just get FOG working.
I was in the same boat quite a number of weeks ago.
Setting up FOG on your established network will be tough to get right.
Use the standalone approach firstly.
It probably took me 40 to 50 hours of work to get a solution.
Last week using my Fog server , I was able to image 50 PCs in Win7 Sysprepped mode ready to join the domain.
My breakthru was seeing FOG actually working when I used a VMbox setup on my own PC following a YouTube tutorial.

good luck

When I can, I will be copying the sql table over to the new server.
I will update as to success when trying to push an image out.

DANG… Once again stupid I feel … Tried to update VIA SVN but original install install was GIT. Ran update on GIT and pow fixed.
Close please… LOL

@Tom-Elliott And you can’t calculate all the hours you’ve saved for other admins.

@george1421 So sorry for the late reply (2 months even) but this sorted my issue out

Thanks

@Tom-Elliott I have to say, FOG has some of the speediest devs 🙂 Y’all do great work. The migration from 0.32 to 1.3.0 was pretty straight forward and worked quited well. To be honest, I had expected more issues since I made such a big jump in versions but they were minor and easy to fix. This is a testament to how dedicated the FOG team and community are to this project.

For anyone still running 0.32 (if I was not the last hold out), the migration is straight forward. Follow the directions on the wiki and you will be up and running in no time.

Thanks for the help everyone.

@kenoboy

Short answer: Not with the client, but perhaps with some post-sysprep script.

Long answer: Azure AD is not your standard enterprise directory service system. A directory service is meant to manage things like identity, workstations, security, network policies, and so on. It is also standard for a directory service to provide the LDAP protocol for authentication (Lightweight Directory Access Protocol). This is what the client leverages to join Windows Server AD, Apple Open Directory, Samba, and any other LDAP compliant directory service.

Azure AD only focuses on the identity portion, and one of its main uses is as SaaS (Software as a Service). As such it has no need to provide LDAP support. Instead it provides modern web-tech based protocols via REST api and such. It’s used to integrate with other software and provide a SSO interface.

Azure AD and your standard LDAP domain are fundamentally different, and as such the client cannot join it. Instead you may need to use a script that runs after sysprep completes (setupcomplete.cmd). A quick Google search results in this article: https://azure.microsoft.com/en-us/documentation/articles/active-directory-azureadjoin-devices-group-policy/ . I haven’t looked through it in detail, but it appears they are using a powershell script to join Azure AD.

For future people.

I realize this posting is a bad example of things. But it must be noted. All I personally care about with fog is that the main elements operate.

E.g. Capturing/Deploying images is working, (not the text behind it), the server is sending and working properly with the FOG Client (both legacy and new), and the like. Text that has NO impact on these elements don’t matter to me. What was coded there before I even started developing for this project is likely what was/is used.

Now that FOG is on GIT, it doesn’t have to me ONLY me making changes. If I disagree with changing the text, it’s not likely anything I’m going to disregard if a pull request is made for it. This is what really got me. I don’t care what the text is, and why – especially if there’s real issues to take care – do I have to be the one to make these changes?