@george1421 Still no dice with getting this to run with the legacy boot option.
I’ve cloned my FOG server for UEFI testing but the laptops don’t boot using IPV4 - they just hang. or say that the file is not found (going by the previous posts).

EDIT:
It seems to be working on a Dell E7270. I’ll test after the holidays with the other Dell laptop 🙂
Thanks for the help, George and everyone else! Much appreciated as always!

@adukes40 At my old job, my co-worker managed the start menu via group policy. So there’s that path.

@Quazz said in Where are the logs!?!?!:

From what I can tell, this answer file has some issues, but I’m far from an expert on them.

I’m not an expert either. I thought these files were being generated by some helper program that you can run to set everything the way you want? Please do not tell me everyone has to manually make these things.

as for updating your host file something as simple as
echo "192.168.1.40 fog_server" >> c:\windows\system32\drivers\etc\hosts in a batch script should add the reference to the host file.
If you have a number of entries saved in a text file you could use something like type hupdate.txt >> c:\windows\system32\drivers\etc\hosts to update the file.

Disclaimer: I have not tested the commands above, they just came to me as I was typing, so YMMV.

@mohit.kishor First, you probably need to figure out which boot files you’re ACTUALLY using. From the sounds of things, your layout is still setup as it once was for 0.32 which will not work (as you’re no doubt finding).

When 1.0.0 was released, the mode of booting had switched from using pxelinux.0 to using undionly.kpxe which allows the use of http protocals. TFTP is limited to transfer rates of only 10Mbps, where TFTP is limited by the network itself (e.g. a gig network can send data at 1000Mbps).

It is suggested to use undionly.kpxe as the boot file rather than using pxelinux.0 (which didn’t ship with 1.2.0 to begin with).

