I have tried many ways and it seems that powershell can’t do this or i missed something.

What i have tried now is to make a snapin pack with psexec.exe and a batch file.
Also in this batch i can’t write to HKCU.

I used now the following code to store the key and this works for now. It’s not a nice solutions but it works.

If anyone can give me the trick to do this in powershell, let me know.

PsExec.exe -i -s -u %COMPUTERNAME%\%username% -p -nobanner -accepteula -i REG ADD "HKLM\SOFTWARE\Test" /v "Machinenummer" /t REG_SZ /d %COMPUTERNAME% /f

@azureeyedtech Ok, let’s take this one step at a time.

First off: If you’ve used the image type “Multiple Partition Image - Single Disk” only (are you sure about this ???) then it’s near to impossible that FOG has done anything harmful to your source disk! But if you’ve switched over to “Single Disk - Resizable” somewhere along the way then might have changed anything on disk, although we haven’t seen it do anything harmful on upload in a long time. So please tell us, have you ever run an upload task on this machine when image type was “Single Disk - Resizable”? We need to know.
Keep in mind that you cannot switch image type between uploading and downloading the image. If you change the type you need to re-upload the image again!

The PC had secure boot disabled, UEFI disabled Legacy Boot enabled […] I switched the PC host back to UEFI and secure boot and it failed to load Windows

You cannot just switch from UEFI to legacy BIOS and back as you like. These setting needs to be set prior to installing an OS on disk hand have to be left alone after that. UEFI is looking for a FAT32 formated partition to find the boot loader file(s), while legacy BIOS on the other hand tries to find the boot loader code in the MBR. So again, you need to decide which way you wanna go UEFI or legacy BIOS and then leave things as is. In your case it sounds as if the OS was (pre-)installed in UEFI mode. Then you need to run FOG in UEFI mode for this client as well!! FOG can do this. On PXE boot the FOG DHCP server is handing out the correct boot binary to the client depending on it being set to UEFI or legacy BIOS. But if you use a different DHCP server then you need to set this up yourself: Instructions see here…
Secure boot setting is different. You actually need to and should be able to disable secure boot as FOG is not able to handle this. Most people just leave it disabled but AFAIK you may enable it after having uploaded/downloaded an image from/to a client.

So what to do now?

First and foremost find the image on your FOG server (hope you have not overwritten it by several uploads) and make a backup copy of the whole directory. Should find it in /images/<IMAGENAME>. Hope we never need it but you never know. Might be the last copy of your original partition layout we have. While you are there, post the contents of the text file d1.partitions that you find in the image directory. Plus run ls -al /images/<IMAGENAME> and post listing here. Change image type to “Multiple Partition Image - Single Disk” and leave it like that for now! Set UEFI/legacy BIOS on your initial source machine to whatever it was before you played with it (I suspect UEFI) and see if it boots up Windows properly again. Setup your DHCP server to serve both UEFI and legacy BIOS machines with different boot binaries (see the wiki article above). To see if the UEFI boot partition is still there boot the machine up using a Linux live CD/DVD open a terminal window, become root/sudo and run the following commands: mkdir -p /mnt/boot mount -t ntfs -o ro /dev/sda1 /mnt/boot find /mnt/boot umount /mnt/boot gdisk -l /dev/sda

Take a picture of the output on screen and post here.

By the way, are you sure you can actually do what you are trying here? Cloning one image to several Alienware machines with a pre-installed OS that cannot be activated through normal windows keys. Maybe I get you wrong here but this sounds as if it is going to cause much trouble anyway.

Nevermind, though this is definitely not something FOG did by itself… case closed.

Thanks everyone, I upgraded to the newest version of Fog, and had to do the following and now it works:

Windows 8.0, 8.1, and 10 (and most likely future Windows versions) have a feature called “Fast Startup”. This feature basically sets windows so that a hibernation occurs whenever the system is shutting down. This enables Windows to startup much faster than in past Windows versions. Because this feature is on by default, the windows OS partition has a hibernation file which prevents mounting and imaging via FOG, and also marks the OS partition’s “Dirty Bit” to ON. Even when hibernation and fast startup is disabled, the hibernation file remains and the “Dirty Bit” remains ON and these things causes problems. There are a few ways to fix/get around this.

Way 1 (clean method)
Disable: “Turn on fast startup”, located here: Control Panel (Classic View) -> Power Options -> Choose what the power button does -> Change Settings that are currently unavailable -> “Turn On Fast Startup & Hibernate”

