@Lee-Rowlett Sorry,trunk version 7709 i believe
Best posts made by gwhitfield
-
RE: Utilizing Postscripts (Rename, JoinDomain, Drivers, Snapins)
-
RE: Chainloading failed / boot looping
@george1421 Nope, my bad. Unintentionally ticked off Wayne. Nothing more to tell, these aren’t the droids you’re looking for.
-
RE: Help! DHCP suddenly gone haywire!
@Junkhacker @Quazz Thank you both ! I did try re-installing FOG on one server and it worked. Then I tried just restarting another server and that worked too. I then restarted ALL the affected servers and they all worked. Don’t know why the problem occurred, never seen that happen in 10 years so I guess I learned something today and I can sleep well tonight
-
RE: Utilizing Postscripts (Rename, JoinDomain, Drivers, Snapins)
@Lee-Rowlett Success!! Evidently my fog.postdownload and fog.drivers files got corrupted by editing in Notepad. Thank you for sending me a clean version! Working like a champ. Also for purpose of posterity or future users, the name of the folder for each individual hardware type needs to exactly match the spelling and case of the “System Product” field in the “Inventory” for that machine (or type of machine):
-
RE: some global settings being cleared during group settings update
@Wayne-Workman - Here’s exactly what I’m seeing. It is consistent, happens every time I click screen resolution update when there are existing group settings configured. No errors logged in Apache log.
------------ Apache error logs BEFORE updating screen resolution --------
[Mon May 16 15:02:10.146640 2016] [mpm_prefork:notice] [pid 1084] AH00169: caught SIGTERM, shutting down
[Mon May 16 15:02:42.854884 2016] [mpm_prefork:notice] [pid 1100] AH00163: Apache/2.4.20 (Ubuntu) OpenSSL/1.0.2h configured – resuming normal operations
[Mon May 16 15:02:42.856884 2016] [core:notice] [pid 1100] AH00094: Command line: ‘/usr/sbin/apache2’------------ Screenshot of GROUP settings BEFORE updating screen resolution--------
------------ Screenshot of group MEMBER settings BEFORE updating screen resolution--------
------------ Apache error logs AFTER updating screen resolution (didn’t change at all) --------
[Mon May 16 15:02:10.146640 2016] [mpm_prefork:notice] [pid 1084] AH00169: caught SIGTERM, shutting down
[Mon May 16 15:02:42.854884 2016] [mpm_prefork:notice] [pid 1100] AH00163: Apache/2.4.20 (Ubuntu) OpenSSL/1.0.2h configured – resuming normal operations
[Mon May 16 15:02:42.856884 2016] [core:notice] [pid 1100] AH00094: Command line: ‘/usr/sbin/apache2’------------ Screenshot of GROUP settings AFTER updating screen resolution --------
------------ Screenshot of group MEMBER after updating GROUP screen resolution --------
-
RE: Windows 10 unattend.xml (sysprep answer file) challenge
@Boyan-Biandov I also have basically re-used my Win7 unattend, though I did run it through the Win10 SIM to validate it. The only place I put it is in C:\Windows\Systems32\Sysprep folder. However, I have had the “Windows could not parse…” error and in looking at the setuperr.log in C:\Windows\Panther\UnattendGC folder (this one is different than the setuperr.log in C:\Windows\Panther, I don’t recall how though), it pointed me in the general direction of the <ProductKey>xxx</ProductKey> entry in “Specialize” pass. I ended up removing all product key entries and don’t have the error anymore. I have never really used audit mode, I just enter product key during installation and run “c:\Windows\System32\SLMGR.VBS” /ato" to re-activate after imaging (in setupcomplete.cmd). Good luck!
Edit: Forgot to mention that it always seemed to me that the unattend in C:\Windows\Panther was a post-sysprep record with all the sensitive data removed from the file by Windows as it processed it. I never before ran into any instructions to put it both places so I never have. Now if someone could tell me how they make the Win10 Default User profile keep the pinned icons on the taskbar I’d be the happiest camper alive.
-
UEFI chainloading error
I haven’t done any UEFI booting in months and ran into this error this morning (Trunk 8499 - just updated):
I found and edited my copy of the default.ipxe file but thought I’d mention it since maybe an error has crept into it on SF.net.
-
RE: UEFI chainloading error
Update: It seems that maybe it’s just the VMWare having issues with refind.efi since both laptops I’ve tried (Dell E5550 and E5570) have booted right through to the OS if no task is waiting. It’s not a guarantee but it sure looks better. I’d say all in all, this is solved since it was really just originally a typo in default.ipxe and the remaining issue with VMWare seems to be inside refind.efi.