How to set up a local Windows account

Topic

New Reply

WINDOWS 11 By Will Fastie Microsoft is pushing Microsoft accounts for Windows, but there are good reasons to have a separate local account other than
[See the full post at: How to set up a local Windows account]

9 users thanked author for this post.

jknauth, opti1, IBM1130, Norio, Cybertooth, rc primak, DLivesInTexas, lmacri, fisher75

Reply | Quote

Replies

I have the same local account on all my computers so that I can transfer files between any of them. The only issue I run into is that sometimes one of the computers is not picked up on the network. In the Network section of Navigation pane sometimes the active computers don’t always show up even if I refresh the network line. This has been an issue with Windows for several years now. I end up having to use the \\ with the computer name to bring it up.

JohnD

2 users thanked author for this post.

windbg, Cybertooth

Reply | Quote

I ran into the same problem with computer not showing up in the Network section and also use the \\ workaround. I’m glad to hear it’s not just a problem for me or my home network.

Reply | Quote

Just a quick addition,

You can add local users using the Computer Management MMC – once it’s open (use windows search) go to System Tools -> Local Users and Groups -> Users, right-click in the right pane or select Action and open the New User dialog

It’s a more granular method which I prefer.

 

Kris Arneson

4 users thanked author for this post.

windbg, bbearren, rc primak, EricB

Reply | Quote

If all you want to do is add/modify a local account you can enter lusrmgr.msc in the Run command line and it will open like this –

4 users thanked author for this post.

windbg, Will Fastie, RetiredGeek, rc primak

Reply | Quote

kcarneson wrote:

You can add local users using the Computer Management MMC

This is the method I use, and I only use local accounts—no Microsoft accounts.  For me, there is no good reason to have a Microsoft account.  I do use OneDrive, and it signs in at logon, but it does it online, not on my machine.

Always create a fresh drive image before making system changes/Windows updates; you may need to start over!

We all have our own reasons for doing the things that we do with our systems; we don't need anyone's approval, and we don't all have to do the same things.

We were all once "Average Users".

Computer Specs

Reply | Quote

Am I missing something?

I’m on Win 11 Pro 23h2, and creating a local account is done through Computer Management.  Navigate to Local Users and Groups in the navigation tree, and click the Users folder.  Right click in the client area where the other accounts are shown, and click New User from the context menu.

AFAIK, this has been the process back to Win 3.1.

Reply | Quote

Will Fastie wrote:

I have no immediate (or even anticipated) need for RDP, but I would like to be able to move files between my desktop and laptop Windows PCs.

I think everything you’ve covered can be easily accomplished using RDP.  About the only thing that can’t be done using RDP is a repair/reinstall—that has to be done directly.  There are a couple more, but rarely come up.

Always create a fresh drive image before making system changes/Windows updates; you may need to start over!

We all have our own reasons for doing the things that we do with our systems; we don't need anyone's approval, and we don't all have to do the same things.

We were all once "Average Users".

Computer Specs

Reply | Quote

EricB wrote:

lusrmgr.msc

Us old folks remember all the management consoles because in many cases they were the only way to get things done. But Control Panel is diminishing while more and more is being put into Settings. My goal here was to accomplish this simple task using Settings.

Reply | Quote

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
eventually 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@[xxx.xxx].

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 immediately 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@[xxx.xxx] 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

Moderator Edit: to change email address. Please do not post personal information (email address) on the Forum.

Reply | Quote