Posts made by george1421

@sebastian-roth OK since this is an efi system can we do the trick of,

1. formatting a usb drive as fat32
2. Create a directory structure of /EFI/BOOT
3. Then take /tftpboot/ipxe.efi from the FOG server and place it into that directory structure on the usb flash drive.
4. Rename ipxe.efi in /EFI/BOOT to /EFI/BOOT/BOOTX64.EFI
5. And probably for good measure, take /tftpboot/i386-efi/ipxe.efi from the FOG server and place it into that directory structure on the usb flash drive.
6. Rename ipxe.efi (from the i386-efi directory) in /EFI/BOOT to /EFI/BOOT/BOOTIA32.EFI
7. And finally move that flash drive to a mac and usb boot from it?

If iPXE is happy you should get the FOG iPXE menu.

Since this is a new server and on new hardware, why not just upgrade 1.2.0 to 1.4.4 (I assume that you have your old fog server on old hardware as a backup system?). The issue is, I fear, that the FOS kernel with 1.2.0 isn’t new enough to support new hardware. Plus 1.2.0 doesn’t support UEFI firmware, Windows 10, GPT disks and a laundry list of other things you might need. Since you have 1.2.0 install and recorded in the fog database. After you upgrade you will still be able to use the older images with FOG 1.4.4.

@imagingmaster21 There shouldn’t be a problem with a real machine. I think there was something wrong with your first disk, or structure or something. I capture from an EFI vm to a physical machine and it works well.

