@ManofValor We need your Ubuntu version before we can help any further. See https://help.ubuntu.com/community/CheckingYourUbuntuVersion for how to find it.

@ManofValor what version of ubuntu are you running? Did you get 1.3.0 beta from git or svn?

@cotec
The legacy client (The one shipped with 1.2.0 and below) should be Windows 10 compatible. The new client (shipped with developer builds of FOG) is definitely compatible.

@dustindizzle11
Disclaimer: I am not sure if this is even possible.

FOG 0.32 and 1.2.0 do not support GPT, which Windows 10 defaults to. Your best bet would be to install Windows 10 with an MBR configured disk. Once that is done, you should be able to treat it like a Windows 7 image.

See https://forums.fogproject.org/topic/6414/snapin-questions for how to run an msi using snapins.

Snapins just let you run any file remotely. When you go to create / edit a snapin you will see several fields.
A snapin gets executed in this format:

{Snapin Run With} {Snapin Run With Arguments} {Snapin File} {Snapin Arguments}

The best way to understand this is with a couple of examples.

EXE

Let’s say you have an exe you want to run on a computer, and you normally run it like this:

MyFile.exe /foo /bar

Then you would upload MyFile.exe, set Snapin Arguments to /foo /bar and that’s it.

If you have an exe that is an installation (e.g. vlc), you will need to provide the silent installation parameters in the Snapin Arguments box.

MSI

Let’s say you want to deploy an MSI. To install an msi from the command prompt you would run

msiexec /quiet /i MyFile.msi

So to make that a snapin, upload your MSI, set Snapin Run With to msiexec and Snapin Run With Argument to /quiet /i

Batch script

Let’s say you want to deploy an batch script. To run a .bat / .cmd from the command prompt you would run

MyFile.bat

So to make that a snapin, upload your script, and that’s it.

Hopefully this helps, but if you have any more questions let me know.

@Wayne-Workman its not just inside VMWare. I have had multiple physical servers with just CentOS 7 installed fail with this update.

Assuming this is the same issue I have been seeing, CentOS 7 screwed up big time. My CentOS server just recently stopped being able to start after updating, and I have other people experiencing the same issue. This is the closest bug report I have been able to find: https://bugs.centos.org/view.php?id=9860

The fix I used was to append initcall_blacklist=clocksource_done_booting right after quiet on the grub boot menu. Once it successfully boots edit /boot/grub2/grub.cfg and permanently append that line to all of the boot entries that have a quiet.

If this does not work, you should still be able to recover your data by booting to a live ISO and mounting your disk.

v0.9.10 has been released and addresses this issue.

Your build is failing because you are missing WiX toolset. See https://github.com/FOGProject/fog-client/blob/master/README.md#environment . Note that the 0.9.X branch has no build.ps1 like the master branch does. I can give you a build in a little bit.

It is not released yet. I would need to send you a build of it.

I have finished the patch. Currently it is completely untested so if I could have some volunteers to test, that would be greatly appreciated.

GitHub issue:

https://github.com/FOGProject/fog-client/issues/34

@mrayzies I’ll push out a patch when I get a chance.

@jmeyer , the client was meant to be upgraded in a linear fashion, but with GPO mucking things up that linear upgrade path is now broken. The best approach is what Tom suggested. Use GPO to remove ALL CLIENTS completely. v0.9.7. v0.9.9, everything needs to be wiped. Then use GPO once to deploy v0.9.9, once deployed remove the GPO policy, or be very careful when you create the policy so that its a one-time only deal.

Disable the client updater module on all computers, that will halt the massive network traffic.

@mrayzies for the unattend, use a generic windows key. It will give a several days of ‘inactivated’ use before requiring a proper key, plenty of time for the client to activate the machine. Let me know if you need the generic keys.

@jmeyer Are/Were you using GPO to deploy the client?

If you did, then that is your culprit. If you use GPO to deploy an MSI it will automatically enforce that msi upon all computers in the domain unless otherwise specified. This means when the client upgraded to v0.9.9, GPO saw that there was no v0.9.7 and pushed it out. Newer versions of the client will superseed in terms of files so while v0.9.7 is “installed” its running v0.9.9 still.

@Brian-David that indicates you have an incomplete installation. When you get time if you can send me a chat with a teamviewer session I may be able to help.

@Arrowhead-IT what issues are you experiencing with including the client in the image? Its actually safer / more secure to install the client into the image rather than after imaging completes.