GPMC, Group Policy Objects, Group Policy Preferences, Registry, Windows 10

How to: Enable Windows 10 Biometrics (Facial and Fingerprint) Logon

Enable all of these policies and set the registry key to enable the Windows 10 facial and fingerprint logon feature.

Group Policy settings:

Computer Configuration\Administrative Templates\System\Logon

  • Turn on convenience PIN sign-in (Enabled)

Computer Configuration\Administrative Templates\Biometrics

  • Allow the use of biometrics (Enabled)
  • Allow users to log on using biometrics (Enabled)
  • Allow domain users to log on using biometrics (Enabled)

Computer Configuration\Administrative Templates\Biometrics\Facial Features

  • Use enhanced anti-spoofing when available (Disabled)

Computer Configuration\Administrative Templates\Windows Hello for Business

  • Use a hardware security device (Enable)
  • Use biometrics (Enabled)

Group Policy Preference settings:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]
“AllowDomainPINLogon”=dword:00000001

 

Advertisements
Windows 10

Inside the Windows 10 Fall Creators Update: The MVP Perspective Q and A

Highlights from the Windows 10 MVP Q&A

Question: How do you propose I should keep 4,500 desktop and laptops across 90+ separate physical schools updated in an 18 month period?
Answer: This is a longer conversation and I would be happy to have it with you offline. The problem breaks down into 4 categories.
1.Hardware being compatible (Analytics Upgrade readiness will help here)
2.Software being tested and compatible (Windows Analytics really helps you focus here). Lots of FUD here that can easily be scoped.
3.Infrastructure – look for software solutions to reduce the number of servers and eliminate the network impact
4.User process – scheduling and control by the end user to ensure your timing is not disruptive (WOL is always a good call for education)


Question: So every windows 10 upgrade will be a clean install or it just retain the state with all settings and applications as in the previous version?
Answer: Upgrade is in place and leaves user state and applications 1untouched. Upgrades are the recommend path once you are windows 10 with UEFI. You will have the ability to back-out and upgrade assuming your space cleanup process has not run yet. There are several triggers for cleanup like running out of space. As for a clean install, you can use Imaging via SCCM to ensure that process is available for break-fix, new hire, replace, or security-based issues.I would be happy to talk more about the 4 major categories of Operating System Deployment (OSD).


Question: When will Windows 10 1703 go Current Branch for Business?
Answer: The term for Current Branch for Business (CBB) has been replaced by Semi-Annual Channel.  The process to promote a deployment from Semi-Annual Targeted to Channel is based on you testing targeted in your environment than going broad.


Question: Can windows S be patched using SCCM? Can we define these folders via GPO? Why not protect them all?
Answer: I believe Windows 10 S Enterprise is to be managed via Intune as S does not allow you to run non Store applications.  I have not seen any mention of SCCM/ConfigMgr in regards to Windows 10 S Enterprise.


Question: There are a lot of features not required in Enterprise which is making LTSC more attractive for a stable build to avoid build change cost.
Answer: Long Term Saving Branch is for very specific scenarios.  I would not recommend LTSB for any internet connected device as there are too many exploits coming to quickly. LTSB has had issues with RSAT, software compatibility, MDM, windows hello, DoD requirements, lack or new hardware support (LTSB only supports silicon from when it was released), etc. That being said, LTSB does have very specific use cases as long as you are aware of all the pitfalls.


Question: Does it reinstall Store Apps?
Answer: During an upgrade, applications would not change.  However, new features may be added.

Administration, BIOS, Deployment, DHCP, PXE, UEFI

DHCP Policies and Custom Vendor Classes

Many organisations still have legacy BIOS devices that do not support UEFI boot. So setup DHCP to provide both BIOS or UEFI boot files depending on what the device BIOS uses.

By using DHCP policies and custom vendor classes for the following DHCP Options:

Option 60
Option 66
Option 67

Assume that you have CM configured with a PXE enabled distribution point and a valid and configured DHCP server. You should therefore be at a configured state where you are able to PXE boot BIOS based devices.

Create Custom Vendor Classes for Use with your DHCP Policy

Think Custom Vendor Classes as Detection Method’s used to determine how devices are requesting a boot image from the DHCP server.

Open the DHCP Console and expand the IPv4 Node
Right-Click on ‘IPv4 Node’ and select ‘Define Vendor Classes’
Click ‘Add’
Create the UEFI 64-Bit Vendor class first by entering the following information
Enter the following information for the respective fields:
DisplayName: PXEClient (UEFI x64)
Description: PXEClient:Arch:00007
ASCII: PXEClient:Arch:00007
Click ‘OK’
Click ‘Add’
DisplayName: PXEClient (UEFI x86)
Description: PXEClient:Arch:00006
ASCII: PXEClient:Arch:00006
Click ‘OK’
Click ‘Add’
DisplayName: PXEClient (BIOS x86 & x64)
Description: PXEClient:Arch:00000
ASCII: PXEClient:Arch:00000
Click ‘OK’

