ajbritton

%USERPROFILE%\Favorites is correct.

If you are talking about removing the 'execute' NTFS permissions then I don't think it will work. If a student is able to copy a file into their home folder then as the creator of the file, then implicitly have the permission to change the permissions on it. That means that although the file may inherit a set of permissions that does not include the execute permissions, the student cannot be prevented (other than by hiding the interfaces) from changing the permissions on that file.

... by which I mean that the original film is a classic and the remake a big smelly pile of poo.

Rather than trying to block particular locations, it can be easier and more secure to just allow the locations you want executables to be launched from (eg C:\Program Files, C:\Windows)

I've used them a couple of times over the last few years and have had no problems.

Use SRP to restrict access to COMMAND.COM and CMD.EXE. No problem. Use permissions to restrict access to private information. No problem.

What?!?!?! I can't believe this is even a serious question?

Is there something specific that you are worried about them doing on the network? If you are trying to prevent them from executing unauthorised code then software restriction policies are the only watertight way of achieving this.

Assuming your user accounts are 'standard' user accounts, then they cannot do any damage on the C: drive anyway. What's the problem?

If you are logged on to the server as Administrator, then mapping an S: drive will have no effect whatsoever on any other users. Drive mappings are 'per-user' settings anyway so a manual mapping would only affect the user account you are using on the machine you are using. I would say that it would be worth checking the contents of the registry key that I mentioned. If nothing else, it will remove it from suspicion. Another way forward would be to ramp up the Windows Installer logging level and run the installer again. The resulting log should give a better indication of where the problem is.

I have to say that I too was mildly irritated to receive a notification about the one event that surely everyone on this forum knows about anyway. I'm reassured by Tony's comment however.

The Pro version does give you quite a lot more. If you are planning on creating a lot of packages, the conflict management/detection facilities are very powerful. Also, the Wise Script Editor, which does not appear to be in the Std edition, can be very useful. I've used the Pro version and been more than satisfied with it. Having said all of that, there is no such thing as a foolproof packaging tool. I've created a lot of packages for education software and I would say that at least 95% of them have required tweaking in some way to make them work properly.

It certainly shouldn't be the case, but it is. When the SIMS client updates itself on a PC, it also writes files to S:\SIMS\... This is a major bug in my opinion and I've raised it with Capita on a couple of occasions. If access is limited to Read only, the error messages appear, usually relating to a PDF file which the update routine is attempting to write to. You should certainly limit access by using a specific group rather than using Everyone though. The simplest approach is to create a SIMSUSERS group and add the appropriate users to it and then use it to grant Modify access to S:\SIMS.

That error looks like it's from Windows Installer. When Windows Installer runs, it verifies the existence of certain Windows 'special folders', such as My Documents and the like. The paths to these special folders are all stored in the registry at the following location; HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders By default, all the values are set to %USERPROFILE%\......, but if you are using roaming profiles and the like, maybe one of them is pointing to S:\... If that's the case, you have a simple choice; 1 - Revert the registry entries which reference the S: drive to the appropriate location under %USERPROFILE% or 2 - Map the appropriate drives so that all the paths mentioned in the registry actually exist. I attach a registry fragment which should reset the User Shell Folder values to the defaults (from an XP laptop anyway). Once you've done one of these, the installer should run OK. user_shell_folders.reg

I've tried it and although it usually works, it's not perfect.

Many thanks PiqueABoo. I don't have time to actively develop the script right now (and I think there are far more skilled developers here anyway...), so I've posted what I've got so far. The script needs SQLITE3.DLL (download from sqlite.org) and DSWIN32.EXE (which appears to work perfectly) and GDIPLUS. I've found SQLite Expert Personal to be very useful for working on the SQLITE DB. The script defaults to using BugLog.DB3 in the same directory as the script, but can be redirected using the INI file. The same goes for the target directory for screen dumps. buglog.zip

Can't you use Active Directory Migration Toolkit? This will drag the passwords from the old accounts into the new accounts and you will never see them.

You should not have to extract the contents of the MSI package to edit an INI file. The MSI file contains an INI table which holds all the settings for all INI files that are created or edited by the package. You can edit this with ORCA.

I believe AutoIT has that functionality built in. If not, I suppose Blat would do it. It would have to be via SMTP though.

@PiqueABoo: Thanks for the posting, but I should probably have mentioned that the estate of machines I need to run this script on are quite old. They will be Win2Kpro PCs with as little as 128Mb and almost certainly no .NET framework installs. I've got a work in progress for the reporting script. At present, it does the following; 1 - On loading (at user logon), it records the computer and memory details on the SQLite DB. 2 - Creates a tray icon and sits in the background waiting for user to trigger it. 3 - When triggered, prompts for a description of the error and then logs this along with another memory status snapshot in the DB file. When I've knocked it into shape a bit more I'll post it.

I'm working on an AutoIt script which reports back to an SQLite DB at a network location. If anyone knows of a scriptable utility that can take screenshots (freeware of course), let me know and I'll try to include it.

I'm looking for a bug reporting script which will do the following; 1 - Ask the user for a description of the problem 2 - 'snapshot' the environment (process list, cpu config, memory etc) 3 - Either email the lot to a predefined address or store in a central DB I can probably knock something together myself in AutoIt, but there's obviously no point in reinventing the wheel. Has anyone seen anything like this?

I've note tried it, but Password Filter DLL looks like it might be of use. It's a generic Password Filter that calls a user definable script on password change events. It should be a simple matter to look up the username in AD, check the OU the user is in and... well, you can guess the rest.

That would certainly work, but it's not a particularly scalable or flexible solution. IMHO, the best way to do this would be to use the filtering, but rather than putting the user account in the DACL, I would create a group, whose name matches GPO that contains the script and add the required user(s) to the script. I try to avoid adding users to DACLS for one simple reason. When the user account gets deleted, the DACL is left with a reference to a non-existent user account. When you look at the DACL, all you see is the GUID/SID reference. You'll have no idea who/what it refers to. If you use a group of course, the group will still be there. When you want to get rid of the group, rather than deleting it, remove all the user accounts from it and rename it as UNUSED_(old group name).

I did search the forums for 'Active Directory Explorer' and found about 2000 hits. I checked the first page of hits and could not see anything with Active Directory Explorer in the subject so I went ahead and posted!