An issue was found in 1.5.6 that calls for an early next release to fix that. Find the details here if you run into problems with FTP connections on kernel updates or storage nodes in 1.5.6: https://github.com/FOGProject/fogproject/issues/311
@Razuel remote management is what it sounds like. Public facing meaning the fog server is accessible from the internet.
While technically possible to image, it really wouldn’t be the best experience. By remotely managed we simply mean you can change the host name, tell it to join a domain, configure printers, set up snapins, and that kind of thing. I wouldn’t recommend imaging over the internet as it would be constrained by your internet upload speed and the remote sides download speed.
Usually download speed is fine anywhere but upload is typically limited much more so.
@george1421 Hey thanks, So today I accessed a known good Fog server running 1.5.4 (fog1.5.4 from now on) on hyper-v with the same specs above (I used the settings as a guide for setting up the new ones, but it was a fresh install each time)
fog1.5.4 historically would capture at 300mb/m and would images at 1.2gb/m (limited by the network connection), I’m currently uploading the image at 21mb/m (this is the same if I attempt to capture the last known good image, whilst writing this I got the rcu_sched self-detected stall error). I’ve updated its network connection to the synthetic connection and it will deploy images at 7-8gb/m now.
I’m about to upload a previously imaged computer in to fog1.5.4 to see what it does.
When uploading a windows 7 image from hyper V to fog 1.5.4 (its running currently) I’m getting 220mb/m but that’s fluctuating currently (between 210 and 230 mb/m due to the hang on the current block as described before).