A client’s pilot deployment of Windows 11 24H2 (2024 H2 update) did not go as planned. What was intended as a routine in-place upgrade from Windows 11 23H2 turned into a troubleshooting saga. Multiple devices experienced severe issues during or after the upgrade process, forcing us to halt the pilot. Initially, the root cause was unclear – the symptoms were varied and perplexing. After an in-depth investigation, we identified a single configuration setting as the common denominator: CIS Benchmark Recommendation 18.9.17.3, “Disable OneSettings Downloads” set to Enabled. This seemingly innocuous hardening setting was directly responsible for the cascade of upgrade failures we observed.

In this post, we will detail the issues encountered, how we traced them to the OneSettings service, and why the “Disable OneSettings Downloads” Group Policy (a CIS-recommended security measure) interfered with the Windows servicing stack. We’ll also discuss how this setting impacts the upgrade Panther logs, what OneSettings does during an OS upgrade, and why a security configuration meant for protection can introduce operational risks during OS servicing.

Symptoms Observed During the Upgrade

During the production pilot, a range of issues surfaced on the test machines. These were not typical minor upgrade glitches, but serious failures that halted or reversed the upgrade. Key symptoms included:

  • Unexpected Dual-Boot Entries (Boot Configuration Corruption): After rebooting into the 24H2 upgrade, many PCs presented a dual-boot menu with two Windows 11 options. In effect, the upgrade process left the new 24H2 installation alongside the old 23H2 installation instead of replacing it. This “dual-boot” scenario indicated the upgrade hadn’t finalized properly – the system was confused about which OS was the active one. Users had to manually pick an OS at boot, and often the new 24H2 option failed to load, reverting to the older version.

  • Domain Trust Loss: Several machines, upon rolling back to 23H2 after a failed upgrade, could no longer authenticate with the domain (“The trust relationship between this workstation and the primary domain failed”). We discovered that these computers had to be rejoined to Active Directory. This suggested something during the upgrade process (or its failure) disrupted the computer’s domain credentials – a severe side effect for enterprise devices.

  • Stalled or Incomplete Upgrades: Many systems got stuck partway through the installation (for example, at 85% or 98% progress) and then eventually reverted to the previous version. In some cases, the upgrade appeared to hang indefinitely, forcing a hard reboot. When the machines restarted, Windows reported “Failed to install update” with generic error codes. Notably, one error code we saw was 0x80070002, a generic “file not found” error, which on the surface didn’t reveal much.

  • Inconsistent Behavior Across Devices: Perhaps most frustrating was the lack of a uniform failure pattern. Some PCs cleanly rolled back to 23H2 without user intervention; others ended up in the dual-boot state. A few actually succeeded in upgrading to 24H2 with no issues at all. This inconsistency made it hard to pinpoint the cause – hardware models and images were standardized, so why were outcomes different? The inconsistent behavior hinted that a timing or environmental factor (like network connectivity or policy application) might be at play, rather than a simple bug that hits every machine the same way.

Faced with these issues, our team dug into the problem using log analysis and a process of elimination. We suspected everything from driver incompatibilities, to BIOS settings, to group policies. Only after examining the Windows Setup “Panther” logs did a clue emerge pointing to a less obvious culprit.

Investigation: Digging into Panther Logs and Servicing Stack Errors

Windows upgrades produce extensive logs under the C:\Windows\Panther\ directory (and its subfolders like Panther\Unattend or Panther\NewOS). We collected the setuperr.log and setupact.log from several failed upgrade machines. In these logs, a pattern became clear – there were repeated OneSettings-related errors at the time the upgrade failures occurred.

For example, in the setuperr.log of multiple affected PCs we saw entries like:

Error MOUPG SetupHost: OneSettings initialization failed: [0x80072EE2]
...
Error CONX AppraiserSettings::GetSettingsInternal: Failed to Query OneSettings [0x80072EE2] :: (AllowedToQueryServer:[TRUE])​:contentReference[oaicite:0]{index=0}​:contentReference[oaicite:1]{index=1}

