@trialanderror Incorrect.

The last RC was released in early November. November,December, and January are usually development wastelands for MOST Products, due to the large amounts of holidays, outside of work obligations, and then inside of work end of year stuff that needs to get done.

Developers here are working, as always, as they can with the time allowed. I’d expect some more news in the coming weeks, but that is nothing more than a gut feeling I personally have vs having anything to go on.

As this is a opensource project, if you’d like to see more development, you are more than welcome to jump in and try to fix open issues!

@danpbow Short answer; No, no it is not.

Long answer: No, unless you’re wanting to spend thousands at a data recovery spot and potentially get nothing back for it.

This is a great chance for you to discuss backup, and if you’re in a domain environment, setup redirected folders and the like.

@Wayne-Workman I find that a bit overzealous. My fog server itself is a crappy *buntu Vm with 2g of ram and 2 cores, hooked into our Vswitch of 8 ports, and my clients are all i5 8g of ram laptops. I routinely image 10 at a time in unicast, 40+ in multicast. When I have all 10 imaging, yes, the imaging is around 50% slower than just doing 1, but the time savings are still huge.

No dice here. It’s open house night at work.

on the plus side, was able to use FOG to image out 700 units in 3 hours today. Thanks, multicast and stacked switches!

@guilherme.lima

It’s possible with many different VDI tools. Fog is not a VDI tool. CCBoot is.

For Linux, using LTSP would work easily to stream the OS to the users, and have their data on a central NFS setup or the like.

For Windows, using something like RDP is the easiest, but you have to deal with user cals and the like becuase of this. There are third parties, like Citrix and such, as well, but you still need to deal with licenses.

Maybe you should start with what is your goal. Stream the oS from a boot environment? to cheap chromebooks? what.

@x23piracy said in Webcast: Imaging with FOG, Managing with PDQ:

Sounds great how do you guys want to manage fog images in a better way as it is? Little details please?
FYI i am a paying PDQ Deploy Customer Lovely tool.

What i found so far:

http://bobhenderson.org/fog-zero-touch-imaging-with-pdq-deploy/
http://bobhenderson.org/pdq-deploy-fog-imaging-happiness-take-2/

Regards X23

Mod edited

ha, holy crap, that’s me!

http://bobhenderson.org/pdq-deploy-fog-imaging-happiness-take-2/

Create that in inventory, and after the machines join the domain from the Fog Client, it’ll find em in the collection and deploy! It’s that easy!

@george1421 Thanks George. I understand about the IP reasons.

That site makes sense, now that I can see where the offline service bit had to be put. I had it in the wrong spot on mind, which meant drivers weren’t being picked up. Moved it, and it’s working great.

Thanks!

@george1421 Actually reminded me to renew the domain name on that one before I lost it! God I need to post more updates.

We’re still using FOG and PDQ to image out our 1:1 fleet of computers, as well as having it tied into our server deployments automated via Ansible onto our Proxmox KVM boxes. It’s working fantastically.

The next thing I’m working on (shoot for the moon, right?) is to use FOG to host Snapins and make them accessible outside of the LAN, that’ll then pull down some powershell to grab files via HTTPS from our web cluster to do remote installations if needed. I’ve got a proof of concept working, but I’m a 1 man shop and haven’t had time to do much more on it. But if it works, I’ll effectively be able to push installs both on and offsite, without having to use DirectAccess as the tie back. The powershell has some if’s in there to see if they’re on the LAN, which will then tell it to grab PDQ’s packages, but if they’re off, it’ll grab them from the HTTPS repository and fire off msiexec on them manually.

It’s poor mans SCCM!

@x23piracy Look at the wiki bud, it’s in there line for line.

https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

sc config FOGService start= auto
shutdown -t 0 -r

you basically put that in your setupcomplete.cmd and boom, done.

http://bobhenderson.org/pdq-deploy-fog-imaging-happiness-take-2/

Create that in inventory, and after the machines join the domain from the Fog Client, it’ll find em in the collection and deploy! It’s that easy!

@x23piracy USually you’d need to have PDQ fire off a powershell that then calls the installer and such and use the runas option there. PDQ runs as the deployment account to my knowledge

@trialanderror Incorrect.

The last RC was released in early November. November,December, and January are usually development wastelands for MOST Products, due to the large amounts of holidays, outside of work obligations, and then inside of work end of year stuff that needs to get done.

Developers here are working, as always, as they can with the time allowed. I’d expect some more news in the coming weeks, but that is nothing more than a gut feeling I personally have vs having anything to go on.

As this is a opensource project, if you’d like to see more development, you are more than welcome to jump in and try to fix open issues!

@uwpviolator Yep, I sure am calling the unattend. I’m imaging the same way I have been for a while.

Would you be able to sanitize your unattend and provide, and I’ll do a line by line? As stated, my Unattend hasn’t really been updated since hte Win7 days, so I’d love to see a modern one that is known working…

@uwpviolator Actually, I think George is right. To test this and make sure it’s none of my scripts that are acting up, I actually dumped the drivers in the C:/Driers folder prior to capture, and then sysprepped with hte info. So eve nwith the files there 100%, windows doesn’t see them and goes on it’s own merry way.

I’m with @george1421 on this one, 1709 is doing something dumb again. Honestly, I think they are trying to push us more and more to MDT/WDS…or for them, SCCM.

@george1421 That’s probably it. It’s a 1709 image, as we’re always pushing the latest and greatest for whatever reason. I’m sure they’ve made it more difficult to get your drivers from anywhere but Windows Update…

@george1421 See, that’s the issue. I have that right after OOBE, as you can see below, and it still doesn’t pull. Weird huh?

@george1421 Yep, I’ve found that before numerous times. My problem is mostly ignorance of not knowing how the Unattend.xml is built, so I don’t know where to put that. Hence asking if someone had a sanitized one they’d be willing to share, so I can see the layout and go.

I’ve used the generators, as well as my existing Win10/Win7 ones, but still don’t really know where to put it.

Thanks!

@uwpviolator Could you share how you got OOBE to point to the drivers folder? I’m in the same boat you are, and have yet to figure out how to edit my Unattend to look in C:\Drivers for Win10

Even better, if you could share your unattend with the critical data ripped out, I’d love to see it.

@george1421 Not worth it. Security through obscurity is a joke and just a portscan away.