Posts made by Joe Schmitt

One by one, go through each module on the web portal and disable it for the host. Once you disable it, restart your device and see if the logging issue is fixed. Repeat for all modules.

Can you try removing all scheduled snapins for the device, and restarting the device. Does that fix the log issue?

I need the output of this command;
[CODE]sc query “fog service”[/CODE]
Make sure you run it on the toublesome device after FOG stops logging.

Is that all of the log file; is that the last entry before the service stop? Also, have you tried other devices and do they work?

You state that the log file is written to when you restart your device. Can you upload that log file here? Without it I have no idea what could be happening.

The problem is that the FOG service cannot properly identify your network adapters. From what I can tell it seems like you are running Windows 8, is this correct? I also need you to run the commands
[CODE]netsh interface show interface
getmac[/CODE]
and post the output (if you wish, you may filter out the mac addresses, but leave any that report [B]NA[/B])

Could you open a browser tab and go to the address: [url]http://172.29.0.1/fog/service/servicemodule-active.php?mac=XX:XX:XX:XX:XX&moduleid=snapin[/url] (Insert a valid mac address) and paste the output here (you can filter out any sensitive data)

It would seem some incompatible data is being retrieved by the Client. In order to help your further I would need to see the data the client receives (you may asterisk out any information you feel should remain private such as your AD password. If you still feel uncomfortable with posting the information you may PM me with it). To see what data is being sent, get the MAC address of one of the clients that is failing. Then open a browser tab, and go to the url (change the bolded parts as needed):
[B]FOG_SERVER_ADDRESS[/B]/fog/service/hostname.php?mac=[B]XX[/B][B]:XX:XX:XX:XX:XX[/B]

And then post/pm me the output shown (remember to asterisk any private info)

I also need to know if you are using the prebuilt HostnameChanger.dll or you compiled your own version.

I can not promise anything but I will look into implementing this feature into the new FOG Service. It shouldn’t be overly difficult. If and when I do get around to it, would you be willing to beta test parts of the new service to see if the local port network printers work properly (I don’t have any to test on)?

I believe that the problem lies with the product key modification. The deprecated service (the one in the current stable builds that you are running) will throw an error if it does not receive an EXACT amount of info from the server. The new Hostnamechanger expects extra data compared to the original as it can now handle a product key. Linked is a copy of a modified Hostnamechanger that will solve this issue. ([url]https://github.com/mastacontrola/fogproject/blob/dev-branch/FOGService/src/FOG_HostNameChanger/MOD_HostNameChanger.cs[/url]). Download that version and use it instead, it will support both hosts with and without product keys.

The FOG Server requires PHP 5.3 or higher because it uses [URL=‘http://php.net/manual/en/functions.anonymous.php’]anonymous functions[/URL] which were introduced in PHP 5.3

From what I can tell chkconfig is in the root PATH variable so you need to enter a root environment before running the install script. To do this run [B]su[/B] and then execute the install script.

Yep, exactly what you said, upload the HostnameChange.dll file. If you have any errors compiling, please let me know.

Scott, unfortunately the service installer uses a deprecated project format. I am working on a full rewrite of the FOG Service but I have no estimated completion date yet. Your best bet may be to just compile the HostnameChanger by itself and upload it to the FOG update section on the web interface. If you wish to recompile the installer please let me know, I should be able to throw something together for you.

That error “No DHCP or proxyDHCP offers were received” sounds like the computers are looking to FOG for an ip address ( I have run into this issue but with a different model), this method should also get your undionly.kpxe working without the need of chainbooting. First undo the changed you have made to chainload PXE to IPXE. Once that is done,install dnsmasq by running [B]sudo apt-get install dnsmasq[/B] Then follow this guide. [url]http://www.fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server#DNSMASQ_settings_for_iPXE[/url], (ltsp.conf is located in /etc/dnsmasq.d/)

If your computers are on the 192.168.x.x subnet, change the line in /etc/dnsmasq.d/ltsp.conf that says
[code]dhcp-range=10.0.0.10,proxy[/code]
to
[code]dhcp-range=192.168.1.10,proxy,255.255.0.0[/code]

Afterwards restart the dnsmasq service. If running [B]sudo service dnsmasq restart[/B] fails, use [B]sudo /etc/init.d/dnsmasq restart[/B] instead.

Ensure that you did that step where you made a symlink between undionly.kpxe and undionly.0, if you don’t computers won’t find a file to boot to.

Once you have completed those steps, test a computer.

If this method works, you can disable the 3 second time-out on network boots by changing the line [B]pxe-prompt=“Press F8 for boot menu”, 3[/B] in /etc/dnsmasq.d/ltsp.conf to [B]pxe-prompt=“Press F8 for boot menu”, 0[/B]

Can confirm that the snapin client does [B]not[/B] expand system variables. Adding this feature to my todo list with high priority. The reason is that the snapin client uses:

[code]p.StartInfo.FileName = strRunWith;[/code]

instead of

[code]p.StartInfo.FileName = Environment.ExpandEnvironmentVariables(strRunWith);[/code]

In the mean time you may just set the “Snapin Run With” to msiexec.exe, this will automatically find the file if it has been added to the system path, which windows does by default.

Sorry about the confusion, when the list of active snapins is present, by double clicking one of the “Delete” buttons the page goes blank as pictured in the screenshot. A standard refresh of the page does not resolve the issues, only clicking the “Active Snapin Tasks” link on the left side properly reloads it. Non of the snapin tasks are removed, only the gui glitches.

If you are referring to an administrator account for the FOG web management portal you can set the password to be blank by running these terminal commands on the FOG Server

[CODE]
sudo mysql -u root -p
use fog;
UPDATE users SET uPass = NULL WHERE uId = 1;
exit
[/CODE]

This will wipe the first user’s password, which is the default administrator account.

When viewing Active Snapins ([url]http://XXX.XXX.X.XXX/fog/management/index.php?node=tasks&sub=active-snapins[/url]) you can make the content of the page (the list of snapins) disappear by double clicking delete on any of the snapins.

FOG Version: 1.2.0

[url=“/_imported_xf_attachments/1/1231_Screenshot.PNG?:”]Screenshot.PNG[/url]