These messages were crucial. The MOUPG and CONX prefixes indicate components of the Windows Setup and compatibility appraiser (responsible for checking system compatibility and coordinating the upgrade). The error 0x80072EE2 is a WINHTTP timeout/error indicating the system could not reach a server. In plainer terms, Windows Setup was trying to initialize “OneSettings” and failing to connect – it retried and ultimately gave up. The log even shows AllowedToQueryServer:[TRUE], meaning the system believed it was permitted to contact the OneSettings service and attempted to do so. Despite permission, the connection could not be established.

Another related error we saw in logs was:

Error CONX AppraiserSettings::GetSettingsInternal: Failed to retrieve DeviceTicket: [0x800704CF]​:contentReference[oaicite:3]{index=3}

The code 0x800704CF translates to “network location cannot be reached.” This further reinforced that the upgrade process was unable to reach out to Microsoft’s servers for something called a Device Ticket or configuration data, presumably via the OneSettings service. Essentially, the compatibility appraiser and servicing stack were flying blind – they could not download the configuration and compatibility settings needed for a smooth upgrade.

These OneSettings errors lined up with the timing of the failures (the stalls around 85–98%). It appeared that OneSettings connectivity issues were stalling the upgrade until a timeout was reached, at which point the installation either rolled back or left the system in an incomplete state (hence the dual-boot remnants). The fact that some PCs eventually did upgrade successfully hinted that perhaps those machines had momentary connectivity or some difference that let OneSettings succeed where others failed.

At this stage, we had a strong lead: something was blocking or breaking OneSettings connectivity in our environment. We next examined our group policies and security baseline settings, since all machines in the pilot were built from the same hardened image. Very quickly, we found a likely suspect in our CIS (Center for Internet Security) baseline GPOs: “Disable OneSettings Downloads” was Enabled across these systems. This setting, part of the CIS recommended security configuration, immediately stood out given the errors we saw.

Root Cause: CIS 18.9.17.3 “Disable OneSettings Downloads”

After identifying that the CIS 18.9.17.3 policy was enabled in our environment, we had our “aha” moment. This policy setting’s name is self-explanatory: it prevents Windows from downloading data via the OneSettings service. In our case, this GPO was applied as part of a Level 1 CIS hardening benchmark for Windows 11. The intention of the policy is to enhance privacy and security, but as we discovered, it came with unintended consequences for OS upgrades.

What is OneSettings? OneSettings is an under-the-hood Windows service/feature that isn’t well-documented publicly. From what’s understood, it’s a cloud-service connection that Windows uses to download configuration settings and telemetry-related data to “keep the computer healthy” (for instance, pulling down updates to Windows compatibility lists, feature configuration, or health telemetry info). It is not a traditional local Windows service with a running process – rather, it’s a cloud endpoint that the OS contacts during certain operations. In later builds of Windows 10 and Windows 11, the OneSettings service is leveraged during Windows Update and upgrade processes to fetch the latest configuration information (such as whether the device should be blocked or if there are critical patches to apply during upgrade).

What the CIS policy does: The CIS recommendation 18.9.17.3 specifically advises enterprises to enable the policy “Disable OneSettings Downloads,” which turns off Windows’s attempts to contact the OneSettings service. According to the CIS documentation, “This policy setting controls whether Windows attempts to connect with the OneSettings service to download configuration settings. Because transmission of data to a third-party vendor can present a security risk, the control disables these downloads.”  In other words, from a security standpoint, OneSettings is seen as a potential avenue for data exfiltration or unwanted external communication (since the “vendor” in this case is Microsoft’s cloud). By disabling it, organizations aim to prevent any behind-the-scenes exchange of configuration or telemetry data with Microsoft.

In our environment, this policy was enabled on all pilot machines (as is common in tightly secured enterprise images). The result: whenever the Windows 11 24H2 setup tried to utilize OneSettings, the policy blocked it. This manifested exactly in the Panther logs – OneSettings initialization would immediately fail. The upgrade process could not download critical upgrade configuration data due to our own policy.

We confirmed this root cause by performing a controlled test: on an identical machine, we disabled the “Disable OneSettings Downloads” GPO and retried the 24H2 feature update. The upgrade completed without any of the previous issues. No dual-boot entry, no hang – the machine cleanly updated to 24H2. This correlation was further backed by reports from the tech community. For example, one administrator noted that Windows 11 23H2 cumulative updates were failing in their environment until they reversed the ‘Disable OneSettings Downloads’ setting, which had been applied per CIS benchmarks​. In our case, it was the feature update that was failing, but the fix was the same. Thus, we confirmed the CIS OneSettings policy as the root cause of our pilot failures.

