Add Windows Product key to Image

[george1421]

Just to document what I “think” could be done to support this request. We do have to realize this is a windows only feature and FOG is used for many operating systems. But since the majority of operating systems being deployed are MS Windows based there is some merit to this request.

1. Add a new field to the Image management property page to contain the “Host Product Key”
2. Update the database schema to support this new field.
3. During the image deployment process (maybe prior to the post install scripts) have the FOS engine check to see if the image “Host Product Key” contains a value (prolly no need to validate the key, if it contains “any value” is the only check) then copy the value to the target host “Host Product Key” field and store the object.

Beyond that, no other “new” actions are needed. The fog client will pick up that value and do what it already does today. It seems pretty quick of a fix. The only downside is that it does require an updated database schema to support the new “Host Product Key” field in the image definition.

[Tom Elliott]

I’m a little hesitant to add a feature (at least in the core FOG system) like this. Not because it wouldn’t be useful, but because of the potential security/licensing fraud elements something like this could create.

We store Product Key’s in the database per each host, because a host is what the key is use with. While I do understand the usefulness of such a thing as associating Key’s to an image, and sending that key off to a host, I think this isn’t a feature I would add as a “core” element.

This, I suppose, could do well as a plugin possibly?

[george1421]

@Tom-Elliott Well since this “feature” would only apply to enterprise image deployments, I can see the value of adding it to fog via a plugin instead of updating the stable core code of FOG. That way if the FOG System Admin wanted to use this function, turning on the feature would be as simple as installing the plugin (akin to enabling the location plugin).

[Tom Elliott]

@george1421 That was my thoughts too.

I could probably code a POC style for this, but I think it would be high time for somebody beyond the lead devs to write it all out (Yes I will help, but I think it would be nice to have other users work with these things too).

[Wayne Workman]

It is so incredibly easy to apply a product key to many systems via groups. A plugin for keys would be duplicating something that can already be easily done with existing features.

[Tom Elliott]

@Wayne-Workman They are not referring to to the “application” of keys to hosts/groups. They are referring to trying to place the key with the image.

This way you can have a “list” of all the Key’s in your organization and assign the one you want to an image (or set of images).

Using groups just applies whatever you type to all hosts in the group, it is not linked to the image. This request is more, or less, just trying to ensure the admin’s have a relatively simple method of ensuring the right key is used to activate against the image. It leaves less chance of user error.

[george1421]

@Wayne-Workman (note this is not a lets beat up on Wayne thread).

While I go about this a different way, I can surely see value for this feature in a SMB or enterprise environment. If you look at it from a work flow standpoint, if I have a key associated with an image then as the workstation goes through its life cycle I can be sure that when I change the image that is deployed to the host, it will always get the proper key for activation. In addition when you look at the host record, you will see the key used to activate the host. Yes it could be done with groups but its just one more step that the Deployment Tech has to do for every system. FOG should be focused on reducing the number of steps to produce a solid image and not by adding more (case in point the persistent groups plugin (hack) )

And also consider image deployment using only iPXE and the FOS engine. Lets say you deploy an image via quick image (ok so I forgot the new name of the function). From quick/instant image you can select any image for deployment. If the key is attached to the image then the proper key will be assigned to the target computer without requiring FOG Management console access/interaction.

I can foresee a few caveats here too. If you have a host defined OEM key assigned to a host and then you assign an image to that host that contains a VLK key reference, your OEM key will be replaced with the VLK key potentially loosing your OEM key for every. But in most enterprises you don’t deploy with OEM keys anyway. But the point is you MUST be aware of this condition if you enable/deploy images that have a key association.

I surely see this as a value-add feature.

[Wayne Workman]

I see the value - I really do. I just never thought it a big burden to update keys via groups as needed. And I don’t manually type keys, I copy/paste. I think I remember putting keys into descriptions of some of our heavily used images at my last job for easy copy/pasting.

Maybe instead of continuing to invest in 1.3.x this could be worked on in 2.0 while efforts in 1.3.x focus on bug squashing ?

[Tom Elliott]

Working with @george1421, we created this plugin already.

I’ve tested it’s functionality as well.

If you would like to start using this plugin, please jump onto the working-1.3.4 branch and install like you normally would.

[x23piracy]

I had to ask a question about the plugin and i also crosspost the link here because it was the original thread related to plugin question:

https://forums.fogproject.org/topic/10877/windows-keys-plugin-and-hosts-product-key-field-coexistence-who-wins