What determines your USERPROFILE Environment Variable when launching a .NET app

Question

I have a .net/C# application when launched on a test server running VMWARE / Windows Server 2008, receives a USERPROFILE Environment Variable pointing to C:\\windows\\system32\\config\\systemprofile, but other applications seemingly built in a similar fashion inhert the correct value of C:\\Users\\{username}.

A slight twist - the application receives the correct value when run locally on my development machine. So I'm thinking this is a profile/registry issue with some combination of setting in my app.

The issues is manifested when you attempt to open an OpenFileDialog or similar. You get the exception "Location is not available: C:\\Windows\\system32\\config\\systemprofile\\Desktop refers to a location that is unavailable..."

Any ideas?

UPDATE: The application is WPF running web services against IIS via WCF. Locally in development I am using IISExpress. I've found that after touching the WCF services in the client, the application inherits the APPDATA and USERPROFILE of the IIS AppPool the services are running under. If I adjust the AppPool values to use my user account instead of ApplicationPoolDefault and set LoadUserProfile = true - things work. Obviously this is a bad thing. As an alternative, I cache off the environment variables when the WPF app runs, and after it initially connects to WCF, I reset the variables. This appears to get around the issue but I'd like to solve it a better way but I have no idea what is influencing this behavior in WCF and my IIS Services.

Answer 1

It might have to deal with what account the web app is running under in IIS. You can change it from the default "Network Service" account to an actual user account.