Hello. How can I ban the access to OI for all users from all applications? (to make a technical verify) Thank you.

Rename the OINSIGHT.exe temporarily. Perform your verify. Afterwards, rename it back again.

Another way is to perform your verify at night, when there are no users in the system. It's pretty much like a backup in this respect.

Another way would be to verify a restored copy of the system backup from another volume.

This works great if no users are already logged in. Is there a low-overhead method that could be used to force a user to log out due to a sys admin command or setting?

I am thinking that a post index process could check a table column for 'logout' true and then log out the user. If then the user tried to log back on, the logon item could check the table column for 'logout' true and again log out the user.

Best to do this without posting a message to the user. They'll call anyway, so what is the point!

This seems like I have to plan ahead - anyway to force this NOW, with no prior programming effort?

Does this seem like the best method to you Steve? Seems too simple, so I fear I am overlooking something!

Steve is correct here .. easiest way is to rename oi.

Once you get your system stable you might want to create a routine which sets a flag that all users check periodically. Then have it auto shutdown or warn or ..

Makes admin a little easier.

[email protected] onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

DSig's Radio Free Oregon

David Tod Sigafoos ~ SigSolutions

Ralph,

I can't speak to the OI32 aspect of it, but I am in the middle of implementing a "global messaging system" like that in ARev. I am pretty much taking your approach, where there is a replace-index process that will check a table for global messages that need to be displayed. I am also providing a "force logout time" so that the system will automatically log the user out after a specified time.

I am developing this so that I can gracefully boot users out of the system if I need to do an index rebuild or some other process where I don't want anyone else in the system.

[email protected]

Greyhound Lines, Inc.

I've worked on many 24/7 systems or at places where they wanted the place empty except between 9-5pm, or at really large places. In such cases you have to automate the logoffs. For OpenInsight I've previously used a VB executable (hidden/invisible) on each workstation that closed down OpenInsight in response to a sockets-based broadcast. Quite easy. Except where indexing is active from a workstation.

S/Web from Sprezzatura provides such centrality to the processing - such that you simply have to shut down the Web services to get full control.

There are other issues with OI - such as XREV.DLL and OICGI which can support sessions independently.

It all depends on your architecture - you're all correct - you need to design the centralized shutdown into the application.

Steve

Excellent tip! It seems that the invisible VP (or other kind of app for that matter) could be the 'launcher' for OI too. It could deal with the Xrev.dll and the oicgi shutdown too I guess, right?

We have delayed our plans to switch over to the Universal Driver, since we use the LH-IPX data (that the NLM_STATS command also appears to use) to track users and activity on our network. Without knowing how to do this with the IP based UD, we lose this capability. BUT using an external application sounds like a reasonable work around, if it could report on own most critical activity needs.

Ralph - had this problem with midday backups at another client.

We use a small VB6 utility to trace the people who are in and out of the application, and write their user name as a file in a path - updated every 10 seconds. We can then ring the phone extensions of those people from the IT room.

It can be configured (via a command line parameter) to nominate the application to trace. The utility tells you who is still in the application. It also is invisible to the end user while it runs on their workstation (from the startup group).

So perhaps blocking access isn't the issue here. Perhaps tracking who is still in the application will suffice.

Steve

[email protected]

View this thread on the forum...