I have been in this business for 29 years and have seen some odd issues. Many have been a nightmare to track down and resolve... this is one of them, and we have pulled our hair out trying to determine the problem.
The problem-child is a Dell Optiplex 9020 running Windows 10 Pro at a client site with 23 other similar machines with 10 Pro, on a Windows 2012 Domain with 1 PDC/FileServer (FS1). We are scheduled to replace the server soon, but I would really like to figure this out because it is decreasing productivity and mainly because it has so many of us stumped.
We have setup new shares on this server, with FULL ACCESS sharing AND file security permissions for Everyone, Domain Users, Domain Admins, and the specific user we are testing.... we have ensured that no limited permissions by inheritance.
Everything works fine for a while after a server reboot, then this ONE Windows machine will all of a sudden start this odd problem with it not being able to read or write to the FS1 shares.
Once the problem starts occurring, ANY user on this machine can BROWSE to all FS1 shares and SEE the files, but cannot read or write.
- It doesn't matter what user is logged onto the machine... domain user, domain admin, local admin with same username/password as the domain user or admin, or even if FS1 doesn't recognize the user and we enter domain user or admin credentials at the prompt.
- It doesn't matter WHERE the machine is connected... we thought it may be a bad switch port or cabling, but moving the machine to a location with a known good working machine is located produces the same result
- This machine has no special delegation or policies applied on the domain, same group policies as all other machines... GPupdate works fine until the problem occurs, then it can browse to and see the policy file on the server, but cannot read it.
- There is no kind of MAC filtering on the network or server
- We are running Bitdefender Gravityzone on this client... no malware is detected... and the BD policy is the same as all other machines which continue to work fine.
- I have reset the local security policy to default MS settings then re-applied the default domain policy
- We have checked (and reset) all Windows Firewall settings
- DNS points only to the FS1 server (which points only to itself)... no DNS issues on any workstations
- DCDIAG is all good.
- While the problem was occurring on this machine, we created a local share and was able to read/write to it from other machines... we also created a share on another server (not on the domain) and this PC could read/write to it just fine... but still couldn't read/write to any of the FS1 shares
- They are running an EMR application... when the issue starts occurring, the first sign is this in the Application Event Log:
The VB Application identified by the event source logged this Error:
ERROR: Full Permissions not set at Default Image location location: \\internal_ip_of_FS1\path_to_EMR\IMAGES\TestCopyFile.txt for this user.
Please grant this user full permissions in the folder's Properties-Security Tab.
Error: #0 EMR_NAME will not operate properly until this is corrected.
- The user has full permissions to the share and file security settings with no limitations or restrictions being inherited
- AGAIN... none of the shares or permissions CHANGE, so why does it work for a while, then stop working?
It would seem that there would have to be some sort of socket connection limitation that is getting maxed out
- This is only happening on this workstation, which happens to be the latest workstation added to the domain.
- I do have one of these on the workstation today (THE BOLD IS WHERE I REPLACED ACTUAL INFO WITH FILLER INFO):
An account failed to log on.
Subject:Security ID:S-1-5-18
Account Name:WORKSTATION_NAME$
Account Domain:OUR_DOMAIN
Logon ID:0x3E7
Logon Type:2
Account For Which Logon Failed:Security ID:S-1-0-0
Account Name:Administrator
Account Domain:WORKSTATION_NAME
Failure Information:Failure Reason:Unknown user name or bad password.
Status:0xC000006D
Sub Status:0xC0000064
Process Information:Caller
Process ID:0xedc
Caller Process Name:PATH_TO_OUR_MANAGED_SERVICES_AGENT
Network Information:
Workstation Name:WORKSTATION_NAME
Source Network Address:-
Source Port:-
Detailed Authentication Information:Logon Process:Advapi Authentication Package:Negotiate
Transited Services:-
Package Name (NTLM only):-
Key Length:0
This event is generated when a logon request fails.
It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon.
This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
- It doesn't clear up until we reboot the server, then everything works fine for an inconsistent amount of time... most of the time, it is only a few hours.
- Nothing specific to the denial of access shows up in the event logs for the machine or the server; however, we do get some of these - not many (1 or 2 every couple of days), but they indicate a local login issue in the Security log on the server itself (not from the workstation in question):
An account failed to log on.
Subject:Security ID:S-1-0-0
Account Name:-
Account Domain:-
Logon ID:0x0Logon
Type:3
Account For Which Logon Failed:Security ID:S-1-0-0
Account Name:OUR_DOMAIN_ADMIN_USERNAME
Account Domain:OUR_DOMAIN_NAME.local
Failure Information:Failure Reason:Unknown user name or bad password.
Status:0xC000006D
Sub Status:0xC000006A
Process Information:Caller Process ID:0x0
Caller Process Name:-
Network Information:
Workstation Name:FS1
Source Network Address:FS1.INTERNAL.IP
Source Port:57834
Detailed Authentication Information:
Logon Process:NtLm
Ssp Authentication Package:NTLM
Transited Servicesackage Name (NTLM only):-Key Length:0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon.
This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested
Any help is appreciated!
The problem-child is a Dell Optiplex 9020 running Windows 10 Pro at a client site with 23 other similar machines with 10 Pro, on a Windows 2012 Domain with 1 PDC/FileServer (FS1). We are scheduled to replace the server soon, but I would really like to figure this out because it is decreasing productivity and mainly because it has so many of us stumped.
We have setup new shares on this server, with FULL ACCESS sharing AND file security permissions for Everyone, Domain Users, Domain Admins, and the specific user we are testing.... we have ensured that no limited permissions by inheritance.
Everything works fine for a while after a server reboot, then this ONE Windows machine will all of a sudden start this odd problem with it not being able to read or write to the FS1 shares.
Once the problem starts occurring, ANY user on this machine can BROWSE to all FS1 shares and SEE the files, but cannot read or write.
- It doesn't matter what user is logged onto the machine... domain user, domain admin, local admin with same username/password as the domain user or admin, or even if FS1 doesn't recognize the user and we enter domain user or admin credentials at the prompt.
- It doesn't matter WHERE the machine is connected... we thought it may be a bad switch port or cabling, but moving the machine to a location with a known good working machine is located produces the same result
- This machine has no special delegation or policies applied on the domain, same group policies as all other machines... GPupdate works fine until the problem occurs, then it can browse to and see the policy file on the server, but cannot read it.
- There is no kind of MAC filtering on the network or server
- We are running Bitdefender Gravityzone on this client... no malware is detected... and the BD policy is the same as all other machines which continue to work fine.
- I have reset the local security policy to default MS settings then re-applied the default domain policy
- We have checked (and reset) all Windows Firewall settings
- DNS points only to the FS1 server (which points only to itself)... no DNS issues on any workstations
- DCDIAG is all good.
- While the problem was occurring on this machine, we created a local share and was able to read/write to it from other machines... we also created a share on another server (not on the domain) and this PC could read/write to it just fine... but still couldn't read/write to any of the FS1 shares
- They are running an EMR application... when the issue starts occurring, the first sign is this in the Application Event Log:
The VB Application identified by the event source logged this Error:
ERROR: Full Permissions not set at Default Image location location: \\internal_ip_of_FS1\path_to_EMR\IMAGES\TestCopyFile.txt for this user.
Please grant this user full permissions in the folder's Properties-Security Tab.
Error: #0 EMR_NAME will not operate properly until this is corrected.
- The user has full permissions to the share and file security settings with no limitations or restrictions being inherited
- AGAIN... none of the shares or permissions CHANGE, so why does it work for a while, then stop working?
It would seem that there would have to be some sort of socket connection limitation that is getting maxed out
- This is only happening on this workstation, which happens to be the latest workstation added to the domain.
- I do have one of these on the workstation today (THE BOLD IS WHERE I REPLACED ACTUAL INFO WITH FILLER INFO):
An account failed to log on.
Subject:Security ID:S-1-5-18
Account Name:WORKSTATION_NAME$
Account Domain:OUR_DOMAIN
Logon ID:0x3E7
Logon Type:2
Account For Which Logon Failed:Security ID:S-1-0-0
Account Name:Administrator
Account Domain:WORKSTATION_NAME
Failure Information:Failure Reason:Unknown user name or bad password.
Status:0xC000006D
Sub Status:0xC0000064
Process Information:Caller
Process ID:0xedc
Caller Process Name:PATH_TO_OUR_MANAGED_SERVICES_AGENT
Network Information:
Workstation Name:WORKSTATION_NAME
Source Network Address:-
Source Port:-
Detailed Authentication Information:Logon Process:Advapi Authentication Package:Negotiate
Transited Services:-
Package Name (NTLM only):-
Key Length:0
This event is generated when a logon request fails.
It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon.
This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
- It doesn't clear up until we reboot the server, then everything works fine for an inconsistent amount of time... most of the time, it is only a few hours.
- Nothing specific to the denial of access shows up in the event logs for the machine or the server; however, we do get some of these - not many (1 or 2 every couple of days), but they indicate a local login issue in the Security log on the server itself (not from the workstation in question):
An account failed to log on.
Subject:Security ID:S-1-0-0
Account Name:-
Account Domain:-
Logon ID:0x0Logon
Type:3
Account For Which Logon Failed:Security ID:S-1-0-0
Account Name:OUR_DOMAIN_ADMIN_USERNAME
Account Domain:OUR_DOMAIN_NAME.local
Failure Information:Failure Reason:Unknown user name or bad password.
Status:0xC000006D
Sub Status:0xC000006A
Process Information:Caller Process ID:0x0
Caller Process Name:-
Network Information:
Workstation Name:FS1
Source Network Address:FS1.INTERNAL.IP
Source Port:57834
Detailed Authentication Information:
Logon Process:NtLm
Ssp Authentication Package:NTLM
Transited Servicesackage Name (NTLM only):-Key Length:0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon.
This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested
Any help is appreciated!