gerardsweeney

Oo-er, Missus. Sorry - couldn't resist (really wish you had tried! Ed) Seriously, though... Good to see da bosses are trying to get the line toed a little

If it's of help, my install of Rigolo1 (local) does the following: msiexec /i "blah\Rigolo 1.msi" subinacl /subdirectories "C:\Program Files\Nelson Thornes\Rigolo" /grant=users=c subinacl /subdirectories "C:\Program Files\Nelson Thornes\Rigolo\*.*" /grant=users=c Completely lazy, I know, but time was short and it was easier than finding out which files actually get written to Cheers, Gerard

If you mean the old "needs 3Mb of memory" thing, then there's a way to fix it without modifying the PC.. Here y'go: http://www.edugeek.net/forums/educational-software/19605-really-old-projector-macomedia-program.html#post427051 Takes about 2 mins assuming the Director file follows the same format (which dozens in our assorted schools seem to do) Regards, Gerard

Who knows? They might actually go with my plea for an automated email or RSS feed.. I guess if enough folk badger (badger badger, mushroom, mushroom) them...

Cool - I'll need to have a word with our AD bod (I am but a humble desktop tech). Thanks for all of the replies, folks. Gerard

Yes, we use that... However, the problem stems from our XP install method.. Or - at least it seems to From what I can gather: if you install XP from CD, and allow ITS installer to do the partitioning and formatting, then C:\ is marked as read only. The method we use to build a new PC is to deploy a blank NTFS partition, and then run the setup. This removes the stupidly long time it takes to format 300Gb However, it appears(!) that if you use this method, that XP's installer adds a Special Permissions bit to the drive, which lets them create a new file/folder in C:\ They don't need to be able to SEE drive C: - the installer will quite happily let them type it in. I suspect the problem lies with the original NTFS image - we basically chucked a drive into a USB caddy, formatted it as NTFS, shoved it back into a desktop and imaged it. I'm guessing Windows added the Creator_owner bit at that stage. The write access doesn't carry down... For example, they can't write to C:\Windows or C:\Drivers, nor can Pupil1 write to a folder created by Pupil2 - but they can create C:\BLAHBLAH and install a non-registry-editing game to it. Hope all of that makes sense

JJonas - Yep, I'd been doing that before I found how to stop them. The Librarians/teachers didn't seem that bothered, so there was no - shall we say - incentive for the kids to not do that. storkyIV - Yes, My Computer has drives masked. However, installers of things like portable games will cheerfully let you install to C:\ by manually typing in the path, and then display a final dialog with "Launch gameyoujustinstalled" afterwards cookie_monster/Dos_Box - Yep, we use AD but I was under the impression that doing this can have a knock-on effect of overwriting other NTFS permissions already in place... Say, for example, we need them to write to C:\Windows\IniFileForAProgram.ini (kind of idea) Cheers, Gerard

Hello, all.. In case anyone is ever faced with the same problem, I found the solution on SETACL's discussion forum. https://sourceforge.net/projects/setacl/forums/forum/235314/topic/2190447 setacl -on "c:\\" -ot file -actn ace -ace "n:%COMPUTERNAME%\users; m:revoke; p:add_subdir; i:sc; w:dacl" setacl -on "c:\\" -ot file -actn ace -ace "n:%COMPUTERNAME%\users; m:revoke; p:add_file; i:sc,io; w:dacl" Regards, Gerard

I know this is an old thread, but just in case anyone else stumbles upon it.. There's actually a pretty easy way to fix a lot of these scabby old Director files - I've used it to fix about 20 of the things in our various schools.. Original source: sacah: How to edit 'Director Player 6.0' and 'Director Player 5.0' to stop '*mb of free virtual memory' error on XP/Vista Edited version from my notes for my colleagues to use: If you get the following when running an older application on a PC with 1Gb+ of RAM: --------------------------- Director Player 6.0 --------------------------- This program requires at least 3MB of free virtual memory to run. --------------------------- OK --------------------------- Here is how to patch it, rather than changing the virtual memory. Download XVI or another hex editor Load the START.EXE (or whatever launcher filename is) into the editor CTRL F Check "Hex string" Search for either 7D 6E BE 80 or 38 00 7D 6E or 20 75 38 00 7D including the spaces. Click no when asked about a case sensitive search. The whole string found should look like: 7D 6E BE 80 00 00 00 8D 85 E0 FD FF 7C FF FF FF 3D 20 75 38 00 7D 6E Double click on the "7D" box, and type in 7E and hit return. Now use File, Save as, and save it as START2.exe (or something similar). EXIT XVI Try running your newly created exe. For Director 5, I got it to work by searching for 20 75 38 00 7D and changing the 7D to 7E MUCH easier than faffing about with Virtual memory. Regards, Gerard

Hi.. Sorry - that didn't seem to work (bah!).. I made the permissions change, but it doesn't seem to have worked. Looking at the permissions for C:\ Under Advanced, Users and Everyone have "Create Folders/Append Data". So far, it seems Subinacl and/or cacls don't overwrite this - unless I'm missing a particular switch, of course?!?! Regards, Gerard

Hello, all.. We have our systems formatted as NTFS (took us long enough!!). One of the things I've noticed is that while pupils can't write to (say) C:\Program Files, or to existing folders in the root of C:\ they ARE able to create their own folder and then write to it. This is allowing the little bugg - erm - darlings to install portable versions of apps/games to C:\ I'm assuming(!) that there's some easy way to fix this with NTFS and Subinacl, but for the life of me, I can't find it. Any chance some kind soul can help me out here? Regards, Gerard

jzepeda... This part is lifted from: appdeploy.com]packages]detail.asp?id=1482 (replace the ] with /) (I can't post URLs) by AngryTechnician To deploy the .msi package using Group Policy, a minor modification is needed. If you attempt to deploy the original .msi, you may receive the error message "Unable to extract deployment information from the package. Run validation on the package to ensure that the package is correct." This appears to be because of erroneous data in the Languages field in the .msi Summary Information. I had to open the .msi in Orca, go to the "View" > "Summary Information menu", and edit the Languages field so that it only contained 1033 (the language ID for US English). Only then would it successfully deploy. Alternatively, I use: msiexec /i "Google Earth.msi" TRANSFORMS="1033.mst" - don't know if that's applicable to GPO (we don't use that). Any help? Gerard