Windows 10 Registry tweak to disable Microsoft Edge Icon for MDT or ConfigMgr

The icon for Microsoft Edge is now placed by default in every user profile.
It is not placed in Public Desktop, but created for each user at logon (DOH!)

Thank god there is way to stop this behavior.

You can simple add the following registry key:
Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer
Value: DisableEdgeDesktopShortcutCreation
Data: 1
Type: REG_DWORD

If your using MDT (Microsoft Deployment Toolkit) or ConfigMgr (System Center Configuration Manager)
You can add the following oneliner task sequence step, to stop the creation of the Microsoft Edge icon.
Commandline: reg.exe add HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer /v DisableEdgeDesktopShortcutCreation /t REG_DWORD /d 1

In case your wondering what i have in the steps to disable Cortana, let me share them:

Registry tweaks for Build and Capture or Windows 10 Deployment task sequences

Disable Cortana Voice:
reg.exe add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE /v DisableVoice /t REG_DWORD /d 1

Disable Cortana Search:
reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Search” /v “AllowCortana” /t REG_DWORD /d 0 /f

Disable Cortana Search Box:
reg add “HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Search” /v “SearchboxTaskbarMode” /t REG_DWORD /d 0 /f

Using SCCM CI Baseline to check for expiring user certificates

The topic is almost self explaining.

You need to monitor specific user-based certificates, to avoid a situation where they have already expired.

You can add this to your daily security compliance checklist.

Prerequisites for running CIs can be found here: Compliance Baseline prerequisites

  1. Create Configuration Item

Go to Assets and Compliance, Compliance settings Configuration Items, right click and select Create a new configuration item:

Create Configuration Item

Provide the name CI – Script – USER CERT Expiration check, leave the configuration item type as Windows and press Next:
Configuration Item Wizard

Optionally you can provide a description that gives an overview of the configuration item and other relevant information that helps to identify it in the Configuration Manager console.

Select the OS where this configuration item assumes to be applied and click Next
client operating systems that will assess this configuration item for compliance

To create Configuration Item, click New:
Create Configuration Item Wizard

Type in the name CI – Script, from drop down of settings type select Script and data type as String.

There are two options to specify where a script would reside

– Discovery Script

– Remediation Script

Remediation is not handled in this post.

To place discovery script since to evaluate compliance, click on Add Script.

Please note that this script needs to be runin the logged-on user context, therefore please check “Run scripts by using the logged on user credentials”

Create Setting

Select script language as Windows PowerShell and type in the script (see attached USER_CERT_Expiration _Discovery.ps1) in the Script field:
Edit Discovery Scripts

#

$Compliance = ‘Compliant’

$Check = get-childitem -path cert:\currentuser -recurse | where-object {$_.thumbprint -eq ‘‎‎‎‎‎‎245c97df7514e7cf2df8be72ae957b9e04741e85’}| where { $_.notafter -le (get-date).AddDays(30)}

If ($Check) {$Compliance = ‘NonCompliant’}

$Compliance

#

Script download: USER_CERT_Expiration _Discovery (64 downloads)

and click OK

Click Next

Specify settings for this operating system

After the script is in place, you can click the “Compliance Rules” tab. Now compliance rule needs to be created. This rule will determine how the compliance is reported once the script runs on a computer (based on how the compliance a machine could be either Compliant or NonCompliant).

 

Click on New

Specify complance rules for this operating system

Type in the comSpecify rules to define compliance conditions for this settingpliance rule name and click on Browse:

Select the name of the configuration setting that just created (if not already selected and then click on Select):
Select a setting for this rule

In the Rule Type select Value and then select if the value returned is Equals to Compliant.

Click OK

Click Next
Use compliance rules to specify the condition that make a configuration item setting compliant

Next screen presents the summary of the settings, if any changes are needed then you can go back and make changes here. Click Next.

create an operating system configuration item with the following settings

Configuration Item is ready now.
The Create Configuration Item Wizard completed successfully

Next step is to create Configuration Baseline.

  1. Create Configuration Baseline

Right click Configuration baseline and create configuration baseline.
Create Configuration Baseline

Type the name of configuration baseline CB – Script – USER CERT Expiration check. Click on add and select configuration item from drop down menu.
Specify general information about this configuration baseline

Please make sure that Purpose set to Required!

Select the configuration item just created and click OK. This would finish creating configuration baseline.

