* *** ASKWOODY_WINDOWS_11_INSTALLATION_PROPOSAL_POST TXT - 24 Mar 2025 00:17:32 - JGKNAUTH Windows 11 Installation Proposal ------- -- ------------ -------- (posted as a reply on https://www.askwoody.com/2024/how-to-set-up-a-local-windows-account/ for 9/9/24 AskWoody issue) Because of some possibly unique circumstances for me (see the "Aggravating Factor" section near the end), I'm trying a different way to handle the file sharing problem described in Will Fastie's 9/9/24 article. For various reasons I wanted to avoid creating a second account (local) whose purpose is just to enable the file sharing that could not be done with a Microsoft account ("MS account"). So far my approach seems to be working. Maybe the following details will be helpful to others or maybe someone can point out mistakes I have made. I have also updated my "Windows File Sharing Notes" document, https://jgkhome.name/PC_Info/File_Sharing_Notes.htm >>> BACKGROUND <<<: I recently completed installing Windows 11 on a new PC, which when received had Windows 11 partially installed by Dell. For the installation I used my MS account, as Microsoft wants us to do, instead of a local account. I intentionally decided not to try any of the constantly changing workarounds to enable doing the install via a local account. Of course using the MS account led to the file sharing problem Will described -- an MS account username does not work (at least usually) in the network sharing process if Hello is configured. However it is even worse for me because of the way Windows 11 installation chose to name my \Users\[name] folder; details are in the "Aggravating Factor" section below. >>> SOLUTION <<<: My approach (sometime well after Windows installation was complete) was to convert the installation account from an MS account to a local account. To do this, I just used the normal procedure in Settings > Accounts > Your info > Account settings and ignored the red warning about what facilities I would lose by changing the account to local. (Of course I had done a full system backup immediately before trying this, just in case.) After the account was converted from MS to local, it was able to fully participate in network file sharing. (I was surprised and suspicious that it was so easy.) I haven't seen this conversion approach mentioned elsewhere as a possible solution to the sharing problem. It seems like an obvious thing to try. Am I missing something basic? In the following I will use "convert" and "conversion" as shorthand for the "Microsoft account to local account conversion". The Settings > Accounts ... conversion procedure let me specify a username and password for the soon-to-be-local account. I was able to use jeff as the username. The user folder stayed \Users\jeff, as it had been named (unfortunately) in the Windows installation using the MS account. With the username now being jeff and the account now being local, sharing now worked in both directions across all my PCs, including the new one. Each now had a jeff local account and everything worked as it had in my network before the new PC was added. During all the time before the conversion, the files on the new PC could not be shared to the other PCs. However sharing in the other direction worked fine, i.e., the new PC using my MS account could access shared files on the other PCs. That working direction of sharing was my main need at the time since it eased building the system on the new PC. I did the conversion about two weeks after completing the Windows 11 installation. During all those intervening days I was learning Windows 11 on the new PC, configuring it to my liking (many changes), finding some workarounds for various problems, building my full system with all its applications and my desired Windows settings, etc. My highest priority was to see if there were any bad surprises with Windows 11. The inability to network share files FROM the new PC to other PCs was low priority at the time. Thus the conversion was not done right after the Windows 11 installation. That delay *can be significant* because the system had been heavily modified while running all this time under the MS account. Some resulting fallout is described below, An aside: My other (all pretty old) PCs had originally been on Windows 10 with only local accounts. I installed Windows 11 on one of them over Windows 10; no MS account was required to do that Windows version change. So the sharing problem had not occurred on my network before I had to deal with completing the Windows 11 install on the new PC. Having used only local accounts for many years before, I am very new to the MS account characteristics, benefits, pitfalls, etc., so I could well be missing something that will be a problem later. >>> PROBLEMS <<<: So far I haven't encountered any major problems after the conversion, just some minor ones noted below. Of course there may be remnants of my MS account install that are currently in hiding and waiting to attack. I did find that a Task Scheduler task started failing. It was one I had created under the "jeff" MS account; thus the MS password used for the task was no longer valid now that the account was local. I have recreated the task with the "new" (local) username, which is still spelled "jeff"; the task now works. Many other scheduled tasks were created pre-conversion during the installation of various applications, but fortunately none were affected by the later conversion from MS to local. I'm still able to access my cloud Microsoft account on the Microsoft website, although the path thru Settings > Accounts > Microsoft account > Sign-in seems broken, displaying the scary error message that my email username was now not known to Microsoft! (Something to be investigated later.) However signing in via the web page account.microsoft.com still works as it did before the conversion, e.g., if I need to check on the status of a purchased product or (presumably) to activate a product. I'm assuming the error message on the Settings > Accounts path is something I can ignore for now. One time the cloud account sign in insisted that I had to use a pin or facial/fingerprint recognition, but eventally it went back to just accepting my MS password, the normal procedure I have used for years. I don't know what caused that temporary change to requiring local credentials. OneDrive remnants (warning messages) sometimes still appeared unexpectedly after the conversion. After Googling "stop OneDrive" I found I needed to "unlink" it from my PC, which I did by following the instructions in Microsoft's "Turn off, disable, or uninstall OneDrive" webpage. Other things may pop up, given that I had done so much setup work before doing the conversion instead of converting immediately after the Windows install completed. For anyone using this approach, to minimize such possible problems I would definitely recommend doing the conversion right away after the Windows installation completes. >>> SOME UNKNOWNS <<<: I don't know if it is easy or even possible to switch the jeff local account back to an MS account if needed for some reason. It appears it should be possible in Settings > Accounts, but I haven't tried it. Also, I see areas where Windows encourages you to "Sign in to your Microsoft account". I didn't test those, but assume they would try to convert my account back to an MS account, which I don't want to do unless needed. OneDrive was thrust upon me because I installed Windows using the MS account. I'm unfamiliar with OneDrive and was concerned about some of the warning messages it started producing. Probably this was all normal, associated with the installation process of my many applications and the associated deletion of temporary work files. Anyway, it was worrisome to a OneDrive neophyte and I was glad not to be so entangled with OneDrive after I did the conversion. Again, the quicker the conversion is done, the better. I don't know if OneDrive is now broken for me, but I didn't use it before and don't really care if I can't use it now. This conversion approach may not work as well for others, those who want to be more integrated with MS, e.g., maybe with heavy use of OneDrive, or who want settings syncing somehow across multiple PCs, etc. Those are things I don't use currently and are far less important to me than network file sharing. >>> STATUS <<<: I have been using this new setup heavily for nearly two weeks now. It's working fine so far for the things I do. All the applications I had set up when building my full system under the MS account (including Office 2024), all the Windows settings, etc., seem to have survived the conversion. Also, my Hello facilities after a restart (facial recognition, fingerprint recognition, and pin) all work as they did when my account was MS instead of local. Presumably that's because those credential checks are handled entirely at the PC and do not require anything from the cloud MS account. It's strange that the MS account, with Hello configured, normally says a password no longer works for that account; thus the MS username cannot be used in a credential. Yet a local account works with Hello and still has a recognized password, so its username can be used in a credential. Do I have that right? >>> AGGRAVATING FACTOR <<<: I was forced to do something like the account conversion because of the way the Windows 11 install process named my \Users\[name] folder. For that folder, Windows apparently uses up to the first five characters of the user name in the user's email address for the folder name instead of letting the user choose the name during Windows installation. (The full email address is used as the MS account username.) Thus my folder name became \Users\jeff because my email address is jeff@jgkhome.name. Given that unfortunate folder naming, I assumed I would be unable to set up another account on the new PC (this one local) with a username of jeff so I could do file sharing across all my PCs using jeff as the local user on each. Given that, I didn't try the "create a new, local account to enable sharing" approach or variants of it. I wanted first to see if the simple "account conversion" would work. So far it has -- at least for the requirements I have, which are met by every account being local. Also, I have tools that depend on the \Users\[name] being \Users\jeff. I did not want to modify those tools if I could avoid it. I'll be very happy if the converted system continues to work with just local jeff on all the PCs. If the \Users\jeff conflict had not existed at the start, I probably would have installed using the MS account, then immediatedly created a jeff local account and built my system on that account, never going back to the MS account, unless required to for some currently unknown reason. >>> FALLBACK PLAN <<<: If the conversion approach had failed, my "I sure hope I don't have to do this" fallback plan was: 1) Restore the system from my backup. 2) Use the restored MS account to create a temp local admin account. 3) Use the temp account to delete the jeff@jgkhome.name account. 4) Create a jeff local account, now that \Users\jeff was freed up. 5) Rebuild my whole tailored system on the jeff local account. Ouch! 6) Delete the no-longer-needed temp account. I was pretty sure files could then be shared back and forth among all the jeff PCs. However rebuilding what I had done in the original MS account to set up my normal environment would have been a *LOT* of work. >>> MY SUMMARY DOCUMENT ON SHARING <<<: While doing sharing experiments over a number of years, just to get my own network able to do what I wanted, I created a document summarizing my experiences: https://jgkhome.name/PC_Info/File_Sharing_Notes.htm . I have now updated it after my recent Windows 11 work. It does not try to detail the conversion described above, but mainly focuses on network file sharing in which "all accounts participating in sharing are local", not how they might have become local. It puts together in one place the sharing information I wish I had years ago. It also points out what appear to be some Windows bugs I hit during my recent share testing as well as including a lot of details on that testing. I hope it's accurate and can help others. Jeff