Replies

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.

I now run only Windows 10 on this PC, but it is actually a dual-boot system via TeraByte Unlimited’s BootIt UEFI (BIU), which I use for backups/restores and other partition work. After a recent attempted reboot, my PC got the deadly “Verifying shim SBAT data failed…” message briefly; then the system powered off. The same thing happened on any subsequent poweron.

Apparently the newer version of BIU (v2.01) makes windows happier. I have now installed that upgrade on two PCs that had the “shim SBAT” problem. So far all now works again.

I don’t know if BIU itself is based on Linux. At any rate BIU seems to experience the same “shim SBAT” problem that many Linux users have now reported. Apparently it was the installation of Windows update KB5041580 that caused all this. I had installed KB5041580 on 8/14/24 and had no problems with it until I rebooted today.

I recently replaced a desktop’s HD with an SSD, but had some special
considerations because of the partitioning/multibooting I do. Woody
suggested that I post my experience as a reply to Fred’s post.

I have a desktop that runs 24/7/365, doing World Community Grid work
when I am not on the system. I thought the PC’s 4.5-year-old 2TB hard
drive was started to make some peculiar sounds. (Its predecessor had
lasted only two years.) Encouraged by Fred’s recent Crucial SSD
experience, I bought an MX500 and successfully replaced the old HD.

For most desktop configurations this is pretty easy to do. I had to get
a bracket to fit the 2.5″ drive into the space built for 3.5″ drives in
my Dell XPS 8500 desktop. I also bought a SATA-USB3 cable to clone my
old drive to the SSD, as shown in the Crucial videos.

The difficult part was the disk cloning. I had done some pretty
complicated partitioning on my hard drive, using TeraByte’s BootIt Bare
Metal (BIBM). I use the BIBM facility to enable more than four primary
partitions so I can boot from many different partitions for testing. Of
course nowadays Dell and Microsoft create their own special primary
partitions for utilities, factory restore, system partition, etc. BIBM
by default even creates a tiny one of its own. Also I have an extended
(primary) partition for logical volumes. At last count I have nine
primary partitions and can multiboot to many of them. To enable all
this, BIBM creates a special Extended Master Boot Record (EMBR) to
replace the disk’s standard MBR — a potential stumbling block for disk
cloning softwatre.

Note my desktop is an old, non-GPT, non-UEFI system. BIBM does not
allow booting from a GPT partition, so I stayed with NTFS. There is a
new BootIt UEFI (BIU) product from TeraByte that removes some prior
restrictions, but I don’t have any experience with BIU yet. Probably on
my next new PC. One step at a time.

Given the complicated disk structure, I was concerned that the Crucial
(Acronis) copy/clone software would not be able to clone the HD
properly. I had a chat session with Crucial Support and they agreed. I
had suggested using BIBM’s Disk Imaging facility instead. They agreed
with that as well, so that’s what I used. It worked.

The only problem I had with the BIBM cloning was the time it took. That
was probably my fault. I could have opened up my desktop and put in the
SSD as a second SATA drive. That should have made the cloning go very
quickly (I’m pretty sure). However putting in a second drive in that
desktop requires some extra steps — you have to remove the HD cage to
get at the second slot. In contrast, cage removal is not required to
get to the first slot. So I decided to just use a SATA-USB3 cable to
clone the drive externally, per the Crucial videos, which are geared
toward laptops. I knew it would take longer, but it seemed safe.

I had previous experience when replacing the original hard drive years
ago. For that I had put the replacement drive in an external drive
enclosure (an old Thermaltake BlacX ST0005U) and easily did the cloning
using BIBM in about an hour. Unfortunately I had forgotten that I had
used an eSATA cable instead of USB3 to connect the BlacX to my PC, which
has an eSATA port, so the drive was effectively inside the PC directly
on the SATA bus. Fast.

