User can't access server

Have you looked at the user's account in Active Directory?  It's possible she has time restrictions deined in her account.

I have checked AD and there is nothing in the account that has time restrictions.  Just to verify I checked the AD account with another user's that can access this location and they were virtually identical.  That, and she has been able to work from another machine all day without problems getting an access denied.

The only other thing that we did to this machine after the user started working on it was install a piece of software that installs a specifically older version of Java (jai-1_1_3-lib-windows-i586-jre).  We were thinking it was potentially this, but then realized other users that this works with have the same programs and java installations.

Is there anything in the event log around the times when she stops being able to access the server?

Event logs for the server and the workstation.  Maybe a conflict or a problem with Kerberos?

The only things that I could find in the Event Viewer were the following

Application - Both Warnings
A provider, PolicyAgentInstanceProvider, has been registered in the WMI namespace, ROOT\ccm\policy\S_1_5_21_842925246_2139871995_839522115_7300, to use the LocalSystem account.  This account is privileged and the provider may cause a security violation if it does not correctly impersonate user requests.
A provider, PolicyAgentInstanceProvider, has been registered in the WMI namespace, ROOT\ccm\policy\S_1_5_21_842925246_2139871995_839522115_12267, to use the LocalSystem account.  This account is privileged and the provider may cause a security violation if it does not correctly impersonate user requests.

Security - Failure
Logon Failure:
       Reason:            An error occurred during logon
       User Name:      user name
       Domain:            domain
       Logon Type:      11
       Logon Process:      User32  
       Authentication Package:      Negotiate
       Workstation Name:      computer name
       Status code:      0xC000005E
       Substatus code:      0x0

System - 1 error

The application-specific permission settings do not grant Local Launch permission for the COM Server application with CLSID
{24FF4FDC-1D9F-4195-8C79-0DA39248FF48}
 to the user NT AUTHORITY\SYSTEM SID (S-1-5-18).  This security permission can be modified using the Component Services administrative tool.


This is what I get.

I should have also mentioned that the Login succeeded the next time.

This should not affect file shares, only COM applications.

Which is why I am still confused about the problem.

The most odd thing is that it worked fine for the new machine for a few hours and then stopped and any other user on that machine can still access the data flawlessly.  I also had the idea of copying the user's entire profile from a machine where they can access the data to the machine where they can't and that didn't work either.

What about if you copy the faulty profile to a good machine?  Does that result in a second faulty connection?

Also, are there any event logs on the client side?

What I pasted was the event log from the Clients side, I should have been more clear on that.  I had one of our network administrators look at the error log on the server and it was clean.

I copied the user's profile to my machine and the access ceased to work.  I then deleted the profile, created a new one with their name and it worked fine.  My plan for Monday as the user has left for the day and I don't want to do anything drastic to her while she isn't here, is to copy the profile that I created on my machine to her machine after renaming and moving her profile.  I did this before unsuccessfully but I could have missed something.  I also will not copy any of the user's data to the new profile until I test to see if accessing the server works or not.

If all goes well it should be fixed on Monday.  I will let you know.

It sounds like a profile problem, then, if you can recreate it by copying the profile to a working computer.

I would be very interested in finding out what the problem is.

I copied the profile I created for the user from my machine to their current machine and had them log back in.  She could access the server and files just fine.  I copied most everything from the old profile to the new profile (desktop items, documents, etc...) and it still worked.  The user is going to write down everything they do on their machine because this access stopped working the last time after 3-4 hours of use.  

If it is not a problem I will also be leaving this question open until later today when I verify that the access doesn't break again.

The problem for the one user is fixed with a new profile that was created.  The problem now is that someone else is having the same problem and they didn't tell me until now.  It is the same problem with the profile but I don't know why it would happen with just these two people out of everyone.  I know that this may be stretching towards me asking another questions and keeping this open but would you know of anything in Group Policy that would disallow people from getting to a location.

The reason I ask is that I performed a "gpupdate /force" on the original machine after I recreated the profile and it completely broke the user's access.  I did the same function on my machine and it did not break.

I'm assuming you have Administrator access and the broken user does not.  Generally, a policy does not affect administrators (as you don't want to restrict and break those logins), so it's likely that if something in group policy is the culprit, it would not affect you.

As a Help Desk we technically don't have admin rights on anything but the desktops and the Group Policy isn't handled by us, but we think that we found the culprit(s) of the whole mess.

Since we found that it was the profile we decided to tear the profile apart and remove folders until it started working.  We found that once we remove the following folders the access immediately works, and when we put them back it fails.

C:\Documents and Settings\%user%\Application Data\Microsoft\Credentials
C:\Documents and Settings\%user%\Local Settings\Application Data\Microsoft\Credentials

So we know that is the cause but we aren't sure the why of it and why it would stop just two people.

Well, those two folders both hold the user's network credentials issued by Kerberos as well as some certificate information (if applicable).  If these folders become corrupt or are tampered with, it may cause Kerberos to throw errors because it thinks that the user is either being impersonated or someone is trying to hack the network.

Additionally, since Windows requires these folders in order to provide single sign-on for all applications that use the Integrated (Windows Authentication) scheme, if you delete the folders, Windows will automatically recreate them and replace their contents with a new set of Kerberos tickets.

Sorry for not saying anything lately, but I have been trying to trigger the breaks on the user's machine.  They still seem to be random and still have only seemed to be with the one person.  

Is it more believable that the server is messing up credentials or is it more believable that the user's AD account is messed up and to have that recreated?  Unfortunately these are the only two things that I can do at the moment to resolve the issue.  

I will get that done and let you know