I'm glossing over quite a bit here, of course, but it's a decent semi-technical summary that would be suitable for communicating to others who are not familiar with Active Directory itself, but generally familiar with computers and the issues associated with authentication and authorization.
Active Directory is, at its heart, a database management system. This database can be replicated amongst an arbitrary number of server computers (called Domain Controllers) in a multi-master manner (meaning that changes can be made to each independent copy, and eventually they'll be replicated to all the other copies).
The Active Directory database in an enterprise can be broken up into units of replication called "Domains". The system of replication between server computers can be configured in a very flexible manner to permit replication even in the face of failures of connectivity between domain controller computers, and to replicate efficiently between locations that might be connected with low-bandwidth WAN connectivity.
Windows uses the Active Directory as a repository for configuration information. Chief amongst these uses is the storage of user logon credentials (usernames / password hashes) such that computers can be configured to refer to this database to provide a centralized single sign-on capability for large numbers of machines (called "members" of the "Domain").
Permissions to access resources hosted by servers that are members of an Active Directory domain can be controlled through explicit naming of user accounts from the Active Directory domain in permissions called Access Control Lists (ACLs), or by creating logical groupings of user accounts into Security Groups. The information about the names and membership of these security groups are stored in the Active Directory.
The ability to modify records stored in the Active Directory database is controlled through security permissions that, themselves, refer to the Active Directory database. In this way, enterprises can provide "Delegation of Control" functionality to allow certain authorized users (or members of security groups) to perform administrative functions on the Active Directory of a limited and defined scope. This would allow, for example, a helpdesk employee to change the password of another user, but not to place his own account into security groups that might grant him permission to access sensitive resources.
Versions of the Windows operating system also can perform installations of software, make modifications to the user's environment (desktop, Start menu, behaviour of application programs, etc) by using the Group Policy. The back-end storage of the data that drives this Group Policy system is stored in Active Directory, and thus is given replication and security functionality.
Finally, other software applications, both from Microsoft and from third-parties, store additional configuration information in the Active Directory database. Microsoft Exchange Server, for example, makes heavy use of the Active Directory. Applications use Active Directory to gain the benefits of replication, security, and delegation of control described above.
Whew! Not too bad, I don't think, for a stream of consciousness!
Super short answer: AD is a database to store user logon and group information, and configuration information that drives group policy and other application software.
Best Answer
I don't have a play domain to test against - but if you change the schedule at the "NTDS Site Settings" instead of on each Connection Object, will that accomplish what you want? You may need to delete the existing Objects and let them get recreated with the new schedule.
Obviously, this won't work if you want to change the schedule for only some objects in a site but not all.
(Also, out of curiosity, what problem are you solving by changing this schedule?)