In any event, although the BlacX has a 2.5″ slot, I decided not to try
using it for the HD to SSD cloning since I was concerned I might fry the
SSD (different voltages?). I think newer BlacXs may support SSDs, but
was dubious if my old one did. I sent a query to Thermaltake Support on
this, but never got a response. I played it safe and did not really
consider using the BlacX. Had I thought more about using it, I would
probably have remembered why that external cloning with BIBM had gone so
quickly — the eSATA connection.

Long story short, the cloning thru the SATA-USB3 cable with BIBM worked,
but took almost *nineteen* hours. I suspected the USB3 connection to a
known-good USB3 port got dropped to USB2, either because of some
inherent BIBM restriction or because of the options I had selected for
the cloning. Anyway, it finally completed without any errors. I was
patient.

The good news was that I was able to immediately boot Windows on my
production WIN10 partition. All looked normal. Later I did some BIBM
tests. I made a copy of the WIN10 partition to my TEST2 partition’s
space, then booted the TEST2 partition successfully. I next did a
backup of WIN10 to an external hard drive and then did a restore of that
external image to my TEST3 partition, then booted TEST3. All went
normally.

With the SSD I am now back to where I was with the old hard drive —
able to copy partitions, back up and restore partitions, and multiboot
from numerous primary partitions. The SSD is faster and produces no
worrisome sounds (hopefully it has some way of telling me if it is about
to die). The cloning just took much longer than I expected. If I were
doing it again, I would probably just remove the HD cage and install the
SSD as a second drive. That would require at least two cage removals:
remove cage, insert the SSD in slot 2, replace cage, clone, remove cage,
take out the dying drive from slot 1 and put the SSD in its place,
replace cage. Or maybe use some modern enclosure with SSD and eSATA
support?

I later reported my experience to TeraByte Support, asking if there were
different parameters I should have used. The answer I got was
essentially that’s the way it is for that type of connection if BIBM
(actually Image for DOS) is used — a BIOS limitation. However it would
have gone much faster if I had used their Image for Windows or Image for
Linux products, which bypass BIOS. It’s not too important to me now,
unless I have to do this again some day.

Possible addition: As described in Fred’s post, Crucial has optional
Momentum Cache software to speed up its SSD even more. I wasn’t sure if
it would play well with BIBM. I posted a query on the TeraByte BIBM
forum. Terabyte Support quickly responded that they were unfamiliar
with Momentum Cache, but said “you’d want to ensure it’s not something
that lives across reboots and it’s abstracted by the firmware so it
looks and acts like a regular drive.” I later found this Micron
writeup, “TN-FD-32: Enhancing SSDs With Momentum Cache – Crucial”,
which provides some more details (Google search for it). I passed that
info on to TeraByte, with my thought that as long as you did a full (no
Fast Startup or Hibernate) shutdown to be sure the MC cache was flushed,
MC sounded safe in a multiboot environment. (The Crucial PDF doesn’t
make clear when a “shutdown” flush is done by the MC driver, so I
assumed worse case — MC might leave some bits not written to the SSD
until that Windows resumed from its hibernation, causing possible data
loss if another OS was booted instead.) However since I’m happy with
the SSD speed as it is for what I currently do and don’t want to make
things more complicated, I’m not planning to use Momentum Cache in my
multiboot environment for now. Jeff

2 users thanked author for this post.

10Ring, columbia2011

The Bitdefender people got back to me a little while ago after I
reported that the problem seemed to have been solved. They said they
knew of nothing specific in today’s B update that would have fixed this
problem, but they said they are constantly adjusting things when a new
Windows release comes out. They said they had been able to reproduce
the problem and did verify that B antivirus and firewall were indeed
working properly even though Windows said they were off.

They also sent me a link to a page that might be useful in the future if
such a problem comes up again.  Bitdefender help page
https://www.bitdefender.com/consumer/support/answer/9329/
“What to do when Windows Security Center reports Antivirus and/or
Firewall are turned off”.  Since by then the problem no longer existed
on either of my 1903 PCs, I can’t say how helpful it would have been.
Jeff

