https://forums.fogproject.org/topic/5963/unknown-response-datetimezone-__construct-unknown-or-bad-timezone

@Asthea We currently do not have widget support, nor do we plan to for 1.3.0. What you describe would take a lot of work and put our v1.3.0 release even further away. (I do like the idea, but we don’t have the resources to devote to adding it).

@LJedi @BigT Sorry for not stepping in sooner, it has been a pretty hectic week / month for me.

@Wayne-Workman is correct. Assuming you never changed the webroot of your fog server (that is, if it is still x.x.x.x/fog to access via a browser) then you can simply do this

msiexec /i FOGService.msi /quiet WEBADDRESS="x.x.x.x"

Where x.x.x.x is your fog server ip / DNS name

When it comes to the registry entry you should be able to alter it in there, however to err on the side of caution this above method is best.

@Matthieu-Jacquart

I will try and replicate when I have time (may be a week or so depending on when I can get my servers back online). However, if you have time for a teamviewer session where I can access a computer having the issue, send me a PM.

@plegrand

No release date is planned. For now keep using the legacy client. The next release of the client will be v0.10.0 which will include OSX + Linux compatibility.

@Claude-Girard
This is a bug that is fixed in my nightly builds (as seen by @Uncle-Frank 's link). For now you should be able to add a space infront of
“C:\tmp” in your “Snapin Arguments” field. Hopefully that should serve as a hot-fix.

The patch will only be applied on the next official release 0.9.6 or 0.10.0

@plegrand The patch will be applied next release.

@Uncle-Frank in the long run (for FOG 2.0) it’d be best to have a proxy dhcp written in Node.js in order to ensure universal compatibility. Judging by my initial impressions from CloneDeploy’s solution, it shouldn’t be overly difficult or unreasonable to achieve.

@ibloss

service/Post_Stage3.php is called on the server side when a client finishes imaging.

Yes: ‘HOST_IMAGE_COMPLETE’

See my Pushbullet plugin for an example: https://github.com/FOGProject/fogproject/tree/dev-branch/packages/web/lib/plugins/pushbullet
Specifically this file for registering the hook: https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/plugins/pushbullet/events/ImageComplete_PushBullet.event.php#L18

Bug confirmed and isolated. Ticket has been made here:

https://github.com/FOGProject/fog-client/issues/22

Basic explanation:
For some reason the samba LDAP domain is returning an error code of 1355 instead of 2 or 50 (which correspond to OU errors). On OU errors the client will try using a null OU. I just have to add 1355 to the cases of OU errors.

@plegrand said:

I cant join domain with new client

Can you upload the log for that client?

As I previously stated, according to your log its because the client couldn’t authenticate. You have to press 'Reset Encryption Data"

Confirmed. The server is replace ’ with &#39. This is now in @Tom-Elliott s domain

@plegrand The error you reported in your last log “Invalid security token” is because you re-installed the client. You have to click “Reset Encryption Data” for the host on the web portal whenever you do that.

Now then as for Samba. The most likely reason this only occurs for the new client is because the server can’t properly parse your ’ character. Here is why: The new client does on-the-fly encryption, meaning the server encrypts the AD password with a special encryption key only the client knows and sends it to the client. With the legacy client, you were giving the server the FOGCrypt’d password, which from a plain text perspective did not contain a ’ . More than likely it is because the server is stripping out the ’ , and nothing to do with the client. Every release the client is tested against multiple AD scenarios, and LDAP scenarios. In addition, it is XP compatible.

I will try and confirm this shortly.

I cannot replicate this issue. I’ve replicated your snapin configuration and it works fine. According to the log you posted, the issue is with a configuration on your computer, not the client (the return Code 1). Try running the command on the machine manually (using a local copy of your license.dat file).

The client requires .NET 4+. Most windows systems will automatically have it if they perform windows updates. Granted if someone skips the .NET 4 framework Window’s update then the computer won’t have it.

You can upload the log file to this thread. Or, if you prefer, you can PM me a link to where I can download it.

@Marcus-Allen said:

Unable to Install Fog Project CA

This error is with installing us (fogproject) as a CA on the machine. I’ll be in contact via PM to further debug this.