Task Manager problems

[Alc]

There are a few procedures that run when my Access database closes (backing up data, etc.). Since this can take a minute or two to finish (running over a network), one of the users here has started to use Task Manager to shut down the application.

This is not ideal, as the same user has also deleted the backend on more than one occasion. Should both happen on one day, we'd lose that day's updates.

Asking them not to do it doesn't work. Explaining why doesn't work. Telling them not to do it doesn't work. If I ask their supervisor to tell them not to do it, they just deny it. It's starting to look like the backup scripts aren't running, when they work fine for everyone else.

Is there any way of either
(a) Preventing them from doing this (unlikely, I'd have thought)
or
(b) Recording the fact that this has happened.

It doesn't necessarily have to be recorded in Access itself - although that would be ideal - if there's some other file I can access to get the info?

Any suggestions are gratefully received.

 

[Dennisk]

if you have a switchboard with a button to quit access you could append the user name and date/time to a table. then if task manager closes down access that user would not appear in the table.

 

[RuralGuy]

You also might consider doing your housekkeepping when the application loads rather than closes. It might be inconvenient but you have a captive audience that needs the application and will probably wait.

 

[Alc]

Thanks both.

DennisK - I do exactly what you say, at present. Unfortunately, my boss doesn't take the fact that someone is recorded as logging on at a certain time and has no log-off time as being sufficient evidence that they're logging off 'illegally'.

RuralGuy - That was my initial thinking, but I was told to run it at the end, on the grounds that most people start the close procedure running and go home.

 

[tehNellie]

You can disable the task manager in XP, but I'm not sure you can do it programmatically as and when required.

http://www.windowsnetworking.com/kb...ableDisableTaskManagerinWindowsXPHomePro.html

A quick search on "Disable task manager" in google should give you more information than I have time to browse at the moment.

That was my initial thinking, but I was told to run it at the end, on the grounds that most people start the close procedure running and go home

You could always just lie and say it runs at the end and that the "slow" start up is just initialising the floobles, making connections to floozles, reticulating splines and any other reasonable sounding mumbo jumbo you can think of. When in doubt I blame the network

 

[Alc]

Thanks. I'll look into that.

Like you say, it may not be possible to switch it on and off programatically, but it would solve my problem.

 

[tehNellie]

You could always smile sweetly at your windows admin and ask them to apply it to your problem user only.

 

[CraigDolphin]

Since the supervisor is clearly an idiot, simply deny the person access to the db and then deny that you have denied the access if asked.

Alternatively, install a keylogger on the machine with the supervisor's permission to prove your case. Maybe something like this...
http://www.freedownloadscenter.com/Utilities/Misc__Utilities/Actual_Keylogger.html

 

[The_Doc_Man]

OK, first things first. You will NEVER get a stupid supervisor to agree that anything is wrong with their people until you rub their noses in it. So...

BEFORE you do the closeout stuff behind the scenes, make a log entry to an external file, opened in VBA, for append, showing date/time at which this user started the shutdown. Close the file IMMEDIATELY. THEN make a second entry a couple of minutes later showing that the shutdown is complete. Again, close the file IMMEDIATELY.

Put the shutdown file in a sub-folder on the server where you DB is located so it isn't "in their face" when they open the folder with the DB. AND despite many Access security requirements, it IS permitted that in a sub folder you would deny them DELETE access to some or all files.

I believe there is an advanced permission that would allow a user to INSERT TO but not UPDATE or DELETE FROM a given file. Get your security manager to help. I'm not 100% certain but I believe that the server's event logs will capture an attempt to delete a file when the attempt fails due to permission settings. So if someone attempts to kill this log file you will know about it. I'm not sure whether that counts as a network event or a security event when the delete request comes through the network.

When you take this approach, everyone should have two entries in your shutdown logs. When you find someone who does not, take the time of that entry and talk to your security manager to find out if there is an EVENT, APPLICATION, or SECURITY entry for that time of day on the user's workstation relating to a Task Manager shutdown of an application. This is much easier if your user's aren't also the administrators of their own machine, but some sites take the easy way out on that one... If they are not the machine admins, then they probably cannot clear the event logs and that works in your favor. Anyway, that entry in the event log plus the oddball entry in your shutdown logs will be your evidence of someone doing an unkind and illegal thing to your database.

Second, as to deleting the BE, ask your security manager for help in this one. Set an AUDIT ACL on the BE file so that if anyone deletes it, you will get a silent entry in the security log. Then when you lose the file, talk to the security manager to get a printout of the log for the appropriate time. The entry will give the network name of the person performing the delete. This will be your evidence for someone deleting the BE file.

Now, the next part is trickier, but MUST be done. You say that you stand a chance to lose a day's worth of work. Whoever sponsored this database MUST own up to the need to protect it AND issue some official statement about the importance of the DB to company operations. And the cost when data gets lost because of improper use of the DB.

Then, armed with the manager's signed statement of importance and logs showing whodunit, approach the perpetrator's supervisor with your evidence. Tell the twerp in no uncertain terms that you will disable the perp's access until the twerp and the perp talk to your manager about lost time and effort due to lost transactions.

Obviously, if this database is important enough to the company, you will get results. If it is not, then you have learned something useful as well. But I can assure you that if there is value in the work done using this DB, then you will have evidence that someone cost the company the money equivalent to the salaries of those whose day's worth of transactions got lost because of a stupid user who knows just enough to be maliciously dangerous.

Now, if this persists, there is always the death-knell approach...

Keep a table in the database somewhere that tells who left the database properly. Update that via recordset operations at the start and at the end of the post-processing routines. If a person tries to come in with a record that says "You left the database improperly - cleanup is needed. Go away and try again later" then they will get the message.

In summary, the ONLY way to solve this kind of problem is to be willing to rock the boat until someone falls out. If it is YOU, then it was time to find a new job anyway. If it is the perp or the twerp, congratulations.

 

[Alc]

*Whew* Lots to take in, there. Thanks very much.

I'm hoping I can resolve it without recourse to netwrok security as they aren't the most helpful people, but I shall definitely bear it in mind.

As far as the following is concerned, I already built it in (guess I'm not as dumb as I thought)

Keep a table in the database somewhere that tells who left the database properly. Update that via recordset operations at the start and at the end of the post-processing routines. If a person tries to come in with a record that says "You left the database improperly - cleanup is needed. Go away and try again later" then they will get the message.