Add Configuration Item

Now it is time to deploy this base line to relevant Users Collection(-s).

  1. Deploy the Configuration Baseline

    Go to configuration baseline and right click and select Deploy.
    Deploy Configuration Baseline

Select the configuration baseline CB – Script – USER CERT Expiration check.

Browse and point it to targeted Users collection (its recommended to run it for some limited collection for testing before deployment to production)

Change the evaluation schedule as per as your requirements (taking in consideration that in case of it seems to be critical for your environment, in production running this CB probably once a day is recommended)

Again, the key thing here is to be sure that you deploy this CB to users and not to your systems!

Select the configuration baseline that you want to deploy to a collection

Click OK

Note: When the configuration baseline is deployed, please allow that it can be evaluated for compliance within about two hours of the start time that you schedule.

  1. Verify that a device has evaluated the Configuration Baseline

To check it on a Windows PC client (general recommendation to do it for all targeted OS client types)

On a Device, go to Control Panel, System and Security and open the Configuration Manager applet. In the Configurations tab you’ll see what Configuration Baselines the client will evaluate at its specific schedule. Click on configurations and click on “Evaluate”, “Refresh” and then “View Report”.
As shown in the pictures below, Configuration Baseline was evaluated to be Compliant or Not
Configuration Manager Properties

Report view

Report view, non-compliant

 

Compliance baselines prerequisites for SCCM

PREREQUISITES

  1. Run Compliance Baselines on clients using SCCM

This setting is located in the Administration workspace under Overview ⇒ Client Settings ⇒ Default Client Agent Settings. Then right-click and select Properties. This will open the properties window for the client settings. By setting the “Enable compliance evaluation on clients” option to “Yes”, you enable this option in the default settings. The default schedule for evaluation is every 7 days.

You can adjust this schedule as necessary for your environment, including using a custom schedule that will allow you more control over when it runs.
The default schedule will typically be adequate for most environments.

You can also modify the default client settings, create new custom client settings, or modify existing custom client settings. You can create or modify custom client settings when you want to apply a group of client settings to specific collections.Client Settings - Default settings

 

  1. Running Powershell scripts on clients using SCCM:

    1. is to sign the script with your company trusted certificate
    2. is to set the PowerShell execution policy to “Bypass”.

    If you are not about to sign your scripts, please go to Administration->Client Settings, select the default (or create a new) Client Settings and set the PowerShell execution policy to “Bypass” in the “Computer Agent” section of the client settings. This action allows unsigned PowerShell scripts to run properly when they executed by the Computer Agent. If you don’t use the default client settings, you need to make sure the custom client settings you created are also deployed to the collection you will be checking compliance on.
    Client Settings - Powershell execution Policy

 

  1. Reporting Services Point SCCM role

    Should be installed in your environment for reporting.
    Assuming this role is already installed as reporting is a core requirement in the majority of SCCM functions.

ConfigMgr 2012 Application Catalog Web Service Point broken after OS upgrade

Upgrading your ConfigMgr from Windows Server 2008 R2 to Windows Server 2012 R2 ?
I have had a couple of cases, within the past moth.

.NET seems to break after the OS upgrade.
During some troubleshooting on a not working Application Catalog Web Service Point

  • Clients with new software center, did show some applications (but only a few/old from a synchronisation before the upgrade)
  • Trying to access Application Catalog Web Site gave an error:
  • Cannot Connect to the application server
  • No errors in the Application catalog website or service point installation files

So if we dig in to <CMInstallDrive>:\Program FIles\SMS_CCM\CMapplicationCatalogSVC\Logs\ServicePortalWebService.log did show some error:

[11, PID:7048][05/04/2017 12:12:23] :System.TypeLoadException: Could not load type ‘System.Runtime.Diagnostics.ITraceSourceStringProvider’ from assembly ‘System.ServiceModel.Internals, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’.

The error is related to broken/corrupt .NET

The solution:
Download and install: Microsoft .NET Framework 4.5.2 (Offline Installer)

 

Activation tool to use Windows OEM Key from BIOS

A simple tool to extract and use the Windows activation key from BIOS.
The tool will extract the key Windows Management Instrumentation Command-line.
The key extracted will be install and activated using Windows Software Licensing Management Tool.

Tool is command-line based.

Can be used with your favorite client management tool

https://gallery.technet.microsoft.com/Activate-using-Windows-OEM-db93ca97