How “Disable OneSettings Downloads” Disrupts the Upgrade Process

Why did disabling OneSettings downloads wreak such havoc on the feature upgrade? The Windows servicing stack expects to be able to use OneSettings for certain tasks during an OS upgrade. Let’s break down the technical interference caused by this setting:

  • Blocked Compatibility Updates: OneSettings is used by the Windows Compatibility Appraiser – a component that runs during upgrades to assess software/hardware compatibility and to fetch any known issue blockers. By disabling OneSettings, our systems likely failed to download the latest compatibility database or “device ticket” from Microsoft. The logs (Failed to retrieve DeviceTicket) hint that our PCs could not obtain a token or config that might relate to compatibility approval. This means the upgrade might proceed without awareness of known issues or without proper config for the device. In some cases, Windows Setup will fail if it cannot verify compatibility or gets no answer from the service, which explains the immediate errors (0x80072EE2). In other cases, it might proceed with stale or no data – essentially a blind upgrade – which can cause unpredictable outcomes (e.g. hitting an issue that would normally be flagged as a “block” condition). In short, the CIS setting removed an essential safety net and communication channel for the upgrade.

  • Servicing Stack Failures and Timeouts: The servicing stack (the part of Windows that orchestrates updates) has built-in steps to contact external services (Windows Update, OneSettings, etc.) for content and instructions. With OneSettings connectivity disabled, the servicing stack would hang at steps waiting for responses that never came. The error code 0x80072EE2 is a timeout – the setup waited but the connection was prevented. These timeouts translated to long stalls during installation (users seeing the progress bar stuck). Eventually, Setup might time out and attempt to continue without that info or trigger a rollback. This explains why many upgrades froze near the end – they were likely waiting for OneSettings data before finalizing.

  • Dual-Boot (Rollback) Scenario: When an in-place upgrade fails late in the process, Windows will usually revert to the old OS but sometimes fails to clean up everything. In our case, the new Windows 11 24H2 files were actually installed (hence an extra boot entry existed), but because OneSettings failure prevented a clean commit, the system fell back to 23H2 as the default. The leftover boot menu entry for 24H2 indicates the rollback wasn’t fully tidy. This is a direct consequence of an upgrade failure in the final stages. Disabling OneSettings led to an incomplete upgrade, where the installer had gotten far enough to copy the new OS, but not far enough to switch over entirely. We had essentially a partially aborted transplant of the OS.

  • Domain Trust Issues from Rollback: The domain trust problems we observed are a secondary effect of the rollback and dual-boot mess. When a machine joins a domain, it has a secure channel and password with the domain. If the upgrade process changes the machine’s SID or if the machine’s domain password was changed during the attempted upgrade (which can happen if the upgrade spanned multiple reboots and the computer account password cycled, or if the rollback restored a system state not in sync with AD), the trust can break. We suspect that the repeated failed upgrade attempts (and possibly the time taken during troubleshooting) caused some machines to revert to a state where their idea of the domain trust didn’t match the domain’s. Additionally, an OS upgrade could temporarily sever domain connections (especially if system restore points or rollbacks occur). Thus, the OneSettings-induced failures indirectly led to some machines losing domain trust, requiring a rejoin to fix.

  • Inconsistent Behavior Explained: The variability in outcomes across devices can be tied to how each device handled the blocked OneSettings calls. It’s possible that slight differences in network conditions or timing caused some machines to fail more ungracefully than others. For instance, if a PC had no internet connectivity at all, the OneSettings failure might have been immediate and the installer could have decided to abort early (resulting in a clean rollback). Another machine with intermittent connectivity might have partially downloaded something or taken longer to time out, causing a more tangled rollback (e.g. leaving a dual-boot entry). Additionally, some machines might not have encountered a particular known issue, so proceeding without OneSettings data didn’t hurt them – those rare cases might actually upgrade successfully because they effectively ignored the OneSettings step and luckily didn’t need it. This explains why a handful of PCs updated to 24H2 fine – if their configuration had no latent incompatibilities that Microsoft would normally flag via OneSettings, they could squeak by. However, relying on luck is not acceptable in production; the inconsistent results were a symptom of a process being subverted by the policy.