@sebastian-roth Sorry english is my second language (binary is #1). I need to be more specific with my question.

Is the issue in the transition from MAC PXE Roms to IPXE or does the MACs do not like iPXE all together? If its the first one we can get around, if its the second one we may need to do more looking.

@x23piracy said in FOG Client / FOS report bios product key to database (Host) Activate through BIOS key (Deployment):

what i am doing here is legal if the appropriate vl has been purchased

While this post is 4 years old, this is EXACTLY what I’ve been saying.

My previous post:

For FOG Deployment, when you are deploying Windows OS, you must use a Volume License key. These can either be MAK or KMS keys. You can pick up a single VLK license per OS you need to distribute . That is just one license per OS, you pay the same price for the VLK for 10 systems or 100 systems. The only caveat is to buy into the open program you need 5 MS points, the VLK license counts as one. What some people have done is purchased the 1 VLK licenses and 4 network CAL licenses to reach the 5 count.

From the article:

1. The OEM and the VL license must be the same edition, e.g. you cannot deploy a Pro VL image to Home OEM licensed PCs using this licensing technique.
2. You must ensure that the versions are matched, e.g. the OEM license entitles you to Windows 7 (including downgrades) if deploying Windows 7 images. For example, you can’t deploy a Windows 7 VL image to a PC with a Windows Vista OEM sticker/license using this licensing technique.

What if you company does not have a VL agreement? You need to 5 products to start one. You can buy a single copy of Windows (to get the ISO download and MAK/KMS keys) and 4 cheap dummy CALs – now you have a VL at minimum cost, and you can re-image your OEM-licensed PCs with an image made from your VL media.

You may deploy OEM media, as long as you have purchased a VLK key for that media. But then again once you have a VLK key you have access to download the volume media too. I have not tested it, but I assume a VLK key will activate an OEM image.

But again, if you purchased the VLK key and have it, there is no need to query the firmware for the bios OEM key. That key WILL NOT activate volume licensed media.

Understand I’m not saying no to this feature, I’m just not seeing the value in it. If you know what needs to be done, by all means fork the fog project make your changes and then submit the changes back to the project. That is one way to get your needed features back into the base code.

@sebastian-roth What that error means is (under unicast) the FOG server doesn’t have anything for the target computer to do. I know this is a confusing error (type Null) that really needs to be changed to make it more user friendly.

As far as I know this was never a feature of the usb boot. As for making it work with multicasting… I would have to ask why are we using usb booting with the macs? Is it because they don’t pxe boot or is it that they do not like iPXE? The reason why I ask is I think multicasting asks you a question about what stream you want to connect to. That part is iPXE. I tought I had a way to chain load from grub to iPXE. If iPXE works on macs then there is a chance to make this work. If iPXE hates macs then we have a problem.

The more I think about it, the less I’m inclined to say this is a needed feature. While its technically possible to add this to fog. I don’t see the value in having the devs spend their time to read out and store the bios activation key. That key is only of value to activate OEM images. The only way the OEM image can be deployed is via the original media is was delivered on. With OEM media you are not allowed to install, alter, capture and redeploy an OEM install. It may be only installed from the original OEM media. That process is not the intent of FOG Project.

For FOG Deployment, when you are deploying Windows OS, you must use a Volume License key. These can either be MAK or KMS keys. You can pick up a single VLK license per OS you need to distribute . That is just one license per OS, you pay the same price for the VLK for 10 systems or 100 systems. The only caveat is to buy into the open program you need 5 MS points, the VLK license counts as one. What some people have done is purchased the 1 VLK licenses and 4 network CAL licenses to reach the 5 count.

When I get onto my other computer I’ll post a link to a post on Spiceworks that talks about what you can and can’t do (legally) with imaging MS products.
[update]: Here is the link I mentioned above https://community.spiceworks.com/how_to/124056-reimaging-rights-for-windows-10-licensing-how-to

So I think if I had a vote, I would rather have the devs work on this unable to read inode from library issue than spend time adding a feature to FOG that only a limited number of people might use.

@x23piracy said in FOG Client report Windows key to FOG WebIf (Host definition) Activate through BIOS key (Deployment):

Yes, i think thats the way to go but what if someone uses FOG in an already deployed but growing environment. Typically FOG Client would be mass installed, is the FOG Client reporting the same inventory stuff like the inventory been done by the boot menu? If not FOG Client also should have the ability to read the key from bios and report it.

I agree, but that is where your handy code comes into use. That can be integrated into the {next} fog client to update the bios key field if the developers see value in it.

can i try your usb FOS Image, maybe boot from the stick and try if i can get the serial from bios?

Yes that should work well. I forgot about that method of booting. There is a debug mode built into that usb stick. So it is pretty easy.

Lets say that works can’t we start with sending that key to fogs database for the current product key field? If this has been done we are good to go because currently fog client can activate a deployed system by an entered key in that host definition field.

The risk here is replacing a MAK or KMS key with the bios value may not be what all users consider useful. That is why I picked a new field, so it is stored. Then a crafty IT admin could write a simple mysql command to copy it over if its blank. I’m not seeing this as a widely used feature. But a useful one if you need it.

@msaglioc99 I’ve been working on 1703 in my home lab and I’ve run into the issue where windows can’t install correctly after sysprep.

After some intense debugging there are a few things that I came across.

1. I have to place the unattend.xml file in c:\windows\panther if I placed it in the traditional place I’ve used since, forever c:\windows\system32\sysprep I was getting an error that windows couldn’t install because it couldn’t find the defined unattend.xml file. As soon as I change the location to c:\windows\panther and updated my sysprep command that part worked.
2. For my unattend.xml file I decided to use the online generator here: http://windowsafg.no-ip.org/ I wanted to use this site to generate the unattend.xml script because I wanted a clean unattend.xml file and not rely on the one I’ve used for imaging for years. The unattend.xml downloaded from the online generator caused another error in that the product key defined by the generator was not liked by OOBE for Win10 1703. I removed the product key from the unattend.xml that came from the online generator and then it worked.

Once the above fixes where implemented the sysprep and reboot on the reference system worked correctly. I’m currently in the process of rebuilding the reference image completely again with MDT to start with a clean build again to test the next part (capturing and deploying with FOG). To see if I can generate the error in this and other threads with not being able to capture and deploy the image correctly.

Well we have to remember or be sure to create an isolation between FOS and the target OS. For windows activation that needs to be done inside windows. Either through the unattend.xml file or slmgr or fog client.

What would be interesting is if / when FOS takes an inventory of the target computer it could also read the bios key and store it in a field. Maybe not the activation key field but a bios key field. Then at some time that bios key may be copied to the activation key field and let the fog client do its thing. OR within the FOS post install scripts to be able to have access to that information (via the gethost.php script) so the post install script can use it to update the unattend.xml or patch a setupcomplete.cmd line that runs the slmgr command. But the idea is that if we collect this during inventory then I don’t see any other bits of fog needing to be changed other than adding a field to the inventory table, making that new field visible in the webgui and changing the inventory script to collect the key.

I can’t say for sure that the stuff that I found works. My Linux Mint laptop is built for Win7 so there is no key to be found when I inspect the MSDM table.

@george1421 And then the post after the accepted one here: https://askubuntu.com/questions/233181/retrieve-windows-8-product-key-from-mainboard

sudo tail -c+57 /sys/firmware/acpi/tables/MSDM

@x23piracy I’ve been lurking on this thread. Isn’t the goal here to be able to read the key from bios using linux? (BTW, your PS code is pretty sweet!! Nice job)

I think I found something–>

To get it, you need to read the contents of the /sys/firmware/acpi/tables/MSDM file.

Here’s an example:

riking@hp-laptop:~$ sudo xxd /sys/firmware/acpi/tables/MSDM
0000000: 4d53 444d 5500 0000 0313 4850 514f 454d  MSDMU.....HPQOEM
0000010: 534c 4943 2d4d 5043 0100 0000 4850 2020  SLIC-MPC....HP  
0000020: 0000 0400 0100 0000 0000 0000 0100 0000  ................
0000030: 0000 0000 1d00 0000 4639 XXXX XXXX XXXX  ........F98**-**
0000040: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX  ***-*****-*****-
0000050: XXXX XXXX XX                             ****T

*** are the contents of the license key, in ASCII text.
<–

ref: Accepted post here https://superuser.com/questions/637971/how-do-i-get-out-my-embedded-windows-8-key-from-a-linux-environment

@imagingmaster21 Hopefully one that has partitions on the disk and not under them

@george1421 So what does that really mean. Are there partitions on that drive, is the disk empty, is FOS blind? Well at this point all we know is that FOS can’t see the partitions on that disk. Can you confirm by adding that drive as a second hard drive on another computer and use windows to confirm that the disk contains partitions.

@imagingmaster21 OK so you see on the fog server there are partitions on /dev/sda like (/dev/sda1 and /dev/sda2 and so on) and on the FOS engine (target computer) there is only /dev/sda

@jveronese the combination of subnet mask and IP address will say they are on the same subnet.

i.e. 192.168.1.0 with a subnet mask of 255.255.255.0 would say they are on the same subnet.

OK if they are on the same subnet, we can use fog to see if we can detect what is going wrong with dhcp.

Follow these instructions and then upload the pcap to a google drive. We’ll take a look at the capture and see what is going on with dhcp
https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

OK so when you attempt to pxe boot the computer, it sits and spins for a bit then boots the hard drive. When it boots via the hard drive, does it pickup a dhcp address?

And based on the answer provided above, is the fog server and the pxe booting client on the same subnet?

So what FOS is telling you about the partition table is correct. As far as FOS and Linux is concerned that 32gb disk is blank

@imagingmaster21 that’s better but says there are no partitions on sda. Run the lsblk command on your fog server to see what I mean.

I’m not really seeing anything out of order on this one. You are just using a standard bios build, with the sata controller in ahci mode. It “should” just work.