Unified Extensible Firmware Interface (UEFI)

Unified Extensible Firmware Interface

For many years BIOS has been the industry standard for booting a PC. BIOS has served us well, but it is time to replace it with something better. UEFI is the replacement for BIOS, so it is important to understand the differences between BIOS and UEFI. In this section, you learn the major differences between the two and how they affect operating system deployment.

Introduction to UEFI

BIOS has been in use for approximately 30 years. Even though it clearly has proven to work, it has some limitations, including:

  • 16-bit code
  • 1 MB address space
  • Poor performance on ROM initialization
  • MBR maximum bootable disk size of 2.2 TB

As the replacement to BIOS, UEFI has many features that Windows can and will use.

With UEFI, you can benefit from:

  • Support for large disks. UEFI requires a GUID Partition Table (GPT) based disk, which means a limitation of roughly 16.8 million TB in disk size and more than 100 primary disks.
  • Faster boot time. UEFI does not use INT 13, and that improves boot time, especially when it comes to resuming from hibernate.
  • Multicast deployment. UEFI firmware can use multicast directly when it boots up. In WDS, MDT, and Configuration Manager scenarios, you need to first boot up a normal Windows PE in unicast and then switch into multicast. With UEFI, you can run multicast from the start.
  • Compatibility with earlier BIOS. Most of the UEFI implementations include a compatibility support module (CSM) that emulates BIOS.
  • CPU-independent architecture. Even if BIOS can run both 32- and 64-bit versions of firmware, all firmware device drivers on BIOS systems must also be 16-bit, and this affects performance. One of the reasons is the limitation in addressable memory, which is only 64 KB with BIOS.
  • CPU-independent drivers. On BIOS systems, PCI add-on cards must include a ROM that contains a separate driver for all supported CPU architectures. That is not needed for UEFI because UEFI has the ability to use EFI Byte Code (EBC) images, which allow for a processor-independent device driver environment.
  • Flexible pre-operating system environment. UEFI can perform many functions for you. You just need an UEFI application, and you can perform diagnostics and automatic repairs, and call home to report errors.
  • Secure boot. Windows 8 and later can use the UEFI firmware validation process, called secure boot, which is defined in UEFI 2.3.1. Using this process, you can ensure that UEFI launches only a verified operating system loader and that malware cannot switch the boot loader.

Versions

UEFI Version 2.3.1B is the version required for Windows 8 and later logo compliance. Later versions have been released to address issues; a small number of machines may need to upgrade their firmware to fully support the UEFI implementation in Windows 8 and later.

Hardware support for UEFI

In regard to UEFI, hardware is divided into four device classes:

  • Class 0 devices. This is the UEFI definition for a BIOS, or non-UEFI, device.
  • Class 1 devices. These devices behave like a standard BIOS machine, but they run EFI internally. They should be treated as normal BIOS-based machines. Class 1 devices use a CSM to emulate BIOS. These older devices are no longer manufactured.
  • Class 2 devices. These devices have the capability to behave as a BIOS- or a UEFI-based machine, and the boot process or the configuration in the firmware/BIOS determines the mode. Class 2 devices use a CSM to emulate BIOS. These are the most common type of devices currently available.
  • Class 3 devices. These are UEFI-only devices, which means you must run an operating system that supports only UEFI. Those operating systems include Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2. Windows 7 is not supported on these class 3 devices. Class 3 devices do not have a CSM to emulate BIOS.

Windows support for UEFI

Microsoft started with support for EFI 1.10 on servers and then added support for UEFI on both clients and servers.

With UEFI 2.3.1, there are both x86 and x64 versions of UEFI. Windows 10 supports both. However, UEFI does not support cross-platform boot. This means that a computer that has UEFI x64 can run only a 64-bit operating system, and a computer that has UEFI x86 can run only a 32-bit operating system.

How UEFI is changing operating system deployment

There are many things that affect operating system deployment as soon as you run on UEFI/EFI-based hardware. Here are considerations to keep in mind when working with UEFI devices:

  • Switching from BIOS to UEFI in the hardware is easy, but you also need to reinstall the operating system because you need to switch from MBR/NTFS to GPT/FAT32 and NTFS.
  • When you deploy to a Class 2 device, make sure the boot option you select matches the setting you want to have. It is common for old machines to have several boot options for BIOS but only a few for UEFI, or vice versa.
  • When deploying from media, remember the media has to be FAT32 for UEFI, and FAT32 has a file-size limitation of 4GB.
  • UEFI does not support cross-platform booting; therefore, you need to have the correct boot media (32- or 64-bit).

