Software Restrictions not working on one lab, denies every program

I'm implementing Software Restriction Policies for student accounts in our school and I'm having issues with one of the labs.

So far, here's what I've done. I've created an initial test policy with the default rule as disallow, and then added paths as needed [such as network application UNC paths and Program Files, and the default system paths]. These work great on every other lab and system in the school. Using a student test account with that policy enabled, I'm allow to only run what's installed already on the computer, and I can't run any executables from USB drives, student H drives, my documents folder, desktop, user profile, and other locations besides Program Files and application drives.

On this one lab however [all lab computers are the same image, different image per lab], the computers won't allow a student with this policy enabled to run ANY application. Internet explorer works, and that's about it. Everything else, including Notepad, fails to launch and says that there's a software restriction policy preventing it. I logged into another computer in the lab just to make sure there wasn't something going on with that exact computer, but I got the same results on the next machine.

When I log onto the machine as a local administrator and pull up the Event Viewer, I see the following entry for Software Restriction:
Access to C:\Documents and Settings\Test-Student\Start Menu\Programs\Accessories\Notepad.lnk has been restricted by your Administrator by the default software restriction policy level.

Sure, .LNK is an extension that's included in the default designated file types list in the policy, but why isn't it affecting any other system builds in the school?

I really want to roll this out because students are starting to use tor for web browsing and playing games brought in via USB drives. This would work perfectly for preventing all of that, and it works for every system. But this lab of 10 computers doesn't work with it, so I can't roll out the policy until I find out what's causing it. Any advice would be greatly appreciated. Please let me know if anyone needs more information.

have a look at where the icons on the other machines are comiing from. Redirected start menu's for instance may not be covered by the policy.

Quote:

---

Originally Posted by strawberry

have a look at where the icons on the other machines are comiing from. Redirected start menu's for instance may not be covered by the policy.

---

Thanks for your reply.

That's a good thought, but the strange thing is that none of the icons are redirected from anywhere. The start menu's are all local. I build every image the exact same, just loading different software onto each one depending on what lab the image is for.

The way I typically build images involves me tweaking the Administrator account to how I want it to look for everyone else, and then I copy the Administrator profile to default profile, and sysprep/image. Everything always works great. This one image though for whatever reason doesn't want to cooperate with the software restriction policies. I just booted up the exact same hardware, one from the problematic lab, and one from one of the many working labs next to each other. I logged in as the restricted test user on each, and on the working one, I was able to launch Word, notepad, anything that was installed right on the system. On the problematic lab, I can't launch a single application except Internet Explorer or a file explorer window. Any more suggestions?

Also, I looked at the path as suggested. The path for say, the OpenOffice.org icon on the desktop, is the exact same path on both systems, and both systems have the exact same policy as the policy is applied to the user.

Any other suggestions would be greatly appreciated. I really want to roll out this policy but I can't until I get it working with this lab. Do you think anything in the system PATH could confuse it if there's different entries on both machines?

Anyone got any ideas on why this may be?

When you say the same policy is applied (user) to both a working & non working machine are they in the same OU?

I would move a 'working' PC into the OU of a broken one and see if the problem occurs on that box and vice versa.

Good idea, but the exact same policies are sent to both OU's. The two computers are both in a parent OU called "Student Computers", then there's two OU's underneath for the sole purpose of organization, no policies applied right at the child OU. Room 115 and Lab 129 are the two OU's. Room 115 is one of the many that work with no problems, Lab 129 is the problematic lab. Again, I never would have known by just using the computer, it works great. But when I apply the restriction policy to all students, and they try to log into Lab 129 as a student, that's when I realize I can't open anything. Again, the path's in the properties of any shortcut on both a working computer and a Lab 129 computer both show the exact same path. One works, one's restricted.

If you refer back to my first post, you can see that an error showed in the Event Viewer. It's interesting because this should technically be the exact same path on both systems, and yes, .lnk's are in the list of items to block, but the object that's blocked isn't the .lnk file, it specifically shows c:\windows\system32\notepad.exe has been blocked just on that one lab.

Anything in Environment Variables that would throw this off? I know I had to modify the path on this lab at the beginning of the year because Mastercam decided it would have some fun and instead of append the Mastercam directory to the end of the list, it would just remove everything in PATH and just add itself. So no login scripts were running at first. I then copied a working path from another computer, and combined it with the custom entries that Mastercam had made, and login scripts started working perfectly.

In the Administrator account, if I go to Environment Variables I see TEMP, and TMP directories at the top for User variables, and I also see a PATH directory up there referring to a PTC Pro/ENGINEER program. I don't know if that makes a difference that that's there.

