SNAP INS. Lets talk about them...
-
OS: Debian 10 Buster
FOG OS: 1.5.10Hi All,
We are trying to integrate Snap Ins into our workflow for running scripts and installing applications to make things more streamlined and easier for deployment and I’m really struggling to get any Snapins to work properly and I’m at a loss for what else to try. I’m hoping someone can point out if I’m missing anything, or if Snapins just aren’t reliable in general.
Through this process, I have also learned that Snapins run as the SYSTEM user, which makes it difficult to create scripts that require user interaction. I’ve been trying to build a script that runs a quick QC Diagnostic test and allows the person imaging the computer to interact with it or at least see the test results it in a PowerShell window, but no luck so far. And it sounds like the SYSTEM user does not allow for any sort of interactivity and completely runs in the background. Not the end of the world, I suppose. I may be able to figure out some sort of workaround on that front (i.e. a snapin task that manually schedules a ps1 file using the Task Scheduler on the computer image or something).
However, more recently, I’ve tried using snap ins to run a simple batch script that installs Office 2019 and pins it to the taskbar. The script downloads to the
C:\Program Files (x86)\FOG\tmpdirectory but just sits there, and the task in FOG Dashboard don’t clear it. This script has always been run manually by the person doing the deployment off of a share drive but we’re trying to automate this. I can even run the script as an Admin fromC:\Program Files (x86)\FOG\tmpand it works. But from what I understand, it’s supposed to download from the FOG Server, run the script, and then delete it. Right?Here’s what I’ve tried so far:
- Reinstalled FOG from scratch, both on the Master Server and on storage nodes.
- Increased memory limits (in www.conf file to 2048M), which helped fix some loading issues but didn’t solve Snapin problems.
- Made sure Snapins were correctly defined and verified paths, passwords, and permissions.
- Snapins do get tasked, but they just don’t seem to execute on the target machines.
- Used FOG API to automate tasks post-imaging, but Snapin execution still fails.
We’re using only Windows clients, with PowerShell scripts that ideally run from a network share. Even though Snapins get queued, they never seem to actually run. Just trying to check my own knowledge here.
I have also reviewed the log files that FOG creates and it usually just either hangs at “Starting snap in” or it says it’s done and nothing happens on the computer (this is rare though)
Has anyone else experienced similar issues with Snapins? Am I missing something really obvious, or are Snapins known to be unreliable in certain setups? Any insights would be incredibly appreciated.
Thanks in advance for your help!
-
@danieln the act of “pinning” I believe requires user interaction. I also suspect, possibly, the office 365 is awaiting user interaction. Once the task starts, look at the task manager. My suspicion is you’ll see office installer is running. But it never completes which is why you don’t see it finishing the task on the server.
-
Hey Tom,
You’re right, this is usually a manual task. I use a Windows freeware “pin to taskbar” utility that I have built into my install office script and when it’s run with an elevated command prompt it automatically pins Word, Excel, and PowerPoint to the taskbar. It’s also Office 2019 SPLA and not 365 (although we’re likely switching to that in the future)
As for the Snap Ins themselves, I could be wrong, but it really seems like it just runs the Snap In as the SYSTEM user which is great because that should theoretically have highest privileges, but it runs it completely in the background.
I have however been able to have a test Snap In batch script that write a test text file to the Users desktop upon execution, but I have to include
set indicator_path=C:\Users\Admin\Desktop\and specify where I’d like the file written to. Just using%USERPROFILE%\Desktop\doesn’t work.I can’t imagine anyone on this forum hasn’t used Snap Ins to execute PowerShell or batch scripts and I just wanted to make sure i’m not missing anything.
To be fair though ,the Office install script that we use is a little more complex than just a simple msi and we use their Office Deployment Tool to run an additional XML file off of a network share drive that has our product key baked into it. There is just something about the way that snap ins run that is just different from just running it as an Administrator that I haven’t figured out yet.
-
@danieln using using expansion variables wouldn’t work because the user doing the expansion of %userprofile% from a snap in is system.
Those types of snap ins work just fine when directed appropriately because there is no user interaction. I suspect the 3rd party tool simulates the interaction via elevated credentials but those interactions will not work from the system user. I know it’s a pain, but that is one limitation of windows and system user. System user has full reign on the OS. It should be able to do these things. However, security wise, it’s a black hole in that any application or service that would run as the system user after being installed by an elevated permission, would also have full reign. So to prevent complete destruction of the OS and experience Microsoft has made it impossible to have the system user directly interact with other users profiles. I see both sides of it. There simply isn’t a way around this currently that I’m aware of.
-
Yeah, this was my suspicion. I see both sides of it too. Sounds like I’ll have to either super simplify some of my install scripts and make some sacrifices or figure out another solution.
I appriciate the response and confirmation!
