FOG Snap Ins getting caught on big installations. Limitation of Snap Ins or problem with the program?

[THEMCV]

Server

• FOG Version: 1.3.0 RC-37
• OS: Debian 8.6.0

Client

• Service Version: 0.11.7
• OS: Windows 7

Description

Namely the big ones are Visual Studio and office. I bumped up the limit for Snap Ins past what is normally set and it does install, but the FOG client doesn’t see that it’s finished. Sometimes it’s VMware, sometimes it’s Visual Studio 2013, sometimes it’s office, but on the bigger ones it get caught up and I have to reboot, remove the rogue snap in task, and then it’ll go.

Is this me pushing snap-ins too far or the programs messing up? As I said, they do install, but the FOG client doesn’t realize that and doesn’t exit to go to the next one.

[Tom Elliott]

Can you provide the client log files?

[THEMCV]

@Tom-Elliott This is the one that it got stuck on. at I rebooted a few minutes after 4, removed the task, and then it continued after that. It’s 5.97 GiB in total.

 12/22/2016 3:15 PM Bus Emmiting message on channel: Notification
 12/22/2016 3:15 PM Middleware::Communication URL: http://10.4.200.150/fog/service/snapins.checkin.php?taskid=795&exitcode=0&mac=84:2B:2B:A6:D1:92||00:00:00:00:00:00:00:E0&newService&json
 12/22/2016 3:15 PM SnapinClient Snapin Found:
 12/22/2016 3:15 PM SnapinClient     ID: 796
 12/22/2016 3:15 PM SnapinClient     Name: Visual Studio 2013
 12/22/2016 3:15 PM SnapinClient     Created: 2016-12-22 19:03:38
 12/22/2016 3:15 PM SnapinClient     Action: 
 12/22/2016 3:15 PM SnapinClient     Pack: True
 12/22/2016 3:15 PM SnapinClient     Hide: False
 12/22/2016 3:15 PM SnapinClient     Server: 
 12/22/2016 3:15 PM SnapinClient     TimeOut: 0
 12/22/2016 3:15 PM SnapinClient     SnapinPack File: cmd.exe
 12/22/2016 3:15 PM SnapinClient     SnapinPack Args: /c "[FOG_SNAPIN_PATH]\install.bat"
 12/22/2016 3:15 PM SnapinClient     File: VS.zip
 12/22/2016 3:15 PM Middleware::Communication Download: http://10.4.200.150/fog/service/snapins.file.php?mac=84:2B:2B:A6:D1:92||00:00:00:00:00:00:00:E0&taskid=796
 12/22/2016 3:22 PM SnapinClient C:\Program Files (x86)\FOG\tmp\VS.zip
 12/22/2016 3:27 PM SnapinClient Processing SnapinPack VS.zip
 12/22/2016 3:27 PM SnapinClient Extracting SnapinPack
 12/22/2016 3:31 PM SnapinClient Processing SnapinPack settings
 12/22/2016 3:31 PM SnapinClient New SnapinPack File: cmd.exe
 12/22/2016 3:31 PM SnapinClient New SnapinPack Args: /c "C:\Program Files (x86)\FOG\tmp\Visual Studio 2013\install.bat"
 12/22/2016 3:31 PM Bus {
  "self": true,
  "channel": "Notification",
  "data": "{\r\n  \"title\": \"Installing Visual Studio 2013\",\r\n  \"message\": \"Please do not shutdown until this is completed\"\r\n}"
}
 12/22/2016 3:31 PM Bus Emmiting message on channel: Notification
 12/22/2016 3:31 PM SnapinClient Starting snapin...
 12/22/2016 4:07 PM Main Overriding exception handling
 12/22/2016 4:07 PM Main Bootstrapping Zazzles
 12/22/2016 4:07 PM Controller Initialize
 12/22/2016 4:07 PM Zazzles Creating main thread
 12/22/2016 4:07 PM Zazzles Service construction complete
 12/22/2016 4:07 PM Controller Start

[Tom Elliott]

@THEMCV If I had to guess as to the issue, I don’t think it’s anything wrong with the GUI or the snapin running. Rather, the installation is requiring some user action? This is just a guess considering it just “stuck” there for an indefinite amount of time.

[Tom Elliott]

Of course seeing the install.bat file would probably help (removing any licenses in the batch file to show us).

[THEMCV]

@Tom-Elliott The thing is that it isn’t always the same one. Office will usually go through fine, but sometimes it hangs there. VMware installs and I’ve tested it to install just fine, but sometimes it will be the one that hangs up. Visual Studio too.

Here’s what I have

Office 2016’s install.bat

@echo off
setup.exe /adminfile adminfile

Simple, but here’s the admin file.

Update UI is hidden, Setup reboot is turned off, and Display Level is set to None.

And I’m just realizing I deleted the Visual Studio 2013 zip… @Tom-Elliott Does FOG store snap ins somewhere I can get to them? Then I can download it and show you the installer.

[Wayne Workman]

@THEMCV I think the snapin timeout is being reached and the fog client quits caring about the process.

It may deploy to one box great, right? But when rolling out to a ton at once this happens right? The fog server’s throughput gets maxed and the next one that starts while it is maxed gets throughput of bits per second instead of megabytes per second and the timeout is reached - or its literally still transferring.

This same sort of thing can be seen with file transfers or imaging. The first is fastest. Each one after gets half of available bandwidth that way there is always bandwidth available. (Tcp/ip). And even if earlier ones get done, the later ones don’t really speed up.

How to solve this? Reduce the max client setting in Storage Management, of course. I recommend setting it to two or three.

[THEMCV]

@Wayne-Workman I’m actually only testing max two at a time. FOG server is still in development for us and getting it to work right.

I’ll try reducing it still and see if that helps.

[Wayne Workman]

@THEMCV In that case, I’d like you to reduce max clients to 1 just for troubleshooting, and also increase the snapin timeout for the fog client. Set it to something much larger, something that you know the snapin will get done within. But it would seem the default is unlimited already… Can you upload a client log from an affected system?

EDIT - this is the timeout field: