@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?

@arnaudrigole Please ensure that if you have STP enabled on this “test” port, you must ensure one of the fast STP functions are enabled either RSTP, Port Fast, or Fast STP (depending on what your building switch maker calls it). Or just disable STP on the “test” port to see if that fixes your problem. I would suggest leaving STP on and making sure one of the fast protocols are enabled.

We have also seen GreenEthernet (802.1az) cause problems with the FOS engine.

Out of curiosity, what make and model is your building switch?

@Tom-Elliott Ever seen this Download failed: filesize = 0 error? I haven’t…

@cojohnson The message Image failed to restore and exited with exit code 0 usually means that something went wrong when running partimage. Can you please get your camera ready for when the blue partimage window comes up. Take a quick picture or possibly a (steady) video) of the error you see on that blue partimage window. That probably will help us a lot.

@Wayne-Workman

Wayne, you made my day! Thanks!! You guys are awesome!

Cheers,

Joe

Tom says he added code for node replication to iterate through each group it belongs to.

However I’ve already done an overhaul to go down to just one storage group and I THINK replication is working.

When the dust clears, we will know.

@Lombard Please check if the primary MAC for the host is correct.

@arnaudrigole Cool. Glad you got it resolved.

Yes, background image is different issue I have learned from previous problem. Again, thank you for your helping with this netmask and IP range problem. Without your help I probably go crazy, LOL.

@Wayne-Workman nope not a parsing issue more likely it was an importing issue that failed to set up the macs for the host. It has been , as far as I’m aware, been fixed for at least 5 days though.

@tom.langenfeld Your fogguiuser and fogguipass fields are completely separate from the username/password fields as defined in the fogsettings file. Those new fields are ONLY relevant to the GUI itself.

Well, I’m not sure what happened but I tried to restart it yesterday and then it wouldn’t boot up. Something about no controller. Anyway, I guess CentOS 7 gives you the ability to boot from a last known good configuration and when I did that everything worked. I updated FOG and Apache2 went through without a hitch. Sorry to waste your time, thanks guys.

@Tom-Elliott Sure does. Thanks for the help!

@Wayne-Workman:
The GPT was the issue. I am now able to capture the image from the M72z. Thanks for the help.

-Roy

Thank you so much that worked and fixed my issues too!

Running very latest svn 5829, client 0.11.2 on Win 7 32 bits. Framework 4.0.

dmidecode is not available by default in OSX it seems. I started the fog debug mode and got the following:

# dmidecode 2.12 # SMBIOS entry point at 0x8cd15000 SMBIOS 2.4 present. 51 structures occupying 2746 bytes. Table at 0x8CD14000``` The message " Invalid entry length (0). DMI table is broken! Stop." only appears at the end of the dmidecode command.