Posts made by Darrin Enerson

@x23piracy That looks like it might be exactly what we’re experiencing but I have no clue why it would only show up intermittently. I’ll test this out and see if it fixes the issue when I can get it to trigger again. Thanks for the info.

@wayne-workman That’s my thought as well now with this new data. The fact that this one is working fine on a re-image now tends to rule out the sysprep, unattend file, setupcomplete.cmd, fog client, and image process itself. I’m going to deploy snap-ins one at a time to the control machine as well to see if one of them is the culprit.

@wayne-workman It’s occurring on both the built-in webcam and an external USB webcam so that makes me think it’s some kind of access control issue in the OS between the software and the hardware. It’s worth noting that I just re-imaged the same laptop and it’s not currently exhibiting the same symptoms which is strange. Possible it’s some kind of hardware fault but then I’d think that it wouldn’t work in the camera app either. We’ve had similar issues with this image/Windows version and doc cam software this year as well so I suspect there’s some trigger I’m missing.

@Wayne-Workman We don’t bake any software into the image and deploy it all after deployment using either snap-ins or GPOs. The software that complains is anything that taps into the webcam other than the built in camera app so it seems to be an OS issue and not specific to any application.

What I’ve been using as a test is the built in Skype app with no additional snap-ins or software deployed in the image. If I replicate the same steps on the same hardware but install off the ISO file instead (and skip sysprep as a result) I don’t have the same problem so that seems to point toward something in the process between sysprep and deploy.

Edit: We do have one application installed in the image actually; the fog client. I kind of doubt that’s causing the issue though.

I’m running into a bit of a head scratcher on our Windows 10 (1703 EDU) sysprepped image. Every computer I deploy it to reports that it’s webcam is in use by another application even when process view is showing nothing hooking into that hardware running. Interestingly the Windows 10 Camera app works just fine though. This seems like it must be a problem with our sysprep process, our unattend file, or the image process (doubtful) since if I install Windows straight onto the same hardware using the ISO image we used to create our syprepped image I don’t run into the same issue. I’m at a bit of a loss as to what would cause this though. Any help tracking it down so I can squash this issue would be appreciated.

@Tom-Elliott Thanks Tom :). I’ll have a chance to do a confirmation test in my setup sometime next week and let you know if I encounter any issues related to this.

I was able to do a bit more testing on this today and think I may have discovered the root cause of the issue. The problem doesn’t actually appear to be in the imaging system but rather in the snapin system. I say this because I can image 25 computers simultaneously with no snapins and don’t encounter any issues, however, if I deploy to the same 25 with snapins it exhibits this behavior as soon as the snapins start applying. The issue appears to be that when a snapin is first pushed out it looks to be running a hash function on the server and client, presumably to make sure it received an unaltered file before executing. The problem is that if a number of these tasks start at roughly the same time it maxes out the CPU and RAM on the server and strange things start to happen. I haven’t found the lower limit of where this starts to occur but I can reproduce it with my process every time I try it so can do any further troubleshooting needed as well as provide an entire batch of logs.

As an update to this I can image smaller batches of 10 with no issue. That would tend to indicate a load, memory leak, or process leak issue. Let me know if you need more troubleshooting on my end to narrow this down. I’ll proceed in smaller batches for now so that I can get everything prepped by my deadlines but I can set up larger batches for testing this as needed.

Not sure if this is an issue or just an eccentricity of the system so I’m putting it in Developers/General. On 1.3.0 RC8 with client 0.11.5. I noticed this only due to trying to work with no coffee in my system (generally a bad idea this close to the start of the school year). In my non-caffeinated state I created an “All Snapins” task for a host that had no snapins actually assigned to it (obviously not going to do anything). Now the strange thing is that not only does the system create this task just fine it also doesn’t recognize it’s existence client side. This results in an “All Snapins” task that will sit in the active task list but never actually do anything or get picked up by the client. This task would likely happily sit there forever until manually deleted (which works just fine). My guess is that the reason the client doesn’t see this as a snapin task and clear it is that the task is meant to have actual snapins inside of it and since it doesn’t the client doesn’t even see the parent task. As a result the server never clears it out so it just sits there.

