In Windows 10 1809 Clipboard History was introduced in Windows 10. Basically it keeps a history of all you clipboard items, you can even sync them across devices. Which is really cool!

Many use Password managers and many IT departments use password managers or some sort of safe storage to secure sensitive passwords, like “break the glass” domain admin passwords. So how does a Password manager work with Clipboard history? Well in this example I used Password Safe, it tells us it will securely delete the password when you close the app. Most Password Managers do that.

What it really does is just copy blank text to the clipboard and that works just fine, if we haven’t turned on Clipboard History then we can see all the passwords copied and the blank entry that Password Safe created to wipe the password from the clipboard history. Pressing Windows logo Key + V will display the password history.

So before using this new cool feature maybe inform our users is a good idea about how it works and the fact that they can use it but if they copy something sensitive, they can delete it. Same for admin workstations maybe it is better to turn it off?

The registry key that controls clipboard history is: HKU\Software\Microsoft\Clipboard\EnableClipboardHistory

We can put that in a Group Policy preference for example to make sure it is turned off.
Clipboard history is really cool, we just need to keep this behavior in mind and inform our users and admins.

In Configuration Manager we always had log files for everything, extremely useful when troubleshooting. In Intune we have the event log and the MDMDiagnosticsTool which is our best friends.

Win32app and PowerShell Scripts deployed are installed using the Intune Management Extension and for that we do have log files where we can track/troubleshoot application deployment. The Management Extension is installed the first time the Computer needs to run a PowerShell script or Win32App from Intune on Corporate owned devices and not Personal. It is installed in Program Files(x86) assuming 64 Bit Windows 10. Detection Scripts and content(temporary) are downloaded to this folder as well.

The log files for the Intune Management Extension are in “C:\ProgramData\Microsoft\IntuneManagementExtension\Logs”

Agentexecutor.log will show:

• PowerShell scripts that are executed and their status

IntuneManagementExtension.log will show basically everything around Win32App deployments:

• Win32App Detection methods being evaluated
• Win32App installations and status

Example from the IntuneMangementExtensions.log showing the command line being executed and the result code.

How do we read log files then? Of course using CMtrace which is our at least current favorite log reader, I deploy it to all my Intune Managed devices https://ccmexec.com/2018/12/copy-and-associate-cmtrace-using-intune-win32app-and-powershell/

Last week I was presenting with fellow MVP Ronni Pedersen in Zurich and we concluded that we recommend the same thing. Use PSAppDeployment Toolkit, https://psappdeploytoolkit.com/, if you and your organization are used to use PSAppDeployToolkt today. It still offers a great value like updating a registry value in all user profiles on the machine now that custom ActiveSetup keys are cleared when doing a feature update. We have all the log files in the same location when troubleshooting as well. Example Program for deploying an app using PSAppDeployToolkit.

Detection rule can still be the MSI or something more complex if you need it.

Then we get the log files from PSAppDeployToolkit as we all love.

If you never used it before and don’t like to start learning it, at least add logging to the MSIexec.exe command line so you have more logging when troubleshooting. Add /l*v “C:\Windows\temp\App_Chromex64.log” as an example to the command line then you can easily find all log files by sorting on A or search for App.

And then we get the log file for advanced troubleshooting as well.

That makes troubleshooting much easier.

Happy troubleshooting!

I love testing out new features in Configuration Manager Technical Previews, always some great stuff in there. This time it is 1908.2 which contains some cool feature that I hope make it to 1910. I just had to write a short post with my testing so far.

Teams integration in the Console Connections node.

We can now right-click on a connection and select “Message Administrator”

Prereqs from the Docs:

• The Administration Service must be enabled for the Last Console Heartbeat to function.
• For messaging administrators, the account you want to message needs to have been discovered with Azure AD or AD User Discovery.

It works really well and I can see that this will be really useful. Teams needs to be installed as well of course.

Set Default Keyboard layout in Windows, setting in the Apply Windows Image step, a great addition. However, I really need System Locale, System Language, user Locale etc. as well for it to be useful and replace what we do today many of our OS Deployment solution.

Multicast Support, has also got a lot of love in this release. It no longer requires WDS as it did before and It can also receive multicast content in the full OS, it’s not limited to only Windows PE. That is big news! If we look at a package for example the text that it only works in WinPE is gone.

CMPivot improvements, more processing has been moved from the server to the client making CMPivot even more powerful in the queries we can do. Who would have thought this 2 Years ago, amazing!

For the whole list of improvements check out the official docs. https://docs.microsoft.com/en-us/sccm/core/get-started/2019/technical-preview-1908-2

Spent last night testing this one out, Microsoft Bitlocker and Managment tool built in SCCM. This is one of the big features me and all my customers are looking forward to! It will make managing MBAM much easier than today by providing:
– MBAM client being part of the SCCM client, so no separate installation and updating anymore
– No additional infrastructure for MBAM, the Management Point role will have the MBAM Recovery and Hardware service.
– Updating the MBAM backend with new Service Releases is not painless today, and now we don’t need to anymore!
– No separate SQL Server/license needed.

MBAM is still the best way to manage your Bitlocker keys today, for having the Recovery keys in a Database separate from Active Directory provides protection against accidental deletion of a computer account and then the Bitlocker recovery key is gone as well. We can cleanup our AD an have it up to date with active clients and still have the recovery keys available if an old computer surfaces that needs to be unlocked.

