application fails after joining PC to domain

Hi All,
I have a very frustrating problem that we cannot pin down.
I have a small business2003 domain with 10 pc's and 5 macs connected to it. The PC's need to run an ASP.NET application that runs a time sheet and estimates program all the domain users need this to keep track of jobs work flow etc.
The app runs on the server and then there is a client that runs on the PC's.
The app writes the new documents to a shared drive on the file server
This worked fine whilst the PC's were all part of a workgroup but we recently joined them all into the domain.
The application now launches fine and allows the user to look at the jobs etc recorded on the system, however every time the user tries to create a new job it crashes. Creating a new job involves opening a word document and then saving this back to the shared drive.
This now always fails.
If however the user logs off and then logs on again as an administrator the process works fine.
To get round this I have created a small C# 'wrapper' that runs the application as an admin but this is not a good solution.
What could be going on on the domain?
I have allowed anyone to write to the the shared drive in desparation so now there really is no security on the drives.
This is proving to be a big problem and I need to find a better solution than my ugly hack
I realise I am being somewhat vague here but I am rather lost.
To recap.

Since joining the PC's to a domain the app fails.
The ap only runs as an administrator why?
I am pretty sure it is not network permissions.

This is the fix currently in place but it does not always work
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace CherryWrapper
    class Program
        static void Main(string[] args)
            string pw = "password";
            string path = "C:\\Program Files\\Cherry\\Cherry.exe";
            string user = "administrator";
            string dom = "CHERRY";
            System.Security.SecureString password = new System.Security.SecureString();
            foreach (char c in pw.ToCharArray())
            System.Diagnostics.Process.Start(path, user, password, dom);

Open in new window

Who is Participating?
tim_storeyConnect With a Mentor Author Commented:
I have fixed the issue and it was in fact not anywhere near as complex as I thought....  

Sadly it was a "doh" rather than a "eureka" moment!

The problem lay with application pools, so for anyone else this is what it was.

Under IIS6.0 the worker process runs in an application pool, which has a user identity which is by default the network service account.

This account is a member of the IIS_WPG security group which ensures it has  just enough permissions to run the site and access directories the relevant directories, but NOT anything else.
Hence the application failing whenever the worker process tried to write to the network shares in question....

To fix....

Create a new user.

Add this user to the IIS_WPG group (this means the has the needed permissions to create a background thread access the directories etc)

Add the new user to the network shares etc and grant it enough permissions.

Create a new application pool and then configure the new application pool to run as the new user.

Associate the website with the new application pool.

Restart the pool (you need o do this other wise the application pool will not cache the new user details)


there is short tutorial on this here....

Thankyou all for your help
If it is ok to make your user admin on his PC (not a domain admin) then add that domain user to the local admins group and check it out , it might work though ,,,
tim_storeyAuthor Commented:
don't want to have to do that there are getting to be too many users and they cannot all be trusted.
Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

Steve BinkCommented:
When joining a domain, the local computer is secured according to the domain's group policy.  My guess is that your app is requiring a write permission that exists on a local PC, but is locked down once it is filtered through GP.  I assume when you say "it runs as administrator", you're referring to the local PC admin, which means you're logging on to the local PC and bypassing your GP.

If the problem is solely related to writing to the share, remember that permissions are broken into two groups - share and NTFS - and the final permissions are the intersection between those two.  That means that if you have no permission in NTFS (or "deny", which trumps "allow" in all cases), it doesn't matter how much permission you provide in the share - NTFS will lock the user out.  The vice versa also applies.  This may be as simple as allowing writes for the domain users group on the share, both in the share permissions and NTFS.

Go download process monitor:

That app will help you find out exactly what permissions are lacking, causing your program to crash.  You may need to run it concurrently on the client and server to figure out what is being denied, and it may not even be related to the share.  It does require a bit of digging, since the app suffers from TMI, but I have found it to be an outstanding investigatory tool.  

A user running a .NET program may need modify permissions in some strange places.  For example, with ASP.NET, I've seen some apps requiring modify permission on the web.config file, even though nothing is ever changed by the app.  I'm certainly not a .NET guru, but you can usually find a clue as to what is missing and stumble forward from there.
tim_storeyAuthor Commented:
thankyou routinet, yes I feel it something to do with this.

