Workaround: When the #Windows10 Windows Hello setup UI won’t open…

Recently while traveling on the road for 3 weeks, my brand new notebook with Windows 10 x64 Enterprise Edition (Fall Creators Update) started blue screening at boot (safe mode wouldn’t even start).  I really didn’t have the ability to take the time to troubleshoot it too deeply and none of the standard Windows 10 repair functions worked.  In the end I used “Reset my PC” which seems to have solved the blue screen of death, but left me with no installed applications (which really sucked) although my user profile was mostly left intact.  I actually had to use “Reset my PC” 3 days in a row at one point so I could work, and then finally my notebook seemed to return to a stable working condition – until Saturday morning that is.

Well enough was enough – I can’t trust the Windows installation not to give me grief again in the future, and since I use Veeam Agent for nightly backups, I decided to start over by booting WinPE and running Diskpart then Clean on my two SSDs.  I reinstalled Windows 10 x64 Enterprise Edition (Fall Creators Update), along with all the zBook 14u G4 drivers, and proceeded to setup my notebook like I always would.  After several hours of installing and configuring software and restoring about 1TB of data from Friday night’s Veeam backup, I had two things left to do.  Configure my fingerprint reader and encrypt my drives with Symantec PGP Corporate Desktop.

So Windows Hello needs a PIN before you can add a fingerprint – annoying as hell, but necessary… I mean – I have a strong password to protect my account – why the hell should I have to add relatively weak PIN to enable my finger print (but I will digress on this rant and get to what’s important here).  So I go to Settings –> Account –> Sign-in Options and add my PIN.  Now that my PIN is added, I click on the Add Finger Print button…

2017.12.04 - 13.50.07 - SNAGIT - 0005

The Windows Hello setup UI opens and then immediately closes – basically just a flash…  I hit it again and still no go.  Uh-oh… Reboot?  Nope.  Drivers?  Nope.  After some Googling and removing all fingerprint data from the BIOS, I’m still no further ahead and out of leads.

Hmm – I used a new tool to customize my profile and did a few changes to my profile that I normally haven’t done in the past – what if it is my user profile fighting with UAC that is causing this?  So I log in as Administrator and find the “Finger Print” button is greyed out.  Ok, well maybe I need to do it as a standard user, so I open a command prompt and create a new user with:

net user testuser password /add

I logout as Administrator and login as testuser.  When I open Settings –> Account –> Sign-in Options, the Finger Print button is active, and when I click, it opens and allows me to scan my finger.  It appears the issue is my account / profile as opposed to something specifically in Windows 10.  This is a good news / bad news scenario.  I don’t need to reinstall Windows yet again, but I don’t want to have to spend hours re-configuring my profile yet again either.  So it’s time to get creative.

Here are the steps I used to get my finger print registered in Windows (note – this doesn’t fix the problem long term, it just works around it for now, which is all I need).

  1. Reboot the machine and login as Administrator
  2. Navigate to C:\Users and rename my user profile folder to C:\USERS\JBGEEK.good
  3. Open Regedit and navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList and removed the entry that existed for my user profile.
  4. Open Computer Management, navigated to Users and Groups and removed my user account from the Administrators group.
  5. Logged out as Administrator
  6. Logged in with my userid (which creates a new user profile associated to my SID)
  7. Opened Settings –> Account –> Sign-in Options and clicked on Finger Print – the Windows Hello setup UI for finger prints opened and allowed me to register my fingers
  8. Rebooted Windows and verified I could login with my finger print from CTRL+ALT+DEL
  9. Rebooted Windows again to ensure my profile was unloaded and logged in as Administrator
  10. Navigated to C:\Users and renamed my newly create user profile to C:\USERS\JBGEEK.temp and then renamed my good user profile back to C:\USERS\JBGEEK
  11. Open Computer Management, navigated to Users and Groups and re-add my user account to the Administrators group.
  12. While in Computer Management, I also deleted my testuser and removed it’s user profile too.

I am now able to log into Windows using my finger print (without having lost my profile settings and data).  And although the Add Finger Print UI still doesn’t function for me, but I really don’t care because it is not like I plan to grow any new fingers anytime soon that I will need to register in Windows until the next reinstall!

Anyways – hopefully this blog will help someone else stuck in the same boat.

HOWTO: Find the SRP & Auth Key in the SQLDB of an existing BES12 installation

This post is going to be pretty short and simple.  We had a customer who had lost track of the corresponding Auth Key to their existing SRP ID in Blackberry Enterprise Server 12.  A simple SQL query was all that is required to pull the SRP and Auth Key from the existing production SQL database.  This **should** work on any version of BES12, but I only tested it on BES 12.5.2 and BES 12.6.

  1. Open Microsoft SQL Server Management Studio.
  2. Connect to the SQL server instance that hosts the BES database.
  3. Click the “New Query” button on the toolbar (or press CTRL + N).
  4. Paste the following query into the query editor, then click the Execute Button (adjust the BES_DATABASE_NAME as required)
SELECT TOP 1000 [id_sws_tenant]
,[created]
,[modified]
,[external_tenant_id]
,[external_authenticator_id]
FROM [BES_DATABASE_NAME].[dbo].[obj_sws_tenant]

The output will contain the SRP (external_tenant_id) and Auth Key (external_authenicator_id).

2017-02-01-11-06-42-snagit-0090

As always – Use any tips, tricks, or scripts I post at your own risk.

HOWTO: Change a Windows’ network type from Public to Private via PowerShell

Stupid Windows Server 2016…  Stupid Windows 10…  Damn Microsoft…

Ever find yourself with a network interface that is stuck as Public and no obvious way to change it via GUI?

2016-12-24-14-24-28-snagit-0024

Five simple PowerShell lines to the rescue!

Get-NetConnectionProfile
$Profile = Get-NetConnectionProfile -InterfaceAlias "interface_alias_name"
$Profile.NetworkCategory = "Private"
Set-NetConnectionProfile -InputObject $Profile
Get-NetConnectionProfile

2016-12-24-14-25-51-snagit-0025

2016-12-24-14-26-07-snagit-0026

And now your network type should be set to Private network.

As always – Use any tips, tricks, or scripts I post at your own risk.

KB3148812 breaks Windows Server Update Services

Earlier this week, Microsoft pushed out KB3148812, which enables ESD decryption provisioning in WSUS (on Windows Server 2012 and Windows Server 2012 R2).  From what I read and understand, KB3148812 is going to be a mandatory update for WSUS to support Windows 10 updates after May 1.  Unfortunately, it appears that KB3148812 also breaks the WSUS console.  Rather than re-issue KB3148812 so it doesn’t break WSUS, Microsoft has published in a blog posting the necessary post-install steps to “un-break” WSUS after install KB3148812.

Basically you need to perform two steps to return WSUS to a working condition on Windows 2012.  First, you need to re-run the WSUS post-install.  And then you also need to add HTTP Activation to your WSUS server.

For Step 1, to re-run post-install, open an administrative command prompt and run:

"C:\Program Files\Update Services\Tools\Wsusutil.exe" postinstall /servicing

For Step 2, to install HTTP Activation, open an administrative PowerShell command prompt and run:

Install-WindowsFeature -Name NET-WCF-HTTP-Activation45

No reboot should be necessary and the WSUS console should now open and function normally for you.  There is the possibility you’ll still get client connectivity issue though with an error of 0x80244007, which is something entirely different that Microsoft is still looking at as of 2016.04.22.