Peter Flindt wrote:
> VanguardLH wrote:
>>
>> Peter Flindt wrote:
>>
>>> someone knows if time.windows.com is permanent down?
>>> I can't synchronize since 4 days with this server and I have no idea
>>> when windows synchronize the time with this server successfully last
>>> time.
>>>
>>> I read some psot in some forums, but this posts were from 2007.
>>>
>>> (The question is not "How to select another time server", the question
>>> is if someone knows something about time.windows.com!)
>
>> You think this newsgroup is a free venue to support from whomever at
>> Microsoft is administering their NTP servers?
>
> And where I should ask for information about this? Except for contact
> the paid support? There is no "microsoft.public.general" group,
> microsoft.public.news.server, microsoft.public.msnewservers or
> microsoft.public.windows.server. are wrong too. Therefore I choose
> the best matching (in my opinion) and active newsgroup, even though I
> know this is the wrong group, to ask for information.
That's why I mentioned having to pay for an incident ticket at Microsoft
if you want to go through the effort of trying to get connected to
whomever actually administers that Microsoft server. If someone were to
ask you about Microsoft's server status, could you answer their question
as an *administrator* of that host? We're just users here, too. This
is Usenet, not Microsoft.
I don't recall that Microsoft ever acknowledged that they are
responsible for providing a time service to their Windows customers in
their EULA. They have no service contract with you. They may bring
their NTP server down anytime they wish, do maintenance on it whenever
they wish, get around to bringing it back up whenever they happen to
notice and decide to get around to it, and may simply choose to
discontinue the *free* service.
You explicitly stated that you didn't want solutions that got you away
from using their overtaxed NTP server so I didn't go there.
As a *user*, I did the following tests (but which go beyond what you
asked for):
- A ping gets no response from time.windows.com. That doesn't
necessarily mean their host is down or unreachable. They may not have
enabled the ping reply in their TCP setup (i.e., it is disabled).
Many hosts do not respond to pings. They don't want to waste the
resources to answer them.
- A "telnet time.windows.com 123" command does not get a connection.
However, NTP uses UDP instead of TCP so using telnet may not work.
- A tracert to that host dies at an internal host at Microsoft:
tracert time.windows.com
1 192.168.1.1 (my router)
... (my ISP's network)
8 ge-0-3-0-0.chg-64cb-1b.ntwk.msn.net [207.46.47.178]
9 ge-0-0-0-0.chg-64cb-1a.ntwk.msn.net [207.46.43.150]
10 ge-3-3-0-0.co2-64c-1b.ntwk.msn.net [207.46.43.153]
11 ge-1-2-0-0.wst-64cb-1b.ntwk.msn.net [207.46.43.205]
12 ge-0-1-0-0.cpk-64c-1b.ntwk.msn.net [207.46.43.224]
13 ten3-4.cpk-76c-1a.ntwk.msn.net [207.46.47.197]
14 10.22.0.18
15 Request timed out. (repeats hereafter)
Sometimes that means the route to the target host is unusable because
of an unresponsive node (host) in the route. However, many companies
do not like you wandering through their network and will terminate
traces once you get to their boundary host. So I can't say if a host
in the route is unresponsive or Microsoft blocks further tracing
because the stop occurs at an internal host to their network.
- I use a 3rd party (non-Microsoft) time sync utility. I just now
configured it to *not* use its list of NTP servers (to find the
fastest responding one with the lowest network delay) and had it query
only the time.windows.com host. The NTP query completed okay.
Although I could not use TCP via telnet to connect to the host, and
despite that it doesn't respond to pings, and despite that I couldn't
trace inside of Microsoft's internal network to get to that target host,
the NTP query via UDP did complete okay and I got an update. So, for
me, yes, Microsoft's time server is up and responsive - but that is NOT
what you asked. You asked if their server is down. It might've been
down or unreachable for each time your host happened to try querying
their NTP server. As for you, a node in your route to that host might
be unresponsive, your firewall is blocking the UDP packets (since they
return after the query and will look unsolicited), or something is
failing with your NTP service in Windows Vista or its Windows Time
service is not starting or won't stay running.
I'm using Windows XP and its Windows Firewall service doesn't block
unsolicited inbound UDP connects (which are only of signficance if you
have a listener process on the port to which they connect or are trying
to resolve a DOS attack); however, I'm not relying on the Windows Time
service in Windows to sync my time. Instead I use Socketwatch and it
has been added to Windows Firewall as an exception and why it manages to
keep my host synchronized because a hole for Socketwatch has already
been punched through my firewall. I believe the Vista version of
Windows Firewall has more options, or you might be using a 3rd party
firewall (many of which are more restrictive and do require you to
define an application or exception rule to permit NTP responses). You
could try following the advice at:
http://www.beaglesoft.com/clwaxpfirewall.htm
on how to add a port definition to the exception rules for Windows
Firewall to then check if you can sync to Microsoft's NTP server.