DMVPN Phase III is same as Phase 2 but removes some restrictions and complexities of Phase
2. Also allows greater variety of DMVPN network designs we use:
+ ip nhrp redirect in hub: tells the initiator spoke to look for a better path to the destination spoke than through the Hub. Upon receiving the NHRP redirect message the spokes communicate with each other over the hub and they have their NHRP replies for the NHRP Resolution Requests that they sent out.
+ ip nhrp shortcut in spokes: overwrite the CEF table on the spoke. It basically overrides the next- hop value for a remote spoke network from the default initial hub tunnel IP address to the NHRP resolved remote spoke tunnel IP address)

The command "lease 0 12" set the duration of the lease (the time during which a client computer can use an assigned IP address). The syntax is "lease {days[hours] [minutes] | infinite}". In this case the lease is (0 day) 12 hours.
We also notice that the pool of IP addresses that can issue to the clients are rather small as the network 192.168.1.0/24 only supports 253 assignable IP addresses. But the first 49 IP addresses were excluded so we only have 253 - 49 = 204 assignable IP addresses < 300 users.
Therefore the best solution is here to reduce the time of each issued IP address (to 2 hours instead of 12 hours) as they only need to use in 2 hours per day, thus increasing the chance of reuse the IP addresses for the clients.

If a router is configured to get the time from a Network Time Protocol (NTP) server, the times in the router's log entries may be different from the time on the system clock if the [localtime] option is not in the service timestamps log command. To solve this issue, add the [localtime] option to the service timestamps log command. The times should now be synchronized between the system clock and the log message timestamps.
Reference: https://community.cisco.com/t5/networking-documents/router-log-timestamp-entries- are-different-from-the-system-clock/ta-p/3132258