Thanks for the reply, and no worries about losing track. You’re doing great work, and I appreciate you supporting the community. 
I’ll try out some different options and see if I can get one to work better, and let you know if I need any more help on this one.
I posted another question in which @fry_p mentioned your name to see if you’d have any thoughts there. If you have some time, maybe you can help determine what’s up there too.
@fry_p said in Issue joining domain & activating Windows after deployment:
Any of you have thoughts on this? Perhaps the System account is indeed messed up? Any tests I can run for further diagnostics?
Any thoughts based on the results of the page you asked for?
Hey Sebastian, thanks for the response. Some external vendors nuked our network over the weekend while performing some kind of maintenance in the data center, so I’m without access to the FOG server until the pieces can be mended. I’ll get back to you with the info once I can. They worked through the night and the network is 98% functional! Here’s what you asked for:
#!ipxe
set fog-ip 172.17.207.144
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
colour --rgb 0x00567a 1 ||
colour --rgb 0x00567a 2 ||
colour --rgb 0x00567a 4 ||
cpair --foreground 7 --background 2 2 ||
goto MENU
:alt_console
cpair --background 0 1 ||
cpair --background 1 2 ||
goto MENU
:get_console
console --picture http://172.17.207.144/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
colour --rgb 0x00567a 0 ||
cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||
item --gap Host is registered as LNPC08CU55!
item --gap -- -------------------------------------
item fog.local Boot from hard disk
item fog.memtest Run Memtest86+
item fog.keyreg Update Product Key
item fog.deployimage Deploy Image
item fog.multijoin Join Multicast Session
item fog.quickdel Quick Host Deletion
item fog.sysinfo Client System Information (Compatibility)
choose --default fog.reginput --timeout 3000 target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
:fog.memtest
kernel memdisk initrd=memtest.bin iso raw
initrd memtest.bin
boot || goto MENU
:fog.keyreg
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param keyreg 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.deployimage
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.multijoin
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param sessionJoin 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.quickdel
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param delhost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.sysinfo
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=http://172.17.207.144/fog/ consoleblank=0 rootfstype=ext4 storage=172.17.207.144:/images/ storageip=172.17.207.144 loglevel=4 mode=sysinfo
imgfetch init_32.xz
boot || goto MENU
:bootme
chain -ar http://172.17.207.144/fog/service/ipxe/boot.php##params ||
goto MENU
autoboot
@Sebastian-Roth I was able to capture it on video finally.
Yesterday, I deployed 3 identical laptops with the same image I’ve been working with in this post. Two of them exhibited what I describe, sitting at the local admin login without the ability to sign into the domain. One of them, however, actually worked as expected and allowed me to sign in for the first time using my domain credentials.
On all of them, each time I logged in, a command prompt would briefly pop up, displaying the following:
C:\Windows\SysWOW64>sc config FOGService start= auto
[SC] OpenService FAILED 5:
Access is denied.
It then would proceed to shut down based on the second line of SetupComplete. I had to delete the file from C:\Windows\Setup\Scripts of each computer in order to stop them from shutting down.
I have attached a screenshot of the Host Module Config page.
Client settings > Task Reboot
Fog configuration > FOG Client - Task Reboot
Attached log: fog.txt
Totally right, fry_p, I’d forgotten that step. One recurring theme that might point to an issue is this quote: “Response Module is disabled globally on the FOG server.”
I’ve looked around at the FOG web console, and I’m not seeing any buttons, switches, or knobs for Modules, let alone the Response Module.
Looking up that warning, Frank in this thread inferred that he fixed his issue by restarting an agent, but I’m not sure what agent that is.
Critchleyb in this thread mentioned that they migrated hosts from an old server, which I had done; is there a step I may be missing?
@fry_p I originally only had the two lines you quoted in the setupcomplete file. I had some issues with that, so I tried setting it up so that it would only run once. I couldn’t remember the specifics, so I tried it again.
After mirroring what you quoted in SetupComplete and deploying, this happened:
One other question along this line of discussion: I’ve noticed when I choose “Boot from hard disk” in the FOG PXE menu, it goes to a black background, white text, with items that look similar to the regular menu, and a countdown timer that keeps looping 3,2,1,3,2,1… without actually booting to the drive. I can get a picture later, but have you seen that / know what the issue is?
Bump.
An earlier Windows 10 image I created worked as expected; FOG deployed the image, Windows booted and stretched its legs, it joined the domain and then restarted, so I could use my domain account the first time I logged in. Lately, the images I’m pushing out sit forever at the local administrator login. When I log in as the local admin, I see the command prompt open, and SetupComplete run. Shortly after that, FOG says it wants to restart the computer, after which I’m joined to the domain and Windows is activated.
Also, every subsequent login displays the SetupComplete window. Thoughts on what’s up here? Here’s the script:
sc config FOGService start= auto
:: Check
IF EXIST C:\Windows\Setup\scripts\fin.txt goto END
break>“C:\Windows\Setup\scripts\fin.txt”
shutdown -t 0 -r
:: END
I’m curious, what benefit are you hoping to achieve with this? I wouldn’t think that much would change in the way of software applications day to day, and this really isn’t the best method to use for data backup.
If intended for data backup, you would end up having a massive amount of duplicated data. There are specific backup tools that can be used to copy only files that have changed since the last backup, for instance, which would be much easier on bandwidth and storage space.
recommended branded Ethernet dongle
Yeah, I’ve read into the MS Surface devices and how people have purchased Microsoft-branded USB to Ethernet devices to PXE boot. Problem is, if I go that route, I’d potentially need one for Surfaces, one for Carbons, etc which like you said gets expensive. If one $30 device worked on all of them, that’d be ideal.
iPXE … has a larger set of supported network adapters
I have a D-Link adapter, and I tried to do an iPXE USB boot once, but it didn’t work. I’m kind of thinking I didn’t do it properly (may have just had the iPXE file in the root of the flash drive, with the partition marked for booting). I’ll try this again and put the file under /EFI/BOOT this time. Thanks!
Thanks for the suggestions, George, that sounds reasonable. I’ll do some testing on that when I get a moment!
Sorry to revive an old thread again, but like another person mentioned, I think it’s good to keep the knowledge combined into one thread. I understand that this thread was posted with the intention of supplementing an incomplete UEFI implementation on older computers that lacked UEFI PXE booting.
Is it possible to use this process for new devices (Microsoft Surface tablets, Lenovo Carbon X1 laptops, etc) that lack a built in Ethernet port? I understand that PXE requires drivers built into the computer’s firmware, which aren’t available for generic USB > Ethernet adapters. Is it possible to create the USB-booting PXE launcher, with a driver for a particular adapter wrapped into it?
Where I work, we have two network segments (build and production). Both have connection to the Internet, as well as basic communication between them (employees on the production network can connect remotely to a computer on the build network to QA the finished build, and computers on the build network have access to network shares on the production network).
However, I think when those built computers move to the production network, they lose touch with FOG. I really like the idea of using FOG’s inventory, snapin, and printer services, but those would be pretty limited if FOG can’t reach across. Is it possible to set something up so that I can push snapins, review login history, etc when the computers are on the prod network?
Then again, as I think about this post further, is that already possible / active? I haven’t specifically tested it, but on prod, the computers can ping the FOG server, so maybe the FOG client can still check in? I think PXE probably doesn’t work because of the different network segmentation, but that part may not matter as much. I’d like your thoughts on this. Thanks!
Flash BIOS/firmware or change boot order?
I want to change boot order, but I understand it would be vendor specific. I brought it up, as I remember reading a thread where the BIOS was changing after deployment, and it was an undesired action for them, but in my situation, I’d want it to change. I’ll set that aside for now, though.
… fog.reginput and check Default Item there. …
Hey, this worked, thanks!
One other question along this line of discussion: I’ve noticed when I choose “Boot from hard disk” in the FOG PXE menu, it goes to a black background, white text, with items that look similar to the regular menu, and a countdown timer that keeps looping 3,2,1,3,2,1… without actually booting to the drive. I can get a picture later, but have you seen that / know what the issue is?
I thought I had seen some options in the current version (1.5.5) to reorder the menu, but I’m not finding them. I found the thread above from about a year ago, with the suggestion that it’s not worth time/effort to implement, and explaining the difficulty when determining whether a host is registered or not, etc.
My ideal would be that first boot into FOG’s PXE menu would default to full host registration. Once registered, the next time it could default to booting to the drive (which is fine, since tasks preclude the menu, so if you requested an image deployment during registration, that would proceed).
Another idea I would like to see if possible is to update the BIOS/UEFI boot order when finished. That way, I could receive a new computer, set LAN as the first boot item, then restart. Type in my registration info, request deployment, and restart. Image the computer, restart, update the BIOS/UEFI. Connect to AD, run Snapins, restart as needed, finish.
@Sebastian-Roth Yeah, I did think it odd that you didn’t put it somewhere on github along with the rest of the code. Anyway, I’ll use that for now. Thanks!
@Sebastian-Roth That sounds good! You’re doing wonderful work! Do you know about an ETA on the next release? Should I use the modified DLL till then, or do you think that’d be bad practice?
