Exercise 1: A Local Security Policy Setting Reverting on a Domain Machine — Possible Solution
====================================================================

WHAT'S MOST LIKELY HAPPENING
------------------------------
Per this chapter's own warn-box, "on a domain-joined machine, a locally
configured policy that conflicts with a domain GPO will be silently
overwritten at the next background refresh - exactly the behavior a
user might report as a setting 'reverting on its own.'" The colleague's
Local Security Policy change most likely conflicts with a domain Group
Policy Object that's already enforcing a different value for that same
setting - and per this chapter, "domain GPOs take precedence over
local policy by default whenever the two conflict."

WHY THIS MATCHES THE TIMING DESCRIBED
------------------------------
Per this chapter, policy changes normally apply "on a background refresh
cycle (roughly every 90-120 minutes, with a randomized offset)." A
setting reverting "within a couple of hours" lines up closely with that
refresh interval - the local change took effect briefly, then the next
scheduled domain policy refresh reasserted the domain GPO's own
conflicting value, overwriting it.

WHY THIS ISN'T A BUG OR A MISCONFIGURATION
------------------------------
This chapter is explicit that this "is domain precedence working as
designed, not a fault in the local configuration." The local setting
wasn't rejected or applied incorrectly - it was genuinely applied, then
correctly overridden by a higher-precedence source exactly as domain
Group Policy is designed to behave, per this chapter's own compare-
table naming Local Security Policy's precedence as "same as Local
Group Policy - same underlying rule," which is lower than any
conflicting domain GPO.

HOW TO CONFIRM IT
------------------------------
Per this chapter, "gpresult /h confirms it directly by naming the
domain GPO actually in control." Running gpresult /h report.html on the
affected machine and checking which Group Policy Object is actually
listed as the source of that specific setting would show the domain
GPO responsible, confirming the cause directly rather than continuing
to guess or repeatedly reapply the local setting.

WHY THIS WORKS AS AN ANSWER
------------------------------
It identifies domain GPO precedence as the specific cause using this
chapter's own warn-box, connects the reported timing to the background
refresh cycle this chapter describes, explains why this reflects
correct behavior rather than a fault, and names the specific
diagnostic step (gpresult /h) that confirms it.