Take hostname from Windows

[george1421]

@ReneWerk I will get the information for you in about 1 hr. I have to get ready to leave for the office.

You will need some linux skills to do this because you will need to download the FOG inits, unpack the inits, and then edit the fog.reg (I think) to mount the target hard drive, and then query the windows registry, debug, repack the inits and upload the inits (as a new name) to the fog server.

Understand this probably possible, but it is very detailed in its execution.

[Tom Elliott]

If you’re running the new FOG Client it will automatically register new hosts with whatever the hostname of the system is. Do not use Quick Registration to do this as all it does is make it so people don’t have to type anything and it’s purpose is to set the hostname.

I can try to look at a method of pulling the windows hostname out autonomously but this is more a feature request than a “problem”.

I think the new FOG Client installed on your systems would do better what you’re asking.

When the new client checks in, if host register is enabled, it creates the host entry into the FOG system under a “pending” status. This pending status should have the windows hostname as the hostname of the host within fog. All you would need to do is approve it.

[george1421]

@Tom-Elliott

Just so I’m clear here…

If the OP installed the FOG client on the target system first, then the client would check into the FOG server and create a “pending” host record?

If that is true, then the proposed work flow would be something like.

1. Install the FOG client on the target windows system using a similar command line:
   msiexec.exe /i FOGService.msi /quiet USETRAY="0" WEBADDRESS="<fog_server_ip>"
2. Wait for at least 2 check in times (just a guess) or about 20 minues.
3. Go into the FOG web gui and find the host record in a pending state and mark it as active.
4. Update the host record in the web gui and connect it to the proper image.
5. Setup the FOG capture/ deployment task
6. PXE boot the target computer and since it is already registered it will begin the scheduled task

[Tom Elliott]

@george1421 100% correct. Though I imagine the check in times would be unnecessary because the “register” happens as a part of the authentication portion. That’s not to say waiting 2 check in’s is a bad idea.

[ReneWerk]

Very much thanks!!!
i am trying it nog but the client das not register the host.

error:

------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
 1-11-2016 11:53 Client-Info Version: 0.11.5
 1-11-2016 11:53 Client-Info OS:      Windows
 1-11-2016 11:53 Middleware::Authentication Waiting for authentication timeout to pass
 1-11-2016 11:55 Middleware::Communication Download: http://192.168.2.233/fog/management/other/ssl/srvpublic.crt
 1-11-2016 11:55 Data::RSA FOG Server CA cert found
 1-11-2016 11:55 Middleware::Authentication Cert OK
 1-11-2016 11:55 Middleware::Authentication ERROR: Could not get security token
 1-11-2016 11:55 Middleware::Authentication ERROR: Kan bestand C:\Program Files\FOG\token.dat niet vinden.
 1-11-2016 11:55 Middleware::Communication POST URL: http://192.168.2.233/fog/management/index.php?sub=requestClientInfo&authorize&newService
 1-11-2016 11:55 Middleware::Response #!ih


 1-11-2016 11:55 Bus Registering ParseBus in channel Power
 1-11-2016 11:55 Middleware::Communication URL: http://192.168.2.233/fog/management/index.php?sub=requestClientInfo&mac=02:71:CC:4E:A4:6B|00:71:CC:4E:A4:6B|00:71:CC:4E:A4:6B|00:71:CC:4E:A4:6C||00:00:00:00:00:00:00:E0&newService&json
 1-11-2016 11:55 Middleware::Response ERROR: Could not parse data
 1-11-2016 11:55 Middleware::Response ERROR: Unexpected character encountered while parsing value: #. Path '', line 0, position 0.
 1-11-2016 11:55 Middleware::Communication URL: http://192.168.2.233/fog/service/getversion.php?clientver&newService&json
 1-11-2016 11:55 Middleware::Communication URL: http://192.168.2.233/fog/service/getversion.php?newService&json
 1-11-2016 11:55 Service ERROR: Unable to get cycle data
 1-11-2016 11:55 Service ERROR: De objectverwijzing is niet op een exemplaar van een object ingesteld.
 1-11-2016 11:55 Middleware::Response Success
 1-11-2016 11:55 Service Initializing modules

[Wayne Workman]

Find that host in the web interface, click the “Reset encryption data” button and then see if the errors in the log stop.

[Tom Elliott]

@Wayne-Workman the host isn’t registered that’s what we’re trying to get working.

[Tom Elliott]

@ReneWerk give me a little bit. Apparently it’s not erroring properly to try passing the register portion.

[ReneWerk]

idd and i will wait, your support is very nice and quick thank you!

(also cant seem te get tftp working on centos 7, get timeout if i try to connect)

[george1421]

@ReneWerk said in Take hostname from Windows:

idd and i will wait, your support is very nice and quick thank you!

(also cant seem te get tftp working on centos 7, get timeout if i try to connect)

Please start a new thread with this issue. We try to not mix issues in thread. In that new thread please state (exactly) what you have configured for dhcp option 66 and 67. If we can’t find the answer easy then we will need to grab a pcap (tcpdump) of the dhcp conversation. I will give you exact instructions in that thread. The last bit that helps us is to have a screen shot of the error using a mobile or other device.

[ReneWerk]

Made a ticket for the other problem sorry i putt it here

[Tom Elliott]

@ReneWerk Please try updating to the latest RC (19) and your hosts should start auto registering again.

[ReneWerk]

@Tom-Elliott

I have updated fog and wil check today if it works and let it know, very much thanks all!!