Domain PCs showing local machinename when logging in


Domain PCs showing local machinename when logging in

t

Over the last 3 days our domain PCs (win7 and win10) have been showing the local Machine Name when getting to the login screen.  You can still login with a domain user, using domain\username.  You can also clear this by rebooting the workstation (after reboot it shows the domain name like it should).

Checking the event logs, the only event that we see consistently is error 1504:  

Microsoft-Windows-GroupPolicy: The processing of Group Policy failed. Windows could not obtain the name of a domain controller. This could be caused by a name resolution failure. Verify your Domain Name System (DNS) is configured and working correctly. 

I can ping the DNS and DC server from the affected PCs (happens to be the same machine).

Any ideas on why this would occur?



p

Does this error at Group Policy Processing happen at startup (I mean, when you boot the machine)?

If so, It´s very probable that you have enabled "Spanning Tree Protocol" (STP) at the ethernet Port where your machine
is connected. If STP is enabled, it takes about 30seconds for the ethernet port for being operational and start forwarding traffic. While the port remains at the LEARNING STP protocol STATE, no traffic (except de BPDUs associated to STP) are forwarded. That causes that the DNS queries sent by this PC are blocked at the ethernet switch.

Solutions:
* Disable STP at the ethernet port (if you may assure that no switch will be plugged in to that port in the future) or
* Enable STP FastStart. Even with this solution, where the transition to FORWARDING state happens in 3-4seconds instead of 30, current machines boot so quickly that first DNS queries are sent when the port is alredy at the LEARNING state)
t

Thank you for the suggestion.  The issue would happen while the machine was already on, usually on a Saturday or Sunday.

We are actually leaning towards our Bomgar Remote Support application.  We updated it and that is when these started happening.

p

tmartinac - 1/10/2018
Thank you for the suggestion.  The issue would happen while the machine was already on, usually on a Saturday or Sunday.

We are actually leaning towards our Bomgar Remote Support application.  We updated it and that is when these started happening.

Does the problem happen periodically?

Try to schedule a powershell or vbs script that sends a ping to the DNS name of your DC/DNS_SERVER and that sends the results to a log file with a timestamp.

t

pepinpadin - 1/10/2018
tmartinac - 1/10/2018
Thank you for the suggestion.  The issue would happen while the machine was already on, usually on a Saturday or Sunday.

We are actually leaning towards our Bomgar Remote Support application.  We updated it and that is when these started happening.

Does the problem happen periodically?

Try to schedule a powershell or vbs script that sends a ping to the DNS name of your DC/DNS_SERVER and that sends the results to a log file with a timestamp.

Happens weekly.  One of the identifiers is our AV stops updating because it cannot get to the share, even though I can \\ to it from the trouble machine.

If we reboot the box, the problem goes away for 6-7 days and  then comes back.  We can also restart the Bomgar Jump Client service on the box and that fixes it as well (part of why we think the version of Bomgar we have is causing it).
p

tmartinac - 1/10/2018
pepinpadin - 1/10/2018
tmartinac - 1/10/2018
Thank you for the suggestion.  The issue would happen while the machine was already on, usually on a Saturday or Sunday.

We are actually leaning towards our Bomgar Remote Support application.  We updated it and that is when these started happening.

Does the problem happen periodically?

Try to schedule a powershell or vbs script that sends a ping to the DNS name of your DC/DNS_SERVER and that sends the results to a log file with a timestamp.

Happens weekly.  One of the identifiers is our AV stops updating because it cannot get to the share, even though I can \\ to it from the trouble machine.

If we reboot the box, the problem goes away for 6-7 days and  then comes back.  We can also restart the Bomgar Jump Client service on the box and that fixes it as well (part of why we think the version of Bomgar we have is causing it).

What´s your AV solution?
It´s very probable that AV uses its own propietary protocol for getting "AV Signature Updates" instead of CIFs/SMB, so making a successfull UNC connection (\\AV_SERVER) does not imply that AV Signatures will be downloaded correctly.
On the other hand, it seems that the problem is caused Bomgar Jump Client . try to schedule a restart of that service with "sc"


GO


Similar Topics


Reading This Topic


Login
Existing Account
Email Address:


Password:


Select a Forum....








LOGbinder Forum


Search