2 users thanked author for this post.

geekdom, Elly

The Bitdefender vs. Windows 1903 communication problem seems to have
been solved. Initially the B people had given me a temporary
workaround. This was to turn off Windows Defender antivirus which was
starting automatically because Windows mistakenly thought B antivirus
was not running even though B antivirus and firewall actually were
running. Although this setting got around the problem of having two
potentially conflicting antivirus programs running in parallel, it had
some problems of its own, e.g., Defender was no longer available as a
backup if B shut down for some reason. I persisted in asking the B
people to solve the underlying problem.

A few minutes ago, the B program put up a notification that a reboot was
required to install an update. After the reboot, everything was back to
normal: Windows B antivirus and firewall were running and Windows
detected that was the case, as shown by the Windows “Manage providers”
display. Right after the reboot I got one Windows notification saying
no antivirus and firewall were running, but I always get this at that
stage while B is just getting started and Windows steps in temporarily.
However after B got going, the Windows display showed all was now as it
should be and I have gotten no more Windows nag notifications.

I haven’t gotten an email from the B people yet to confirm they made the
fix. I assume I will get one soon. I’ll post here if there is any
additional information. Jeff

1 user thanked author for this post.

geekdom

geekdom wrote:

Have you put a query to Bitdefender?

As noted  in the above post, I sent two queries to Bitdefender.  The term they used in the first reply actually was “visual glitch”  instead of “cosmetic”.  Hopefully the second report I sent will get soeone to look into it more deeply.

2 users thanked author for this post.

DriftyDonN, geekdom

Thanks, that sounded reasonable, but apparently that’s not the problem.
I looked under Control Panel > Sound > Sounds and saw Default Beep was
assigned to a wav. Just in case, I reassigned it to a different wav,
clicked Test (sounded OK), then clicked Apply. But the slider Test
still stayed silent. I know the audio works because of the Sounds >
Test and because I can play Windows Media Player.

I also verified on another PC that I could change Default Beep and the
slider test would change to match the new sound. So something else is
going on than a misset Default Beep. Jeff

Just thought I’d let you know I decided to get my own cable modem and stop paying the man! So a new Surfboard 6141 cost me 89.99 at Amazon which will save me 5.99/mo (not including taxes). So the payback period is 15 months then I’m home free.

As you did, I just replaced my cable modem with a Surfboard 6141. In
fact Time Warner Cable (TWC) had recently raised the rental for their
modems to $8/month here in Wake Forest, NC; that put me over the edge.
I had been getting good transmission speeds before: a little over 21
Mbps down and a little over 2 Mbps up; that didn’t change significantly
after the new modem was installed. My old modem was used both for
broadband and for phone service. They let me keep the old modem for the
phone connection, but won’t charge me for it. So far there have been no
problems with anything after I made the change.

I had also recently upgraded my router to a Linksys WRT1900AC to improve
wireless reception around the house and to prepare for some anticipated
broadband speed increases. The router is also working well.

On May 5th TWC is making a big change here and converting the cable
system to all digital. Currently the system uses a mix of digital and
analog, with analog channels taking up a lot of the available cable
bandwidth. Going all digital will mean a much more efficient use of the
bandwidth will be possible. TWC says that after the conversion is
complete they will be able to raise everyone’s broadband transmission
speeds by a large amount at no additional charge. We’ll see. There has
finally been some high-speed broadband competition in the Raleigh area
with AT&T and Google both promising gigabyte speeds. TWC had to do
something.

An impact of the TWC conversion to all digital channels is that any TVs
that previously had connected directly to cable, using their own digital
tuners, must now connect thru at least a small Digital Adapter, if not a
much more elaborate set-top box. After the May 5th cutover all the
cable channels will be encrypted; the TWC boxes are required to do the
decryption. For the next year the Digital Adapters are free. Then TWC
will start charging for them, no doubt making up for all the modem
rental fees they will be losing as more and more people buy their own
modems.