So how does it work then?

To start with you need to run your Configuration manager site in HTTPS mode.. And it makes sense, do you want to transfer your Bitlocker keys over HTTP?? No, Let’s hope that the released version will Support Enhanced HTTP where self-signed certificates are used.

On the server side we create our MBAM policies under Assets and Compliance\Endpoint Protection\Bitlocker Management

Here we create our MBAM policy, it is the same settings we have in the GPO except for the Reporting endpoint URL is removed.

On the Management Point we have a new Endpoint in IIS (Yes, I had to do some manual steps to get it working). We have an eventlog for troubleshooting as well. So no more updating of the MBAM backend services, Yeah!

On the client and this is really nice:

When the policy is applied to the machine the SCCM client kicks of the installation of the MBAM client automatically from C:\Windows\CCM as shown here in BitlockerManagementHandler.log

There are a second log file on the client as well, BitlockerManagement_GroupPolicyHandler.log which does what it says it applies the settings from the MBAM Bitlocker Policy.

The MBAM eventlog is still there on the client to troubleshoot as well so no difference there.

And when the drive is encrypted the recovery keys, user information and computer information is written to the MBAM DB tables in the SCCM Database! No more separate database!

I really want this to be in the 1910 release of Configuration Manager it will make many admins life easier! Some questions are still open like how do we encrypt the disk during OS Deployment? will there be a new self-service portal or not? Time will tell!

If you want to try this out fellow MVP Niall Brady has written an awesome blog post that will save you a lot of time, you can find it here: https://www.windows-noob.com/forums/topic/16726-on-premises-bitlocker-management-using-system-center-configuration-manager/

My colleague, Johan Schrewelius has done it again! Windows 10 Lock Screen Watermark application. I demoed this at MMS in Minnesota earlier this year as a sneak peak, now it is live!

It is simple and great, it displays a picture on top of the logon and lockscreen.

The application itself is transparent and requires DotNet 4.6.2 or higher.

In this example we show an informational picture advising how to retrieve a new password, but the application can show any .png or .jpg within reasonable size and also mimic a simple slide show by rotating a series of pictures. See some samples below to show both logon screen and lock screen.

How does it work then?

LSWatermark.exe is installed at the following location:

%ProgramFiles(x86)%\Onevinn\LSWatermark

The application is launched by a Scheduled Task when any of the following events occur:

#1: System Start

#2: Session logoff

#3: Session lock

The application closes itself when any of the following is detected:

#1: Session logon

#2: Session unlock

Really simple no config needed.

Installation

Windows 10 Lock Screen watermark application is a single .MSI which will install the application and copy the images needed either from the installation folder or a share.

The “Images” folder should always contain a minimum of one png/jpg file or language specific subfolders, each with at least one file.

In other words; if you only support one language you can put you image(s) directly in the images root folder. If you must support multiple languages, you will have to create subfolder like:

The .msi accept five (5) properties:

Example Command Line: msiexec /I “LSWatermark 1.0.19180.02.msi” SIZE=45 IMAGEDURATION=60 REMOTEIMAGEFOLDER=”\\Server.domain.com\images$” /qn

If you want to download the pictures from a share during installation the sample .MST file can be used as it maybe easier than supplying multiple properties during installation.

The pictures will be loaded and shown in alphabetical order. If a language folder is missing the root images will serve as fallback. In the download there are a complete manual which includes more details. And yes, it works on modern managed computers as well of course where personal is even more important.

Happy lockscreening

https://gallery.technet.microsoft.com/Windows-10-Lock-screen-d401ec06

Back in January 2019 I wrote a post on how Application approval in Configuration Manager 1810 was a game changer over at https://4Sysops.com, which it truly is! Some things were still early then, but let’s look at what’s new in System Center Configuration Manager (SCCM) 1906 when it comes to instant application delivery using application requests. Check out the post I wrote on Application requests in SCCM 1906 and what is cool and new! over att https://4sysops.com/archives/whats-new-in-application-requests-in-sccm-1906/ And yes, it has a new name in the admin console.

If you haven’t already tested out instant application installations with Configuration Manager 1906 you really should!

By my Padawan and co-worker Sassan.
This is a quick post about the possibility to manage and configure some BIOS settings on Dell computers using Intune and Win32 apps. In this example we’re going to set an BIOS/admin password, but this could of course be expanded to configure other settings that are available through the DellBIOSProvider – https://www.dell.com/support/article/se/sv/sebsdt1/sln311262/dell-command-powershell-provider?lang=en
Note: The Dell PowerShell Provider requires platforms supporting WMI-ACPI BIOS

Mike Terrill posted a great article about using Dell’s PowerShell Provider with ConfigMgr which you can find here: https://miketerrill.net/2016/10/23/how-to-deploy-dell-command-powershell-provider-with-configmgr/

Gary Blok also made a great followup post to Mike’s that you can find here: https://garytown.com/dell-powershell-provider-install-w-configmgr

And while we’re at it, another big thank you and credit to Scott Ladewig and his post about the Visual C++ 2015 requriement for Dell’s PowerShell Provider 2.0 that you can find here: https://www.ladewig.com/dell-powershell-provider-2-0-requires-visual-c-2015/

I ran into a problem trying to import the DellBiosProvider module in the script:

