I can quickly think of 3 solutions right now.
Use a simple text file to store state informations. Write it with your Windows Service, and read it from the ASP.NET application. PRO: extremely primitive and simple to implement, and has minimal overhead. CON: If the state query gets more complex, the implementation can get more complex quickly.
Use a shared database to store these informations in a specific table. PRO: More platform independent solution, can be queried from anywhere; easier to maintain or extend. CON: bigger overhead.
Implement a very simple WCF service, host it in your Windows Service, and query it from anywhere for state informations. See more info here. PRO: easy to maintain or extend in the future. CON: harder to implement, expecially if you don't have any WCF experience; it's a bit too big gun for only simple state information.
On the client side the best and simplest approach would be IMHO a periodic tiny AJAX request to poll the state information from your web application, and present it to the user.
UPDATE
If you want to poll the service from ASP.NET MVC application periodically in the background, check WebBackgrounder project. However, I don't think it's a good practice to follow unless you really need to due to some special needs.
A better approach would be to serve this information when it's needed, when a request comes for it in some Action of some Controller. You can also apply ASP.NET caching to it if it is requested too frequently. Then on the client side you can do the periodic request via AJAX.
UPDATE2
If you don't like the periodic AJAX requests, you can check out AJAX push technics, for example here. I don't have any experience though, and cannot give you more points. I still believe that a frequent polling could be satisfactory, because these would be really tiny data transfers I guess.