How to Interpret ID 4624 Type 3 Events on a Domain Controller

If you're looking for the interactive logon on a given client computer, the event long on that client computer is where you need to be looking. A user who logs on with, for example, cached credentials, won't be creating entries in the event log of a domain controller. Even if you're not looking for logons with cached credentials, configuring the client computers to audit logon events and looking in the client computer's event log is going to give you the best, most accurate, and easy to locate information.

@gWaldo has a good idea in terms of increasing reliability and updating your outdated DC, but it's a "guess" as to if it'll fix the issue. @Chris-S is correct in comment that bandwidth (at first glance) doesn't sound like it's the issue either.

First you should ensure that WAN connection is reliable, has no packet loss, and has ample available bandwidth throughout the day.

Also a DC not being available will not prevent a Windows client login (assuming default GPO's) because cache credentials on a domain let you in. It would help if you posted the actual errors the users are getting.

For mapped drives, if they are done by login script then you have little to no ability to see any logs about that info, but I would move that functionally to Group Policy Preferences which will let you map drives, make them persistent, and also log to the client event logs on any issues. Your mapping issues could be either they can't get the script, or they can't access the drive... but hard to tell without logging.

Again, keeping DC's current and having one at remote site is "better" but is just throwing darts at the wall of this specific issue. I've had 70-100 remote sites on much lower WAN speeds with no remote DC's act just fine as long as connection was reliable and had available bandwidth.