Hi @GFm
I had the same issue in the past. The reason this is happening is that the newer revisions of the FOG client are much more efficient than the legacy client. It is basically kicking in too early. The way to fix this is to disable the service before you sysprep it pre-capture (best practice for the FOG Client). You then use the setupcomplete.cmd method shown in this Wiki Article:

https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

You are basically telling it to re-enable and start the FOG service after sysprep is finished.

Installing as we speak. Well done! Though I recently joined the active community for this project, I’ve been using FOG since the 0.29 days and am amazed to see where the project is now. It’s come a long way to say the least. You take tools like this for granted when you are forced to do it the old fashioned way. I (briefly) worked IT at a factory that refused to implement any imaging solution. Each PC was built from OEM Windows from scratch. It sucked.

I’m glad to be back using my favorite open source project out there. Though most things we use at my job are proprietary, the support for FOG far surpasses any paid software. I can literally post on the forums and hear from a moderator, developer, or the legendary Tom Elliott himself within the hour. Even early in the morning!

I’m already thinking in the future, but I must ask, will the trunk style of updating disappear once the final revision of 1.3 is out? It would be bittersweet to lose that. On one hand you have the obligatory bugs that come with any testing, but being on the cutting edge of a growing project is actually pretty cool.

But I digress, keep up the good work guys and kudos for the dedication to the project. I look forward to the 1.3 release party

@Wayne-Workman I figured it out! I’m actually kinda proud of this one. Please see below for all of my Windows Server 2012 configs

Please let me know if you need anything else for this. It did indeed work. Thank you so much!

Congratulations everyone! I’m actually going to miss trunk/svn/RC’s in a weird way lol.

@Quazz I just tried both arguments on a surface pro 4. As long as you put

usbcore.old_scheme_first=1

before

has_usb_nic=1

separated by a space like you said, it works with no errors.

@Sebastian-Roth said in Stuck at Task Management Page "Unable to start task. Unable to upload file":

Not because it’s screwed but because more often than not you can learn something by re-doing things.

Amen to that. I learned Linux basics and the finer capabilities of FOG from rebuilding from scratch. Most people who use FOG seem to inherit an old installation from the last regime, myself included. I tried to fix what was there but it was poorly set up and unstable. It took some convincing and getting my hands dirty but I am on Trunk and loving it.

@george1421 I took a complete 180 on the methodology on this problem with the help of my co-worker who is better with Powershell than I am. Below is the sanitized version of our simple script to check Domain PC’s for the FOG Client:

ForEach ($Computer in (Get-ADComputer -Filter * -SearchBase "OU=Sample,DC=yourdomain,DC=com")) {
$ComputerName = $Computer.Name
If (Test-Connection $ComputerName -Count 1 -Quiet) {
    $FogService = Get-Service -Name FogService -ComputerName $ComputerName -ErrorAction SilentlyContinue
        If ($FogService) { Write-Output "FOG is running on $ComputerName" | Out-File C:\Scripts\FOG.csv -Append}
        Else {Write-Output "FOG is not running on $ComputerName" | Out-File C:\Scripts\FOG.csv -Append }}
Else {Write-Output "$ComputerName is Offline" | Out-File C:\Scripts\FOG.csv -Append}
}

It isn’t the prettiest, but it is versatile in the way that you can really sub the FOGService with any other service name to check if said service is installed and running. I have a initial CSV for the online PC’s that had a broken or not installed FOG Client and set a GPO Startup script to remove any old service, install the new service, and finally start the service. Below is a sanitized batch file for that:

msiexec /q /x C:\LegacyClientInstaller\FOG Service Installer.msi"
msiexec /i "C:\NewClientInstaller" /quiet USETRAY="0" HTTPS="0" WEBADDRESS="YourFOGAddress" WEBROOT="/fog" ROOTLOG="1"
net start FOGService

Hope this may help someone someday!

I just recently used FOG to create a surface pro 4 image. My workaround was to use a port replicator/hub to have both an external USB keyboard and Ethernet adapter plugged into the surface. It seemed to recognize both. It isn’t a permanent solution but It is how I did it.

So, this is really dumb on my part… It was our web filter blocking the calls out to pushbullet. It now displays the email and name in the table and the GUI after I whitelisted it. I will double check that notifications are working tomorrow, but this is looking like a whoopsie on my part. Most likely solved.

@ITSolutions I suppose my method is a band-aid fix of sorts. At my place of work, we are moving to standardize the models of PC’s we are putting in. By the time next school year starts, we will have about 75% of all of the PC’s in the network be Dell Optiplex 5040’s. Ultimately, we are going the model-specific route of images since we only have a handful of models we use. I agree with what you are saying though.

@sebastian-roth Just a quick question, is there a place where I can get this init without moving to the dev branch? I am very compelled to stay on the stable branch at this time. Are the inits on fogproject.org this version, or the old stable ones?

@sebastian-roth we may have found a workaround since we have a uefi/bios co-existence setup, we are trying to legacy boot to capture/deploy the uefi image. It appears to have worked. I am not sure I want to pursue this issue further since it is a very old model and a one off case.

I appreciate your help on the matter regardless, thank you.

@sebastian-roth thanks for the advice. I tried ipxe.efi and also tried compiling my own. Unfortunately both times I received the same error. I am wondering what else I could try if this is a fixable issue.

Hi all,
FOG 1.5.9, boot file snponly.efi, kernel 5.10.34 TomElliott.

Get a strange error when trying to UEFI netboot an old Dell Vostro 470. It has the latest released firmware (A14 from 2018) and throws an error about edk2 (see below). It will not progress past this. I am wondering if this is due to the age of the pc model.

Let me know if you need any more details as I’m sure I left out an important detail or two by accident.

Thanks!

@sebastian-roth @george1421 I may have posted this thread prematurely. I ended up having my colleague try a different type of Ethernet dongle (USB-C vs regular USB) and that did seem to fix the halting issue. I can verify tomorrow, but I think that message in the picture is still there, it just keeps imaging until complete now. I also found out a nice new BIOS came out for this model, so it is possible an update can fix the message. I can test the bios update with one at some point, but we are pretty busy with students returning next Tuesday in person.
I think we can mark as solved in the meantime.

@george1421 To my knowledge they are. I am gathering info this afternoon about it and will check a problem device tomorrow morning.

Hi All,
I have a batch of T495s laptops we are working through imaging. Everything was going well up until today when we started to get the error below that halted the deployment process.

Nothing has changed on our side (FOG 1.5.9, 5.6.18 kernel). It went from one laptop displaying this on attempt #1 and working the second attempt, to a laptop that now has failed 3 times in a row.

Please advise and please tell me what info I missed here since I most certainly forgot to include one thing or another. I can get my hands on one tomorrow to test with.
Thanks!

I am totally geeking out hearing this! The film technology they used is also quite fascinating.

@george1421 You have a great point. I discussed it with the boss, and we went the path of no client on the laptops. It is a relatively small number right now that need a somewhat quick turnaround. I figure we can bang out renaming and joining manually for these. Perhaps I will investigate other methods if there is a future order or it is the direction we end up going. Thanks!

I’m still on 1.5.6 and this doesn’t work for me. Honestly it has not worked in many iterations of FOG prior either. I usually just go into the VM and manually remove them after I delete the definitions in the GUI. Thought it was just a bug on my end.