U
UberBakery
We posted this in Reddit too. We thought we will post it here with the detailed post on Reddit in hopes of getting some interest in finding the resolution. Thank you for help!
Issue: User accounts on Windows 10 Pro that get disabled(?) after updates - happened once last year too - is the closest way to explain this. We use the word "disabled" because one of such post we found was to use the "lusrmgr.msc" to see what user/group accounts were there and also how to check properties.
Troubleshooting up until now: Before posting here for advice/guidance/feedback, we've scoured the internet and found a post with reference to the above tool that started to show some stones to turn.
The one stone to turn was that certain accounts were 'disabled" when checking the properties of accounts we had before this month's upgrade. We also found out that the "DefaultAccount" listed, which is the workhorse account used each day to log in for office work to run the bakery ,was no longer a member of Administrators & Users on top of being disabled.
After turning enabling and adding the DefaultAccount back to being members of Users & Administrators, we rebooted the system for the nth time - LOL.
Upon the log in challenge, the list that shows on the left bottom still showed only a local Administrative account & the "Other Accounts" that enables you to put it other accounts.
Knowing that the workhorse DefaultAccount used daily was connected to a Microsoft Account, we put that in & the password. Voila, we were finally able to get the correct profile as the desktop showed what it was the last time the bakery was open pre-Memorial Day.
But this turned to be shortlived as after rebooted and the user name now was added to the list showing at the log in challenge screen, the exact same password that was used 5 minutes ago would let us in.
Then it dawned on us. During the troubleshooting this morning, we did try to log into the microsoft account portal but the portal tells us that the microsoft account doesn't exist; it was an email address used for years ending in onmicosoft.com that we've been using with our Office365 subscription for years. The kicker is that the Office365 portal still recognizes this same email address to get us into the Office365 admin console that mcirosoft account portal says they have no record of!
Workaround: Because of the difference in how Microsoft Account portal vs Office365 portal reacts to the Microsoft Account Email we've been using to log into our Windows 10 Pro desktop which is now blocking us after the update, the workaround to loggind into the desktop to get the right profile/apps/desktop/etc. was to make sure the desktop is off the grind (disconnect ethernet & wireless) and log in with the Microsoft Account that their servers say doesn't exist (but was for years). Assuming that this workaround of temporarily going off the grid works because the password is still kept there for that Microsoft Account locally. We verified this workaround to be necessary because the screen saver just kicked and the desktop would not accept our Microsoft Account password (that Microsoft says doesn't exist on their system). Going off-grid let us in with the same Microsoft Account password we've used for years.
What we need to sort out and need help/guidance/direction: To us who just want to run the bakery back office without these issues eating up our morning & piling up work that can only be done through our Windows computer are as follows:
Thank you in advance for your inputs.
Continue reading...
Issue: User accounts on Windows 10 Pro that get disabled(?) after updates - happened once last year too - is the closest way to explain this. We use the word "disabled" because one of such post we found was to use the "lusrmgr.msc" to see what user/group accounts were there and also how to check properties.
Troubleshooting up until now: Before posting here for advice/guidance/feedback, we've scoured the internet and found a post with reference to the above tool that started to show some stones to turn.
The one stone to turn was that certain accounts were 'disabled" when checking the properties of accounts we had before this month's upgrade. We also found out that the "DefaultAccount" listed, which is the workhorse account used each day to log in for office work to run the bakery ,was no longer a member of Administrators & Users on top of being disabled.
After turning enabling and adding the DefaultAccount back to being members of Users & Administrators, we rebooted the system for the nth time - LOL.
Upon the log in challenge, the list that shows on the left bottom still showed only a local Administrative account & the "Other Accounts" that enables you to put it other accounts.
Knowing that the workhorse DefaultAccount used daily was connected to a Microsoft Account, we put that in & the password. Voila, we were finally able to get the correct profile as the desktop showed what it was the last time the bakery was open pre-Memorial Day.
But this turned to be shortlived as after rebooted and the user name now was added to the list showing at the log in challenge screen, the exact same password that was used 5 minutes ago would let us in.
Then it dawned on us. During the troubleshooting this morning, we did try to log into the microsoft account portal but the portal tells us that the microsoft account doesn't exist; it was an email address used for years ending in onmicosoft.com that we've been using with our Office365 subscription for years. The kicker is that the Office365 portal still recognizes this same email address to get us into the Office365 admin console that mcirosoft account portal says they have no record of!
Workaround: Because of the difference in how Microsoft Account portal vs Office365 portal reacts to the Microsoft Account Email we've been using to log into our Windows 10 Pro desktop which is now blocking us after the update, the workaround to loggind into the desktop to get the right profile/apps/desktop/etc. was to make sure the desktop is off the grind (disconnect ethernet & wireless) and log in with the Microsoft Account that their servers say doesn't exist (but was for years). Assuming that this workaround of temporarily going off the grid works because the password is still kept there for that Microsoft Account locally. We verified this workaround to be necessary because the screen saver just kicked and the desktop would not accept our Microsoft Account password (that Microsoft says doesn't exist on their system). Going off-grid let us in with the same Microsoft Account password we've used for years.
What we need to sort out and need help/guidance/direction: To us who just want to run the bakery back office without these issues eating up our morning & piling up work that can only be done through our Windows computer are as follows:
- Without endangering above workaround we figured out to at least get back into the desktop with the right profile (DefaultAccount listed in lusrmgr.msc), how can we fix the problem of the Microsoft Account on their servers not being recognized?
- Who/what is responsible for resolving why Office365 continues to properly acknowledge login credentials which is the Microsoft Account that is rejected by Microsoft Account portal?
- Going forward, can multiple accounts - Microsoft Account and newly created local accounts - load the same profile (desktop/apps/etc.) so if this stupidity (sorry, as an owner who uses Windows & subscribes to Office365 to operate our bakery back-office like ordering, production, inventory, account receivable/payable, etc. I am a little more than frustrated), we may have a better chance of getting to other workarounds without having to go off-the-grid every time we need to log into the desktop? If so how easy or difficult is it to clone(?) the accounts as backup?
Thank you in advance for your inputs.
Continue reading...