Posts made by ITSolutions

@phil_guy That sounds like there maybe an issue elsewhere such as the client with a static address, or the switch doing something odd. If the fog server is the only DHCP on the network and you unplug it the client shouldn’t receive any IP at all. Can you try a different client machine?

Does this happen only to this client?
Does it happen only with this snapin?
what version of FOG are you on and what OS?

@phil_guy said in "TFTP open timeout" Error when trying to PXE boot.:

@ITSolutions I unplugged my fog server from the network and on my client machine it shows the DHCP server to be the fog server.

But did you do an IPCONFIG /refresh or reboot the machine to ensure that it isn’t getting an ip with the FOG server unplugged?
Also it sounds like you have 2 nics in the server, are you sure that everything in FOG, DHCP and TFTP are configured tot he correct NIC?

@phil_guy said in "TFTP open timeout" Error when trying to PXE boot.:

@Quazz To my knowledge, there is no other dhcp server.

Can you try unplugging your FOG server from the network and checking a client machine to ensure there are no other DHCP servers on the network?

@JJ-Fullmer I started digging a little further and found my scripts that I used for that and started to remember a few things. I had mixed results with the scheduled task also it worked sometimes, but not always and so I had to come up with a different solution and what I did was created a runonce entry in the reg and an auto login, then rebooted the machine. At the end of the script that ran I logged back off automatically, this is how I was able to consistently get the program to run. I eventually found a different solution for the program I was using and no longer had to use this. Hopefully you can make use of it though

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce /v LWSoftware /t REG_SZ /d \\10.1.90.2\software$\Software_install.bat /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultDomainName /t REG_SZ /d .
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUsername /t REG_SZ /d Thecontrollerofall
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /t REG_SZ /d supersecret
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /t REG_SZ /d 1
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoLogonCount /t REG_SZ /d 1

Just in case you were wondering this was my scheduled task script, that as I said I got it to work on a couple machines, but very unreliable

C:\Windows\system32>schtasks /create /tn "FOG install" /tr "\\10.1.90.2\software$\Software_Install.bat" /sc once /st 12:00 /f
C:\Windows\system32>schtasks /run /tn "fog install"
C:\Windows\system32>schtasks /delete /tn "fog install"

@Wayne-Workman I have to ask the question that you ask and we all ask, What version are you on? And did it just start in a recent update?

What OS are you using(Ubuntu, Cent…)?
Did this occur after an update or did anything else change over the 3 weeks?
Are there any other DHCP servers on the network?

@JJ-Fullmer Not the best solution, but one work around I had done for a program that I had the same issues with is to schedule a task to install the software. I created a snapin that setup a scheduled task (using SCHTASKS) on the client and then kicked off the task before finishing. This allowed the program to come up in the user session and either be interacted with or in your case run the autoit script. I tried to find that script but I must have deleted it because I can not find it anywhere. But that may give you a starting point to try.

What mode of bonding did you setup when you did the test? Also did you make sure each virtual NIC was assigned to different physical NIC’s?

What version of WinPE are you using, this could make a big difference with the drivers?
Are you pinging the IP or server name?
What do you get when you run an IPCONFIG /all?

@jhuesser I noticed that you said that you re-installed the client then re-sysprepped, re-uploaded and redeployed. Can you try to just re-install the client on this one machine. Don’t sysprep it or upload it, just uninstall the client and re-install it to see if it will rename correctly. Trying to rule out that the sysprep process or something else could be causing this. Lets make sure it works before complicating it with sysprep.

@george1421 Sounds great, like I had said I wasn’t sure if it was possible for quick image. If not I don’t see it as a big deal in my opinion. The exit to the HDD I think is a very small issue, If you want to go to the HDD just remove the USB key. lol
I have been hoping for a usb boot option for a while, but I have very limit knowledge in creating such a thing and not enough time to explore and learn. Glad you and Tom are able to work on this part.

@george1421 Maybe give the option “If no scheduled task to complete, would you like to do a quick image?” I see that is not an option on the GRUB menu, not sure if that would be a viable option to build into this. But it would be helpful at times.

Do you have a spare PC that you can wipe and setup as a FOG Storage node?

You sure it is looping back? It should go to the “Installed Plugins” page after installing. and then in the top ribbon there should now be a new icon for the location plugin.

