Q2: Can Images be deployed that I did not capture?
The short answer is No. You must capture the image from FOG to deploy it.
There is no central repository for OS images. You must create your own, based on your own requirements from DVD. In my company’s case we use MDT to build our golden image then capture and deploy with FOG. A hardware agnostic design is surely possible. We have a single image that we deploy to 15 different models in our fleet of computers. The key/trick is to use a FOG post install script to copy the correct drivers to a defined location on the target computer just after deployment, but before the first OS boot. Once the drivers are at the precise location then windows will detect them and load them. Sometimes we find that we need to use dism in the the setupcomplete.cmd to finish injecting the drivers after oobe but before first login. It does take time to setup your environment but once done you can regenerate your golden image at any time with the latest windows updates if you use MDT.
@jim-graczyk The limits are set at 128MB, as this is the default for PHP as a whole. I have thought about making the limit’s higher, but as the use cases are different I feel it’s just as appropriate to leave it as “default” but adjustable. One of the upside’s to this being adjustable in the DB as it currently stands is it allows the admin’s to limit the memory usages as necessary and those settings stay regardless of system updates. Setting a higher limit isn’t hard (very easy to tell the truth) but it’s also just as easy to inform the user/admin where to make the setting and I think it’s more appropriate to let the user/admin decide what their top limit should be rather than let FOG make those determinations
While you’re correct that 10 snapins, in this case, on 20 devices would make a lot of snapins, Iam of the opinion that this is relatively an edge case. I totally understand the feasibility of what the snapins are doing, and I can actually look into the snapin history elements to gain more insight into what’s causing the memory issue, but it’s, in my experience, not a normal thing. (The not normal meaning most people I’ve helped typically only have 1 or 2 snapins. I have seen other cases where the user may have many more than 10 though these are FAR less than the number of user’s I’ve helped over time.)
Using time based model to get the snapin report makes perfect sense and I do plan on reintegrating it, but wanted to also make sure that what was in place worked and worked properly before worrying about extending how to obtain the reports. I work on the “whole” of FOG and my main focus is on making the GUI as usable as I can (as you can hopefully tell by the quick turnarounds to fix the issues almost at the time I see the new report). Yes, the reporting elements could use refinement. No, I’m probably not going to be as quick to get the refinements in as I am to get the gui layout, look, and feel mostly completed. Yes, I do plan to get these refinements in the 1.5.x series. No I doubt I will have these refinements for 1.5.0 stable. (Not saying it can’t get done, but I’m literally one guy).
Looks like your connection to FOG Project was lost, please wait while we try to reconnect.