@Joe-Schmitt Thinking of it that way I see your point. I hadn’t considered the malicious halting but now that you mention it I could see that being a major issue. I withdraw my request/suggestion on this one. Thanks for the time to explain your thinking.

@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.

@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.