So after all kinds of testing and complete confusion I finally figured out what was causing the issue with this. But not sure what happened to cause it. It was caused by my increasing the max size for snapins. I had a snapin the was approx 500mb so I changed the php settings in the old server to accept 3000m (3gb) and it seemed to work. But when I went to the new server and changed the settings to allow for it, it wouldn’t work. When I deleted that snapin completely from the server, everything started to work. Still not sure why when I would delete the snapin tasks from the host and deployed any other snapin it didn’t work. But everything seems to be running smoothly now that I don’t have any large snapins. I think I am going to go back to using scripts for large snapin tasks.

I was too focused on the small problem that I missed the big issue there.
When I am troubleshooting an issue, if a new problem comes up it can be easy to over look the obvious issue at first, not sure why the PC time was so far off.

@Tom-Elliott Sorry, yes I just caught that too. I fixed the time on the machine and now it no longer gives the validity error. But it still is giving the original error from OP.

So I am still trying to figure this out and have new things happening.

First I have found it looks like this is only occurring on new deployments or new installations on systems that don’t have the FOG client already.
It appears that all of the machines that have been previously imaged and/or previously had the FOG client appear to be working.

I tried to remove the FOG client completely from a freshly imaged machine and re-install and get the following error

------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
 5/24/2016 4:28 PM Client-Info Version: 0.10.6
 5/24/2016 4:28 PM Client-Info OS:      Windows
 5/24/2016 4:28 PM Middleware::Authentication Waiting for authentication timeout to pass
 5/24/2016 4:30 PM Middleware::Communication Download: http://10.1.90.2/fog/management/other/ssl/srvpublic.crt
 5/24/2016 4:30 PM Data::RSA FOG Server CA cert found
 5/24/2016 4:30 PM Data::RSA ERROR: Certificate validation failed
 5/24/2016 4:30 PM Data::RSA ERROR: Trust chain did not complete to the known authority anchor. Errors: A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file. (NotTimeValid)
 5/24/2016 4:30 PM Middleware::Authentication ERROR: Could not authenticate
 5/24/2016 4:30 PM Middleware::Authentication ERROR: Certificate is not from FOG CA


 5/24/2016 4:30 PM Bus Registering ParseBus in channel Power
 5/24/2016 4:30 PM Middleware::Communication URL: http://10.1.90.2/fog/management/index.php?sub=requestClientInfo&mac=34:64:A9:30:E2:F2||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0&newService&json
 5/24/2016 4:30 PM Middleware::Authentication Waiting for authentication timeout to pass
 5/24/2016 4:32 PM Middleware::Communication Download: http://10.1.90.2/fog/management/other/ssl/srvpublic.crt
 5/24/2016 4:32 PM Data::RSA FOG Server CA cert found
 5/24/2016 4:32 PM Data::RSA ERROR: Certificate validation failed
 5/24/2016 4:32 PM Data::RSA ERROR: Trust chain did not complete to the known authority anchor. Errors: A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file. (NotTimeValid)
 5/24/2016 4:32 PM Middleware::Authentication ERROR: Could not authenticate
 5/24/2016 4:32 PM Middleware::Authentication ERROR: Certificate is not from FOG CA
 5/24/2016 4:32 PM Middleware::Response Success
 5/24/2016 4:32 PM Middleware::Communication URL: http://10.1.90.2/fog/service/getversion.php?clientver&newService&json
 5/24/2016 4:32 PM Middleware::Communication URL: http://10.1.90.2/fog/service/getversion.php?newService&json

 5/24/2016 4:32 PM Service Creating user agent cache
 5/24/2016 4:32 PM Middleware::Response ERROR: Unable to get subsection
 5/24/2016 4:32 PM Middleware::Response ERROR: Object reference not set to an instance of an object.
 5/24/2016 4:32 PM Middleware::Response ERROR: Unable to get subsection
 5/24/2016 4:32 PM Middleware::Response ERROR: Object reference not set to an instance of an object.

This is on 2 different images, multiple machines and one computer that hasn’t been imaged since I have been here and so it is a completely different setup and model.

But it appears that all of the machines running the FOG client before the rebuild are communicating with the server just fine. I had a scheduled snapin that runs every Thursday that deployed to all of those machines just fine.

I am attaching the FOG.log file from one of the misbehaving machines to hopefully shed some light on what is happening.

0_1464983650439_fog.log

@Data31337 My instructions are for a USB or Firewire style drive.

You could instead just mount it the same way you currently do, just directly to /images instead. make sure you copy all files from the current /images including hidden files.