Why anyone would ever do this intentionally I don’t know but I thought I’d bring it to someone’s attention just in case it needs to be addressed. It did have me scratching my head for a bit though since I kept seeing it in the task list. Then of course the obvious dawned on me and I actually assigned snapins to the host and felt like a bit of an idiot for not seeing that sooner :).

@Wayne-Workman On these the WiFi settings aren’t loaded until the computers join the domain so they’re entirely LAN based connection until then. As I mentioned if I image each of these one at a time it works without a hitch but in a batch of 24 it fails seemingly randomly and hammers the FOG web interface into instability in the process. I haven’t tried smaller batches yet because I didn’t want to destroy the client logs if they could be helpful. I will note however that in FOG 1.2.0 with the old client this setup doesn’t cause any issues so it’s definitely related to 1.3.0 and the new client.

@Wayne-Workman That’s something that I’d considered but what gets me is that the drop down loads appropriately on the “List All Hosts” page. I haven’t taken a look to be certain but I’d guess that the code is the same for both pages for that part so the fact that it works on one for me and not the other would seem to indicate a bug that I’m hitting due to some edge or corner case.

@Wayne-Workman

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
C:\Users\IT>ping fogserver
Pinging fogserver.beaconacademy.com [172.16.12.6] with 32 bytes of data:
Reply from 172.16.12.6: bytes=32 time<1ms TTL=63
Reply from 172.16.12.6: bytes=32 time<1ms TTL=63
Reply from 172.16.12.6: bytes=32 time<1ms TTL=63
Reply from 172.16.12.6: bytes=32 time<1ms TTL=63
Ping statistics for 172.16.12.6:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Users\IT>

I can pull up the FOG management page from that computer as well.

@Wayne-Workman Both Firefox 48.0.1 and Chrome 52.0.2743.116 m load the drop down appropriately on the same computer that is experiencing the issue in IE11.0.9600.18350. When I try the same page on a different computer running Windows 7 Enterprise with IE11.0.9600.18426 I get the same result with the drop down not appearing correctly. Seems to be an issue with IE11 on Windows 8.1 and 7 at the very least.

@Wayne-Workman The SQL commands produce this:

[root@fogserver ~]# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 31
Server version: 5.5.50-MariaDB MariaDB Server

Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> use fog;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [fog]> select groupID,groupName from groups;
Empty set (0.00 sec)

I deleted /var/www/html/fog as directed and then reinstalled fog from my existing git pull. Created new group “Test”.

Searched for “Test-650G1-01” with the same result:

Here is the result of the same SQL commands after this process:

[root@fogserver bin]# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 14
Server version: 5.5.50-MariaDB MariaDB Server

Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> use fog;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [fog]> select groupID,groupName from groups;
+---------+-----------+
| groupID | groupName |
+---------+-----------+
|       2 | Test      |
+---------+-----------+
1 row in set (0.00 sec)

@Wayne-Workman The system won’t let me upload it as a file and it’s too long for the posting requirements. Here’s the Google Drive link to one of the logs though: https://drive.google.com/file/d/0BzdlDm_GwIvwdllHakduWGdwUTQ/view?usp=sharing.

This comes from a host that was one of the last to finish imaging in this batch. As such the other hosts were already going through joining the domain and attempting to apply snapins. Since whatever is causing this issue also causes the web interface to become increasingly unstable this one failed to even join the domain. Let me know what logs, if any, you need from the server itself.

@Wayne-Workman Group deleted:

New search for Test-650G1-01:

@Wayne-Workman Same result on both searches:

@Tom-Elliott Here’s a screenshot of our groups listing on that server. I should also note that I’m using IE11 on Windows 8.1.

Server

• Version: 1.3.0-RC-8
• OS: CentOS 7

Client

• Version: 0.11.5
• OS: Windows 7

Description

The drop down box for “Add to group” appears to be non-functional and/or not populated when performing a “New Search” on “Host Management”. The drop down box isn’t populated with groups and is only a sliver wide (see screenshot). The box works properly if you instead use the top row search boxes from the “List All Hosts” screen. We only have a single group configured currently if that makes a difference.

@Tom-Elliott Each host has the same set of 17 snapins associated to them.