Both of those settings should be turned off for use with FOG. They may be turned on at a later time via GPO or snapins.

Shutdown and then boot the system.

Then run this command from an elevated command prompt to disable hibernation and remove the hibernation file:

powercfg.exe /H off

Now you can shut down and reboot once or twice, and then capture your image via FOG.

Hi @george1421 :
Sorry for reply you late.

There was two things that I question.

The router for your network is configured as the FOG server at 10.0.2.15

I have check it again. My network is configured to the FOG at 10.0.2.15.

The subnet mask for your network is 255.0.0.0 ?? is that true?

I also check that the subnet is 255.0.0.0 .

And I found that it works when I change my dhcp server from dnsmasq to isc-dhcp-server by following your link.

Thank you very much @george1421 for your help.

@george1421 it works. Thanks!

@george1421 already a problem, i don’t have /etc/httpd/conf.modules.d i have /etc/httpd/modules full of mod_***.so files but none with 00-mpm.conf file 😕 could this be a CentOS 6.7 to 7 difference?

@x23piracy update to working branch for now.

@george1421 Yes, I’m all set. Am I able to mark the post as solved, or do I not have that ability?

@Sebastian-Roth Thanks for your help, my issue has been resolved!

@sebastian-roth said in Transfer host hardware information from .32 to 1.4.3+:

@dsloan-ethra Though I am fairly sure the table structures of both hosts and inventory are slightly different from 0.32 to 1.4.4. So after thinking about this a little more I see that my suggestion on export/import just fog.inventory might have led you the wrong way at first, sorry for that. Most probably there always is an issue using mysqldump if you don’t do the entire database and let the schema updater work on it afterwards! So this is your only chance with the inventory table as there hasn’t been an export for this in 0.32. So even if we’d add an import function now you wouldn’t be able to use it as you cannot export from 0.32.

I understand that the feature won’t be in .32, but having the ability to export and import the Inventory information with the hosts might be useful for future releases even so. I also would like to suggest that the “Host Hardware Inventory” page always be editable, or at least allow the 3 editable fields to show up even if hardware information is unavailable (Primary User, Other Tag #1, and Other Tag #2). When there is no hardware data, the page is nearly blank with the words simply saying “No results found.” The last resort for me was to manually re-type (or script) the data to be pulled from the old DB and entered into the fields, but the fields wouldn’t be available on the screen because there was no hardware information. However, in my humble opinion, that shouldn’t stop me from being able to enter data into those 3 fields manually.

Thank you again for the help! I do appreciate it.

@wayne-workman Thanks for the help. Just wanted to post this as Solved. Checkboxes now work in the Web UI.

Jim

Problem solved.

https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_0.10.0.2B_Installation_Options

Was the part I needed. Thanks!

@george1421 Perfect, thanks. All working now.

@sebastian-roth I see, also i am now able to manually enter clients. This thread is solved. Though i hope the next update fixes this issue.

Sorry for the delayed response! We were very swamped with semester start at the middle of August, in addition to just opening a new Center for Science and Health Professionals with tons of new hardware. I didn’t get a chance to test out the new DLL but I was planning on it… until a hurricane hit us and we’ve been closed for over a week and won’t reopen until after Labor Day (I’m located in Houston).

I will at some point test it out and let you know how it goes. Until then I will say that FOG has been an absolute champ and has made my life so much easier for this semester start. I have no clue what I would do without it.

@mikec96 said in Isolated Network Connection Issues:

Even though I entered 192.168.1.1 into the Server IP address setting, FOG was actually using its previous IP when it was connected to the internet (which was 192.168.1.35).

Did you manually change the server IP after/while running the setup? FOG does not change it for you! FOG uses the IP address in several places internally but it wouldn’t change the actual IP configured on the interface.

Possibly you will run into one or the other issue with the changed IP. So please take a read through this as well: https://wiki.fogproject.org/wiki/index.php?title=Change_FOG_Server_IP_Address

You’re right we implemented a new FireWall and this IP was being blocked. Thanks!

I worked with the OP via IM for a bit and we have things working for dhcp. The root cause is the dhcp config file had a wrong subnet scope defined (10.x.x.x) where the fog server was on the 192.168.1.x subnet. Once we got the configuration file fixed the target computers pxe booted without issue. At this point the OP can pxe boot the computers. He has an issue with imported images from FOG 1.2.0, but that is a story for a new thread.

@msi Yep looks good now.