[sims] S:\ drive permissions.

[vikpaw]

Well after waiting several weeks for a reply from our LEA this is the response on how to secure the S:\ drive permissions:

We have now received a response from Capita and they are recommending full control for the whole drive for SIMS users. See below:

 

That is crazy! Over 8 years ago a learned gentlemen said this was not the case : http://www.edugeek.net/forums/mis-systems/27971-sims-ntfs-permissions.html#post264872

 

I always used to set full control for everyone on the share, and only read / execute on the folder using NTFS perms for staff. @localzuk has a great guide for then granting specific users/groups edit rights as required.

 

I'd say in addition look at the Nova folders for timetablers and also the folder where Cover is published.

 

Edit: @Linfit covered some other folders. So Nova and Attendance folders too.

 

Exams was always a tricky one.

 

The best thing to do is start restricted then get power users to test and see where they need additional access. After years of the same setup, when I finally restricted it all, it was very minimal the amount of additional permission required.

Edited February 23, 2017 by vikpaw
corrections / clarifications

[PhilNeal]

I agree this is highly suspect - I will post as soon as KB has been updated.

[PhilNeal]

I've reviewed the revised advice but asked for it to be simplified.

 

In essence an "ordinary" user of SIMS will not require access to the directory containing the database. Certain actions cause a file to be produced and will require write access to the destination directory e.g. cover writing the HMTL output or the Census output for DfE etc or writing orders to disc.

 

Apologises for taking longer than I had said.

[vikpaw]

I think what people want is a list of those exceptions, so they can easily set up groups and not have to either allow really relaxed permissions or lock it down then spend time working it out on request when things don't work.

[PhilNeal]

@vikpaw - agreed that is what I expect to be getting.

[vikpaw]

@vikpaw - agreed that is what I expect to be getting.

Awesome.

[minimoo]

@PhilNeal - I think you've probably got two different audiences. The audience on here of mainly technical people (who would probably understand the non-simplified version) and then those who are more "office staff" in a primary school for instance. We've got data going back to Star for DOS - which may be safe to delete mixed in with the stuff I know is still used (e.g. your cover example). To that end I'd rather have non-simplified advice that was more explicit as it would allow us to start to tidy up and remove the old star data.

 

[and I think i've just repeated what phil/vikpaw got in first with]

[pete]

^ While you're in a documentation mood @PhilNeal, I'd love a "So, you've been running SIMS since 1993* and have no end of gunk in your SIMS share that you're 99% sure you don't need, but....." guide.

 

*yes really, there's dbase stuff lurking in there.

Edited February 28, 2017 by pete

[vikpaw]

@pete I fixed that by doing a new clean install and only copied over folders that had recent access or would be listed in the new guidelines we're about to receive.

[pete]

^ I've tried that in past migrations and usually discovered someone's still using a SIMS bolt-on that doesn't use $random_folder, but does check it exists.

[vikpaw]

And they probably require you to hardcore a Lan ID right?

[pete]

^ Nothing quite that bad, though our old FMS database (we moved to something else years ago) is technically still required for financial audit purposes. Said auditors will definitely not be getting biscuits with their tea should they ever request access to it.

[PhilNeal]

KB119975 is being updated. Attached is the version that is being worked up into the KB.KB119975.docxKB119975.docx

 

I hope this clarifies things.

[minimoo]

@PhilNeal - some quick feedback - as it's quite a long document:

 

1) First off - really nice - this is the sort of thing that I think people are after!

 

2) The list on Page 1 of permissions misses: a) Nova-P uses need write access to S:\sims\snova\novap (or equiv) b) NovaT6 users need write access to S:\sims\snova\nt6 and S:\sims\snova\transfer (if you want to use that as default transfer directory - i think this dir can get changed so could just be my docs), c) options to S:\sims\options

 

3) In terms of must have permissions to c:\windows\temp - really???? pretty sure we don't give any staff access to that folder with full control and never noticed any issue

 

4) In terms of c:\windows\sims.ini - same - We never have given write access to that - although granted if you use an old sims.ini module you need access but afaik that only applies to the old BDE apps now

[vikpaw]

I think sims.ini has some shortcuts / last used info that is updated by finance and Nova users. Not sure if it's still relevant.

[PhilNeal]

I'm not qualified to answer questions but will pass them onto people that are!

[mavhc]

For people locking down systems with SRP, AppLocker etc:

 

can you also confirm if any folders other than c:\program files and c:\program files (x86) need executable access? And if SIMS works with the SRP registry entries for those folders, or still needs them specifying manually?

 

I hate it when update programs try to download to a temp folder and execute from there

[vikpaw]

If you update with SOLUS 3 that should have the necessary perms.

[minimoo]

For people locking down systems with SRP, AppLocker etc:

 

can you also confirm if any folders other than c:\program files and c:\program files (x86) need executable access? And if SIMS works with the SRP registry entries for those folders, or still needs them specifying manually?

 

I hate it when update programs try to download to a temp folder and execute from there

 

Pretty sure the answer to that is no in terms of exectuable access - although i'm not sure what you mean by registry entries for SRP.

[minimoo]

I'm not qualified to answer questions but will pass them onto people that are!

 

Thanks and @PhilNeal - another one - that word document doesn't reference the advice given in KB72329 re PDOXUSERS.NET file and FMS

[mavhc]

Pretty sure the answer to that is no in terms of executable access - although i'm not sure what you mean by registry entries for SRP.

 

http://www.edugeek.net/forums/windows/170245-list-things-break-when-using-srp.html#post1458073