Skip to main content
T
TimBrotherhood1-Visitor
1-Visitor
September 22, 2010
Question

Security on high school networks

  • September 22, 2010
  • 1 reply
  • 2889 views

John Lee - UK Trainer emailed: "...the IT manager is refusing to install it on their network citing the batch file security issue..."

ProE needs to run scripts – If a school insists on blocking scripts they will not be able to run Pro|ENGINEER. This approach to network securoty reflects an ‘old school’ philosophy of preventing pupils from doing damage at all costs. It usually happens when IT curriculum leaders have abdicated their responsibility to educate pupils about the dangers of electronic communication and may also be done to reduce workload for IT support staff. Thankfully these schools are now a tiny minority. Most schools employ a more enlightened policy, supported by Becta, of allowing pupils more freedom based on a clear policy for IT usage and monitoring/sanctions to identify and deal with transgressors. This is more likely to keep pupils safe when they are at home, often with unrestricted and unmonitored access to the internet.

Schools wishing to maintain the block on scripts do have other options including:

  • Enabling Scripts only for pupils taking lessons that use Pro|ENGINEER.
  • Creating a CAD pupil profile that has scripts enabled. This can be issued to selected pupils in CAD classes in addition to their normal login. The CAD login can be withdrawn without pupils losing all access to the network. The disadvantage of this approach is the pupil sharing files between the two logins.
  • Pupils can only use ProENGINEER at home. Images, DXF, STL files can be brought into school for folios assessment and manufacturing.

    1 reply

    D
    DaleMahalko1-Visitor
    1-Visitor
    February 25, 2011

    I am the IT Manager for a small K-12 district, and while I don't restrict script usage, I do restrict all students to be "users" aka, not logged in as "Administrator" on classroom computers. Pretty much all programs work properly when run as a mere "user", though many older programs don't work.

    This is because older programs written for Windows 3.1, Windows 95, Windows 98, and Windows ME assumed they could always write anywhere, such as in the Windows directory, or in the program install directory. Windows 2000 brought the filesystem security of NTFS into play and imposed a stricter set of operating rules, generally requiring the program directory to be static and unchanging, and the Windows directory as off-limits.

    ,

    A properly written modern program will only make changes to user files within their user profile path, and within the user portion of the registry (HKEY_CURRENT_USER), so that those changes can propagate to other computers via roaming profiles.

    A program that tries to make changes anywhere else such as in HKEY_LOCAL_MACHINE, or in Windows or the program install path, is basically a sign of sloppy or "old school" programming habits.

    ,

    Also to better deal with these older programs that haven't been updated/fixed by the software authors, Microsoft introduced "User Access Control" with Windows Vista, for programs that are sloppy about writing all over the place.

    Vista and Windows 7 will "virtualize" these inappropriate writes so that they are allowed rather than denied, but the programs can't actually modify the local system. Instead these changes also get stored in the user's profile, which is the only place that is writable with "User" level security.

    Terms & ConditionsCookie settingsAccessibility statement