@Tom-Elliott
Thanks Tom, whatever you changed seems to have fixed things right up!

Reboot after is now working without causing tasks to be re-created when next checkin occurs.

You guys are awesome - did I mention that before?

@Wayne-Workman

Yep - I ended up doing that as well, but things I noted:

Some stuff the AD join and hostname change should be completed first (wsus server and policies and proxy via AD and group policies) - and without the service running, that won’t be completed. Enabling the service at the send of the setupcomplete.cmd means the rename and join hasn’t been completed. Doing it at the beginning, and then running other tasks mean that it will reboot while completing the other tasks.

This is what I’ve done to get the best of both…

example sysprep.cmd

sc stop FOGService
sc config FOGService start=disabled
sc stop FOGService

copy \\fog\Deploy\W10\unattend.xml %systemroot%\System32\sysprep\unattend.xml
mkdir %systemroot%\setup\scripts
copy \\fog\Deploy\W10\setupcomplete.cmd %systemroot%\setup\scripts\setupcomplete.cmd

net use * /del
del c:\users\administrator\desktop\*.lnk
c:
cd \windows\system32\sysprep
c:\windows\System32\sysprep\sysprep.exe /quiet /oobe /generalize /shutdown /unattend:unattend.xml

and my setupcomplete.cmd

@echo off
del /Q /F c:\windows\system32\sysprep\unattend.xml
del /Q /F c:\windows\panther\unattend.xml
net user Administrator /active:yes
sc config FOGService start=auto
sc start FOGService
net use * /del
exit

Then the snapins run after fog service renames and joins the domain.

The reason I use snapins for everything else - because I like my setupcomplete to be simple and fast - anything I want beyond the basics, I can choose to implement or not without changing the setupcomplete; just add the snapins (which for @RLane, would be the windowsupdate snapin).

Areca cards work well in both environments, they are all pretty universal. I’ve used quite few different models in both OS’s (DebianLinux and Windows) . Debian has support built as modules (arcmsr) into the kernel out of the box, and those modules are also by default in the initrd. I’m not sure what the FOG kernel/initrd are based on, but I would imagine it couldn’t be too hard to add if needed.

I can attest they are fast cards, and fully support 4k sectors and 64bit LBA, as well as some SSD specific options.

One thing to be aware of - most OS’s aren’t aware of TRIM support for RAID drives. Some controllers expose emulated TRIM and convert it to drive level TRIM, but that is rare. Consequently, SSD’s will wear out rather quickly in a RAID array with a lot of writes.

MBR2GPT not finding the OS partition is either corrupt BCD, or missing recovery environment. Both would occur if not all partitions including the recovery partition, or you didn’t capture the recovery env from the main os partition. Possibly fastboot was enabled and you had a fastboot state saved when captured as well?

Resizable should work, but I suspect that not all partitions were captured being the root cause.

@Joe-Schmitt

Makes sense, and I had suspected as much.

Thanks!

PS snapin if anyone needs it.

Start-Transcript -path c:\SnapinLogs\CleanupUpdaterLog.log
$strFileName="c:\program"
If (Test-Path $strFileName){ Remove-Item $strFileName }
Stop-Transcript

@UserBxl

Just a follow up to the original fog-client info:

I have the client installed in my images: solution for the boot loop issue (if it is the underlying problem)…

A snippet from my sysprep batch file:

sc stop FOGService
sc config FOGService start=disabled
sc stop FOGService

copy \\server\share\W10\unattend.xml %systemroot%\System32\sysprep\unattend.xml
mkdir %systemroot%\setup\scripts
copy \\server\share\W10\setupcomplete.cmd %systemroot%\setup\scripts\setupcomplete.cmd

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE /v BypassNRO /t REG_DWORD /d 1 /f

c:
cd \windows\system32\sysprep
c:\windows\System32\sysprep\sysprep.exe /quiet /oobe /generalize /shutdown /unattend:unattend.xml

Note the service stop and disable. I keep the setupcomplete.cmd and unattend.xml on a network share for ease of access.

in setupcomplete.cmd

@echo off
del /Q /F c:\windows\system32\sysprep\unattend.xml
del /Q /F c:\windows\panther\unattend.xml
sc failure FOGService reset= 86400 actions= restart/60000/restart/60000/restart/60000
waitfor /t 5 null
sc failureflag FOGService 1
sc config FOGService start= delayed-auto
sc start FOGService

