Wrestling with Windows S Mode

Background

I was setting up a new PC for a client yesterday. It shipped with Windows 11 Home edition, and I agreed to upgrade to Windows 11 Pro using a license key he’d purchased.

I prefer to do a fresh install to minimize bloatware, and created a bootable USB drive with the installation media for that purpose. During installation, instead of allowing me to select the edition I wanted to install, it just defaulted to Windows 11 Home:

The installation did not include an Edition Configuration file (EI.cfg) in the .\Sources folder of the installation media, so I created one:

EI.cfg

[Channel]
_Default
[VL]
0

After restarting the installation, I could now choose the Windows 11 Pro edition and complete the installation. On completion, I logged into the PC, and to my dismay, it was configured as “Windows 11 Pro S Mode“…

About S Mode…

The ‘S’ stands for s***…

It’s a neutered version of the OS that only allows you to install S Mode-compatible applications from the Microsoft store, disables access to most configuration options, other browsers apart from Microsoft Edge, and disables access to Command Prompt and PowerShell. Who would want this?

Hint: not me, and if you’re reading this, not you either.

Catch 22!

Although I’d successfully installed Windows 11 Pro, I could not activate it because the OEM had preinstalled the Windows 11 Home license key in the BIOS. To update the key, I needed to disable S Mode, but I couldn’t do that without first activating Windows…

Getting Around It…

I tried…

  • Manually inputting the Windows 11 key using a PID.txt file in the .\Sources folder of the installation media to override the Windows 11 Home key on installation.
  • Logging in with a new Microsoft account, assuming the Windows 11 Home Edition digital license was bound to the Microsoft account I used to log in to the system for the first time before reinstallation.
  • Bypassing the Microsoft account creation process during installation. While I was able to use Shift+F10 to access the Command Prompt in some contexts of the installation process, neither oobe\bypassnro nor start ms-cxh:localonly worked.

To make things even more complicated, the touchpad and the Wireless NIC were not recognized by default! The latter had to be manually installed to progress through the installation process. As to the former, I simply had to do without (i.e., using keyboard shortcuts) until I got into the OS proper. I considered slipstreaming the drivers into the installation media, but it didn’t seem worthwhile…

Once More Into the Breach!

At this point, I had three options remaining:

  1. Give up, reinstall Windows 11 Home edition, and leave well enough alone.
  2. Reinstall Windows 11 Home edition, and then explore other options.
  3. Install Windows 10 Pro edition, then upgrade it to Windows 11.

Options 1 and 2 weren’t mutually exclusive, so I decided to start by installing the Home edition and then try to remove S Mode, which worked. Now that I had a Get button to use (it wasn’t present when Windows wasn’t activated), I could proceed.

Removing S Mode restored my option to update the license key, and after a reboot, I successfully upgraded to Windows 11!

Lessons Learned

This ordeal taught me that the correct upgrade path from Windows 11 Home S Mode to Windows 11 Pro is:

  1. Complete the initial setup as is on first boot, or if you want to get rid of the bloatware, reinstall the OS with Home Edition first
  2. Remove S Mode via the Microsoft Store on the activated Windows instance
  3. Change the license key to Windows 11 Pro and let it complete the upgrade
  4. Activate the new Windows 11 Pro installation

Because this particular system used a pre-installed Windows key, any attempt to install a different Windows 11 edition resulted in an [S Mode induced] Soft Lock Loop (see Catch 22 above). The only way off that crazy train is to install the same version it shipped with, and only then will you have the option to ‘Get’ the ‘Switch Out of S Mode’ app from the Microsoft Store, and the rest falls into place.

How To: Authenticated SMTP When Security Defaults/Modern Authentication Are Enabled

Background

Many legacy applications use authenticated SMTP to send email notifications. Since most organizations use Exchange Online as their email provider, leveraging it as a mail relay for service accounts is helpful and convenient. About five or so years ago, Microsoft began enabling Security Defaults for all new tenants and, shortly after, began deprecating Basic Authentication in Exchange.

While it’s possible to utilize smtp.office365.com as a relay for appliances such as printers and scanners, this may or may not be feasible in a particular use case, as was my situation. After many hours of research, trial, and error, I’d finally worked through all the pieces to get authenticated SMTP working with Security Defaults and Modern Authentication enabled.

Prerequisites