WSUS clients may fail during synchronization and log the following errors: 0x8024400D

Issue: WSUS clients may fail during synchronization and log the following errors: 0x8024400D

Cause: Too much rubbish in WSUS database eg. Lots and lots of expired and superseeded updates. No cleanup or maintenance has been done for a loong time.

Resolution:

Execute a maintenance CleanUp on the WSUS Server. Most of the 0x8024400D are due to a high quantity of updates on the server, even declined, expired, or superseded. This causes that the client WU Engine cannot finish processing all the information, and cannot pass to the Evalutation phase of the update process.

 

-Run Decline-SupersededUpdates.ps1 (Can also be found at www.thomasmarcussen.com – in the Archive folder). If the base Operating System is Windows 2008 R2 of further there should not be any problem to run it on Powershell 2.0

Instructions:

Open a Powershell windows as Administrator

Execute the next cmdlet in order to be able to execute non-signed scripts: Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Execute the script using the next syntax: .\Decline-SupersededUpdates.ps1 -UpdateServer FQDNoftheWSUSserver -Port xx -SkipDecline

Example: .\Decline-SupersededUpdates.ps1 -UpdateServer wsus.domain.local -Port 8530 -SkipDecline

 

After the process finishes we need to run the WSUS Cleanup:

From WSUS Console, go to Options, and open WSUS Cleanup Wizard

– Select only the 4th and 5th option: Expired Updates and Superseded Updates

– After the process finishes, run the Wizard again, just selecting the 1st Option: Unused updates and update revisions.

You might have to run this multiple times, untill it stops giving timeout errors – in case you got A LOT of expired and superseded updates – I’ve put up a script to perform this task instead. – see this post: http://blog.thomasmarcussen.com/susdb-maintenance/

  • Check if the affected clients are running Windows 7 – 32 bit version.

In this case, we will need to ensure that they have at least the WU Agent revision from June 2015:                               (You can download it from Here: https://support.microsoft.com/en-us/kb/3050265 )

  • – Clean the bloated update cache on the affected clients:

From a CMD as Administrator execute:

Net stop AppIDSvc

net stop wuauserv

net stop cryptsvc

ren %windir%\SoftwareDistribution %windir%\SoftwareDistribution.old

ren %systemroot%\system32\catroot2 oldcatroot2

Delete, in the registry: the PingID, SUSClientID and the AccountDomainSID values from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate

Then execute:

net start AppIDSvc

net start wuauserv

net start cryptsvc

wuauclt /resetauthorization /detectnow

Join Mac OS X to Active Directory

Simple script to join a Mac to domain

#!/bin/bash

HOST=”ADserver.domain.com”

DOMAIN=”domain.com”

ADUSERNAME=”admin”

ADPASS=”secretpassword”

# Enable SSH

echo “Enabling SSH”

systemsetup -setremotelogin on

launchctl load -w /System/Library/LaunchDaemons/ssh.plist

# Add computer to Active Directory

echo “Adding computer to Active Directory”

dsconfigad -preferred $HOST -domain $DOMAIN -u $ADUSERNAME -p $ADPASS

Installing .NET Framework 3.5 with MDT 2013 the simple way

In my case I need to automate the installation of .NET 3.5 within a MDT 2013 build and capture task sequence for Windows 8.1

In the State restore add a step to set the WindowsSource Path
The Windows Source will be located within the Operating Systems folder on your Deployment Share

  1. Add a Set Task Sequence Variable step
    1. Type Task Sequence Variable: WindowsSource
    2. Type Value for your source files: %deployroot%\Operating Systems\Windows 8.1 x64 Enterprise VL\Sources\SXS

Set Task Sequence Varable

  1. Add a Install Roles and Features step
    1. Select your Operating System within the step
    2. Mark .NEt Framework 3.5 (Includes .NET 2.0 and 3.0)

InstallRoles step MDT

Is it that simple? Yes!

NOTE: If you want to use a Run Command Line to install it, you could use something like this: DISM.exe /online /enable-feature /featurename:NetFX3 /All /Source:”%deployroot%\Operating Systems\Windows 8.1 x64 Enterprise VL\Sources\SXS” /LimitAccess