@Joe-Gill i successfully ran through a pallet of these - 27 - and no issues. this was my process:
boot into BIOS setup.
Click enable UEFI network stack, scroll down to AHCI and click it. hit Apply.
on the left, select secure boot. disable using checkbox - it will ask if you’re sure. hit yes, hit apply. hit exit.
it reboots, hit f12, network boot ipv4
it works
if it doesn’t work for you, make sure your ipv4 UEFI boot settings are setup on your dhcp server (ipxe.efi instead of undionly.kpxe)
@victorkrazan6267 oooh nice something I can help with.
So I tried exactly what you are trying times 1000, and the very last thing I could get to work was adobe. In fact, I saved the command to finally install it as a txt file called F**ingfinallyabletoinstalladobe.txt lol.
What worked for me in the end was using JUST the installer exe by itself but with a command switch. It basically extracts to a path, uses a switch called
(Exe path) -sfx_o”c:(path to extract)” /sALL msi EULA_ACCEPT=YES
this worked for me. I found it off an adobe forum titled “how to download reader dc 2017.009.20044 msi”
@wayne-workman thanks man but turns out it was due to my crappy netgear switches. actually used a cisco enterprise switch and all the clients connected on meraki AP’s, didn’t do all at once but it did send out office 13 (800mb) and a slimmed down version of smart (1.2) to ~10 at once at any one time.
worked well.
i can’t tell you how awesome this software is - i just got a new job, they gave me this new client to us with 350 machines, 2 weeks to reimage them all and i have a baby due in that 2 week period.
started yesterday, only 320 more go to lol.
Thanks again!
@Wayne-Workman never before. i’ll check it out - thanks.
the makefogmobile project would help me out probably too (for little one and done labs here and there)
Thanks for that!
i’ll see if it helps my current issue. if not i’ll just reinstall them all.
For years I’ve been doing my reference image in ESXi, on a 30GB VHD, installed, audit mode, ran scripts, sysprep, captured with fog.
I’ve always used “Multiple Partition Image - Not Resizable” because I had issues with FOG trying to resize in the past - I handled this by using the <extendospartition>true flag in my unattend.xml.
I never noticed, but apparently my recovery partition always began the disk.
Any chance anyone knows how to force windows 10 to install the recovery partition at the beginning of the drive again? I’m not even sure how I did it in the first place - I’m realizing and testing that I can use single disk resizable in FOG, but would like to ‘fix’ it how it was used before if possible.
@Sebastian-Roth i apologize for the assumptions.
after further reviewing, and testing - it seems that for whatever reason, my scripts are not running at boot.
it is trying to find the old server, and the new installation never happens - just the enabling of the service - hence the errors i’ve been seeing.
not sure why, but win10 1909 is causing it for some reason. might be the computers and their speed but i don’t think so. i’m testing more.
bottom line - it is not a fog issue.
thanks for your assistance however.
i have many - one at most of the sites i support.
the one at the site i created the original image ( home ) is 1.5.6, most of my sites are 1.5.6. i have not changed them any time recently.
in fact, the one where i noticed this was a brand new install that day of 1.5.7.
could it be that pre-image, when i installed fog, it has some sort of file in a local directory that doesn’t get replaced when fog gets reinstalled?
i’d thought this be possible but typically reinstalling the client fixes the issue anyways. since my first run script does that, i’ve been confused.
for whatever reason - when i have been deploying 1909 the following appears in the log:
RSA FOG Server CA cert found
RSA ERROR Certificate validation failed
RSA ERROR Trust Chain did not complete to the known authority anchor. Errors: The signature of the certificate cannot be verified. NotSignatureValid
Authentication ERROR Could not authenticate
Authentication ERROR Certificate is not from FOG CA
This could be something I messed up as I haven’t prepped my images since 1903 over the summer. Workflow is as follows:
Created base 1909 in ESXi, installed scripts and such.
Ran FOG installation, set service to disabled, injected firstlogin script to run installation again, with all quiet batch strings.
Sysprep.
Capture image, then deploy to new machine.
Machine boots, script runs and installs fog successfully. Starts service. Error above appears.
This hasn’t happened on my previous images.
@george1421
yes. so ideally, with the ‘hack’ method with persistent groups - lets say i would go the route i understand.
create template host and template group.
assign template host to template group, assign properties to template host.
add additional hosts to group.
even so, lets say i do full reg. it asks if i want to associate to a group. this is awesome and will effectively get the settings that i need - however, when it asks if i want to deploy the image, and i hit yes, the machine gets imaged. nothing that was ‘set’ is actually ‘deployed’ but rather with the sql hack/trigger, its just a property of the host - but the sql function hasn’t actually ‘pushed’ those settings because maybe it doesn’t know its been changed?
i ran into the issue and as i read through your post for basic persistent groups, other people were having the same issue. so i gave up and scrapped the idea.
i do think code wise it would probably be easy to implement for quick reg.
@george1421
I apologize for ‘hijacking’ this thread, although I believe my request is very similar to @fry_p
Almost as a template would work, which I would expect would almost work similarly in fogserver backend as persistent groups would. I do understand how the persistent groups work, however, as I noticed along with others had mentioned when I’d tried it on that thread, the basic issue we ran into was that the settings weren’t deployed per se to the machines. We’d still have to go deploy those to the machines.
What I was thinking about over the course of the last few months after persistent groups didn’t work for me specifically, was something along the line of a template.
Three methodologies I’d thought of:
I’m grateful for the features and uses we have as it is. I just know that as I setup new machines at different sites (my use case is as an MSP working in schools - 27 currently deployed fogservers, most with minimal hosts, but makes initial large deployments a breeze - but for my use case, I could bring a crummy laptop in with fog installed, and re-image a cart full of laptops very quickly. join to domain, install snapins, yadda yadda. the labor intensive part to me is still the ‘adding’ them to fog. my choices are to install the client pre-image, which then associates with fog so i can add as a group - OR the more likely scenario for me, boot, f12, pxe, fullreg, hostname, no group (at this point is almost useless to join to group), assign snapins 1-12, deploy, reboot, f12, pxe, move to next machine.
while i’m already multitudes faster than my cohorts on the Apple side of things (no MDM because of funding oddities with our clients) where they have to carbon copy clone 4 machines at a time with external hard drives - i can reimage a lab in 15 minutes…the only issue because the initial adding, which for summer projects and the like make this tedious.
also/or the ability to add snapins to quickreg. so certain snapins are assigned in quick reg, so that those snapins are auto-deployed when imaging takes place as well. that would work for me too.
@george1421 you are a wizard.
thats fixed!
now onto my next thing. heres to hoping that once i can grab a HDD big enough for my images that can support these ginormously underused HDD’s in these labs…that all is good 