Order of Operations: Product Key Activation / Client Product Key Updater
-
Just hoping to get a little bit of clarification here.
We have a MAK key that is in our image’s unattend.xml . We also have OEM product keys set in the FOG web interface. The FOG Clients do successfully pull this product key information and activate with the OEM key. However, before they client pulls the OEM key, does it activate with the MAK key?
To my understanding, MAK keys must be used in the imaging process (due to MS volume licensing agreement), but they are pricy and have a limited number of activations; therefore, it would save us in the long run if the client grabbed the OEM key from the fog server and updated with that one (and never with the MAK key). Is that what the client does? Are there any caveats to that process? Are there times when the MAK key would be used, like if the client was running but couldn’t contact the fog server?
-
The best answer will come from @Jbob
I’ve recently messed with product keys and the new client. Hosts seem to activate using the key I’ve typed in via the web interface.
For MAK keys and imaging - I don’t think what you’re told is fully true.
You cannot use one key from one sticker and image one thousand machines with it - that’s illegal.
However, with FOG, you can let said machine use it’s own code on it’s sticker, and the next use it’s own code and so on… Just don’t input a key in your golden image. Every single host can use it’s own designated key that you’ve keyed in. There’s nothing wrong with that. The key on the sticker is for THAT host. -
I think I was unclear – the key that we associate with hosts in FOG matches the specific OEM sticker on that specific box (i.e. we are not using the same OEM key on duplicate boxes).
The MAK (multiple activation) key though is the same – and that’s the key that is in the unattend.xml/image by default.
If we could avoid sticking any key in the unattend.xml, that would be great, but I tried both the classic “* instead of product key” as well as setting “skip auto activation to true”, but neither worked. Additionally, even if those did work, I think Microsoft doesn’t allow that unless it’s used with a KMS?
I certainly could be wrong though and any documentation stating how it actually works would be great (every time I’ve looked, I’ve found no Microsoft documentation that clearly states whether we are in the right or wrong).
-
@mrayzies The new client will activate windows for you. You don’t need KMS or scripts. You don’t even need an unattend file.
-
The unattend.xml is the only way (I know of) to get through all the post-imaging/pre-windows screens, like the “enter activation key”. So if you want the whole imaging process to be automated (i.e. the first time you walk to the box, it is 100% done), I believe you do need it. If you don’t mind going and hitting enter a few times, then I guess you would not need the unattend.xml.
-
@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.
-
@mrayzies said:
The unattend.xml is the only way (I know of) to get through all the post-imaging/pre-windows screens, like the “enter activation key”.
That’s if you sysprep. I don’t.
-
@Wayne-Workman
You don’t sysprep? I’d be interested to hear more about your setup – I might be missing something, but sysprep with generalize is the only way I know of to get a generic windows image that will be usable on different hardware sets.@Jbob
Thanks for the offer of the generic keys, but it looks like it may not be necessary. We left the MAK key in the image and for one host, did not input the OEM key in the host information in FOG; when the hostname changer tried to activate the key, it bailed out with an “invalid key” error. While the format of the MAK key is identical (as far as I can tell) to that of an OEM key, I’m assuming the client made a request to the FOG server, got back an empty string, said that was invalid and did not try an activation. My case appears to be covered. -
@mrayzies said:
You don’t sysprep? I’d be interested to hear more about your setup – I might be missing something, but sysprep with generalize is the only way I know of to get a generic windows image that will be usable on different hardware sets.
We keep at least one image per model. Last I checked we have about 22 images.
We only have three major images though - the rest are tests or updated images or for models we will never update the image for.
For instance - we have an older Toshiba Tecra laptop running Windows XP - it’s sole purpose is to run a structural stress analyzing machine. It doesn’t need the internet or even the network - and the software will only run on XP and lower. After building and perfecting an image for the laptop, I uninstalled and deleted the network drivers on the laptop and then took an image. That image will never be updated.
Another instance is - our primary computer model in the building is the Optiplex 7010 - we have three images for it. One is our most important Windows 7 image, the other two is Windows Server 2012 and CentOS 7. We use the other two to carry out really quick experiments that we don’t want to run on our servers.
Here recently - I updated our Lenovo L530 and L412 laptop images - I didn’t delete the old image just incase something is wrong with the new one. That doesn’t mean I don’t trust my work - it means I know how to work safely.
We have several business grade Lenovo Thinkcenter models with high powered graphics cards - each of those has a base image and a built image. We keep two images for those because it’s far easier to freshly install the very latest auto-cad than it is to update from an old version to a newer version.
As far as licensing goes - We have a KMS server setup for activating Microsoft Office. Windows used to get activated with a single-run script I designed. Then we moved to running a more simple script via FOG Snapins with the old Legacy Client. Now with the new FOG Client Version 0.9.9 ( @Jbob thanks) I just key in any unique product codes into the web interface and the new client activates them for me.
It might seem like a lot of work to maintain these - it’s not. I work in a school district. We don’t run updates during the school year unless there is a problem that is preventing the use of the technology. When we do image during the school year - it’s fine to use the image from last summer because it works. I’m not overly concerned with security because I’ve set a lot of group policy to prevent things like CryptoWall. Users are not allowed to save executible type files (DLL, EXE, BAT, MSI, etc.), and are not allowed to run executibles from their user directories, or from removable media. I’ve removed user permission from installing anything. Students cannot even access the control panel.
I also maintain all 3rd party software via Group Policy and scripting techniques - for about 500 PCs. If an image has an older version of Java or Flash for Firefox or Flash for IE or an older version of Adobe reader- no problem. I have scripts that rip those old versions off - and group policy that puts the latest versions on - this all happens immediately when a computer joins our domain (automatically via FOG).
I deploy required software that we need for educational/testing purposes via Group Policy and Scripting techniques, both to put newer versions on and rip old versions off.
The list of protections and automations goes on. We have a great network team that maintains web filters, our firewall, and also uses safe DNS that is inherited to other DNS throughout the district.
Last year I rebuilt an image from scratch for all models because I chose to use FOG - because it is vastly superior to the paid solution we were using - and it just made sense to make all new images. I spent about a day building each image - and that was while fulfilling my other duties as well.
With clean base images already made - I can update an image before lunch time. Storage is cheap - With FOG, 41GB of used space on a system translates to a 17GB compressed image on the FOG Server. Storage is awful cheap - and I have about a total of 16TB of fault-tolerant high performance storage available to me (not including the off-site backup drives). Fog is using about 350GB of that.
Our images deploy lightning fast because each one only has exactly what it needs and nothing more. I can FOG a computer in about 7 minutes and it be usable for teachers and students - 2 of those minutes is simply the rebooting and domain joining at the end. Each model runs the best that it can run - because it’s image is optimized for the model and usage it’s intended for. For instance, I carefully tune the OS and applications for our older equipment whereas I don’t worry as much about that stuff with newer equipment, and make software and config choices determined only by the intended use and the hardware it’s running on.
Keeping an image per model makes sense for me. Others would disagree and that’s fine. But things are humming along for me, computers are up-to-date and ready to go shortly after imaging - even with using an older (like 5 months old) image. And I’m not working hard - believe that. I’m quite good at my job.
-
Today I was imaging another box and it failed activation. I used “slmgr.vbs /dli” to determine what it was using and found that it was using the MAK key. This command also showed that the MAK key had expired.
Thus, it seems that FOG client will actually activate the MAK key.
I am unsure why I saw the “invalid key” once, unless there were additional characters in the web interface (beyond the key and the 3 bad messed up characters).
@Jbob - since I do not want to burn out more MAK keys, would it be possible to get a generic key?
-
Lead thinks using those in an image would violate MS terms, I don’t suppose you have any links to MS documentation stating its OK to use such generic keys in unattend xmls ?
-
@mrayzies https://msdn.microsoft.com/en-us/library/ff794751.aspx
That’s the best material I can find on the subject.
-
@Jbob
Ahh, thanks for that documentation.
I see in it specifically that it states "To use the keys listed here (which are GVLKs), you must first have a KMS host running in your deployment. ", so that isn’t for us. But I’m sure someone will find it useful.
-
I’ll actually be out til Monday the 28th – I’m sure you have holiday plans (or at least take some time off!), but I’ll make some decision on Monday when I evaluate my schedule.
-
@mrayzies said:
you must first have a KMS host running in your deployment
They are actually not too hard to setup. But the steps are easy to forget. I’ve only done it once.