Now if TWC would just provide a decent DVR and software that doesn’t
hang or reboot so frequently. There are rumors of improvements, but
nothing promised so far. Jeff

Jeff, I think you’ll find that MS started the 100MB partition for the boot files/BCD stuff (you can bypass it by having the disk ready partitioned/formatted to full size, Windows setup will then install the same files to a folder in the root of C: ).

Right. I have used a similar technique when installing Windows 7 from
scratch to a spare partition on a disk already filled with other
partitions. That keeps the boot files where I want them. My point was
really that I wished Dell had given me an ordering option to let me
request the non-separation of the boot files for the pre-installed
system. (I do understand that other people, needing different system
capabilities, would want the files in a separate partition.) Dell’s
putting the boot files in a separate partition caused me a good deal of
extra work to get back to the configuration where I could do the BIBM
backup/restore/copy described in my original post. Of course I could
have just wiped the disk when I got the new PC and re-installed Windows
the way I wanted it to appear, but that would have lost some other
things Dell had pre-installed, which I wanted to keep. Such is life.
Jeff

I do my backup/restore tests by restoring to a separate primary
partition, either on the same hard drive as the main Windows partition
or on a separate drive. To set up the configuration that allows this, I
use Terabyte’s BootIt Bare Metal (BIBM) software:
http://www.terabyteunlimited.com/bootit-bare-metal.htm.

First I shrink the PC manufacturer’s pre-installed (huge) Windows
partition to a more reasonable size — 100 GB or so still gives Windows
and applications a good deal of elbow room. That frees up a lot of
space, some of which I then can use to create a TEST primary partition
(or at least reserve space for such a partition). I then use BIBM to
back up the now-smaller Windows partition and then use BIBM to restore
that image to the space I had reserved for the TEST partition. If all
this works, then I know the backup/restore procedure works properly on
that system. I have had a number of occasions (hardware and software
failures) to use restore for real, not just as a test, so I definitely
value a known-good backup/restore procedure.

I could also use the reserved space as the target of a BIBM Copy of the
Windows partition. BIBM backup creates a compressed image of a
partition. BIBM restore then decompresses that image and puts the
result in the target partition. In contrast, BIBM copy does a
bit-for-bit copy from one partition directly to another; it is an
alternative way of backing up a partition

With Windows 7, Dell (and other manufacturers?) started putting the
Windows boot files into another partition. I had to copy those files
back into the main Windows partition to make it a self-contained unit,
suitable for backup/restore and copy. If you don’t do that, the
restored or copied partition probably will not boot properly since its
new location will be out of sync with where it thinks the boot files are
located. See http://jgkhome.name/PC_Info/BING_WIN7_Dell.htm for the
gory details, which also involve updating Windows Boot Configuration
Data (BCD). But this modification has to be done only once. From then
on, backup/restore/copy of that modified Windows partition is very easy
and reliable for all subsequent times.

I think the above procedure works the same in Windows 8. More modern
PCs than mine, e.g., PCs with UEFI instead of BIOS and GPT instead of
MBR for the hard drive, may throw in some additional wrinkles, as may
Windows 10. I have had no experience with any of these new areas so
far. I would like to know if anyone has tried a procedure like this on
such systems. I believe secure boot in UEFI has to be turned off for
BIBM to work, but don’t know if anything else is required. Anyway, for
older systems, the above procedure works well for testing backup and
restore.

Jeff Knauth

I think many people do not know about the advanced search available in
Thunderbird which is accessed via Ctrl-Shift-F (vs. the Ctrl-F quick
search). For some reason they don’t list this advanced search anywhere
in the UI, e.g., under Tools, although it is documented in various
shortcut key lists. This search seems to provide a pretty powerful
facility, allowing you to combine a number of search criteria. Under TB’s
Options > General, I have “Enable Global Search and Indexer” checked.
However I have “Allow Windows Search to search messages” unchecked since
I found checking that option created some huge files which I didn’t want to
cope with in backups. etc. Jeff