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.

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.

Hi All,
Apologies for my absence. I am not much better than when I went on leave from work back in February, but here I am. For the first time in months, I will be working on something FOG related

I am tasked with imaging a bunch of Lenovo T495S laptops. We see the following behavior on the T495S laptops and our X1 Carbons that are already deployed. Neither of these devices have an integrated Ethernet NIC (i hate this).

To remedy the whole “missing a vital component of a modern enterprise computer” thing we use a pair of Lenovo docks. We currently have a Gen 1 Lenovo USB-C dock and a separate Gen 2 Lenovo USB-C dock.

The problem is that we are presented with two options: Use the docks’ MAC addresses to image the laptops, thus having to join the domain and name each manually, or somehow make MAC pass through (an option to enable in the BIOS) work.

It seems that though the docks have their own MAC’s, there is also an internal MAC for a Lenovo accessory that turns a special usb-c port on the side into an Ethernet port. With using the dock, we are always stuck using each of the two Dock MACs for imaging. We cannot do full registration because it only recognizes the two docks, not anything with the devices themselves. Auto-Naming/registering/joining is not an option using the docks because of 2 MACs vs like 50 Laptops.

Regarding MAC pass through, the devices PXE boot and load into the fog menu perfectly with the correct internal MAC. However if you go anywhere past that (deploy image or Full Registration) it hangs up and times out. I see when it tries to use the Dock MAC to start any task past the FOG menu.

So, it seems the pass through breaks somewhere in the PXE environment and it reverts to the Dock MAC.

So our options are currently order a couple of the special Lenovo Accessory ports and cross our fingers that the dock mac elimination fixes this (back ordered until Mid-July though) or to try to see if getting pass through working is feasible. I am working from home 95% of the time, but please let me know any info you need for the next time I go in. We are still 1.5.6 and are willing to upgrade to 1.5.8 if need be. As always, CentOS 7 is the OS and client is…whatever shipped with 1.5.6 (I’m so out of touch I forget what version…)

Thanks folks!

@rinfog I apologize, I am away from the project as I am home recovering from surgery. I will certainly bump this for visibility.

@Sebastian-Roth and anyone else who worked on this, great work on continually improving the client that some of us rely so heavily on!

@celikbilek

Did you happen to change the “fogproject” user account’s password on the Server? This account is only meant as a service account for FOG and is not meant to be used to manage fog. If you did, you must match the passwords in the following places:

 Web Interface -> Storage Management -> [Your storage node] -> Management Username & Management Password

Web Interface -> FOG Configuration -> FOG Settings -> TFTP Server -> FOG_TFTP_FTP_USERNAME & FOG_TFTP_FTP_PASSWORD

The local 'fogproject' user's password on the Linux FOG server

Server file: /opt/fog/.fogsettings -> password 

The easiest method on fixing this if you did change the service account password (fogproject) on the server is to change that password on Ubuntu to match the other locations by doing this

sudo -i
passwd fogproject 

You will be prompted to enter a new password. Please ensure it matches the password elsewhere.

@EduardoTSeoane said in Bottleneck on DATABASE:

@fry_p Yeah I read it, but my first hit is to keep it more simplest as posible, I think that before to start to implement that it’s bette to do lesser works, there are a few months than I’m thinking that myISAM is not an optimal engine for this, almost for me, and I’m alone as FOG Sysadmin and need to keep my workload under control, I have not much experience with clusters and load balancing, and it’s no so good.

When I can I share documentation about our installation and customizations.

Lone FOG admin? That sounds awfully familiar (I am too)

I have 0 experience with this other than the testing I did. Perhaps when I am recovered I will dig back into this using my work environment. I am glad you will share your findings when you find time and look forward to reading them.

Scalable FOG would really expand the usage of FOG (pun intended) in bigger use-cases. I understand this is all volunteer with everyone having day-jobs, so perhaps while I am on medical leave, I can set up a home lab. I have 2 servers, a few desktops, and proper networking equipment at home. IDK how I will replicate the number of clients we need to properly test large environments, but at least I can do some more proof of concept work.

Give me a few weeks (I will be couch bound at my parent’s place starting Feb 7th for about two weeks at least after surgery) to recover and then I can do some testing. If I don’t do something like this, I will most likely go crazy from boredom lol.

@Sebastian-Roth well then, today I learned! MSI’s only advantage is you can deploy via GPO I suppose. To my knowledge you have to call a script for an exe. Either way works. Thanks for the clarification.

Sorry to necro this thread, but I also want to mention a certain use-case for the MSI. You can pass arguments using msiexec to install. This is useful for remote/silent installation. This has saved me in the past.

From the Wiki:

msiexec /i FOGService.msi /quiet USETRAY="0" HTTPS="0" WEBADDRESS="192.168.1.X" WEBROOT="/fog" ROOTLOG="0"

Firstly, all options are optional. Here’s what they all do:

    USETRAY= defaults to "1", if "0" the tray will be hidden

    HTTPS= defaults to "0", if "1" the client will use HTTPS (not recommended)

    WEBADDRESS= defaults to "fogserver", this is the ip/dns name of your server

    WEBROOT= defaults to "/fog"

    ROOTLOG= defaults to "0", if "1" the fog.log will be at C:\fog.log, otherwise %PROGRAMFILES%\FOG\fog.log