@tmerrick client log before it’s deleted, please.

@Wayne-Workman

That worked.

@dolf The one marked as the answer. We keep the FOG Client article updated, because it’s important.

@Tom-Elliott One more you can clean up:

rm -rf error_log-20160807

Marking this as solved.

The spikes aren’t that big (50Mbps). These are most likely clients that are booting up and are passing through network boot first, the spikes are them pulling the boot ROM from the fog server.

The OP’s problem can be solved with the location plugin in FOG 1.2.0, and FOG 1.3.0. Documentation on the plugin are linked below. Marking this thread as solved.
https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin

The OP’s problem is almost surely a simple FTP credentials mis-match, this was common in FOG 1.2.0. Instructions on fixing it can be found here:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

Marking this thread as solved.

Cool, thank you so much. I love everything about FOG and how it handles, however I can’t stand the white background, so I changed that to black, and now I’m wanting to change the font color to something a little easier on the eyes. Thanks again!

@Tom-Elliott typing error, Now it works. Client updated to 0.11.5 a few second after installing svn.

@Wayne-Workman

All right I got. The lines:

DELETE FROM multicastSessions WHERE 1;
DELETE FROM multicastSessionsAssoc WHERE 1;

returned syntax errors “check your manual”. but truncating the two tables worked.

everything seems to work normally now. 🙂 thanks, guys.

@Shadow00Caster Any news on this?

@cnewman402 The OP had an issue because the fog installer at the time was clearing his db settings in .fogsettings. I appreciate you contributing, but this thread isn’t related to SELinux. Maybe make a blurb in the tutorials area?

@Wayne-Workman sorry I didn’t see it was Ubuntu.

@bmckevitt said in Problems with FOG client servive windows 10:

It seems to register the host and sees it for a little while at which point the connection goes dead. I can’t access the units nor assign tasks to it.

Well, this thread slipped by and I sincerely apologize. Sometimes things get crazy here, and about 2 months ago we were getting about 30 to 60 new threads a day, and that’s a lot for the active members to help with (maybe you can help?). In the future, don’t feel bad about bumping your thread if it’s been a while. Again I apologize.

For the issue, I can’t see anything wrong with the log towards the bottom. It’s communicating with the server properly. I see you installed a snapin early-on, with a return code of 1603. I looked up some info on this, that probably means what you were installing was already installed. Read here for more information on that.

When you say the ‘connection goes dead’, what do you mean? What is indicating this to you? For troubleshooting the FOG Client, you’re very first stop should always be the c:\fog.log, see what it says. Every time anyone has an issue with the FOG Client, we always ask for this file, because it’s the first place to look, always.

@sourcaffeine I’ve updated the FOG Client article to include a section on polling, here:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Polling_Behavior

For why the legacy client is still being used - it’s so people can transition more easily. If there was no ability to transition easily, people would have more work to move to the coming 1.3.0 release. For example, imagine an organization with 10,000 computers, all have the legacy client installed, and they are using a 1.2.0 server. Do you think they will just move to 1.3.0 if 1.3.0 could not control the legacy client? No. Because the FOG Client might be a vital piece of their management. You don’t just image 10,000 systems at once, you image some at a time and move to the new client as you can. And if 1.3.0 can’t control the legacy client, then those people would have a huge gap in very needed management capabilities. How would people do something as simple as schedule an imaging task, if the existing legacy client cannot be ordered to reboot? Should we force people to use outside software like active directory, group policy, or something else? No. We provide a pathway in fog, anything less would be unacceptable.

@Wayne-Workman said in DHCP failed - undionly.pxe:

It’s really easy to do.

@george1421 said in DHCP failed - undionly.pxe:

@tigerpride said in DHCP failed - undionly.pxe:
FWIW: Only the dhcp server needs to be 2012 the reset of your domain can remain on 2008. But you will have to migrate sooner or later. 2008 server is already 8 years old.

If you don’t want to upgrade and can isolate the uefi and bios clients to different dhcp scopes you can do it that way too. Just create different scopes with different boot files for each scope. Its not really clean but will work. In my case we only pxe boot when we image machines, the default target computer will boot from the hard drive and only boot pxe when we select it from the boot menu.

Probably is a snap and I realize it needs to be done, but the thing is, I’m just week 4 into my new position and environment. DHCP is done by the primary DC. I could move it to the secondary (which is 2012) but I don’t know what’s all dependent yet. I’d rather not risk it at this point since my users will return in a week and a half. I’ve a ton on my plate as is, and the main LAN + VOIP system potentially tanking is not really how I’d like to remember my start here.

To be honest I’m waiting for Server 2016 to come out of RC to set up a test tertiary and see about winking off 2008 if that’s to my liking.

@forte647 said in DHCP failed - undionly.pxe:

My company recently switched to Probook 455 G3s, and I had the same issue after the switch. Something about the NIC in these laptops isn’t playing nice with undionly.pxe? I switched my boot file to ipxe.pxe and it worked. So maybe try using ipxe.pxe and see what happens.

You got it! That works. No dhcp failed or kernel panics! I’m grabbing the stock image as we speak, then setting up a fresh W10 image to base a capture from for the rest of this lot.

TYVM! Thanks for all the help everyone!

@Tom-Elliott said in Computers Imaged with FOG wake up again after shutdown (caused by FOG Server):

https://forums.fogproject.org/topic/8290/which-table-to-check-in-db-to-see-if-there-are-pending-wakeup-entrys

Yes this thing is solved @Microsoft

alt text

Possibly the project just needs a bit more money to be able to afford a server with a more reliable connection… All the companies using FOG would like to donate 10 bugs each?? 🙂

@Wayne-Workman I have done this with the MAK key. That works fine. We just wanted to switch over to KMS. Which with our script snap-in it seems to be activating just fine now. I still need to refine it though. I think I’m going to add @Mentaloid’s suggestions to my existing script. I do believe that will finalize automation. 🙂

@LibraryMark You could have pulled the same SVN version as on your old server, installed that, imported your DB and then upgrade to RC6, but glad you got it working anyway.