Why would NTP service successfully exit

I am having recurrent problems with stalled datetime on my virtual Debian 8 machine running in Windows 8 Hyper-V. I haven't done much of a post-install configuration, it's a deliberately rather vanilla install and no fancy stuff — I just use the box as a self-contained POSIX environment, logging in with PuTTY through SSH.

The date seems to "freeze" when the host sleeps and I wake it up after flipping the lid on host laptop after a day or so. The SSH session to the VM from PuTTy on Windows always remains intact. I didn't want to muck about with Hyper-V specific time synchronization services for Linux, I am content with using NTP. NTP has been installed with apt-get install ntp and initially I was getting the following with systemctl status ntp:

● ntp.service - LSB: Start NTP daemon
   Loaded: loaded (/etc/init.d/ntp)
   Active: active (running) since Mon 2017-08-14 23:16:55 CEST; 20h ago
  Process: 1167 ExecStop=/etc/init.d/ntp stop (code=exited, status=0/SUCCESS)
  Process: 1175 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/ntp.service
           └─1184 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 108:115

Today after waking the laptop up and again observing the "frozen" date from yesterday, same command as above tells me the service has exited:

● ntp.service - LSB: Start NTP daemon
   Loaded: loaded (/etc/init.d/ntp)
   Active: active (exited) since Mon 2017-08-14 21:28:57 CEST; 1h 43min ago
  Process: 450 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)

Why does the service seemingly exit on its own? Apparently it exits as soon as the host thaws from sleep/hibernation. And with 0/SUCCESS of all things, letting me believe it behaves so by design and without encountering errors?

Once I systemctl restart ntp the process is back among scheduled processes and date is synchronized. Doing systemctl start ntp doesn't have same effect (maybe because it's already "loaded"/"active").

What's going on? Isn't NTP supposed to be running all the time, periodically synchronizing the clock as necessary when it drifts? Is this some Hyper-V related module in the kernel taking up on Microsofts recommendation not to use NTP with virtual machines, or maybe the network stack causes NTP to bail? Even though it's UDP and even SSH to the VM persists, so why would that be an issue?

/etc/ntp.conf, never edited it myself:

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(6) for help

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient