As you have determined, you can periodically poll using AJAX to see if you need to refresh. If that doesn't sound good, you could try a COMET approach, which involves opening a request that both the client and server keep open, until the server has a message. At that time, it would send a message with whatever instructions you wish (like reload this page) and end the connection, where the client script would then do something with that message. A practical example of that is how Facebook handles notifications. The net result is your server experiences less traffic, and users experience a magical "instant" response at the client. On the other hand, this approach requires proper construction and tuning on the server and in your application, as keeping lots of connections open can create problems.
There are some ASP.NET modules for implementing a COMET solution (and Signalr sounds like one of such solutions), but I wonder why the polling option is so bad if you're only using it on the intranet. You don't necessarily have to poll in several independent areas in your client; you could have one notifier (this is all in JS, mind you) which takes subscriptions from other components, who submit specifics on what things they want you to check on. Then poll once over AJAX to some MVC action with a message containing all relevant subscriptions. I don't imagine that being a big network buster, as I have an application that does that on a pretty fairly large scale.
On the server side, your action would parse that message into jobs, check on each one as requested, and send a response message, if there's anything to do. Then your client notifier receives the message and sends the results to any subscribers if there's anything to do (a trivial example: refresh the page, or more appropriately, refresh a section of the page that has changes... you can use JavaScript- preferably through jQuery- to replace the contents of an element with HTML retrieved from your MVC action to change the contents).
It may sound complicated, but it's not really, particularly in comparison to managing a COMET solution, and you can do it with off-the-shelf technology.
The Silverlight technique you mentioned sounds like using a WCF duplex service contract using a dual HTTP binding, which would allow the server to initiate requests to the client. It's certainly an option, as you could have a Silverlight notifier app, similar to what I mentioned earlier, sitting in your page, taking in subscribers, and receiving push messages from the server. I've not had a chance to implement a duplex service in an actual application, so I don't know how practical it is in a production environment.
