@andrewg78 What I want you to do is start a new thread.

I want you to pxe boot the target computer using FOG 1.5.4 and the post a clear screen shot of the exact error. Lets work through why its not working on your hardware there.

@Tom-Elliott Confirmation was made.

RC-22 officially released. Please update and all should be much more betterer.

@JJ-Fullmer

:urls set msdart-url http://192.168.1.155/2-MSDART :MENU menu colour --rgb 0xff0000 0 || cpair --foreground 1 1 || cpair --foreground 0 3 || cpair --foreground 4 4 || item --gap -- ------------------------------------- item fog.local Boot from hard disk item msdart6x86 Microsoft DaRT for Windows Vista 32bit item msdart6x64 Microsoft DaRT for Windows Vista 64bit item msdart7x86 Microsoft DaRT for Windows 7 32bit item msdart7x64 Microsoft DaRT for Windows 7 64bit item msdart81x86 Microsoft DaRT for Windows 8.1 32bit item msdart81x64 Microsoft DaRT for Windows 8.1 64bit item fog.return Return to previous menu choose --default fog.local --timeout 5000000 target && goto ${target} :fog.local sanboot --no-describe --drive 0x80 || goto MENU :msdart6x86 initrd ${msdart-url}/MSDaRT60x86.iso chain memdisk iso raw :msdart6x64 initrd ${msdart-url}/MSDaRT60x64.iso chain memdisk iso raw :msdart7x86 initrd ${msdart-url}/MSDaRT70x86.iso chain memdisk iso raw :msdart7x64 initrd ${msdart-url}/MSDaRT70x64.iso chain memdisk iso raw :msdart81x86 initrd ${msdart-url}/MSDaRT8.1x86.iso chain memdisk iso raw :msdart81x64 initrd ${msdart-url}/MSDaRT8.1x64.iso chain memdisk iso raw :fog.return chain http://${fog-ip}/${fog-webroot}/service/ipxe/boot.php?mac=${net0/mac} || prompt goto MENU

@Tom-Elliott Updated and confirmed working 😃

@Tom-Elliott Figured it out, it’s a different bug, made a new post
https://forums.fogproject.org/topic/8600/group-service-settings-not-applying-sort-of

Confirmed the issue and have patched it for rc11. To fix immediately, go to line 1291, remove it and place it before the setAD function all.

@Tom-Elliott I did not see that one. Thank you good sir.

@JJ-Fullmer Nah, I don’t think you made a mistake. If you look at the change log for RC-6 it addresses an issue that sounds like what you described here. I’ve also had this happen at work with RC-5 and RC-3. I’m hoping it’s fixed, it’s something we definitely need to pay attention to. We need to really pay close attention to all things in the RC at this point, and bring up all concerns so that the release is as solid as is humanly possible.

@JJ-Fullmer no it would not. The idea is to get a good working list of issues that will then be addressed for RC 2

@Wayne-Workman But sharing is caring. And it’s so much easier to maintain just one file in a shared location.

@Tom-Elliott I do believe that is fixed. As far as I have tested anyway. I will report back if anything changes

Maybe checkmark boxes in the image definition to tell the inits to move the start sectors? Could be I guess 5 checkboxes, for 5 partitions. Some may have more partitions than that but I think 5 would cover most.

@JJ-Fullmer this is awesome thank you for sharing your knowledge and scripts.

Confirmed fixed in 8241

@kwetiaw The professional version allows for network deployment, they also offer a msi repackager for the professional version. http://support.horizondatasys.com/Knowledgebase/Article/View/97/0/rollback-rx-deployment-guide

@Tom-Elliott Oh that makes sense, so not quite so easy to change. I thought it was just a typo, but that makes more sense that it just pulls the description from elsewhere.

@Arrowhead-IT said:

On git 7593 20 days ago upload and download caused disk 2 to go inactive On git 7961 upload works fine but download of the original intended image still causes the problem

First I want to say thank you again for all the testing you did and the detailed information. I’ve spend a couple of hours trying to find what might have caused this issue but I was unable to reproduce the same problem on my machine here. Version numbers are fine when trying to find a problem in the web gui code but unfortunately it’s not the same for the scripts in the init files because the installer always tries to download the very latest inits from the official FOG website. So if you run the same installer without updating your local git/svn repository you will have a newer code in the inits but still the “old” code within the repo. While this is not causing any trouble I just try to point this out to show you that web gui and the installer version are the same but don’t essentially match up with the version of the script code in your init files.

Don’t get me wrong. I am keen to find out what was causing this and when / how we fixed it. But this would cost me a couple more hours and I don’t have the time to dig any further right now. Please keep us posted if you’re seeing this kind of issue again.

Attached is a diff of all the changes within src/buildroot/package/fog/scripts/ in the git repository since around early April. Nothing I would assume has anything to do with the problem you had. I am really wondering if somehow (no idea how!) you had init files in place that were even older (if I remember correctly we found and fixed some issues within the calculate resize magic scripts in early 2016)…

Would you mind if we mark this solved for now?

All fixed and pushed.

So this problem definitely relates to a windows xp to windows 10 file transfer issue and is nothing to do with fog.
From what I found here http://helpdeskgeek.com/office-tips/fix-office-2010-cannot-verify-license-error-message/
I discovered that the file tokens.dat is indeed a part of activation.
If you happen to have a similar problem…

stop the service osppsvc
Delete or rename tokens.dat and cache.dat found at C:\ProgramData\Microsoft\OfficeSoftwareProtectionPlatform
Start the service osppsvc
Open any office program and let it do the self repair

This also fixes the problem of the office installer autoclosing when trying to repair or uninstall.

Needed to not use root as msqluser for storage node.
Set it back to fogstorage with password from the fog webgui fog config →fog settings → storage node settings (something like that)
Put that in the storage node servers /opt/fog/.fogsettings and redid the install again. All is well again