@lebrun78 It’s called hostProductKey in the hosts table. Also, instead of doing this via MySQL - just export all your hosts - modify the export - and then reimport. Web Interface -> Host Management -> Export Hosts -> Export. Make a backup copy of this, modify it with the key, and then re-import.
If you are unsure which field the product key should go into in the import, just put the product key into one host via the web interface manually, export again, find that host and see how the key is laid out.
@Quazz I did!
Problem is that the exported CSV files don’t have headers either and there’s plenty of room for disambiguation. The parameters in the CSV files are not in the order they appear in the GUI either.
I DID get a fair way by changing various parameters in the GUI, re-export, and then compare where the changes show up in the CSV files. I reckon that Tom Elliott has just given me what I need to finish it.
I sill say that with Windows 10 currently, I’ve yet to have it not find a driver for something out of the box through Windows Update. It’s been very lucky, I’m sure, but it’s been huge.
We only have 4 models to support, due to forcing bulk purchases, but use 1 image for it with drivers added to the DriverStore using PNPUtil. Since we’re a Dell and Lenovo shop, they offer SCCM cab’s of the files which makes it very easy to throw them all in.
@lebrun78 OK I just had a chat with the developers over this.
zstd is used for decompression of both legacy and new images (as of FOG 1.3.5). You have the option of using industry standard gzip for image compression or the new zstd for image compression. If the industry standard gzip compression is used, you “could use” any zip program to extract the image from the FOG archive (not very common and only done for a very specific reason).
The newer zstd format can achieve better data throughput (target hard drive compression and decompression) than by using the gzip format. They (the developers) switched to zstd based on a feature request to make FOG imaging even faster (the FOG Project is all about going faster) and with a tighter packed image on the FOG server (smaller disk space used on the FOG server’s hard drive).
The real decision not really a decision. Use zstd and live with the faster deployment speeds, or use gzip and deploy as the same zippy speeds the previous versions of FOG 1.3.x supported.
Really its not a decision use zstd and worry about other things in the world.
FOG Doesn’t keep track of “group” history in an individualized manner. We do keep a history of “everything” in the ‘history’ table of the FOG Database, but it’s not intended to be used as a “reporter” rather right now it’s used more or less as a means to troubleshoot and track unexpected items as they may occur. It does log add/remove/create history but it ties in with “everything” not just groups, or hosts, or images.
We don’t keep track, at an individual item level, that far down. We have such fields as:
‘Created Date’ and for images and hosts we have the ‘last capture and depoy’ times stored individually.
@dloudon96 Just go ahead and stick the extra drive into the box - hook it up however you can, leave the old drive in there and don’t change it’s cables around. SATA II and up is hot-swapable so if you’re just working with SATA III you don’t even have to power the server down to add the disk but you can if you want. After that, run the below commands and provide us with the output (in a nice code-box please). We can get more specific with what’s next after this.