The timer you describe is not common to the .EXE file OR the .MDB - it is a thing in your active workspace, which is a virtual-memory element on each computer.
I'll say something in passing and then address the other aspect of this question. You do not do yourself a favor by sharing a common database file with tables and other features in the same file. Having a split database is really a stability issue. The backend will be far more stable if it doesn't have the additional lock traffic associated with a shared (rather than distributed) front end. This forum has literally dozens of threads in which someone reports database instability, corruption, and incredibly poor performance related to having a single-file, shared copy of the database.
You say "single executable image" on a server, but I sincerely hope you don't mean that the way it sounded. If you are sharing Access.EXE, please be aware that there are license issues to consider even if you are using Terminal Services through something akin to Citrix. If you meant a "single .MDE file on the the server" and everyone actually has their own copy of Access, that is perfectly OK and a lot more stable - though still not at all the best way to run things.
OK, as to timers and having people immediately notified of an event that should "pop up" when some other event occurs: My original comment about workspaces is relevant here. NOTHING happens in the .MDE or .EXE file, whichever one it is that you share. All work happens in the copy of Access that is loaded to your system's memory.
Access creates a purely localized workspace for you when you open a database. Anything you do occurs in that workspace. This is true even if you are using Terminal Services, since there you get your own copy of a Windows virtual system in which to run your .EXE file.
When you open a form, you open it in your workspace. If there is a timer involved, it runs in your workspace. Since your workspace occurs on your machine and (at most) might have a component resident in your swap file, what happens in your machine stays in your machine. (Must be like Las Vegas?)
The ONLY two ways I can imagine to cause this pop-up to occur on everyone else's system is to either (a) establish active network links between all cooperating systems, or (b) put information in a place everybody can check periodically.
Implementing solution (a) is for network gurus and folks with serious masochistic tendencies. The WinSock interface is not that easy to set up from Access. Not impossible, just not that easy. Another part of your problem would be to know how to connect to everyone else in the connection set, i.e. knowing who is already there and getting them to acknowledge you.
Further, your system would have connections growing geometrically, which gets very big very fast. With five users you have 1 connection outbound to each of four other systems, or 20 connections total. (Each outbound connection from A is an inbound connection on another system, so I'll state it this way and avoid double-dipping.) Make that setup for six users and you have 30 connections. Seven users, 42 connections, and so on. (It is an n*(n-1) situation, statistically). You said 20 users. That's 380 connections. Your network folks will LOVE you for that one.
Solution (b), on the other hand, is very quickly and easily implemented by having a "common" table of critical information and just polling that table from a form-based timer. Be sure to use either the DLookup function or, if you do your own query, use optimistic locking. Then when you want something to happen, you store data in the shared table and wait for the Timer-based DLookups to catch it. (DLookup always uses optimistic locking, as far as I could determine.)
The timer and any pop-up stuff would be in your workspace, your memory, your machine. It will be cheaper in technology and cheaper in the time it takes to correctly implement this for you to define a holding table for your special notifications and update it when some kind of global update is required.
