Do windows domains just randomly stop trusting machines?
Posted by MikeD123999@reddit | sysadmin | View on Reddit | 73 comments
So I am probably an advanced windows user, not an admin, probably cocky enough to be dangerous level.
So I have worked at this company for about 20 years. I have some servers that I am in charge of but the real admins are the ones that configure stuff. Within the last six months I have had one off issues with three servers (I’m pretty sure they are VMs) where I try to login with my domain account and it won’t let me in because it says I can’t be authenticated. The admin then logs in with a local account and has to do stuff to tell the domain to re-trust the machine. Talking to the admin, he says this happens randomly and has happened as long as he has been here and can happen to any machine on the domain. This guys seems pretty good but I think it just seems weird, yesterday this happened to a production machine which was annoying. He basically said that every xx days there is a handshake type thing that goes one to rebuild the trust between the domain and machine and this fails sometimes. It seems weird the process wouldn’t be more robust, seems weird the three machines that I noticed were VMs
autogyrophilia@reddit
It happens sometimes.
Basically your computer has an account, to access computer level resources in the domain.
This password gets rotated periodically by your computer. Sometimes it happens that the password isn't rotated well for whatever reason, or the domain rejects the password (usually because the computer has been away for too long), or someone has restored the domain servers from a backup ...
It's not a daily occurrence but we do get 2-3 every year.
Unexpected_Cranberry@reddit
I've seen it happen when reverting snapshots some times. Either the snapshot was old, or even if it isn't, you might have bad luck and snapshot right before the password was rotated.
I believe it can also happen due to delays in replication. I don't recall the specifics though.
I think we saw this fairly often at a previous job where we had two sites. For some reason the network guy had decided it would be a good idea to have the wireless in both sites be the same network. And that network could of course only be associated with one site in sites and services. So whenever you docked or undocked you switched AD site. So every now and then a computer would be on the wifi, rotate it's password and then get docked before the password change was replicated and was promptly kicked off the domain for using a bad password.
autogyrophilia@reddit
These days I would advise against implementing active directory sites if you can be reasonably confident that the connectivity between sites is fast enough. Intrasite replication is much faster and avoids problems if a computer jumps sites for whatever reason, or the servers haven't picked up changes...
Of course this changes for enterprises that have dozens of branches in multiple countries. Even then, I think I would create sites by region rather than one per branch.
touchytypist@reddit
You can actually enable immediate replication between sites with ADSIEDIT
So you can still have a proper AD site topology for DC finding and local network services for Windows clients, while not having the wait the minimum 15 minute intersite replication interval.
https://agderinthe.cloud/2023/11/23/enable-immediate-replication-between-active-directory-sites/
autogyrophilia@reddit
You learn something new every day. Seems like something that should really be a toogable in the MMC.
I still think that it makes sense to put everything that has acceptable latency on the same site, as long as the latency is acceptable.
Unexpected_Cranberry@reddit
I don't recall what we ended up doing there. We relied on dfs to have clients connect to the appropriate file server, and we didn't want that traffic over the site link. But at some we managed to lease dark fiber between the sites, and I think it was upgraded to 10gbit. We probably made it one site once that was done.
Where I'm at now, we generally make a location a site if it qualifies for a local DC. That depends on a bunch of different factors, bandwidth and reliability of the Wan link is one.
patmorgan235@reddit
I've seen this happen with laptops, because they can be turned off for a significant amount of time, or used off site where they don't have line of sight to a domain controller.
If the sever is on 24/7 and has stable line of sight to a domain controller there's no reason it should randomly loose it's domain trust.
ChaosTheoryRules@reddit
"I've seen this happen with laptops, because they can be turned off for a significant amount of time, or used off site where they don't have line of sight to a domain controller."
This is not correct. Machine AD password changes are driven from the client side, if the machine cant contact a DC it is unable to change it's machine password thus carries on happily and on the AD side of things machine passwords do not expire. This is by design.
More than likely, cleanup scripts touching/deleting/disabling machine objects they shouldn't, tech's resetting the wrong machine object, tech's reusing existing machine names etc. pretty much anything that tampers with a machine objects stored password in AD. On the client side using system restore could eventually cause it because Microsoft in its poor wisdom also rolls back the registry keys holding the old and current machine passwords.
mcmatt93117@reddit
The machine AD password change part may be correct, but I've seen the exact same behavior pretty consistently over the last 15+ years.
I've seen a FEW non-laptop's have domain trust break, but could count on one hand probably.
Laptops a user had in their desk drawer for six months? Yea, no it's almost guaranteed to have a trust relationship issue if it's brought in and logged into connected to the domain. Daily? Nope - half dozen a year? Probably at least yea.
the_andshrew@reddit
You've most likely had someone (or some add-on software) doing apme 'helpful' tidy up work on the AD side during those 6 months that has changed the computers AD account and therefore created the issue; because there is nothing about the normal process of how a computer authenticates with AD which would stop it from being able to continue doing that after emerging from 6 months in the draw.
mcmatt93117@reddit
Nope. Small team (local county government, healthcare). 4 of us, only sysadmin.
Two desktop guys have permission to reset passwords and create AD accounts, which is done through a tool. I'm the only person that even has the tools installed outside the DCs - which I (and my boss - who doesn't log into them, never mind clean up AD accounts) are the only two to have access to.
You're free to believe what you want or not - there's many other people in here that say the exact same thing.
And yes, I understand the computer object password changes are driven client side.
touchytypist@reddit
Your anecdotal experience and incorrectly managed AD environment doesn’t change the fact that computer accounts simply don’t go out of sync on their own or from being offline.
mcmatt93117@reddit
Don't care, and not saying they did, I was sharing my experience from what I've seen.
You're welcome to gargle my balls if you'd like?
touchytypist@reddit
Speaking like a true intellectual. You just keep increasing to your credibility. lol
the_andshrew@reddit
And this continues to be one of the most misunderstood things in AD despite to being incredibly simple and well explained by multiple respected sources.
If you understand that the process is driven client side, then you'll understand that a computer turned off cannot lose it's trust relationship with the domain without interference on the AD side, or multiple faults on the client side (ie. multiple reversions to system restore points after AD password charges, or inaccurate time on the device).
BrentNewland@reddit
No, they do expire. I've had to deal with a few laptops this year that had that exact issue, and all the logs pointed back to an expired PC account password.
ChaosTheoryRules@reddit
I'm not going to even continue arguing the point. It is all right here:
https://techcommunity.microsoft.com/blog/askds/machine-account-password-process/396026
Substantial_Crazy499@reddit
And more even here: https://syfuhs.net/on-computer-passwords
touchytypist@reddit
This is an old wives tale. A Windows PC can be offline or off domain for years and its AD account password/trust will not change unless someone makes a change to it.
mediaogre@reddit
We’re currently leaning hard into Zscaler (ZPA) and Entra. Among other benefits, that combo should effectively eliminate the issue of laptops yeeting themselves from domain trust.
jpnd123@reddit
ZPA is such a good replacement for traditional VPN, just a much better user experience
Titanium125@reddit
Every 90 days if I am not mistaken the machines on the domain and the domain controller renegotiate the handshake, which is actually just a shared secret password. This is used to sign every request to the domain controller. If one side or the other has the wrong secret then it will fail. The only time this should happen is if the computer is turned off for a significant period of time or not connecting to the domain. This happening multiple times on VMs that are always connected could mean there's an issue, but that depends on the size of your org. If you have 100 machines then that's a lot and could indicate a problem. If you have 20,000 then it may not be a big deal.
woodburyman@reddit
We used to have this issue frequently besides some random once offs as well. Turns out one of our DCs for a site, the Hyper Visor it was on, would randomly in the middle of the night the Raid controller would lock up for random amount of times and all VMs would lose disk access it'd reset itself with in 15 minutes to two hours. It was always middle of the night so we'd never catch it live. The DC would still talk to clients but anything that was on had a chance at getting domain trust disrupted if it happened to try to talk to that DC in particular.
Firmware and driver updates fixed the Raid controller issue. Happy ever since.
bno000@reddit
Are the VM’s sharing hostnames/being snapshot?? Sounds like they are losing their trust relationship and are having to be rejoined to the domain. Usually happens if 2 machines have the same Hostname/computer object in AD or the VMs are getting snapshot back to the point where the machine object password in AD doesn’t match the one on the machine.
trollinhard2@reddit
This is happening in our environment as well. We always had stragglers but it’s been more frequent over the past year.
drekmac@reddit
Like others said, computer passwords get reset default about every 30 days and things go wrong, but it’s not that often. We started getting a lot when we replaced our DCs with updated versions, I do think newer, more secure defaults had something to do with it. As our IT has shrunk I’ve inherited AD duties and came to realize we have old old encryption types still allowed and nobody had reset the krbtg account since the AD was stood up in 2010. Never got a clear picture why we had a bunch of servers losing trust nearly monthly when they updated that password, and a whole bunch of issues with horizon instaclones, but it seemed to stop after resetting krbtg. It’s a little fuzzy but I think our DC logs showed we had rc4 and AES available, but would only ever use RC4, and after the krbtg reset things actually started using AES.
bbbbbthatsfivebees@reddit
It happens, and honestly it's not all that rare.
The simple version is that essentially every so often each machine on a domain needs to re-authenticate with the Domain Controller for various reasons (Sync passwords and user information, update any Group Policy Objects, and also to make sure that there's not some unauthorized system allowing logins when it shouldn't). Typically, machines need to share some sort of local network access or VPN connection with the DC for it to re-authenticate and this usually just happens automatically, but if something's been offline for too long or doesn't have that local network access, the machine goes "Something's wrong here, I haven't been able to phone home for a while" and it goes into lockdown mode by losing what's called the "Domain Trust Relationship".
The actual repair, however, is just a single command. You get the device on the LAN or VPN, make sure it can communicate with the DC, and then run the powershell command "Test-ComputerSecureChannel -Repair". Takes me about 10-15 minutes, and most of that is honestly just pulling the machine's local admin password and waiting for the "We're getting things ready" screen.
I've mostly seen it happen on laptops, and during COVID it was particularly bad before people started moving more authentication to AzureAD. We still occasionally have this problem with WFH users who will just refuse to connect their VPN for days on and end then wonder why their machine lost domain trust and they have to call us (Usually it's the middle-managers who have "email/meeting-only jobs" and don't need to access anything that's IP-restricted on a regular basis). Nowadays I see it maybe once every 2-3 weeks, usually with a different WFH user who gets the same lecture about needing to connect to the VPN for security reasons.
On a VM, though? Sounds like a firewall/VM networking issue. Maybe the machine can't communicate with the DC properly and it's getting filtered or something. Another possible cause would be that since they're VMs, the system clock gets out of sync and it then can no longer do that handshake. I'd honestly press your IT staff a bit further if this is happening on a semi-regular basis and see if you can't get this escalated and find the root cause.
robotbeatrally@reddit
I think something else that causes that is joining a device to AD with a name that is already in use. It'll knock the first one off the trust.
Sometimes if people don't have a good naming policy they will derp out and join another computer with the same name... you know like... Financecomputer1 or something.
BrentNewland@reddit
Someone could be deleting the AD account for the computer.
scytob@reddit
make sure the machines were not cloned after domain join, this can happen if the SIDs or RIDs are the same
if the machines are on this should never happen, another cause could be a network issue or group policy
Draptor@reddit
Is there anything set to freeze the registry and reset it on reboots? I can't remember the exact terminology, but I've had industrial equipment that's set to not retain any changes an operator might make between reboots. A side effect was that the password exchange between the DC and client machine was basically sent back in time if that industrial machine was ever rebooted, and had to be rejoined to the domain and the new registry edits captured/frozen.
Those machines should never have been domain joined in the first place, of course, and was one of the first things I fixed since it turned out the only reason it had been done were simple SMB shares. SMBv1 at that... ugh.
kagato87@reddit
It's not random. He just doesn't want to explain it to you because he knows it won't change anything.
Yes it's a thing, it happens when the host and talk to the domain for an extended period of time. Either it's off network or there's something wrong with ADSS and these machines are getting by on cached credentials.
I_cut_the_brakes@reddit
I really feel for the admin who is about to get a "well, the poeple on reddit said it can be fixed" email.
Igot1forya@reddit
They probably have a single Domain Controller that is malfunctioning and the random servers having issues have chosen to favor the faulty DC. Most likely the systems are becoming Tombstoned as a result of not having renewed the machines authentication ticket.
LowIndividual6625@reddit
If the machine has been off network for a long time then it is “normal” but if it happening at random then you have AD sync issues between domain controllers
Unnamed-3891@reddit
This happening VERY rarely as a one-off is okay. If this is a common occurrence, it needs to be investigated.
zero_z77@reddit
Yeah, if it's recurring, it means you have networking issues.
OP said VMs, so if i had to guess they're probably all connected to a virtual switch and sharing the host machine's physical interface.
If you have 3 VMs and a host all on the same wire, that's going to look weird to the switch it's plugged into. Could be getting tripped up by port security or QoS if the switch port isn't configured properly. And sometimes the host gets priority over the VMs on the virtual switch, which can cause a plethora of networking issues for the VMs.
In any case, servers usually have 4+ physical interfaces, so you should either be using link aggregation or provisioning a dedicated physical line for each VM if you can.
Another possibility is that they don't have a local DC/DNS server and communication with the external DC/DNS is spotty.
Another thing is wether or not these VMs are in continuous operation. If they are usually paused, suspended, or shut down when not in use, they can easily lose trust with the domain.
kona420@reddit
Physical NIC per VM screams bad planning. Usually you'll have a pair for guest traffic, and a pair for host and management traffic so that backups don't step on guest performance. Size up the link speed as needed, bonding is usually best used for redundancy rather than as a performance tool.
From the switches perspective, it's just plugged into another switch. It's not a typical place for a half-failed type of error.
Even if a machine is shut off through it's machine password expiration date, it's password is still valid when it powers on. Trust issues are usually some sort of rollback of the state of AD-DS itself or the member OS.
NextSouceIT@reddit
That’s not really how virtualization networking works. Multiple VMs sharing a single physical NIC is completely normal. Hypervisors are designed to present multiple MAC addresses behind one switch port. switches handle that just fine.
It's true that port security configured to limit MAC addresses per port will cause issues, but other than that, it won’t “look weird” to the switch or cause problems.
Also, there’s no inherent priority where the host gets bandwidth over the VMs unless QoS is explicitly configured, and dedicating a physical NIC per VM isn’t standard practice.. most environments run many VMs per uplink without issue.
I_T_Gamer@reddit
Yep, if its recurring in any way there is something going on. In our environment we had a spurt of them when we promoted a Server 2025 DC. It was an issue with 24H2 and server 2025, upgrading our machines to 25H2 has helped immensely.
_CyrAz@reddit
Also a known issue if you run 2025 DCs alongside older version ones
finobi@reddit
Wonder if this 2025 security feature has anything to do with it:
Improved security for default machine account passwords: Active Directory now uses default computer account passwords that are randomly generated. Windows 2025 DCs block setting computer account passwords to the default password of the computer account name.
_CyrAz@reddit
I don't believe that's the reason, you'll find quite a lot of infos in those threads :
https://www.reddit.com/r/activedirectory/comments/1j5x35o/
https://www.reddit.com/r/activedirectory/comments/1lltdk1/rc4_issues/n04qpes/
Whyd0Iboth3r@reddit
This happens to our end-user machines. Not daily, but we get about 1 a month.
Unable-Entrance3110@reddit
Yeah, this happens to us maybe once a year. Usually due to file system corruption or a botched Windows update.
mailboy79@reddit
100% this.
Dabnician@reddit
yes its the machine password that rotates every 30 days, since windows 2000, they need line of sight to the domain controller
BitOfDifference@reddit
yes, if a computer does not contact the domain within a set timeframe, which is pretty wide depending on GPO settings, it will be required to have an admin "rejoin" it to the domain. Simple process once its back on site and connected. I see it all the time because users go out on FMLA with their device and dont come back for months. Its not a big deal for us, but the user must bring their device in. Almost exclusively a laptop issue. It can happen with servers, specifically DCs if they stop syncing for a few weeks. Little bit more involved with that kind of fix, but still fixible.
superstaryu@reddit
There was a bug in Windows Server 2025 when it was released that affected a number of machines on older build of window 11. Its been fixed now though. Outside of that its pretty rare.
The usual suspects though:
Device has been offline for too long (or couldn't talk to DC for a long time).
Time on the servers/clients is more than 5 minutes out of sync with the DC.
Someone has been reverting those VMs from snapshots / restoring from backups.
jwalker107@reddit
It's not normal.
The computer account has a password on the domain, just like a user account does. The computer periodically updates this password.
Where I usually see trust failures, is when the computer is restored from a VM snapshot, so the computer reverts to using an older computer account password that had been updated at the domain controller.
If this is happening repeatedly, check whether there is a practice of reverting to snapshots as some part of the workflow at your company.
Subject-Jellyfish165@reddit
If you recently added a Server 2025 as a domain controller in a mixed environment, this happens. After 30 days when machines try to renew their passwords and fail because of a cypher mismatch between controllers. Check if you have a Server 2025 DC with any other version DC in the same domain.
kona420@reddit
Usually a clue that you have replication issues between your DC's, or otherwise have issues with UDP/RPC traffic.
Other than straight up packet loss, UDP fragmentation due to MTU issues is a common culprit. If your fragments arrive out of order RPC is going to start failing. So you are especially looking at VPN tunnels but this kind of thing can happen anywhere you are doing encapsulation like VXLAN's.
Also with virtualization, best to treat AD-DS as a database that requires low latency scheduling. High CPU wait and issues with virtualized networks are also culprits here.
Replication issues can take a shockingly long time to show their face sometimes. Best to have log collection and alerting or at least periodically take a look-see at the DFS logs.
Nandulal@reddit
We have a roulette wheel in the office. You get to put five bucks in the jar to spin it. Each number goes to a random machine on the domain and if it lands on it we just delete it for shits and giggles. If you get 00 you win the pot.
(hehe ;D)
Brather_Brothersome@reddit
That happens because of Time sync if the discrepancy is lartge enough you get trust issues. so sync from outside and the straglers that you see4 post that is that they changed the date on their pcs, normally for end of month stuff.
Wolfram_And_Hart@reddit
It used to happen a lot more. Happens way less now.
Xibby@reddit
For VMs, causes are usually cloning without renaming the resulting VM. So multiple computers get joined using the same name.
The one that was already joined will probably continue working until its Kerberos tickets expire.
Another common cause is rolling back snapshots.
At a previous employer, in the days where it was easy to swap a good hard drive into a new laptop, Service Desk would swap a drive from a broken laptop into a new, and computers were named for the physical asset tag.
I’d end up with an escalated ticket because remove/rejoin didn’t work. Look at it, look at the history for the asset tags… oh yeah I see exactly. Track down the user where asset tag and computer domain don’t match, fix. Rejoin both to domain. Fixed.
itworkaccount_new@reddit
Check the dns configurations on the servers. You most likely have a DC set for DNS that is having replication issues.
Fix your replication issues and make sure the dns is properly configured on the servers and your issue will go away.
Most-Importance-1646@reddit
I've seen this happen but very rarely. I usually just remove the pc and rejoin it.
TrippTrappTrinn@reddit
The first thing to check is computer time. If it is permitted to drift, once it is more than 5 minutes from domain time, it is not permitted to talk to the domain.
CeC-P@reddit
We actually just ran into this this morning and we're all stumped on it. A remote user keeps getting their credentials locked out every 30 days and they log in daily to the domain and connect to the VPN. The guy working on it said he ran some sort of command that might fix it but the last place I worked had TONS of remote users and they weren't even hitting the 180 day kickout that I've heard sometimes happen. Not even sure what's going on with that one. I didn't work on it personally, so it may be a local account or something odd like that.
Forn1catorr@reddit
Have your people check replication with their domain controllers.
Had this "trust relationship" error with one machine, then a few machines, then it got baddd and we had to demote and rebuild a dc that had de-syncd
TypaLika@reddit
It happens, but not with the frequency you are describing. It is typical if a server was restored from a backup, which will break the Trust relationship with the domain and can result in the computer/server using an older machine password than the one it has cycled to.
From a command prompt the nltest command can show you if the secure channel from the system to the domain is healthy.
nltest /sc_verify:<domain>20 years - I'm assuming this is an on-prem domain and not Entra only. If ther servers are Entra joined there could be some additional wonkiness.
Here's what the AI overlords have to say about it. I checked, their answer is accurate.
Machine trust in Windows is established via Active Directory (AD), where each domain-joined computer has a unique account and password, allowing it to authenticate with domain controllers. A "secure channel" (a form of encrypted RPC) is then established using this shared secret to protect communications, such as user logons and policy updates, with passwords automatically managed and synced every 30 days. [1, 2]
How Machine Trusts and Secure Channels Work
Key Security Components
Interdomain TrustsSecure channels are also used between different domains (forests) to ensure that when a user logs into a computer in a different domain, the two DCs can securely verify the user's SIDs (security identifiers). [5, 9]
AI can make mistakes, so double-check responses
[1] https://www.dell.com/support/kbdoc/en-us/000201765/error-on-a-windows-server-or-client-machine-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed
[2] https://www.dell.com/support/kbdoc/en-au/000312106/windows-server-repair-a-broken-secure-channel-on-an-active-directory-domain-controller
[3] https://www.youtube.com/watch?v=jjcxV2vvEYU
[4] https://www.youtube.com/watch?v=8w-Lrd0EMhY
[5] https://learn.microsoft.com/en-us/entra/identity/domain-services/concepts-forest-trust
[6] https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/credentials-processes-in-windows-authentication
[7] https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-or-sign-secure-channel-data-always
[8] https://www.youtube.com/watch?v=DG4pQOf77jw
[9] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nrpc/08b36439-331a-4e20-89a5-12f3fab33dfc
autogyrophilia@reddit
Mods, release the hounds.
SevaraB@reddit
Domain trust works using a network protocol called Kerberos. It’s kind of like DHCP but for domain registrations. If machines don’t check in with a domain controller for long enough (30 days is default), it falls out of sync and you have to forget and rejoin the domain (just like forgetting and pairing Bluetooth).
If the machines aren’t being left turned off or left at home and not on a VPN for at least that long, you need to start looking at whether ports are blocked between your domain controllers and their clients.
glirette@reddit
A Windows domain joined system has an account on the domain and it is in fact a trust relationship. The very much the same as when one domain trust another domain. There is an account with special flags on that account with the machinename$ . The machine also initiates a password change periodically but regardless of what change is made, any change to this account on either side ( the domain side or client side) could cause it to no longer work.
This is a function of netlogon, When you logon with a domain account rather than a local account it uses this trust relationship.
Performing a function like restoring a machine from a previous state could certainly and does often cause this to happen.
The trust aka machine account can be reset from the command line or just go thru the process to re-join the domain, both have the same effect of replacing that account with a new one that is in sync now on both sides.
ISCSI_Purveyor@reddit
All. The. Damn. Time.
And usually when they are remote or a C-Suite machine.
Stufficus@reddit
Had this problem when one of my DC went bad and started going out of sync with the rest of the domain. It had computer account synced with older passwords and when a computer with a newer password tried to authenticate against it, it broke the trust. Reboot it a few times and it landed on another DC and the trust was restored. It usually can indicate a larger problem than just one computer. Also its probably DNS, if not it's still DNS.
Pyrostasis@reddit
Hard to say with out knowing more about your system and setup.
This usually happens when the device isnt connected to the domain for a sustained period.
Usually laptops that are remote and never connect to your network. Your login is cached and works fine but any new login will need to reestablish trust to be authorized.
It could also be a really poorly run setup / system.
Impossible to tell with our more info.
gzr4dr@reddit
This is not norma and needs to be fixedl. I would check the domain controllers and ensure none of them have replication sync issues. Also ensure the FSMO roles are running correctly. It's also possible some of the servers have duplicate SIDs, but the issue is the server is unable to update its machine password with AD and it's losing its trust with the domain, which occurs every 30 days.
Hopefully I got most of the tech jargon right as it has been a while since I've had to fix a similar issue.
ItJustBorks@reddit
Something is not right in the network. Can't really know without investigation. It's probably dns though.
Ssakaa@reddit
Randomly? No. There's always a cause. It's just that it's rarely worth chasing down that cause, as long as you've validated clock et. al. low hanging fruit.
Been a few years for me, but if I recall...
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)BmanUltima@reddit
I've only ever seen that on machines that are off or disconnected from the network for a long time.
Stuff that's on 24/7 shouldn't have that issue.
IlPassera@reddit
I've seen it a few times. Typically they're "abandoned" servers that someone forgot about it so their either old or have been sitting without a valid network connection for awhile.