Creating Custom DHCP Policies

UEFI 64-Bit DHCP Policy

Right-Click ‘Policies’ and click ‘New Policy’
Give the policy a friendly name that coincides with the your vendor class naming scheme:
PolicyName: PXEClient (UEFI x64)
Description: Delivers the correct bootfile for (UEFI x64)
Click ‘Next’
On the ‘Configure Conditions for the policy’ page click ‘add’
Select the ‘Value’ drop-down box and select the PXEClient (UEFI x64) vendor class that you created in previous steps
Ensure that you check the box ‘Append wildcard(*)’
Select ‘Add’
Select ‘Ok’
Click ‘Next’
If you want the policy to affect only a specific range within your scope configure it, otherwise select no and click ‘next’
On the Configure settings for the policy page ensure that ‘DHCP Standard Options’ is selected from the drop down box
Configure the following scope options:
060: PXEClient
066: IP Address of the SCCM or WDS Service
067: smsboot\x64\wdsmgfw.efi
Cick ‘Next’
On the Summary page click ‘Finish’

BIOS 32-Bit & 64-Bit DHCP Policy

Right-Click ‘Policies’ and click ‘New Policy’
Give the policy a friendly name that coincides with the your vendor class naming scheme:
PolicyName: PXEClient (BIOS x86 & x64)
Description: Delivers the correct bootfile for BIOS machines
Click ‘Next’
On the ‘Configure Conditions for the policy’ page click ‘add’
Select the ‘Value’ drop-down box and select the PXEClient (BIOS x86 & x64) vendor class that you created in previous steps
Ensure that you check the box ‘Append wildcard(*)’
Select ‘Add’
Select ‘Ok’
Click ‘Next’
If you want the policy to affect only a specific range within your scope configure it, otherwise select no and click ‘next’
On the Configure settings for the policy page ensure that ‘DHCP Standard Options’ is selected from the drop down box
Configure the following scope options:
060: PXEClient
066: IP Address of the SCCM or WDS Service
067: smsboot\x64\wdsnbp.com
Cick ‘Next’
On the Summary page click ‘Finish’

UEFI 32-Bit DHCP Policy

Right-Click ‘Policies’ and click ‘New Policy’
Give the policy a friendly name that coincides with the your vendor class naming scheme:
PolicyName: PXEClient (UEFI x86)
Description: Delivers the correct bootfile for (UEFI x86) machines
Click ‘Next’
On the ‘Configure Conditions for the policy’ page click ‘add’
Select the ‘Value’ drop-down box and select the PXEClient (UEFI x86) vendor class that you created in previous steps
Ensure that you check the box ‘Append wildcard(*)’
Select ‘Add’
Select ‘Ok’
Click ‘Next’
If you want the policy to affect only a specific range within your scope configure it, otherwise select no and click ‘next’
On the Configure settings for the policy page ensure that ‘DHCP Standard Options’ is selected from the drop down box
Configure the following scope options:
060: PXEClient
066: IP Address of the SCCM or WDS Service
067: smsboot\x86\wdsmgfw.efi
Cick ‘Next’
On the Summary page click ‘Finish’

Remove Default PXE Options

Ensure that you have removed the 067, 066, 060 options from the default scope options to ensure that the Policies take precedence otherwise you will end up with conflict

As long as you have configured everything correctly you should now have the ability to boot machines from  BIOS or UEFI.

Administration, Azure, Deployment, EMS, Microsoft, Office 365, Windows 10

Windows AutoPilot Deployment

Microsoft has announced that Windows AutoPilot Deployment – a new cloud service that enables IT professionals and partners to customize the Windows 10 out of box setup experience. It used cloud configuration, delivering a self-service deployment experience with new Windows 10 Pro devices. It is now available through CSP.https://blogs.windows.com/business/2017/06/29/delivering-modern-promise-windows-10/#7Y0FQE61FUq42yKb.97

For Windows AutoPilot Deployment feature overviews and demos please see below:

Deployment, MDT, reference image, Task Sequence, Windows 7

Persistent Device Drivers in Reference Image