You’ll need to ensure the following is configured for the account you want to use:

  • MFA is enabled for the target user account in the Microsoft Entra admin center
  • The SmtpClientAuthenticationDisabled property (Exchange Online PowerShell) is set to $false (meaning that authenticated SMTP is enabled for this user)
  • Generate and record an App Password for the user
  • Disable POP3 and IMAP to prevent TLS downgrade attacks (optional, but highly recommended)

Putting it All Together

Instead of targeting smtp.office365.com on port 587 as our mail relay, we’ll use [YourTenantID].protection.outlook.com on port 25 with the StartTLS property (required).

We can use PowerShell to test this:

Send-MailMessage -SmtpServer [YourTenantID].mail.protection.outlook.com -UseSsl -Port 25 -From me@mydomain.com -To you@yourdomain.com -Subject "Test Email" -Body "Testing, 1, 2, 3?"

Yes, I know the Sent-MailMessage cmdlet is obsolete and doesn’t guarantee secure connections to SMTP servers, but in this case, we’re only using it to test our settings and connectivity.

If it works, we know that any remaining fault lies with the application configuration and/or the environment it resides in, not your Microsoft 365 setup.

Targeted Email Removal with Exchange Online Powershell

In the course of administering an Exchange Online instance I’m occasionally asked to locate and remove an email (or set of emails) from the entire tenant. The quickest way to do this is via PowerShell:

Connect to the Exchange Online instance, enter your credentials when prompted:

Connect-ExchangeOnline

Next, Connect to the Security and Compliance Center PowerShell, entering your credentials again when prompted:

Connect-IPPSSession

Now that you’re connected, you can create a new compliance search to locate the email(s) you wish to remove:

New-ComplianceSearch [SearchName] -ExchangeLocation 'All' -ContentMatchQuery 'from: "*@something.com"'

In the example above, I’m searching for all content across all mailboxes from a specific domain (e.g. @something.com), but you can modify the scope of the search by adjusting the location and content match query (i.e. searching by subject or just looking at specific mailboxes/folders etc.).

Once the search is created, you will need to start it:

Start-ComplianceSearch [SearchName]

While the search is ongoing, you can check on its status:

Get-ComplianceSearch [SearchName]

NOTE: You can use the |fl parameter to obtain additional information on the compliance search status.

Once completed, you can use the purge the emails located by the search:

New-ComplianceSearchAction -SearchName [SearchName] -Purge -PurgeType SoftDelete

 

Email Hide and Go Seek: How to locate a specific email (down to the folder) in Office 365 using PowerShell

In many organizations, end users receive too much email to manage effectively. Many utilize rules to filter emails into specific buckets to make them easier to find. Over time, these rules compound, and could eventually lead to unintended consequences (i.e. receiving an email but being unable to find it).

When this happens, I’d typically run a quick message trace to establish whether the email was actually delivered or not. Many admins will stop there, advising the end-user to check their rule settings, but using PowerShell, we can find the email(s) for them!

First, let’s get logged into the Office 365 tenant:

$Credential = Get-Credential
$ExchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid" -Credential $credential -Authentication "Basic" -AllowRedirection
Import-PSSession $ExchangeSession

Next, we can determine how many emails match the criteria in case there are more than one (Optional):

search-mailbox -EstimateResultOnly -identity [target user] -searchquery 'from:"[sender emai]" AND subject:"subject"'

Now for the coup de grâce, to reconstruct precisely which folder and sub-folder(s) of where the email(s) that match that criteria are in the user’s inbox:

search-mailbox -identity [recipient] -searchquery 'from:"[sender]" AND subject:"[subject] "' -targetmailbox "[your email] " -targetfolder "SearchResults"

In your inbox, you’ll see a folder called ‘SearchResults’. Using this, you can guide the end-user through the folder structure on their own Inbox that they’ll need to traverse to get to the desired email(s).

Obscure Skype for Business desktop sharing issue

A colleague of mine reported an issue with Skype for Business where he was unable to either share his screen (or application or PowerPoint presentation), nor could others share their screens with him.

From the user’s side, clicking on the Present button allowed him to toggle what he wanted to share, which would appear to work – the border indicated “connecting” while the recipient(s) waited for the presentation to begin. After 30-40 seconds, the presentation error (…”the invitation has expired”) and time out.

If you encounter this issue, you can try the following registry hack, which worked for me:

  1. Open Regedit as an administrator
  2. Navigate to:
    HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
  3. Add the following DWORD and value:
    MaxUserPort=0000x3a98 (15000)
  4. Reboot for the changes to take effect.

You can find more information about MaxUserPort and other TCP/IP registry settings here. This issue seems to be newly introduced with Windows 10 version 1809.