[ad_1]
We’ve all sat and watched the Enrollment Status Page (ESP) during an Autopilot provisioning process — it’s pretty boring overall, showing information that isn’t really useful (e.g. what does “Preparing for mobile device management” really mean) or that doesn’t change very often (e.g. why does that one app take so long). Maybe at some point they can provide a nice, simple view for the end user (just show me a progress bar that gives me some reasonable expectation on how far along the process is) and an IT admin view that is truly helpful (the diagnostics page isn’t there yet).
But until then, we can at least make it interesting. Whether it’s practical or not is a subject for discussion, but you can decide that for yourself. I’ve published another set of scripts to GitHub at https://github.com/mtniehaus/OOBEEntertain that launches a browser window (Edge in kiosk mode) over the top of ESP to display whatever web page you would like. In my case, I configured it to load a Ms. Pacman game (https://pacman.js.org) that is implemented entirely in HTML, JavaScript, and CSS:
The video is edited for length (still some snoozing moments before Intune Management Extension gets around to installing the “app” that launches the browser), but you can see the basic flow: Start off a normal user-driven Autopilot process, and when the first Win32 app installs, the browser window pops to the front. If you want to check to see what’s going on with ESP, you can Alt-Tab to get back to it.
So how exactly does that work? It is a bit of a pain. Here are the steps:
- Package the scripts up as a Win32 app. Nothing too special about that, creating an .intunewin file with the needed scripts and utilities, adding that to Intune, configuring it to run “powershell.exe -executionpolicy bypass -windowsstyle hidden -noprofile -file .launch.ps1”, putting it at the start of a dependency chain so that it installs first. (You might want to put a requirement script on it so it doesn’t run on every machine.)
- The first script, launch.ps1, uses ServiceUI.exe from MDT to launch a second script that runs in session 1 (the console session that OOBE runs in). This is necessary because the app is being run by the Intune Management Extension service, which runs in session 0, and anything in session 0 can’t interact with the user.
- The next script, OOBEEntertain.ps1, has to send a Shift-F10 key combination to OOBE so that any windows we open can be on top of OOBE/ESP. Without that, they’d be there, but sitting behind the ESP screen — you could see it with Alt-Tab, but there would be no way to bring it to the front. Shift-F10 gets around that. It opens a command prompt, but the same ShiftF10.exe utility closes that command prompt because we don’t need it anyway (you’ll see it flash up on the screen momentarily). (The keystroke needs to come from a process running in the same session.)
- After the Shift-F10 logic, the OOBEEntertain.ps1 script can’t just run msedge.exe directly because Edge refuses to run as LocalSystem from (reasonable) security reasons. So, we have to get it to run as defaultUser0 by impersonating that user. To avoid odd “path not found” errors, I had to launch it using cmd.exe so it’s that process that gets started as defaultUser0; that process then starts msedge.exe with the right command line options to load the specified web page in full-screen kiosk mode.
Try it out yourself — specify a different web page that plays a video (maybe something soothing — I’ve used a looping Final Jeopardy video before), or maybe the news of the day. Be creative 🙂
[ad_2]
Source link