You may be tripping one of Windows several heuristics to determine if an application needs administrative privileges. If it determines an application needs administrative privileges, it will trigger a UAC prompt. It's not perfect and not always right, but it's all in an effort for backwards compatibility.
One of the most common ones is simply by file name. If the file contains install or setup (and possibly update) then it will prompt unless explicitly told not to by means of an embedded manifest file. That's nothing you'll be able to change, the developer will have to make this change.
It could be writing to a privileged location, such as somewhere off
C:/Program Files or even a privileged registry location (specifically somewhere off
HKEY_LOCAL_MACHINE). A standard user cannot write (or even access in some cases) these locations, and as such Windows must trigger a UAC prompt for the application to function correctly.
You might check if there are any updates available from the publisher of this application. They may be able to provide you with an update that enables compatibility with Windows Server 2008. If not, maybe try contacting them and asking them if they're aware of any issues and see if they have a resolution.
This program could also be listed in the built in compatibility database as requiring elevation to function correctly. I'm not sure if you can influence this list or not, but you'd probably be best off with a more recent version from the software publisher that they have confirmed compatibility with Windows Server 2008.
It might just be that the app is old and does something weird that trips one of the heuristics. I had an application that I wrote that worked fine on Windows XP, but on Vista and later it triggered a UAC prompt. It did not read or write to any of the privileged locations I mentioned earlier. Changing no code whatsoever and simply recompiling it in Visual Studio 2010 (as opposed to Visual Studio 2005 that it was originally compiled in) fixed that problem.