Import Module : Could not load file or assembly ‘DSMBLibWrapper.dll’ or one of its dependencies. The specified module could not be found.

Dell have KB artible about this – https://www.dell.com/support/article/se/sv/sebsdt1/sln308274/dell-command-powershell-provider-is-not-working-properly-or-can-t-be-imported-into-powershell-correctly?lang=en.

That article states that Visual C++ 2010 and 2012 redistruables are needed, which is correct for version 1.x of the DellBIOSProvider module if I’ve understood it correctly. But for version 2.x the requirement is Visual C++ 2015, which Scott’s blogpost points out. He also points out that as you’re not able to install the C++ redistruabables in WinPE, you can get away with just droppiing some of the DLL files in the DellBIOSProvider module folder. Armed with that info, I tested it out and it worked perfectlly in my tests. So instead of packaging the Visual C++ reditruable as it’s own Win32 app and making it a dependecy to the main app, which one could argue is the correct way to do it – I opted for the lazy way of doing it.

Let’s start fetching the files needed for the package. In this example I’ll be using E:\Intune_DellSmBios as my work folder with two sub folders named source and output.

Step 1
Download the DellBIOSProvider module to a folder. Either download it manually the Dell site or with PowerShell:

Save-Module -Name DellBIOSProvider -Path E:\Intune_DellSmBios\source

Step 2
Armed with the info from Scott’s blog about the DLL files, I installed the latest Visual C++ 2015-2019 bundle on a testmachine and copied out the DLL files below into the DellBIOSProvider folder in step 1.  You can download the latest VC++ 2015-2019 bundle from here:

https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads

After installing the bundle, copy the following DLL files from C:\Windows\System32 to the DellBIOSProvider folder:

msvcp140.dll
msvcr120.dll
vcruntime140.dll

Step 3
Final part of the package is the script(s) that does the actual configuration – which is configuring the BIOS admin password in this case. This script works as-is but should be seen as a starting point or proof of concept that should be modified to fit your needs.

Some notes on the script:

$NewPassword = "SecretPassword" 
$OldPassword = "OldSecret"
$DetectionRegPath = "HKLM:\SOFTWARE\Onevinn\Intune\DellBIOSProvider"
$DetectionRegName = "PasswordSet"

$NewPassword – The password we want to set
$OldPassword – The password that is already set and that we want to change from – if applicable
$DetectionRegPath – Registry key that will be created and that will be used for detection method
$DetectionRegName – Name of the registry DWORD that will be set, used as detection method

The first variables obviously needs to be changed to fo the environment. $OldPassword will only actually be used if a BIOS/admin password already is set on the computer.

The Detection variables can be changed to fit your needs, their purpose is to create a regsitry value to use as a detection method if  and when the script has completed successfully.

Passwords in clear text is obviously not great but hardcoding them in the script and deploying it as a Win32 app in this case will at least not show the password in any log files on the clients or in the Intune portal. Ideally the password would be read from a secure vault of some sorts.

Step 4
Save or copy the script to the source folder, in my case: E:\Intune_DellSmBios\source.

Step 5
Download the Microsoft Win32 Content Prep Tool from https://github.com/Microsoft/Microsoft-Win32-Content-Prep-Tool if you haven’t already. Run the tool with the correct paths to create the -.intunewin file.

We should now have a .intunewin file named the same as what was entered as “setup file” in the previous step.

All that’s left now is to create the Win32 app and deploy it to our test user/device. When creating the Win32 app, make sure to use sysnative in the path of the install command. In my case the install command is: C:\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe -noprofile -executionpolicy Bypass -file .\DellSmBios-SetAdminPass.ps1. I’m also not using a separate uninstall script/command in this example so I’m just using the same command for both install and uninstall, you can of course change this to whatever fits your scenario.

In the Detection rules pane we will configure a manual detection rule type based on the registry key and value name that we specified in the script. SO in this example that is:

Key path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Onevinn\Intune\DellBIOSProvider
Value name: PasswordSet
Detection method: Integer comparison
Operator: Equals
Value: 1

After that we’re done, and we can assign the Win32 app as soon as the file has been uploaded.
To verify we can verify that the  detection rule is there and we also have the transcript/log file in C:\Windows\Temp.

The whole script:

$NewPassword = "eKlient2"
$OldPassword = "eKlient1"
$DetectionRegPath = "HKLM:\SOFTWARE\Onevinn\Intune\DellBIOSProvider"
$DetectionRegName = "PasswordSet"

Start-Transcript -Path "$env:TEMP\$($(Split-Path $PSCommandPath -Leaf).ToLower().Replace(".ps1",".log"))" | Out-Null

if (-not (Test-Path -Path $DetectionRegPath)) {
    New-Item -Path $DetectionRegPath -Force | Out-Null
}

if (Test-Path -Path "$env:ProgramFiles\WindowsPowerShell\Modules\DellBIOSProvider") {
    Write-Output "DellBIOSProvider folder already exists @ $env:ProgramFiles\WindowsPowerShell\Modules\DellBIOSProvider."
    Write-Output "Deleting the folder..."
    Remove-Item -Path "$env:ProgramFiles\WindowsPowerShell\Modules\DellBIOSProvider" -Recurse -Force
}

