Presumably this won't happen if you're logging in using a local[1] Active Directory domain account, where Microsoft account login makes no sense, so setting up

Presumably this won't happen if you're logging in using a local[1] Active Directory domain account, where Microsoft account login makes no sense, so setting up and logging in through a local AD domain is one potential workaround. Doing this is nontrivial and not without consequences, however, so I wouldn't recommend it unless you have more interesting reasons (see below for one example) for setting up an AD domain than to avoid a nag screen. Complications include: 1. Home editions of Windows don't support domain logins. 2. In-place migration from a local user account to an AD account without losing user profile information or ACL-protected resource access granted to the local user is neither automatic nor trivial. 3. Setting up an AD domain requires either an additional computer or VM running Windows Server or Linux[2] to serve as a domain controller. 4. While desktop Windows is supposed to cache logins to allow local login without connecting to the DC, in my experience, this mechanism usually works, but very occasionally fails for reasons I don't recall, so mobile domain login is not risk-free. 5. Cached logins only apply to local logins; remote logins using AD credentials require DC access. This is an issue, e.g., when authenticating between domain-joined VMs on a development laptop. 5a. This can be worked around by maintaining a VPN connection between the laptop and the DC's network or installing a (possibly read-only) DC replica on the laptop (obviously avoid the latter in any case where DC compromise will materially affect the security of anything beyond the laptop itself). 5b. Active Directory relies on DNS for name resolution, so either workaround requires additional care and feeding to avoid complications when traveling and connecting to other networks. Namely, use [3] to redirect DNS queries for the AD domain to the VPN or VM, and make sure the VPN or VM network isn't allowed to override the local DHCP-assigned DNS server addresses (which most VPN clients do by default). The one significant upside that has made a personal AD domain ultimately worthwhile for me — speaking, admittedly, as someone with significant prior AD deployment and administration experience — is AD group policy, which has allowed me to set convenient defaults that automatically apply to the dozens, if not hundreds, of often transient Windows development and test VMs I've set up over the years, including disabling pretty much every other undesirable "feature" Microsoft has added to Windows in the past decade (e.g., Cortana, Bing, and advertising in the Start menu). [1] I'm assuming local because, if you don't want to log in using a Microsoft account, you presumably don't want to log in using an Entra née Azure AD account either, given that the latter is, for present purposes, a Microsoft account that's more complicated to set up. [2] https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Directory_Domain_Controller https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Acti... [3] https://learn.microsoft.com/en-us/powershell/module/dnsclient/add-dnsclientnrptrule https://learn.microsoft.com/en-us/powershell/module/dnsclien...