Well, you should not directly update the UI thread from the background code, but you can, of course, consider updating some shared memory to convey progress.
As a really simple example, if your code can be seen as a sequence of repeating steps, you can simply increase the counter. The Interlocked.Increment() method is especially useful for this purpose, since it does this without the need for locking. Then your UI thread can periodically test this counter and tell it the value - or visualize it if possible (possibly a progress bar or mid-level).
If several machines are involved, it makes sense to store the counter on the machine and report on how the general task goes through the participating peers. You can also consider visualizing the average elapsed time between completed steps ... which can help system users estimate the time to completion (and you could also figure this out).
A more complex implementation is also possible. For example, you can create a shared queue to which you post registration information or activity statuses. It can become quite complicated ... and if it is not implemented well, it can adversely affect performance.
Alternatively, if you want to collect a significant number of performance metrics from your distributed process, you might consider using the Performance Counter APIs in System.Diagnostics . This is a more complicated way, but it allows you to use a highly efficient implementation of the collection and publication of metrics in the OS and allows you to observe and summarize performance information with a tool such as Perfmon .
The specific mechanisms that you use to update the user interface depend on the technology you use (WPF, WinForms, HTML) and whether the distributed code and the user interface code have any components located in the same process. If parts of the distributed / user interface are not hosted in a single process, you will probably need to use some form of IPC to share information and visualize progress.