Write-Output "Copying DellBIOSProvider module to: $env:ProgramFiles\WindowsPowerShell\Modules\DellBIOSProvider" 
Copy-Item -Path "$PSScriptRoot\DellBIOSProvider\" -Destination "$env:ProgramFiles\WindowsPowerShell\Modules\DellBIOSProvider" -Recurse -Force

try {
    Import-Module "DellBIOSProvider" -Force -Verbose -ErrorAction Stop
}
catch {
    Write-Output "Error importing module: $_"
    exit 1
}

$IsAdminPassSet = (Get-Item -Path DellSmbios:\Security\IsAdminPasswordSet).CurrentValue

if ($IsAdminPassSet -eq $false) {
    Write-Output "Admin password is not set at this moment, will try to set it."
    Set-Item -Path DellSmbios:\Security\AdminPassword "$NewPassword"
    if ( (Get-Item -Path DellSmbios:\Security\IsAdminPasswordSet).CurrentValue -eq $true ){
        Write-Output "Admin password has now been set."
        New-ItemProperty -Path "$DetectionRegPath" -Name "$DetectionRegName" -Value 1 | Out-Null
    }
}
else {
    Write-Output "Admin password is already set"
    if ($null -eq $OldPassword) {
        Write-Output "`$OldPassword variable has not been specified, will not attempt to change admin password"

    }
    else {
        Write-Output "`$OldPassword variable has been specified, will try to change the admin password"
        Set-Item -Path DellSmbios:\Security\AdminPassword "$NewPassword" -Password "$OldPassword"
        New-ItemProperty -Path "$DetectionRegPath" -Name "$DetectionRegName" -Value 1 | Out-Null
    }
}

Stop-Transcript

Setting the password is important because knowing the password is a requirement for all future BIOS modifications we need to do in the future, it is of course also a security concern so it should be password protected.

I love playing around with a new Technical Preview and test everything out and complete the scenarios each time a new Tech Preview is released. If you don’t do it yourself, try it out it is great fun.

Orchestration groups

Orchestration groups are here! A long-awaited update/rewrite of Server groups which has been around for a long while but had some limitations. On huge difference is that we don’t use collections anymore. We simply deploy the updates to our servers then we add our servers we want to orchestrate updates to in an Orchestration group and then that Orchestration will take place when the software updates are installed. Really nice!

MBAM

The MBAM integration is one of my favorite features for a long while, it will be great when we have it integrated and can use it in production. In this release the self-service portal can be installed using PowerShell so we have that as well to provide self-service. The reports from the MBAM SCCM integration we had before is now integrated and can be used. I will test this out and write a post on MBAM only as well.

Task Sequence improvements

Using Task Sequences over the internet to do Windows 10 Servicing is great and it has just gotten better as when now can set use download on demand over the internet, which is great especially if we have many language steps in the TS, drivers and more.

Apply Windows Settings Step

They are stored in the following variables so we can script it easily.

OSDWindowsSettingsInputLocaleOverride
OSDWindowsSettingsSystemLocaleOverride
OSDWindowsSettingsUserLocaleOverride
OSDWindowsSettingsUILanguageOverride
OSDWindowsSettingsUILanguageFallbackOverride
OSDTimeZoneOverride

Install Windows 10 Prelrease using Software Updates

We can now deploy insider builds of Windows 10 using Configuration Manger, we have to select the new category and then they show up under Windows 10 Servicing where we can download and deploy them using Servicing plans.

Extend and migrate an on-premises site to Microsoft Azure

In the TP 1909 we can easily migrate or move our SCCM infrastructure to Azure. Especially the Site high-availability scenario looks really interesting check it out from the official blog post. https://docs.microsoft.com/en-us/sccm/core/get-started/2019/technical-preview-1909#bkmk_Azure-migration

CMPivot

CMPivot has gotten a lot of new features and is a great tool for SCCM Admins but also for security people to conduct hunting, check for vulnerabilities and more. Help spread the word to the Security guys now that we have CMPivot standalone as well.

Check out the whole article on what’s new in technical Preview here: https://docs.microsoft.com/en-us/sccm/core/get-started/2019/technical-preview-1909

One feature I am really excited about that are coming to Configuration Manager is the Integration of he MBAM server features. This will save us time and money because we don’t have to use separate servers for MBAM. We don’t have to manage and update neither the MBAM client or the Server backend. I wrote a post on what is new in 1908 technical preview here: https://ccmexec.com/2019/09/sccm-integrated-mbam-services-in-technical-preview-180-2/

In 1909 TP we got more features basically we got the posibility to install both the Helpdesk portal and the self-service portal that is included in MBAM. This is great because then we have those features separate from the SCCM Admin console.

I had to try this out of course: Before I installed the portals I had to install the Prereq: ASP.NET MVC 4.0 (I actually forgot and had to go back and install it when the self-service portal didn’t load.)

To install it we need to copy the following files, mbamwebsite.cab, mbamwebsiteinstaller.ps1
I copied them from the ConfigMgr install Dir to a temp directory:

Before I run the PowerShell command I created the three groups neded:
-MBAMHelpdesk
-MBAMAdmins
-MBAMReports

Then I ran the following command line in my environment to setup both the portals in my SCCM Primary site server:

