Garacesh

It's OK, I got it working. I uninstalled all the net framework stuff and reinstalled from scratch and it launched as normal. Dunno what the issue was but they're needed tomorrow so I didn't really have the time to properly debug it.

Software is working great on most of our laptops, but I've got an issue with one here where it just... doesn't. Same config as the rest of them. Has .NET Framework 4.7.1. But when the program is run nothing happens. I can see the process pop up in the Task Manager but then it quits with no error, nothing at all is displayed to the user. Is there a way I can get it to write a log of what's going on? (Or does it already and I'm just looking in the wrong place?) Scratch that. Completely removed all traces of .NET and reinstalled, it's working now. Something must've just buggered up somewhere with the setup.

It's been available for ages on PC Master race an' all that. Does look fun though. I know I've had my eye on it, and I was either going to buy it once I got the Steam Link or I have bought it, but I'm not sure which. If I don't own it, it's one I definitely will own eventually. Definitely one of those games where you get a few mates round and go nuts. (Also, if you're in the market, try Dungeon Defenders, Spelunky, Magicka, Death Road to Canada or BroForce)

Yeah but the SAW franchise isn't really horror in the traditional sense. I'd consider them more thriller rather than horror.

Hurrduurrduurrr The user account would read the contents of C:\ProfileDirectory and create a local profile based upon that data. Of course, the local profile would be C:\Users\%Username%\, which was set as Disallowed since no allow rule existed. Adding %UserProfile% to the list sorted it out. Though I'm wary of this because I know some malware will try and write to the user profile location if it can't write to temp/appdata/etc. So I might have to drill down a bit more on this one.

We don't use logon scripts. There's one or two startup scripts but none for logon. Everything's done via AD. Pupil profile/start menu is copied to the machine (via startup script) which is what C:\ProfileDirectory\* is all about. the \*\* was based off @DJ-1701's policy but if I don't need it then hey ho, good stuff.

I think I broke it C:\Python33\* C:\Python33\*\* C:\Program Files\* C:\Program Files\*\* C:\Program Files (x86)\* C:\Program Files (x86)\*\* C:\Windows\* C:\Windows\*\* \\server\software\share\* \\server\software\share\*\* C:\ProfileDirectory\* C:\ProfileDirectory\*\* Now when I log in as a pupil I just get a black screen with a mouse pointer.

IIRC Applications running fullscreen disable timeouts. Probably varies by application though.

Then invariably we exhaust our supply of puns and the thread decays. Maybe we should put up plaques in remembrance of all the topics we've been through?

I wouldn't even know where to begin on that >.< AppLocker seems to concern itself with specific programs, which is no good because I want to stop everything running no matter what it is (can you do a wildcard rule..?) Some tinkering will be required. Sorry to have wasted your time so much, folks! Thanks for all the assistance.

Yep. Disable (well, untick 'Link Enabled', same difference) the AppLocker policy and I get our friendly neighbourhood error message. "Your system administrator has blocked this program. For more information, contact your system administrator."

If you boot into the recovery environment you can access the command line and set up the stickykeys trick, so local admin is child's play to get if you have an (easily obtainable) set of instructions. W7 needed its own bcdedit commands to disable the recovery environment.

You're kidding me, right..? You can't use both? Because that makes sense. Thanks Microsoft Yes we have an AppLocker policy in place to disable all the default W10 bloatware and bits that'll just cause hassle. (Microsoft.XboxIdentityProvider, Microsoft.WindowsAlarms, microsoft.windowscommunicationsapps etc)

Still nothing :/ Tried as both user and computer policies. Default security level: Disallowed Enforcement: All software files except libraries (such as DLLs) All users except local administrators Ignore certificate rules Path rules: HKLM\Software\Microsoft\etc\etc [unrestricted] (Default rule) HKLM\Software\Microsoft\etc\etc [unrestricted] (Default rule) %OSDRIVE%\Python33\ [basic User] %Programfiles% [basic User] %ProgramFiles(x86)% [basic User] %SystemDirectory% [basic User] I can still run OpenHardwareMonitor off my USB stick. So it looks like SRP just.. doesn't work. At all.

Could've sworn I replied to this one. Your command brings up an empty results sheet, but gpresult /scope:computer does say the policy is applying, and if I drill down to /Software restriction Policies/Additional Rules I can see that the policies are there. Can't run gpresult /user:$TestAccount because user does not have RSoP data.

W10 Enterprise LTSB 2016 Definitely still is. Of course.

And the results are in: No change. I've put them back in as User policies too, and, still nothing. This isn't like the bloody IE settings where I haven't pressed F5 somewhere to enable something, is it? Like I'm setting all the policies but I've missed something somewhere so none of it is actually getting enforced?

Shall try this. Edit: I'm already using 'D:\*' though, and that doesn't work. That's how I thought it should play out, aye.

Both. If I run it from D:\ (more specifically: D:\OpenHardwareMonitor\OpenHardwareMonitor.exe) it launches fine. No mess, no fuss. I remembered the \*\* entries mentioned earlier, so I've tested running it from just D: (D:\OpenHardwareMonitor.exe) and that still works, too If I run the OHW exe from inside a .zip folder, I get a message coming up saying it couldn't find Aga.Controls.dll (which is simply because I'm not extracting the full folder contents, goes back to my mentioning I don't have an exe on its own that works without supplementary files) - I take this to mean that the exe is still running, looks for its supplementary files, can't find them and throws an error.

Nope. Asterisks ain't working either

Because it's too late to do a whitelist only as we're 'live' and I don't reckon I have the time to fully test a whitelist-only solution. I'd like to do that, but for now I just want to get the minimum infrastructure in place to stop what's happening right now. I am doing it on computer policy now, but without *.. I'll add asterisks and see if that works.

Still not working as a computer policy. I can still plug in a memory stick as D:\ and run Open Hardware Monitor. And I've double-checked, EXE is in the 'Designated File Types' list.

Sorry, to confirm, yes, I'm testing it as a non-administrative account, just a bog-standard pupil.

What, just '%AppData%\', 'D:\', '\\Server\PupilData\' etc? After looking at this, I think I would prefer to work on a whitelist-only rather than a blacklist, but I don't feel comfortable doing that in a live environment. Might tinker around with it over the holidays though.

Not working. These are the current policies in place: But I can still run tools like Open Hardware Monitor from a memory stick (D:\) I don't have a self-contained (as in just the .exe, no .dll's or other supplementary files) to check from a .zip file, but when trying to run the OHW I get an error that it can't find a file, so that looks like it's allowing the .exe to launch still. You can disallow browsing to network shares, so if they do \\127.etc it won't do anything. This will also stop any shortcuts they may have made. You can't stop a shortcut to \\localhost\c$ working though. Even if you disable creating shortcuts, there are ways around it.