In summary, OneSettings plays a vital role in feature upgrade orchestration (especially for fetching cloud-based configuration, compatibility updates, and possibly license/telemetry settings). Our hardened configuration that disabled OneSettings cut off this vital link. The result was akin to attempting to drive with a blindfold on – some might get to the destination by memory, but many will crash or take a wrong turn. The CIS setting introduced conditions the upgrade process was not designed to handle, leading directly to the failures observed.

Security Intent vs. Operational Impact

It’s important to understand that the “Disable OneSettings Downloads” policy was enabled for good reasons from a security perspective, especially in an enterprise that values a hardened build:

  • Why Hardened Environments Disable OneSettings: In high-security environments (government, financial, or other sensitive industries), outbound communication from endpoints is tightly controlled. Even communication with Microsoft’s own services can be seen as a risk if not strictly necessary. The OneSettings service downloads “configuration settings” from Microsoft – this could potentially include telemetry configurations or other system parameters. From a security viewpoint, administrators may worry that this could either expose information (sending device data to Microsoft) or pull down configurations they don’t control. The CIS Benchmarks, which are widely respected guidelines for system hardening, explicitly call for disabling OneSettings downloads​ as a Level 1 (essential) recommendation. The logic is that “transmission of data to a third-party vendor can present a security risk”, so better to shut it off at the source. Microsoft is considered that third-party “vendor” in this context, although the communications are detrimental to ongoing maintenance of the operating system. In essence, the policy is a preemptive strike against unwanted telemetry or cloud changes on the machine.

  • A Double-Edged Sword: While the security rationale is sound, the operational side-effects were clearly underestimated. By following this recommendation, we unknowingly created a situation where Windows could not properly perform a feature update – a core maintenance task. It’s a classic example of security configurations competing with functionality. Many CIS hardening settings have some trade-off, but this one in particular is not well-documented in terms of its impact on Windows Update/upgrade. In hindsight, it makes sense: a feature upgrade is a major event where the system likely needs to communicate with Microsoft for things like update metadata, drivers, or compatibility details (especially now that Windows 11 updates are very cloud-driven). Blocking OneSettings is essentially blocking part of the update’s intelligence. We essentially told Windows “do not trust or accept anything from the cloud,” and Windows in turn couldn’t get the info it needed to upgrade us safely.

  • Why Microsoft Allows This Setting: Microsoft provides the OneSettings disable option precisely because some customers demand the ability to turn it off (for privacy or policy reasons). They also offer a complementary policy, “Enable OneSettings Auditing”, which we had enabled as well per CIS guidelines. Auditing OneSettings attempts (when enabled) can log events whenever the OS tries to reach out to the service​. In a perfect world, an admin might see those audit logs showing blocked attempts during an upgrade and catch on. However, in our case, the failures were so disruptive that we dived straight into setup logs. We will, going forward, also review the Event Logs for OneSettings audit events as part of troubleshooting.

  • The Balance – Hardened but Functional: The experience underscored that enterprise IT must balance hardening with operational requirements. A setting that is great for reducing risk surface can introduce new risks if it prevents system updates or causes instability. In this case, the risk was not a security breach but rather an availability and reliability risk. Feature updates are crucial for getting security patches and improvements; if they can’t be applied, that’s a problem in itself. Additionally, failures like domain trust loss directly impact user productivity and IT support burden. So, one could argue that for a device to remain secure and supported, it must be able to upgrade cleanly – meaning OneSettings needs to function during those maintenance windows.

 

Lessons Learned and Recommendations for 24H2 Deployments