.\MBAMWebSiteInstaller.ps1 -SqlServerName CMTP5.intra.ccmexec.local -SqlDatabaseName CM_TPM -ReportWebServiceUrl https://cmtp5.intra.ccmexec.local/ReportServer -HelpdeskUsersGroupName intra\mbamhelpdesk -HelpdeskAdminsGroupName intra\mbamAdmins -MbamReportUsersGroupName intra\MBAmreports -SiteInstall Both

And it worked the first time!

The scripts created the websites, reports and sets the correct permissions. So if we look in IIS manager we have the new websites there:

Browsing to HTTPS://cmtp5.intra.ccmexec.local/Helpdesk and the helpdesk portal works as expected and looks exactly as it did in MBAM before.

The same goes for the Self-Service Portal.
I accept the user agreement and then I can request my recovery keys.

This is great news! Now we just need to hold our fingers crossed that it will make it in the Configuration Manager 1910 release!

Last week my coworker Sassan (@sassan_f) and I wrote a post on how to manage Dell BIOS/UEFI settings using PowerShell and wrap that in a Win32app in Intune. After that post there was many asks on how to do it for HP so here it is.
Setting the password is important because knowing the password is a requirement for all future BIOS modifications we need to do in the future, it is of course also a security concern so it should be password protected.

HP provides a Powershell module to manipulate BIOS/UEFI settings just as Dell does. One difference is that the HP module does not require Visual Studio Runtimes to work
The PowerShell modules can be downloaded from here: https://developers.hp.com/hp-client-management/doc/client-management-script-library The script posted here can easily be modified to configure settings as well, HP also has a great sample script included in the download above.

Preparing the source files

After we downloaded the Script library from HP we extract it to a folder and just grab the modules we need to manage BIOS settings. We need the following two folders and add our script to it:

The whole script is here:

Start-Transcript -Path "$env:TEMP\$($(Split-Path $PSCommandPath -Leaf).ToLower().Replace(".ps1",".log"))" | Out-Null

$NewPassword = "MegaSecret1"
$OldPassword = "TopSecret1"
$DetectionRegPath = "HKLM:\SOFTWARE\Onevinn\Intune\HPClientMgmt"
$DetectionRegName = "PasswordSet"

if (-not (Test-Path -Path $DetectionRegPath)) {
    New-Item -Path $DetectionRegPath -Force | Out-Null
}

if (Test-Path -Path "$env:ProgramFiles\WindowsPowerShell\Modules\HP.ClientManagement") {
    Write-Output "HP.ClientManagement folder already exists @ $env:ProgramFiles\WindowsPowerShell\Modules\HP.ClientManagement."
    Write-Output "Deleting the folder..."
    Remove-Item -Path "$env:ProgramFiles\WindowsPowerShell\Modules\HP.ClientManagement" -Recurse -Force
}

if (Test-Path -Path "$env:ProgramFiles\WindowsPowerShell\Modules\HP.SoftPaq.Shared") {
    Write-Output "HP.SoftPaq.Shared folder already exists @ $env:ProgramFiles\WindowsPowerShell\Modules\HP.SoftPaq.Shared."
    Write-Output "Deleting the folder..."
    Remove-Item -Path "$env:ProgramFiles\WindowsPowerShell\Modules\HP.SoftPaq.Shared" -Recurse -Force
}

Write-Output "Copying HP.ClientManagement module to: $env:ProgramFiles\WindowsPowerShell\Modules\HP.ClientManagement" 
Copy-Item -Path "$PSScriptRoot\HP.ClientManagement\" -Destination "$env:ProgramFiles\WindowsPowerShell\Modules\HP.ClientManagement" -Recurse -Force

Write-Output "Copying HP.SoftPaq.Shared module to: $env:ProgramFiles\WindowsPowerShell\Modules\HP.SoftPaq.Shared" 
Copy-Item -Path "$PSScriptRoot\HP.SoftPaq.Shared\" -Destination "$env:ProgramFiles\WindowsPowerShell\Modules\HP.SoftPaq.Shared" -Recurse -Force

try {
    Import-Module "HP.ClientManagement" -Force -Verbose -ErrorAction Stop
}
catch {
    Write-Output "Error importing module: $_"
    exit 1
}

$IsAdminPassSet = Get-HPBiosSetupPasswordIsSet

if ($IsAdminPassSet -eq $false) {
    Write-Output "Admin password is not set at this moment, will try to set it."
    Set-HPBiosSetupPassword -newPassword "$NewPassword"
    if ( (Get-HPBiosSetupPasswordIsSet) -eq $true ){
        Write-Output "Admin password has now been set."
        New-ItemProperty -Path "$DetectionRegPath" -Name "$DetectionRegName" -Value 1 | Out-Null
    }
}
else {
    Write-Output "Admin password is already set"
    if ($null -eq $OldPassword) {
        Write-Output "`$OldPassword variable has not been specified, will not attempt to change admin password"
    }
    else {
        Write-Output "`$OldPassword variable has been specified, will try to change the admin password"
        try {
            Set-HPBiosSetupPassword -newPassword "$NewPassword" -Password "$OldPassword"
        }
        catch [System.Management.Automation.RuntimeException] {
            Write-Output "Access Denied error, verify that `$OldPassword is correct"
        }
        New-ItemProperty -Path "$DetectionRegPath" -Name "$DetectionRegName" -Value 1 -Force | Out-Null
    }
}

Stop-Transcript

