@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.

@Paul-Storic Any word on this? Also, current FOG version is 1.3.0 RC-6, and 7 is to be released soon (august 2016).

@MRCUR said in FOG Services Crashes - subsequently doesn't join domain:

@Joe-Schmitt Do you have the new client that I can test Joe?

This issue was fixed in 0.11.3.

Current Client version is 0.11.4, and 0.11.5 will probably be released sometime in the following week (August 2016).

Thank you. Do you know if the legacy client would have the same issue?

@forte647 I believe the method you were using hasn’t been valid for some time now, this one should always work though.

@jbrown said in "List all Hosts" crashing:

Maybe there were too many registered?

No such thing in fog.

What it sounds like is you need to raise the apache/php memory limits. those are in fog settings via the web interface.

@craigj1222 that’s a completely separate issue. I can offer assistance via Team Viewer, message me.

For future readers, the steps in the wiki for moving the ssl stuff for a “new” server would also work for making “another” server have matching certs. Here is the link:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server

@cnbgeren said in PXE boot issue:

I do have a couple of questions during one of my PXE boot test the laptop required me to input the FOG server address but it did work. not sure why that would happen. With the new FOG GUI version I’m not seeing the option to upload image to the server, so is the GUI different than FOG 1.2.0 version? also do I need to syprep each image?

Well lets take this rapid fire questions in order.

During one of my PXE boot test the laptop required me to input the FOG server address but it did work. not sure why that would happen.
A: This typically happens when the dhcp server doesn’t supply the dhcp option 66 {next-server} OR you are using or have running a dhcp-proxy (or dnsmasq) setup on your network OR you have two dhcp servers responding to dhcp requests

With the new FOG GUI version I’m not seeing the option to upload image to the server, so is the GUI different than FOG 1.2.0 version?
Why yes the gui is a bit different. The upload/download functions are there, the developers changed their names because upload/download is point of view dependent. The names have been changed to capture and deploy respectively. If you go into the target host record, you should see menus along the left of the host definition, look for basic tasks the capture and deploy are under there.

Do I need to syprep each image?
There are those that say no you don’t, and technically if you capture an image for a specific model and redeploy that image to the same model then, no its not required (but if you follow Microsoft’s recommendation yes do sysprep always). If you have a single captured image you will deploy to any number of computers and models then yes, you must sysprep to generalize the image. In my case I always require the images to be sysprepped even if they are going to be deployed to the same hardware or not.

@alansopro Why not use CentOS 7? It is free, and newer. We even have this spiffy tutorial for it: https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

Clearly the build you have has issues. These would likely be resolved in CentOS 7.

@kentucky_smith I think I helped you with this via TV today. It was firewalld again.

I know I disabled it from last time - I’m not one to make a mistake with this. Something or someone must have turned it back on.