Can you run a resultant set of policies on the workstation using GPMC and see what the results are, it will tell you what policy is 'winning' when they are applied and what it is setting on the machine, there could be a problem somewhere along the line which is messing things up. I must admit I tend to add in specific programs using the hash rules as oppose to path rules as I've had more success with these personally, software restrictions has done some right weird things to some of my workstations in the past.

Mike.

Thanks for your reply.

I double checked all policies being applied, and as I mentioned before, the policies applied to both labs are identical. The group policy modeling shows the exact same for the two lab OU's. Extremely confusing. The only thing I can think of is that it's something to do with the image on those lab machines, and nothing server side. I just don't know what to check. I built the images all the exact same way, only making the software different on each one depending on what each lab needed. Extremely confusing, all other labs work perfectly with my test restricted user but I can't roll this policy out until I figure out how to make it work properly with the software installed on Lab 129. IE is literally the only thing I can launch besides Windows Explorer windows. Paint, notepad, other software installed on the machine in Program Files, all fail to run due to software restriction policy.

Makes no sense.

Hi,

Have had the same problem ourselves ever since we first deployed Software Restriction Policies. We use RIS / Group Policy to deploy machines and software, and the problem occurs entirely randomly even on two identically configured computers. So don't bother looking for a configuration difference, it's a Microsoft bug and I'm just amazed it's been around for this long.

The reason is that LNK is on the 'restricted file types' list by default, and while most of the time this doesn't seem to stop you from running the programs they link to, sometimes it does, and the best thing seems to be to remove the protection entirely. (The SRP rules will still apply to the programs referenced by the shortcuts, so I don't *think* it opens up any security holes in the process, although YMMV).

You can do this by removing LNK from the 'Designated File Types' list in the root of the SRP policy tree, and saving the policy, but this doesn't always seem to work properly either, and it's not easy to see if you've done it, so I just add a new 'Path' rule to every policy I create permitting '*.lnk' files to run. This seems to do the job and stops any errors from popping up on problematic computers. You may also want to consider enabling '*.url' files, as this is the Internet equivalent of a shortcut used in your Favorites folder, and if you've got an Web sites linked to in your Start Menu, they will be blocked as well.

Incidentally, the reason why Internet Explorer is working, while nothing else is, is probably because you are running it from the Desktop, which is not a 'real' .lnk file. You can tell this from the fact it doesn't have the little black/white shortcut arrow in the bottom right hand corner; if you try to start it from the Start Menu, it will probably be blocked. If not, it might be because the IE Start Menu shortcut is stored in the user's own Start Menu folder (%userprofile%\Start Menu) rather than the All Users start menu (%allusersprofile%\Start Menu) - this sometimes makes a difference as well.

Hope this helps, and if you get any luck reporting this problem to Microsoft let me know, but TBH the workaround is so quick and easy to do, and doesn't seem to affect security as far as I can see, that I've never bothered to.

Kind regards,
Chris Hill

Quote:

---

Originally Posted by Minkus

Have had the same problem ourselves ever since we first deployed Software Restriction Policies. We use RIS / Group Policy to deploy machines and software, and the problem occurs entirely randomly even on two identically configured computers. So don't bother looking for a configuration difference, it's a Microsoft bug and I'm just amazed it's been around for this long.

---

Hi,

Have done some more investigation, and as far as I can see the bug is more in the fact that you're sometimes finding that LNK files are *not* blocked, rather than that they are. My suggested fix remains the same - either remove LNK from the 'Designated File Types' list in every 'disallowed by default' Software Restriction Policy that you create, or add a Path Rule for *.lnk which allows them to be run. This seems to be necessary whenever you create a 'Disallowed by default' SRP policy, and there are other places that recommend one or the other of these options as well, including Windows IT Pro, which is a fairly reputable source. This last one also states that it's not a problem in Vista any more, so it might just be an XP thing anyway.

And just to confirm, this doesn't stop the programs which are linked to in the shortcuts from being blocked by the policy, just the shortcuts themselves, so don't worry about opening up a security hole either; we've been running it like this for ages, and our students haven't found a way round it yet.

Kind regards,
Chris Hill

Hi Chris,

Thanks so much for your help! I've implemented this change by adding just the *.lnk path and set it to unrestricted, and it works! No idea why this was just effecting one lab and none of the others. The part I find odd is it was exactly one lab of 10 computers, where all 10 computers were effected, and not a single other machine in the school was. Very strange. This fixed it though and has allowed me to deploy the policy now that it's working. No problems or complaints so far, which means things should be working and students should only be accessing what they're supposed to ;)

Thanks again!