The following lines needs to be modified both with a new password and an old one if the purpose is to change the password. The next two values are the registry key and registry value that is written to the registry when the script is successful so we can use that as the detection method.
$NewPassword – The password we want to set
$OldPassword – The password that is already set and that we want to change from – if applicable
$DetectionRegPath – Registry key that will be created and that will be used for detection method
$DetectionRegName – Name of the registry DWORD that will be set, used as detection method

$NewPassword = "MegaSecret1"
$OldPassword = "TopSecret1"
$DetectionRegPath = "HKLM:\SOFTWARE\Onevinn\Intune\HPClientMgmt"
$DetectionRegName = "PasswordSet"

Passwords in clear text is obviously not great but hardcoding them in the script and deploying it as a Win32 app in this case will at least not show the password in any log files on the clients or in the Intune portal. Ideally the password would be read from a secure vault of some sorts

Creating the Win32app in Intune

Download the Microsoft Win32 Content Prep Tool from https://github.com/Microsoft/Microsoft-Win32-Content-Prep-Tool if you haven’t already. Run the tool with the correct paths to create the -.intunewin file.

Next we logon to the Device Management portal and select create a new App under Client Apps. As app type we select “Windows app (Win32)”.
We upload the .intunewin file we created before as the app package file.

All that’s left now is to create the Win32 app and deploy it to our test user/device. When creating the Win32 app, make sure to use sysnative in the path of the install command. In my case the install command is: C:\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe -noprofile -executionpolicy Bypass -file .\HPClientMgmt-SetAdmPass.ps1. We are also not using a separate uninstall script/command in this example so we just using the same command for both install and uninstall, you can of course change this to whatever fits your scenario.

In the Detection rules pane we will configure a manual detection rule type based on the registry key and value name that we specified in the script. In this example that is:

Key path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Onevinn\Intune\HPClientMgmt
Value name: PasswordSet
Detection method: Integer comparison
Operator: Equals
Value: 1

After that we’re done, and we can assign the Win32 app as soon as the file has been uploaded.
To verify we can verify that the  detection rule is there and we also have the transcript/log file: C:\Windows\Temp\hpclientmgmt-setadmpass.log

Now we can configure HP BIOS passwords which is important even if new computers are shipped with the correct configuration.

A quick Friday tip about Intune Win32Apps that I find annoying. When using PSAppDeploymentToolkit togethe with Intune the filename in Intune will always be “Deploy-Application.Intunewin” as we point to that when we wrap the application as shown below. The same applies for setup.exe or install.exe as well and other unattended setups.
The filename of the setup file will show up in Intune as well even if we rename the file it will still show as demonstrated below.

A simple solution is to simply create a .txt file with the name we want in the application source folder, in this case 7-zip so the text file have the name we want instead to show up instead.

We point to that file as the setup file when we create the Win32app using the wrapping tool as shown below.

The .IntuneWin file we created will have the correct name and the app will show the correct filename when we have imported it as well.

This is really not a big deal, but as I like everything to be nice and correct this looks much nicer. It will also be easier to go back to my repository, if I save all my .IntuneWin files as well so I can actually see which one is what.
Thanks to Sassan my Colleague for always helping out!

Today during Ignite 2019 Microsoft Endpoint Configuration Manager 1911 Technical Preview was released. The first Configuration Manager release where everything is re-branded from System Center to Microsoft Endpoint. The re-branding makes prefect sense, Configuration Manager has always walked it’s own way in the System Center family, different release cadence, different version name and so on.
Microsoft Endpoint Configuration Manager teams up with Intune even closer now that they are in the same product family which makes perfect sense. They are better together if you have Configuration Manager installed today and this hopefully also ends the discussion about if Configuration Manager is going away..

The answer to that question is once and for all NO! bye bye System Center Configuration Manager you have been a good friend and welcome Microsoft Endpoint Configuration Manager and the whole family in Microsoft Endpoint Manager! Looking forward to great times together in the future!

What about the Technical Preview 1911 release then, well really no big new features but… It is re-branded to Microsoft Endpoint Configuration Manager everywhere. First up is the actual dialog for the Admin Console upgrade.

The Technical Preview scenarios are section is also renamed.

The about dialog is also updated.

What about new features then? DOINC is renamed to “Microsoft Connected Cache Server” and supports Intune Win32app content as well. This i BIG news for all of us who are moving some client types to be Intune managed, then we can still use the investment made in Configuration Manager infrastructure for the Modern Managed clients. Great!

Now back to preparing demos for MMS Jazz edition

I did a presentation at Techdays Sweden on security features in M365. I still get the question many times on what the benefits of Co-Management is that is why this post is written. There are many great features we can use when using Intune / Co-Management for managing our Windows 10 devices. Now that Microsoft Endpoint Manager is announced I hope many more will move to Co-Management.

One is to be able to wipe a device if it is stolen or lost for example. More and more laptops have built-in WWAN and then they are connected, and we can wipe them. Which I had a customer that had a need of last week, but they aren’t using Co-Management so, sorry…

Another one which really few have tested and know how it works is the possibility to wipe a Windows 10 device after x number of unsuccessful logins. It will not actually wipe the device it will reboot the computer and set it in Bitlocker Recovery mode. Awesome really.
If BitLocker is not used it will only reboot the machine, basically useless. And for everyone that is using BitLocker without PIN this is a great feature.