This allows a capture to work with the fog client pre-installed, then turns it on again after the OOBE completes.

I don’t think this is in the link that @Tom-Elliott gave. I based this off of stuff collected from the FOGProject forums ages ago.

@JJ-Fullmer That is an interesting powershell script for winapps provisioning issues, thanks! I’ll have to give it a shot for my W11 image I am having some minor issues with!

MBR2GPT not finding the OS partition is either corrupt BCD, or missing recovery environment. Both would occur if not all partitions including the recovery partition, or you didn’t capture the recovery env from the main os partition. Possibly fastboot was enabled and you had a fastboot state saved when captured as well?

Resizable should work, but I suspect that not all partitions were captured being the root cause.

Recently upgraded from FOG 1.3 to FOG1.5.10

I’ve fixed many problems that occurred, most of them probably due to my direct upgrade from 1.3 instead of stepping through 1.4, however there is one last I can’t seem to figure out…

Adding snapins: The select existing snapin list is empty when creating a new snapin.

However when editing an existing snapin, the list appears.

Not mission critical, I worked around it by selecting a dummy payload for the snapin, then deleting it after selecting the correct snapin in the list when editing.

Thoughts? maybe a permissions issue or something, but I can’t really see that since the list populates when editing.

Mark

@Joe-Gill

W10_edu_act.cmd

c:
cd \windows\system32
c:\windows\system32\cscript.exe //B c:\windows\system32\slmgr.vbs -skms kms7:1688 >> c:\SnapinLogs\W10Activate.log
c:\windows\system32\cscript.exe //B c:\windows\system32\slmgr.vbs -ato >> c:\SnapinLogs\W10Activate.log

.cmd files are handled by the fog client without any run with parms, and you wont have any local permissions issue.

I don’t use a KMS server, so I am unaware of if it would require domain credentials. I would think the machine would have to be domain joined though. I also was under the impression that you can set the KMS details as part of the domain policy.

@Wayne-Workman
.VMX is the ESXi config file for the guest OS - it normally would be stored with your virt HD on your SAN. If you can’t edit/view the file (plaintext) directly on your SAN, You can view it via the vsphere client/web interface. Edit the powered off VM, go to the options tab, and then advanced/general hit the button for configuration params. Be careful in there!

Centos I would imagine supports vmxnet adapters… if you have the option for support in your guest OS, they are more efficient/faster than e1000/e1000e emulation. I think this guide should help you get that running…

vmxnet3incentos7

Back to an earlier point though, you have confirmed that GuestOS/VM0 to another GuestOS/VM on the same VMHost is not working at correct speed?

If VM to VM is good (therefore the VMHost virt switch & virt adapters are working internally), I’d look at your LAG/Bond for your uplink. I’ve have ESXi puke and start dropping packets on a LAG before, and I’ve also had switches with good “links” and no frame errors, but not passing data in one direction after a power loss. This can be frustrating to troubleshoot in LAG/Bonded links. Pull out your all but one of the LAG wires (admin down from switch isn’t good enough as you physically have to break the link for ESXi to figure out that it shouldn’t use the port for data), and verify. If it’s good, pull it, and try another - keep going through and verify each port is functioning on it’s own. Of course you need to ensure your using a known good port on this switch for your test machine!

@Wayne-Workman
Just as a reference, my fog server on ESXi 6 to another (OLD debian jessie, including old unoptimised net devices) VM on the same host

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 10.1.110.100, TCP port 5001
TCP window size: 1.83 MByte (default)
------------------------------------------------------------
[  5] local 10.1.100.50 port 50312 connected with 10.1.110.100 port 5001
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec  7.35 GBytes  6.31 Gbits/sec
[  4] local 10.1.100.50 port 5001 connected with 10.1.110.100 port 40811
[  4]  0.0-10.0 sec  12.4 GBytes  10.6 Gbits/sec

Only thing I can suggest is possibly removing the virt network device from the guest, boot, re-add the most current, and configure.

I honestly can’t see what a power outage would do other than possibly mess something up in the guest os VMX file. Do you have a backup to compare?

These are the relevant lines from my vmx

ethernet0.virtualDev = "vmxnet3"
ethernet0.networkName = "VM Network VLAN100"
ethernet0.addressType = "generated"
ethernet0.uptCompatibility = "TRUE"
ethernet0.present = "TRUE"
ethernet0.pciSlotNumber = "192"
ethernet0.generatedAddress = "00:0c:29:XX:YY:ZZ"
ethernet0.generatedAddressOffset = "0"