Having confirmed “Disable OneSettings Downloads” as the root cause, we updated our rollout plan and baseline configuration. Here are our key takeaways and recommendations for other enterprise teams, especially those using CIS or similar hardened baselines:

  • Temporarily Relax OneSettings Policy for Feature Updates: We plan to disable or not configure “Disable OneSettings Downloads” during our Windows 11 24H2 deployment window, then re-enable it post-upgrade if still desired. This could be handled via a maintenance GPO that is applied only when upgrading. In our tests, allowing OneSettings connectivity immediately resolved the issues. For any enterprise applying CIS benchmarks, consider carving out an exception for this policy when performing major version upgrades. Alternatively, if policy mandates no cloud contact at all, use an offline upgrade approach (for example, running the setup from media with the /dynamicupdate disable switch to avoid online fetches). Keep in mind, though, that bypassing dynamic updates can itself lead to other issues – so our preference is to briefly allow the necessary cloud communication.

  • Ensure OneSettings Auditing is Enabled: As recommended by CIS 18.9.17.5, have “Enable OneSettings Auditing” turned on (set to Enabled)​. This logs OneSettings connection attempts in the Event Log. These audit logs can serve as an early warning – during an upgrade, you might catch events indicating the system tried to reach OneSettings. If those events coincide with failures, you have a strong clue. In high-security environments, auditing provides visibility so that if something or someone tries to use OneSettings, it doesn’t go unnoticed.

  • Examine Panther Logs for OneSettings Errors: If you encounter odd in-place upgrade failures (especially ones that result in rollbacks or hanging at high percentages), check Panther\setuperr.log and look for “OneSettings” entries. Errors such as “OneSettings initialization failed” or “Failed to Query OneSettings” are a clear indication that the OS is unable to reach Microsoft’s OneSettings service. This could be due to group policy (as in our case) or general network connectivity issues. In either case, if you see those entries, focus your troubleshooting on network access and policies related to Microsoft’s endpoints. In our scenario, that was the smoking gun in the logs that pointed us in the right direction.

  • Beware of Blindly Applying Benchmarks: CIS and other security benchmarks are invaluable, but they are generic recommendations that may not account for every environment’s operational needs. Always test security baseline changes in a staging environment with software update processes included in the testing. Our pilot did exactly what it should – it revealed a hidden issue before we rolled out to the whole company. It’s a reminder that even “Level 1” (general consensus) security settings can have side-effects. We will be feeding back our findings to our security team to weigh the necessity of this particular setting. The security benefit of disabling OneSettings (preventing some telemetry/config data flow) must be weighed against the requirement to keep systems reliably up-to-date. For many enterprises, it may be acceptable to leave OneSettings enabled (or at least enable it during upgrades) to avoid these headaches.

  • Communicate with Stakeholders: After discovering the cause, we communicated with both our security policy team and our helpdesk/Desktop support teams. Security needs to know that this CIS control can impede updates, and IT support needs to know that if they see dual-boot issues or trust relationship errors around an update cycle, this policy could be the root cause. Moving forward, any documentation for Windows 11 24H2 deployment in our organization will include notes about this setting. We’ll also include recovery steps: e.g. if a machine ends up with a duplicate boot entry, how to remove the stale entry; if domain trust is lost, how to rejoin quickly. Proactive communication can prevent panic when such issues arise unexpectedly.

 

Our failed Windows 11 24H2 pilot taught us a valuable lesson about the interplay between security hardening and system maintenance. The CIS “Disable OneSettings Downloads” policy (18.9.17.3) was applied with the best of intentions to strengthen security. However, in practice, it crippled the Windows servicing stack’s ability to perform an in-place upgrade, leading to corrupted boot configurations, failed installations, and domain issues. Only by tracing through Panther logs and understanding what OneSettings does were we able to connect the dots between this policy and the upgrade failures.

For enterprise IT professionals planning Windows 11 24H2 (or any future Windows feature update) deployments, our story highlights the importance of reviewing your group policies and security baselines in the context of upgrades. Not every security setting is benign when it comes to major OS changes. In this case, a cloud-communication-related setting introduced an operational risk greater than the risk it was mitigating. The key is to find the right balance: maintain security where you can, but don’t sacrifice the ability to update and manage your systems reliably. After all, staying on supported, patched versions of Windows is itself one of the best defenses against security threats.

By adjusting our approach – relaxing the OneSettings download restriction – we were able to get our 24H2 upgrades back on track. The pilot is now proceeding with this adjustment in place, and thus far, none of the earlier issues have recurred. Going forward, we will treat OneSettings connectivity as a required component for feature updates in our enterprise. We hope our experience can serve as a cautionary tale and a guide for others: always consider how a hardened configuration might impact system behavior, and leverage pilot programs and log analysis to catch these issues before wider deployment. With the right insights and preparation, you can have both a secure and a smoothly operating environment.

Hope this helps!
É