Here is a short video on how it looks for the end user, in this video I have the above configuration set to 5 attempts.

There are many reasons to start with Co-Management and Intune Modern management. If you haven’t already test it out!

This solution is not universal; complex applications with tons of dependencies or that is bound to user profiles will not work, but it covers the most basic needs of installing for example driver related applications, like the one in this example.

A customer of ours have a great number of machines with Nvidia graphics adapters and asked for a method to provision the Nvidia Control Panel application during OSD. This is what we came up with and thought we’d share.

First obtain the necessary files; this can be done by copying the download link from the “Share” button in Microsoft store. Then use an online service to get links to the separate files, .appx etc.

In this case the Store link looks like this:

https://www.microsoft.com/store/productId/9NF8H0H7WMLT

Online service to obtain links to the files can be found here:

https://store.rg-adguard.net/

@M_Cedervall recently published a script that downloads the files to disk right away:

https://github.com/MattiasC85/Scripts/blob/master/OSD/Download-AppxFromStore.ps1

Put the files in a folder on you content share:

Include a cmd file, that’s going to be our “Program”:

Command:

@ECHO OFF

Dism.exe /Online /Add-ProvisionedAppxPackage /PackagePath:"%~dp0NVIDIACorp.NVIDIAControlPanel_8.1.956.0_x64__56jybvy8sckqj.appx" /Region:"All" /SkipLicense

The /Region:”All” switch is pretty much the trick that makes this work at all. Without it, the application is deleted at first logon.

Create a Package with a Standard Program:

The details of the program:

(Category is optional but something we often use.)

Put an “Install Package” step in you TS (After “Setup Windows and ConfigMgr”) and configure it to run the program.

You will probably want a condition on this step, something like this should do the trick (Not tested):

SELECT * FROM Win32_VideoController Where Name Like '%Nvidia%'

Deploy a computer with Nvidia graphics, logon and – Voilá:

Please follow me on Twitter for news and updates: @josch62

I wrote a post on What’s new in application requests in Configuration Manager 1906 over at 4sysops.com https://4sysops.com/archives/whats-new-in-application-requests-in-sccm-1906/ One of the things that is new i the possibility to Retry an Installation if it fails or is uninstalled manually for example.

In the post over at 4Sysops I had three sample scripts on how to Create, Approve and Deny application requests using PowerShell so it could be automated. I got a question the other day if you can do a Retry Install as well using PowerShell and of course we can. Here is a PowerShell script to achieve that.

Sample command line: Powershell.exe -executionpolicy bypass -file RetryAppinstall.Ps1 “W101test120” “7-zip 18.06”

The script:

[CmdletBinding()]
Param(
    [string]$MachineName,
    [string]$AppName
  )

Import-Module "$($ENV:SMS_ADMIN_UI_PATH)\..\ConfigurationManager.psd1"
$SiteCode = (Get-WmiObject -Namespace root\sms -Query 'SELECT SiteCode FROM SMS_ProviderLocation').SiteCode
Set-Location "$($SiteCode):"
$NameSpace ="ROOT\SMS\site_$($SiteCode)"

$AppID = (Get-CMApplication -Name "$AppName").ModelName
$SMSID = (Get-CMDevice -Name "$MachineName").SMSID

$reqObj = Get-WmiObject -Namespace $NameSpace -Class SMS_UserApplicationRequest | Where {$_.ModelName -eq $AppID -and $_.RequestedMachine -eq $MachineName}
$reqObjPath = $reqObj.__PATH

Invoke-WmiMethod -Path $reqObjPath -Name RetryInstall

Application groups have been around for some Technical Preview releases and it was introduced in Current branch 1906. In MEMCM 1910 we got to new features:

• Deploy to User collections
• Allow end user to uninstall an available app group.

It is the latest of the two we will look into in this post, Uninstall. Being able to uninstall an app group is a must so I tested it out and it works just fine but we need it for required deployments as well.

I would like to see more possibilities, specifically a check box for “reverse install order during uninstall” That is how we do basically all uninstalls today, if we install them in a specific order we remove them in the reverse order, in some cases you cannot uninstall them otherwise. Also, the option to the leave an app installed for example when uninstalling.

Note:
– If an application triggers a reboot the Application Group will fail at that step and not install any more apps in the groups.
– If an application in the group is superseded it will be skipped.

In Configuration Manager 1910 the uninstall order is the same as the install order. Let’s have a look what happens.

My app group for testing:

If we look at the client where our Application group is installed the last installed app in “Configuration Manager Support Center” as expected.

So what happens if we uninstall the Application Group using Software Center?

When uninstalling the same Application Group the order is the same InstEd then Orca and last Configuration Manager Support Center is uninstalled as shown below.

I have created a user voice item for this as well, please vote for it here: https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/39265045-application-groups-reverese-control-uninstall-orde

I assume that part of this will be solved when we can select intent when we deploy an Application Group, it is not possible today as the option is grayed out as shown below.

When that is possible it will be possible to have one Application Group for install and one for uninstall with different order, that will be great for all the required scenarios.
However, the uninstall feature would need the above additions to be really useful in the “available” deployment scenario.

Been testing Edge Chromium deployment a lot the last couple of days as the we are getting really close to release when I write this..
Configuration Manager 1910 has a builtin feature to deploy and update Edge Chromium which looks great, hard to test the update part as the Stable release and updates are not released yet.