The files that should be used are not located in /tftpboot/fog/kernel/bzImage or /tftpboot/fog/images/init.gz anymore. You can, of course, customize these items, but the relative paths (the fog/images or fog/kernel part of the path) is relative to the web side (meaning you can download the kernel from your fogserver if you go to http://<ipoffogserver>/fog/service/ipxe/bzImage or http://<ipoffogserver>/fog/service/ipxe/init.xz

The file compression changed from gunzip (the .gz) to xz as well.

The files are separated by their “bitness” meaning bzImage and init.xz are “64 bit” and bzImage32 and init_32.xz are “32 bit”.

The location where FOG can look to download these files is defined in database values under:

FOG Configuration Page (The circle ? in 1.2.0) -> FOG Settings -> TFTP Server -> (FOG_TFTP_PXE_KERNEL, FOG_PXE_BOOT_IMAGE 64 bit) and (FOG_TFTP_PXE_KERNEL_32, FOG_PXE_BOOT_IMAGE_32 32bit). The path, directing fog where to locate these files has an absolute path (for simplifying where the files are to be expected) and is defined under the same element with the KEY FOG_TFTP_PXE_KERNEL_DIR. (Please, keep in mind, that fog uses URL’s to download the files it needs so changing the expected location of the files does not necessarily mean FOG will be able to boot if permissions are incorrect for the location of where to expect those files).

I hope this can help lead you in the right direction.

@sourcaffeine

Moved topic to Windows problems. Please advise if you’ve found a solution to this or are still having the problem.

@george1421 I’ve also used a custom vb program and the unattend.xml first run feature to auto login to the workstation right after imaging and then run the vbscript to move the target computer from a build up OU to the proper OU. Then reboot. I have the fog postinstall script update a parameter that is passed to the vbscript during imaging. While I didn’t write this script http://blog.coretech.dk/jgs/vbscript-move-computer-object-to-another-ou-via-command-line-parameter/ it is crazy similar to the one I wrote. It would have been nice If I found this one first to save me some grief.

The only caveat here is that this script must be run as a user that has domain move computer rights.

Using Microsoft Deployment Toolkit right now to scan my extracted driver installers. Seems like it’s organizing it all for me.

SET PASSWORD FOR 'fogstorage'@'%' = PASSWORD('new-password-here'); FLUSH PRIVILEGES;

Seems to have resolved my issues

#wiki worthy

@jscharfenberg

I run this on powershell

Get-AppxPackage -AllUsers | Remove-AppxPackage

And then I use this sysprep unattend file. It works really well in my environment.

<?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <!-- Autounattend_x64_BIOS_sample.xml This file automates the Windows installation. Before using this file: * Replace ProductKey with a product key for the edition of Windows you are installing (example: Windows 8 Pro) Note: The product key used in Microsoft-Windows-Setup\UserData\ProductKey\Key can be used many times in different installations and is not used to activate Windows. It is only used to choose which edition of Windows to install. The individual product key is either specified by the user, or by setting Microsoft-Windows-Shell-Setup\ProductKey. * Set the default language to your own: Replace "en-US" with your language code in Microsoft-Windows-International-Core-WinPE\SetupUILanguage. For a list of languages, see http://go.microsoft.com/fwlink/?LinkId=206620. * OEMs: Replace OEMInformation with your support information To use this file: Save this file on the root of a USB flash drive with the filename: Autounattend.xml Put the Windows DVD and the USB key into a new x64-BIOS PC. --> <settings pass="specialize"> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <CopyProfile>true</CopyProfile> </component> </settings> <settings pass="windowsPE"> <component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SetupUILanguage> <UILanguage>en-US</UILanguage> </SetupUILanguage> <InputLocale>en-US</InputLocale> <SystemLocale>en-US</SystemLocale> <UILanguage>en-US</UILanguage> <UserLocale>en-US</UserLocale> </component> <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <UserData> <AcceptEula>true</AcceptEula> </UserData> </component> </settings> <settings pass="oobeSystem"> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <OOBE> <HideEULAPage>true</HideEULAPage> <HideLocalAccountScreen>true</HideLocalAccountScreen> <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen> <HideOnlineAccountScreens>true</HideOnlineAccountScreens> <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE> <SkipUserOOBE>true</SkipUserOOBE> <SkipMachineOOBE>true</SkipMachineOOBE> </OOBE> </component> </settings> </unattend>

@Tom-Elliott

I have updated fog and wil check today if it works and let it know, very much thanks all!!

I’ve been thinking on this for a bit, and have thought of some far more complex ways to do it. I think that George’s below post is the best out of all the things I’ve thought of.

Basically have the post-install scripts write a .bat file on the local hdd with the needed arguments. Then make a snapin that runs a .bat file - and that just execute the local .bat file.

It is indeed possible to OEM activate a non-OEM image.

How you do it depends on exactly what kind of OEM license it is, whether it’s OEM:SLP, OEM:NON-SLP or OEM:COA. Read this to see the differences.

‘Activation Backup & Restore 1.7 BETA 1’ can be used to extract OEM:SLP Licensing key and certificate which is tied to the manufacturer, the BIOS, the key, the cert and the OS from an original OEM image.

backup-cert.xrm-ms backup-key.txt

You can then use the same program to restore the OEM:SLP key and cert to a non-OEM image (like GVLK aka KMS).

There are other tools and methods but you’ll have to do some careful digging.

@Wayne-Workman That looks like a very handy script to have. I think it will do the trick to clean up some issues in district. Thanks!!

@Wayne-Workman said in Word - temp environmental variable:

@John-Johnson What is it that you did? I’m asking for future readers.

I kept it offline until I could get Administrator activated. Once logged into Administrator my user account was safe from Microsoft’s unwanted pushed apps.

Thanks! That was helpful!

fixparts /dev/sda worked for me.
thanks

The GUI can also be used to add “filtered MAC’s” this is simply a comma separated list (e.g. mac1,mac2,mac3,etc…)

The GUI accessible portion to add the filtered mac is:
FOG Configuration Page ->
FOG Settings ->
FOG Client - Host Register ->
FOG_QUICKREG_PENDING_MAC_FILTER

@MRCUR said in Recommended guide for Windows 10 image creation (from scratch) ?:

@x23piracy Are you keeping all 3 of the “store” apps? “ConnectivityStore”, “StorePurchasesApp” & “WindowsStore”?

I can’t find a clear answer on what of those three (besides “WindowsStore”) is required to make the store functional if we decide to enable it in the future. I’ve also seen it noted that “DesktopAppInstaller” may be needed for some apps to be installed through the store.

Since i use WILDCARDstoreWILDCARD i think yes because all of that apps cover the word “store”