But sorry to be dumn what do you mean by NTFS permissions?

Also the app will run as either a domain or a local admin if that gives you any further clues.

I will run the sysinternals and see what I get.

I am asuming it is write permissions as the application only falls over when it calls out to word to auto generate a doc, as I do not have the source code and the writer is being unhelpfull I have no idea wether this write is somehow local or on the network share that the document ends up on.
where your application is trying to create the word document ( including any temp directorys if it uses temporary directorys ) it will require the relevant NTFS permissions for your application to do what it is doing with regards to reading / writing data from and to the hard drive so if you have specified for it to write data into


Then the folder

my_word_document will need to have the relevant permissions for the app to read and write to the folder and if you give the user ( if its one user ) or mutliple users to read and write to that one directory ie full control to be able to read and write to that directory then the application should work fine.

To check the persmissions on the directory right click on the folder --> properties --> security tab and ensure the relevant users have the correct permissions.

As per above the NTFS and share permissions have to be set correctly on the correct directorys / paths for your app to work correctly under a restricted user account
tim_storeyAuthor Commented:
Oh I see well all the users have full permissions, thats the odd thing.
So I am wondering if it is a systems account (perhaps the asp net account) that does not have the right permissions.

Working on that logic I assumed that the app was running on a pc so perhaps if I added the PC to the network share this would fix the problem.

Alas not, still the same fail whenever the application tries to create a document.
slightwv (䄆 Netminder) Commented:
Oracle DBA here so be warned.  Just here because of the call for help.

We had a few .Net console apps that had problems with mapped drives in a domain.  Our developer, who is now gone so I can't ping him, did some magic with caspol.exe and it cleared everything up.

Hopefully some of the other experts know more about this program.

Check out:
tim_storeyAuthor Commented:
Hmmm... ok I will look at that
Steve BinkCommented:
>>> But sorry to be dumn what do you mean by NTFS permissions?

I mean the Microsoft proprietary file system called NTFS.  When you right-click a directory in Explorer, select "Properties", and switch to the "Security" tab, you are looking at the NTFS permissions for that directory.  It is also called an ACL - Access Control List.  NTFS permissions allow or deny manipulation of resources on the local file system.  When you create a network share, the hosting server dictates share permissions (on the "Sharing" tab of the same dialog), as well as the standard NTFS permissions.  Both sets of permissions must allow a particular user for a share resource to be available to them.

Every application is going to be run as a specific user.  Generally, it is the name of the user starting the application.  You can see the user that owns the process by looking in your Task Manager.  Whichever user owns the process is the user that needs access to the share.

From your recent responses, I don't think the problem is in share or NTFS permissions, though.  It sounds like it is failing because it is trying to run external code.  I think slightwv may be on to something with his suggestion.  You'll need to find out exactly what part is failing.  Is it the spawning of the Word process, or something that Word process is doing?  What user owns the Word process that spawns?
tim_storeyAuthor Commented:
Thanks routinet, I doubt very much it is ACL issues on the share and its gonna take more digging.
Thats what I am trying to figure out..... who owns the Word process and task manager is not helping me in this regard I suspect the account.
I will try some of these tools and then get back to you all thank you for all of your help so far
My thinking:
 " however every time the user tries to create a new job it crashes."

is that there's not proper error trapping there.  Is the app performing any logging?  Would be nice to get a look at the code, though that may not be feasible.
Do you get any error?  Or when you say it crashes, it completely 'goes away' without notification of any kind?
tim_storeyAuthor Commented:
alas I have not got the source code, also the developer is singularly unhelpfull.
There is, as you say no error trapping or logging.
When the write fails there is no meaningfull error given other than could not write to path or directory. Thats it I'm afraid.
The app does continue to run, it is just when a function is called that requires the creation of a new document.
I am trying to get hold of the code but until that happens I will have to find other paths to investigate.
I almost hate to take another stab at this, because I'm not the guru you need from world, but I believe there is indeed an associated service that you would need to configure.  Check your services on the server - you should see it in the column listing the accounts - I forget the name.
Ensure that this account has write access locally, that is, the NTFS permissions discussed above.
If you need guidance setting that, let us know...
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.