@Joe-Schmitt

Yes, FOG service is disabled in the image, setupcomplete.cmd re-enables.

The driver thing is interesting - and possibly could be part of things.

So today a colleague deployed to ~60 computers.
Half of them failed to start fog service after reboot from FOGClientupdate/renaming/joining domain.
Half of them worked fine.
The difference between them is a different model motherboard (Both ASUS, H61 and B75 based respectively)

The image used was made on a VM, with no drivers pre-installed for either motherboard/chipset. In theory, both would need drivers to be installed during OOBE, so I’m not so sure what…
The H61 based systems should be slower, but not by a whole lot, at least not for imaging tasks.

Anyways, if it is a driver update/WU based reboot, then this reg key will have been created. Could the fog client detect that, and instead of exiting, accelerate the reboot schedule somehow?

HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending

Here is the relevant section of the log file - which looks ok, but looks like for some reason (scheduled reboot?) it did not reboot.

------------------------------------------------------------------------------
--------------------------------HostnameChanger-------------------------------
------------------------------------------------------------------------------
 6/27/2016 4:04 PM Client-Info Client Version: 0.11.2
 6/27/2016 4:04 PM Client-Info Client OS:      Windows
 6/27/2016 4:04 PM Client-Info Server Version: 8263
 6/27/2016 4:04 PM Middleware::Response Success
 6/27/2016 4:04 PM HostnameChanger Checking Hostname
 6/27/2016 4:04 PM HostnameChanger Removing host from active directory
 6/27/2016 4:04 PM HostnameChanger The machine is not currently joined to a domain, code =  2692
 6/27/2016 4:04 PM HostnameChanger Renaming host to HiLibLabBack4
 6/27/2016 4:04 PM Power Creating shutdown request
 6/27/2016 4:04 PM Power Parameters: /r /c "FOG needs to rename your computer" /t 0
 6/27/2016 4:04 PM Bus {
  "self": true,
  "channel": "Power",
  "data": "{\r\n  \"action\": \"shuttingdown\"\r\n}"
}
 6/27/2016 4:04 PM Bus Emmiting message on channel: Power
------------------------------------------------------------------------------

At this point, no snapins have run, and the computer does not reboot…I logged in via RDP:

6/27/2016 10:03 PM Main Overriding exception handling
 6/27/2016 10:03 PM Main Bootstrapping Zazzles
 6/27/2016 10:03 PM Controller Initialize
 6/27/2016 10:03 PM Entry Creating obj
 6/27/2016 10:03 PM Controller Start

 6/27/2016 10:03 PM Service Starting service
 6/27/2016 10:03 PM Bus Became bus server
 6/27/2016 10:03 PM Bus {
  "self": true,
  "channel": "Status",
  "data": "{\r\n  \"action\": \"load\"\r\n}"
}
 6/27/2016 10:03 PM Bus Emmiting message on channel: Status

------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
 6/27/2016 10:03 PM Client-Info Version: 0.11.2
 6/27/2016 10:03 PM Client-Info OS:      Windows
 6/27/2016 10:03 PM Middleware::Authentication Waiting for authentication timeout to pass
 6/27/2016 10:03 PM Middleware::Communication Download: http://fog.XYZ.local/fog/management/other/ssl/srvpublic.crt
 6/27/2016 10:03 PM Data::RSA FOG Server CA cert found
 6/27/2016 10:03 PM Middleware::Authentication Cert OK
 6/27/2016 10:03 PM Middleware::Communication POST URL: http://fog.XYZ.local/fog/management/index.php?sub=requestClientInfo&authorize&newService
 6/27/2016 10:03 PM Middleware::Response Success
 6/27/2016 10:03 PM Middleware::Authentication Authenticated

As you can see, for some reason (foguser?) the service restarted when a user logged in, and carried on - despite a pending reboot that never happened.

UPDATE: As of ~10:30PM, the machines that hadn’t finished the rename/reboot, rebooted on their own (must have been that scheduled power thing!) and started carrying on.

@plegrand
No worries!

@Joe-Schmitt

Makes sense, and I had suspected as much.

Thanks!

PS snapin if anyone needs it.

Start-Transcript -path c:\SnapinLogs\CleanupUpdaterLog.log
$strFileName="c:\program"
If (Test-Path $strFileName){ Remove-Item $strFileName }
Stop-Transcript