Topics created by klaus.jauk

@Tom-Elliott
Hi Tom,

set as default, but how we can run this as a task like deploy, capture or disk or other tasks ? We have clients, they are not online at the moment. On next boot they should automatically go to the correct PXE Menu entry.

BR
Klaus

@klaus-jauk In FOG groups are not like you might be used from other software. It’s more like a tool to push out settings to a group of hosts but it’s mostly not a persistent settings thing where you store information for the whole group. For AD settings, if you set those through the group you’ll see that the values will be shown in the group AD settings as long as you don’t change a value for any of the single hosts. When you do this the value from the group AD settings will disappear.

This is the concept of FOG groups. Search the forums for “persistent group” and you’ll find a lot of information on this.

I see that it’s a bit unfortunate in the case you describe where you register a new host and join that to the group. But on the other hand you’ll still have all the values set for all the other group members. You just don’t see it in the group AD settings view anymore.

@klaus-jauk I understand for $osid and driver packs. In the case of drivers, using FOG’s built in $osid is not a problem, because for Win10 for example a win10 drive works across all win10 platforms. The same for Win8 and so on.

Here is an idea: What I see is at issue is the KMS key where you think you need custom $osid values. There is a key management plugin for FOG. Where you load the KMS/MAK keys into a key table and then associate that key with a host. I don’t know if that will solve your problem with kms keys or not, but the resultant link key should show up in hostproductkey so you don’t need to do anything special in the post install scripts.

The issue I see with creating custom $osid values is that FOG uses that $osid values internally when creating the disk partitions and how to deal with boot block. If you create your own $osid values then the internal programs that look for $osid (9) for example would not work because it would see your custom $osid value. Now of FOG internally would mask off (only look at) the lower 8 bits of $osid for FOG’s internal use then you could do what you want by creating custom IDs with the upper 8 bits of that $osid value.