When creating the deployment of Edge Chromium using the built- feature we select channel and version to deploy. Which is great as we most likely will have developers, testers that needs the Beta/Dev version as well for testing.

It will download the content and create a Application with two deployment types one for x64 and one for x86, both are deployed using a PowerShell script. The PowerShell script also turns off automatic updates so that they can be handled by MEMCM instead of using EdgeUpdater.

Detection Method for the Deployment types are configured automatically to allow for updating of Edge Chromium using MEMCM as the detection method checks registry value and is configured with the operator “Greater than or equal to” as shown below.

To be able to use the script the Powershell Execution policy needs to be set to RemoteSigned or Unrestriced.
Allsigned will timeout after 30 minutes
Restriced will result in immediate failure

Restriced is default in Windows 10 and if you are using that modifying the Install command will solve the problem for you by simply adding -ExecutionPolicy Bypass to the command line. Sample below
Sample original installation string:

powershell -File “.\Install-Edge.ps1” -MSIName “MicrosoftEdgeBetaEnterpriseX64.msi” -ChannelID “{2cd8a007-e189-409d-a2c8-9af4ef3c72aa}”

After adding -ExecutionPolicy Bypass
powershell -Executionpolicy bypass -File “.\Install-Edge.ps1” -MSIName “MicrosoftEdgeBetaEnterpriseX64.msi” -ChannelID “{2cd8a007-e189-409d-a2c8-9af4ef3c72aa}”

Let’s look at the PowerShell script as well to prove that is sets the AutoUpdate policy to “0” , it is set during deployment.

If you choose to deploy Edge Chromium in another way make sure you configure AutoUpdate using GPO/Intune according to your update plan and that your detection method can handle the way you choose to update it!

Stay tuned for more Edge Chromium posts the coming days as it goes live!

Windows Autopilot is a great feature and together with the Enrollment Status Page (ESP) it becomes even more powerful as we can make sure for example configuration, applications, certificates and much more is applied before the end-user logs on for the first time so we can optimize their experience.  

During our latest projects we have run into the issue that is discussed in many forums and social media. The dreaded extra login caused by an extra reboot that breaks the amazing experience that the ESP provides for the end-user. The purpose of this blog post is to highlight the learnings we made during multiple projects and which settings generated an extra login/reboot. Hopefully this will save time for the community not having to find this out yourself. I am counting on the community to provide feedback as I haven´t tested every setting out there, I will update the post with all comments and hopefully make it more complete. 

It is a challenge to troubleshoot this issue as the only entry in the event-log that can be found is like the sample below.  

And in the Microsoft-Windows-Shell-Core-Operational we find this as well.  

The tests were made on Windows 10 1903 and 1909 and a first conclusion is that if you deploy Security Baselines, Configuration Profiles, Update rings etc. to users and not devices you are in a much happier place! 

Settings that will cause extra reboot/login when deployed to device are: 

-Update Rings 

-Device Lock 

-Password Polices (configuration Profile and Compliance) 

-Security Baseline 

-Credential guard policies 

-Application Control policies 

Why do we deploy some settings to devices instead of users? Well many customers have a percentage of shared devices and for those many need to deploy a different level of security.  

How can we troubleshoot it then? If we collect the log files from the client for example using the following command. 

mdmdiagnosticstool.exe -area Autopilot -cab C:\Temp\autopilot.cab 

Then we get all the useful logs in one single .cab file. If we extract the file we get the following log files for troubleshooting. 

This is great to send all the log files in to IT so someone can troubleshoot the issue, but it is still not that easy to troubleshoot and in the case of the unexpected reboot not really much there to see. 

I got this question many times “what does the Mobile Apps Co-Management workload actually do”. So here is a short post on the topic. It is fairly simple it controls where applications (PowerShell scripts) can be installed from, Intune & MEMCM or only Configuration Manager.

We start by enabling the Mobile apps feature which is still pre-release in MEMCM 1910.

When we turn the above feature on we can control what users see in Company Portal and where applications and PowerShell scripts can be installed from. We enable the Client Apps workload for our Pilot group.

And then we enable the Client Apps workload for our Pilot group.

If we then log on to a computer that is NOT a member of the Client Apps workload and start the Company Portal app we get the following experience.

And when we log on to a computer that is part of the Client Apps workload we can install applications from Company Portal.

The Mobile Apps/Client Apps workload can be used to pilot application and PowerShell script deployment from Intune. Extremely useful in a pilot scenario for some users that are road warriors for example pulling applications from Intune is a great feature.

With a new version of Edge Chromium there is of course new setting we can do = new ADMX/AMDL files. It is important for admin to keep up so even if we allow auto-update of Edge Chromium there is still work that needs to be done for every new release.

This is the new Group policy settings I found that is new for Edge Chromium 80 and 81.

New Group Policy settings in Edge Chromium 80 and later

New Group Policy settings in Edge Chromium 81 and later

Deprecated – removed in future releases

This one is really nice,”Hide the First-run experience and splash screen” no more first-run experience and splash screen!

“Configure Microsoft Defender SmartScreen to block potentially unwanted apps” is a great addition.

Lesson learned, admin need to keep track and update the .ADMX/ADML for every new release and keep an eye on deprecated settings as well.

Reference = https://docs.microsoft.com/en-us/deployedge/microsoft-edge-policies