Quicker way to bypass microsoft account creation

lan101

Well-Known Member
Reaction score
503
Found this today and it worked. This may have been posted here before but if so I never got the memo on it lol.

Here it is:

Microsoft has banned email addresses that were used too often in the account creation process. You may use this to your advantage, as it allows you to skip the Microsoft account creation or sign-in phase during setup. The advantage of this option is that it does not require a restart or running a command from the command line.

Here is how this method works (thanks Neowin):

  1. Select Sign-In when asked to create or sign-in to a Microsoft account during setup.
  2. Use the email address no@thankyou.com.
  3. Type any password on the next screen.
  4. Windows will display "Oops, something went wrong" on the next screen.
  5. Clicking Next opens a screen that allows you to create a local account.
  6. You can assign a password to the account, or leave it empty.
Full link here: https://www.ghacks.net/2023/01/26/h...oft-account-requirement-during-windows-setup/
 
Found this today and it worked. This may have been posted here before but if so I never got the memo on it lol.

Here it is:

Microsoft has banned email addresses that were used too often in the account creation process. You may use this to your advantage, as it allows you to skip the Microsoft account creation or sign-in phase during setup. The advantage of this option is that it does not require a restart or running a command from the command line.

Here is how this method works (thanks Neowin):

  1. Select Sign-In when asked to create or sign-in to a Microsoft account during setup.
  2. Use the email address no@thankyou.com.
  3. Type any password on the next screen.
  4. Windows will display "Oops, something went wrong" on the next screen.
  5. Clicking Next opens a screen that allows you to create a local account.
  6. You can assign a password to the account, or leave it empty.
Full link here: https://www.ghacks.net/2023/01/26/h...oft-account-requirement-during-windows-setup/
Thanks for sharing this. I sign in using an outlook account I created just for signing in, when I refurbish laptops. Then, I create a local user account, generally the make/model of the laptop as the user name, make it an administrator, then go delete the outlook user account. Works pretty much the same way [by eliminating the Microsoft account] and it's not that much work. But avoiding it at setup seems a lot easier. I'll have to try a couple options from the article and see how it goes. :)
 
Thanks for sharing this. I sign in using an outlook account I created just for signing in, when I refurbish laptops. Then, I create a local user account, generally the make/model of the laptop as the user name, make it an administrator, then go delete the outlook user account. Works pretty much the same way [by eliminating the Microsoft account] and it's not that much work. But avoiding it at setup seems a lot easier. I'll have to try a couple options from the article and see how it goes. :)
Sounds like a lot of work. Plus, pretty good chance you’ve Bitlockered the drive using that initial account.
 
Sounds like a lot of work. Plus, pretty good chance you’ve Bitlockered the drive using that initial account.
It's actually not that much work. But how would I end up bitlockering the drive? It hasn't happened yet and I haven't had any customers coming back to say they can't get in. Wouldn't that happen, if it was?
 
It hasn't happened yet and I haven't had any customers coming back to say they can't get in. Wouldn't that happen, if it was?

Serious question: How do you know it hasn't happened? I have no idea whether a drive is using BitLocker or not unless I explicitly check.

But even if it is BitLockered, so long as the user has the necessary login credentials for Windows, that really doesn't make any difference, as it's invisible to them. The problem comes in if they lose those credentials and have never had the BitLocker key, which will be associated with the Microsoft Account that was used at initial setup.

I just don't do setup of local accounts as the primary account on a machine anymore. There's just too much data associated with Windows now and that needs to exist in a way that the actual owner of the machine can get at it. If push comes to shove, and I have no information from the client as far as an email address they have, I simply create a new Microsoft Account at setup. When the client comes to get the machine, I log in to that newly created Microsoft Account, add an email address they actually use as an alias, make that primary, and delete the original alias (or at least make it secondary). They can then set the password in person.

So long as there is a MS Account as "the base administrator" for the machine, have at it after that as far as creating local accounts to your heart's content.
 
Serious question: How do you know it hasn't happened? I have no idea whether a drive is using BitLocker or not unless I explicitly check.

But even if it is BitLockered, so long as the user has the necessary login credentials for Windows, that really doesn't make any difference, as it's invisible to them. The problem comes in if they lose those credentials and have never had the BitLocker key, which will be associated with the Microsoft Account that was used at initial setup.

I just don't do setup of local accounts as the primary account on a machine anymore. There's just too much data associated with Windows now and that needs to exist in a way that the actual owner of the machine can get at it. If push comes to shove, and I have no information from the client as far as an email address they have, I simply create a new Microsoft Account at setup. When the client comes to get the machine, I log in to that newly created Microsoft Account, add an email address they actually use as an alias, make that primary, and delete the original alias (or at least make it secondary). They can then set the password in person.

So long as there is a MS Account as "the base administrator" for the machine, have at it after that as far as creating local accounts to your heart's content.
I've noticed that several of the laptops I've removed my account from will prompt the user for a Microsoft account or asks them to create a new one, after a couple of Windows updates. But I've seen nothing that indicates the drive has been bitlockered. So far, anyway. If it ever does, then I'll have to figure it out.
 
But I've seen nothing that indicates the drive has been bitlockered.

