I will have a look into your problem. Can I get back to you monday or tuesday?
To set up the new user account you have created, select 'User' in the Service Configuration tab in the Account dropdown list, and fill in the user name and password.
When you have installed the service you are prompted to fill in a user name and password (this is not always the case). This user name is only needed to install the service, not to run the service. The user name filled in on the Service Configuration tab is used to run the service. You can check this after the service is installed in the Microsoft Management Console Services program, the same program you use to start the service. Double-click the service and go to the Log On tab.
More information about the built-in users: http://technet.microsoft.com/en-us/library/cc782435(WS.10).aspx
The very cryptic message in the Event Viewer sometimes occurs when a .NET library is missing. Make sure the file 'MendixService.exe' is in the same folder as the 'Mendix Service Console.exe'. Do the folders 'x64' and 'x86' exist in this folder and contain these folders (one file each, just like the ZIP file containing the Mendix Service)? The file 'System.Data.SQLite.dll' has the same name in both folders, but it is not the same file!
Update: With help from tech support we have managed to get the installed service running, but it will only start if it runs as an administrator account which is not ideal.
All files seem to be present in the correct locations, so it looks like some sort of permissions issue. When trying to run the service as a non-admin user the misleading .NET error occurs. This user has full control of the Mendix application folder structure and has rights to log on as a service, but the service will not start. After adding this user to the Administrators group, the service starts OK. I'm guessing that the non-admin user has no rights to some system dlls that are needed.
Mendix are investigating further.
Have you checked out the file system security settings? On Windows 2008 you can use the tool 'icacls' to properly set the ACL's. I'm not sure, but it could be that 'icacls' is named 'cacls' in Windows 2003.
I remember there being some clues to the nature of the problem in the Mendix log file. I performed the steps below to get it to work. However, that was a version 2.4.5 installation on Windows Server 2008 R2.
icacls "C:\Mendix\Business Server\Production" /reset /T icacls "C:\Mendix\Business Server\Production\WEB-INF\log" /grant sa-mendix:(F) /T /Q icacls "C:\Mendix\Business Server\Production\WEB-INF\tmp" /grant sa-mendix:(F) /T /Q icacls "C:\Mendix\Business Server\Production\WEB-INF\uploadedfiles" /grant sa-mendix:(F) /T /Q icacls "C:\Mendix\Business Server\Production\i18n" /grant sa-mendix:(M) /T /Q icacls "C:\Mendix\Business Server\Production\web" /grant sa-mendix:(M) /T /Q