We needed to keep the Intel USB 3.0 drivers in a Windows 7 reference image.

  1. Import the drivers into MDT and create a selection profile.
  2. Edit the TS and update the Injected Drivers step to point to the selection profile.
  3. Open and edit Unattend.xml. Add the component called Microsoft-Windows-PnpSysprep to Step 3 Generalize.
  4. Edit the PersistAllDeviceInstalls option to be true.
  5. Save the Unattend.xml file and close.

More information here: http://technet.microsoft.com/en-us/library/ff716298.aspx

Administration, Group Policy Objects

Group Policy Setting – Delete user profiles older than a specified number of days on system restart

A great user policy that purges old user profiles from devices on reboot. Staggering the setting at 180 on week one, then 90 on week two and finally 30 days in the third week.

This setting can be found under Computer Configuration \ Policies \ Administrative Templates \ System \ User Profiles

BitLocker, Configuration Manager 2012, Deployment, Registry, Task Sequence, Windows 10, Windows 7, Windows Preinstallation Environment

Windows 7 Pre-Provision Bitlocker Not Working

After updating Configuration Manager 2012 R2 and adding the Windows 10 ADK, task sequences will no longer pre-provision BitLocker

Reason:

With WinPE 10 it uses the AES-CBC 128-bit encryption method.

Solution:

Add the following Run Command Line steps after Format and Partition and before Pre-provision BitLocker.

  1.  Set EncryptionMethodWithXtsFdv – reg add HKLM\SOFTWARE\Policies\Microsoft\FVE /t REG_DWORD /v EncryptionMethodWithXtsFdv /d 3 /f
  2. Set EncryptionMethodWithXtsOs – reg add HKLM\SOFTWARE\Policies\Microsoft\FVE /t REG_DWORD /v EncryptionMethodWithXtsOs /d 3 /f
  3. Set EncryptionMethodWithXtsRdv – reg add HKLM\SOFTWARE\Policies\Microsoft\FVE /t REG_DWORD /v EncryptionMethodWithXtsRdv /d 3 /f

Available Encryption Methods in WinPE 10

  1. Value Data: 3 (Description: AES-CBC 128-bit)
  2. Value Data: 4 (Description: AES-CBC 256-bit)
  3. Value Data: 6 (Description: XTS-AES 128 bit)
  4. Value Data: 7 (Description: XTS-AES 256-bit)
Configuration Manager 2012, Deployment, Logs, Registry, Script, Task Sequence

CScript Error: Can’t find script engine “VBScript” for script

During a OSD task sequence in Configuration Manager, we ran into an error with a VBS script that has worked previously.

The error in the SMSTS.LOG file was: CScript Error: Can’t find script engine “VBScript” for script

The problem appears to be caused by a changed registry value: HKEY_LOCAL_MACHINE\Software\Microsoft\COM3\REGDBVersion

After some searching on the internet the solution was to add the modify the REGDBVersion to a value of hex:01,00,00

Add to task sequence via a Command Line: REG ADD HKLM\Software\Microsoft\COM3 /v REGDBVersion /t REG_BINARY /d 010000 /f

Profit!

Deployment, MDT, Security Updates, Windows 10, Windows Server 2016, WSUS

MDT WSUS Windows 10 Updates Failing 0x8024401C

Had an issue with MDT failing to install Windows 10 via WSUS. I kept getting the 0x8024401C error.

I upgraded my WSUS on the Windows Server 2012R2 to version 4.0. Then upgraded the host to Windows Server 2016. Still receiving the same error.

After some more googling and trial and error I made the following changes to the IIS server for the WSUS  Application Pool:

  • Queue Length: From 10000 to 25000
  • Limit Interval (minutes): From 5 to 15
  • “Service Unavailable” Response: From HttpLevel to TcpLevel
  • Private Memory Limit (KB): From 18342456 to 0

Build is now receiving updates from the WSUS server.

Deployment, Microsoft, PowerShell, Windows 10, WSUS

Add Updates to Windows 10 Images

Due to the issues with the Windows 10 1607 build and WSUS updates, I have added the April 2017 Cumulative update into my Windows 10 image (install.wim).

Here are the steps that I completed:

  1. md C:\mount\Windows
    Dism /Mount-Image /ImageFile:"C:\Servicing\Images\install.wim" /Index:1 /MountDir:C:\Servicing\mount\Windows
    Dism /Add-Package /Servicing/Image:C:\Servicing\mount\Windows /PackagePath:C:\Servicing\MSU\windows10.0-kb4016635-x64_2b1b48aa6ec51c019187f15059b768b1638a21ab.msu /LogPath C:\Servicing\AddPackage.log
    Dism /Unmount-Image /MountDir:C:\Servicing\mount\Windows /Commit

Once completed the Windows 10 WIM image will have the latest cumulative update installed.