I suggest you open an elevated Command Prompt, PowerShell, or Terminal and run the command: manage-bde -status
as a routine part of your setup protocol (or even when you get a machine to work on) so you know what it's encryption status is.
 
Last edited:
I suggest you open an eleveated Command Prompt, PowerShell, or Terminal and run the command: manage-bde -status
as a routine part of your setup protocol (or even when you get a machine to work on) so you know what it's encryption status is.
I'll try that and see what happens. I've bought laptops with bitlockered drives and, once you sign out, you can never get in again, unless you have the key. None of the ones I removed my Microsoft account from have done that yet, thank goodness..

Just out of curiosity, how would you recover a bitlocker key or is it even possible?
 
Last edited:
It seems that "the major" OEMs are, for the most part, following Microsoft's lead in regard to having BitLocker (on Pro and higher) and Device Encryption (same thing, different name, Home) enabled if initial setup used a Microsoft Account.

But some don't, and 4 recent custom build machines I acquired did not enable BitLocker under Windows 11 Pro on setup with an MS account, but that's likely because the builder disabled that option for their Win11 initial setup "pre-OOBE."

I always check to determine what the state is on a given machine these days. And if it's a new setup and it's on, with rare exceptions, I immediately turn it off. BitLocker makes data recovery an absolute nightmare in many scenarios. And, unfortunately, since far too many users still don't take backups, and drive failures in SSDs are "even more catastrophic" than a typical HDD death, I don't want anything complicating the possibility of data recovery from an SSD (which doesn't have great odds, anyway) added to the mix.
 
@ThatPlace928

Should you wish to disable BitLocker on a device where it's enabled, so long as you're logged in as an admin and have an elevated Command Prompt, PowerShell, or Terminal running, just enter:

manage-bde -off C:

(presuming C: is the drive to be unencrypted and where BitLocker is then turned off).
 
You can only "recover" (and it's not really that) a BitLocker key if you have access to the MS Account under which that instance of BitLocker was originally invoked at system setup. It will be logged in that account.

Otherwise, if it was not recorded, somewhere, by someone, and BitLocker was enabled on a machine where a local admin did it, you're screwed.

Since this is intended as a security measure, it's expected that those that activate it will record the key (or know that the MS Account will have recorded it when one was in use).

And since this is now, often, a "BitLocker defaults to ON" situation where the end user of the device has no idea that this is the case, I despise BitLocker with this default with a passion. I have seen (and seen reported, here) so much grief related to BitLocker that would have been entirely avoidable had its state been checked, and then BitLocker disabled, at machine configuration time. It's a standard part of my setup protocol to do just that with certain very rare exceptions. It takes way less time to decrypt when the machine is brand spankin' new with virtually no user data than there is if it's been in use for heaven knows how long and with many GBs of data to decrypt.
 
You can only "recover" (and it's not really that) a BitLocker key if you have access to the MS Account under which that instance of BitLocker was originally invoked at system setup. It will be logged in that account.

Otherwise, if it was not recorded, somewhere, by someone, and BitLocker was enabled on a machine where a local admin did it, you're screwed.

Since this is intended as a security measure, it's expected that those that activate it will record the key (or know that the MS Account will have recorded it when one was in use).

And since this is now, often, a "BitLocker defaults to ON" situation where the end user of the device has no idea that this is the case, I despise BitLocker with this default with a passion. I have seen (and seen reported, here) so much grief related to BitLocker that would have been entirely avoidable had its state been checked, and then BitLocker disabled, at machine configuration time. It's a standard part of my setup protocol to do just that with certain very rare exceptions. It takes way less time to decrypt when the machine is brand spankin' new with virtually no user data than there is if it's been in use for heaven knows how long and with many GBs of data to decrypt.
I loathe bitlocker, as well. No chance of data recovery, if the customer can't get in but wants to move their data.
 
I don't think it matters what email you use as long as it's not a working email
What's your definition of working? There is no central database so to speak. I'm guessing that MS does a host query and if no MX record is returned it'll choke. I know I've used a non-existent email account before on my domain which have been accepted. Probably because there's an MX record and SMTP response even though the account itself isn't valid.

Screen Shot 2023-06-23 at 5.36.58 PM.png
 
I don't think it matters what email you use as long as it's not a working email
Wrong. Go ahead and try to enter some random email you know isn't taken like asowi342t@24yolisdfh.com and it will just ask you to create an account. What makes it fail and prompt you to create a local account is that the Microsoft account you're trying to log in to has been locked due to too many login attempts. Try anything that's definitely registered and that spammers are sure to be hitting like tom@outlook.com and it will work.
 
In my almost exclusively residential practice, I have been using "no@no.com" forever - easy to remember. And the first thing I do is check for and disable bitlocker, if it's on by default. I also do that if I actually have the clients Microsoft account and log in with it, as most of my clients have no idea what the ramifications are. Next thing I do (if I signed in with a real Microsoft account) is turn off the farking OneDrive backup that Microsoft will turn on by default if you sign in with a Microsoft account. If the client doesn't have an Office 365 subscription, that damned default backup to OneDrive fills up the 5GB of free space and causes no end of annoyance. THEN, and only then, do I restore the FABS backup.
 
Back
Top