Attempting to deploy League of Legends via SCCM (.exe)

[coolsport00]

Hi All -

My 1st post here and somewhat new to SCCM (only a few mos in). I'm attempting to install League of Legends (LoL) during OSD as an app and it hangs for like 6hrs at this step in the Task Sequence and then fails. I looked at 2 of the smsts and smsts-#### log files on the test client device and wasn't given anything definitive in the file as to why it failed. I then broke the install down a bit to test on a Win10 client via Software Center. I figured out it needs .NET 3.5 as a pre-requisite. So, I have that part working & sorted. Installing LoL works in Software Center, but the problem is it's prompting for user interaction (only 1 action needed...to click 'Install'). I can't seem to find a silent install method/switch for the .exe. So my question is this - can applications install successfully via OSD even if there's no way to do a silent install, or must the app be configured to run silently for it to install successfully via OSD? If the answer is no...apps must be able to run silently, then I guess that would explain why it hangs during OSD for so long...seems to be awaiting an 'interaction' to click "Install" during deployment. I haven't yet reached out to LoL support to see if they have a process for installing silently and/or via SCCM. Thought I'd try here first.

If anyone needs more info on this .exe, what it actually does is install the 'Riot Games' (LoL vendor) client, creates a Riot Games directory, then it opens runs the Client automatically, opening the Client window and prompting you to log in with your LoL account to then download the LoL game files to the local device. It's really a mess IMO, to say the least. There's no registry keys or anything. Maybe keys get created after you log into the Client and begin LoL download...not sure. I don't have a LoL acct. I'm just trying to get this to auto-install during OSD for new gaming devices at a school district I work at. Let me know if you all need any other info.

Thanks a bunch!

Shane (@coolsport00)

[anyweb]

they must run silently, so figure out a way to do that and you'll be golden, OR bite the bullet and install the app AFTER the osd part is done, on the users first login, where they CAN click on stuff

 

[coolsport00]

As I thought...thanks much "anyweb". We planned on 'biting the bullet' and was just gonna install it after the OSD cuz there are a few configs we want to do after the OSD to the devices as well. But, I at least wanted to give getting this installed as part of the OSD a good try. You wouldn't happen to have any sure-fire ways to deploy an .exe silently, do ya?  I wish MS's SCCM app deployment documentation would actually state apps *need* to be deployable silently for them to work in their documentation. Would've saved me a few days time researching/testing. Eh well...at least I gained more app deployment knowledge

Cheers!

[anyweb]

the thing is when you deploy apps during OSD they should be installing in SYSTEM context and that is something that the user cannot see or interact with,

so.... once you know this, you have to look at the options in the app itself to get it to install without any user interaction,

or... deploy it to USERS after OSD

[coolsport00]

Gotcha. Good stuff...thanks man.

Cheers!

[School Tech]

Naturally, I dropped in looking for this same thing.  However, you can make system level installs interactive within SCCM.  The trick is that you use the ServiceUI.exe program (the same one that makes imaging interactive, grab it from the tools directory during imaging).

You just call it up using the command line with something like the following (this was for Huion tablet drivers, which they didn't make available for silent install):

ServiceUI.exe -Process:explorer.exe HuionTablet_WinDriver_v14.8.90.1126.exe

My organization has primarily moved on to Intune rather than SCCM, but this also works within Intune as well.  It's not perfect, naturally - but it works pretty well.  (One catch, only one user can be logged onto the device, otherwise it might find the wrong instance of explorer.exe and shot it to that user rather than the one who called up the application).  Of course, this can't be 'pushed out' since it requires a user at the computer to interact with it.

I'll keep on looking, but failing that, this is my backup plan.