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.

This is solved from a FOG point of view.

The problem was that a user replicated several large images overnight and Hyper-V expanded the VM, choking the main servers.

Thank you for all of your help @Sebastian-Roth!

@wayne-workman

Agreed on all counts, plus I don’t have images that need deleting at present to test, nor time to create images just to test deletion (at this point). I’ll check this as the opportunity presents itself.

thanks to all.

Jim