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:
Property
Explanation
Default
SIZE
The height of the picture in percentage of screen height
35
IMAGEDURATION
How long (seconds) a picture should be shown before
switching to the next
30
TOPPOSITION
Distance (percentage) from top
2
LEFTPOSITION
Distance (percentage) from left
2
REMOTEIMAGEFOLDER
Shared folder for images (\\server.domain.com\images$)
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.
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
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:
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:
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.
$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.
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:
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.
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
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.
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:
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
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
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:
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!
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!
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.
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.
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 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:
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.
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
I wrote a blog post on App groups in MEMCM 1910 which is a really great feature. In that blog post I covered uninstall and the fact that the uninstall was made in the same order as the install, which I for one never uses. https://ccmexec.com/2019/12/application-groups-in-configuration-manager-1910/ I also added a link to a user voice item to change the uninstall order to reverse or even better be able to control it. That user voice was recently updated to “Started” and a comment from Djam that it was in MEMCM 2001.2 and sure it is!
Let’s have a look at it. I have created the simplest app group in the world with 7-Zip and Orca.
I deployed it as available to my test devices in MEMCM 2002 Technical Preview.
And during installation it installs in the expected order 7-Zip then Orca as shown below.
And when we uninstall it we can now see that the uninstall order is the reversed which is really awesome!
Another thing that changed as well is that we can now deploy an App Group with the intent of Uninstall/Required which wasn’t possible before! Uninstall was only available for available deployments.
If you ever doubted that user voice works here is the proof! Let’s hope all the features makes into the next CB release, I for one will start using it!
A big ask and dream has been a Webbased admin portal for Configuration Manager for a long time. The new feature in Configuration Manager 2002.2 Technical Preview “Device sync and actions” is the first look at the feature promised and presented at Ignite in 2019. This new features is hopefully the start with more features to come. Right now it is limited to three actions: Sync Machine Policy Sync User Policy App Evaluation Cycle
My hope is that in the future Servicedesk and technicians can use the DeviceManagement portal do to their daily tasks, no more need for them to learn and use the Admin Console. That would mean that we need many more features to achieve this but I hope we get there!
Testing out the new feature, there are some prerequisite like the user you use to log on to the DeviceManagement portal must be synced from AD to AAD and have permissions in the Admin Console. As it is a test environment I used of course Full Administrator permissions, all details on prerequisite can be found here: https://docs.microsoft.com/en-us/configmgr/core/get-started/2020/technical-preview-2002-2#bkmk_attach
So time to test out the new feature. in my environment I already had Co-Management configured, that is NOT a requirement though, the new feature will sync the devices to AAD so we can manage them there.
We start with enabling the new feature, it required a reboot after it was enabled or a restart of the SMS_EXECUTIVE would have been enough.
When that is complete we edit the properties of the Co-Management settings we have a shiny new option. “Configure upload” We can select which collection we want to upload, a good idea perhaps to exclude servers maybe, in my lab we are going all in!
It took a while for the devices to show up in the Device Management portal, you can track the progress in the CMGatewaySyncUploadWorker.log to see that devices are synced. Once it is done we can now see all our devices in the DeviceManagement Portal as shown below. We can easily differentiate co-managed devices from non co-managed.
Now to the exciting part, how does it look? how fast is it? When executing a task on a computer that is not Co-Managed we only have the three new actions as options. We get status back that the action is pending as soon as we initiate the task.
For a device that is co-managed we have many more options.
So how fast is it then.. Well checking the log files at the same time as initiating a “Sync Machine Policy” it takes maybe a second for the command to come down. Amazing! This new feature is very very long awaited after Ignite and it shows some real promise fort the future of Microsoft Endpoint Manager where on-premise and cloud meet in a Hybrid match made in heaven. Really looking forward to follow the development of this new great feature!
This post started as a poll I did on twitter on how many has enabled Strong Authentication in Configuration Manager as a requirement to access the Configuration Manager Admin Console(SMS Provider). The result was interesting..
96,2 percent use Windows authentication… that is a way to high number. Configuration Manager basically owns all devices in your environment, if you managed servers using Configuration Manager it owns them as well. Only require Username and Password to access the system of all systems that control all the others is way to weak!
So how do we get started? Well I for one like Windows Hello for Business, so I enabled it for my hybrid joined devices, here is a guide on Microsoft Docs https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust To be able to enable and configure Strong Authentication we need to have authenticated on the machine we run the Admin Console from using the method we want to configure. In my case I need to log on to the computer using Windows Hello for Business otherwise we will get an error message like this when we try to enable strong authentication.
How do we enable it? Under Hierachy Settings and under the Authentication tab we have the option to enable either certificate based authentication or require Windows Hello for Business.
We can also in the dialog above select which service accounts/use account that are to be excluded from the requirement. Creating a break the glass admin account that is disabled in the domain could be a good idea, you never know what will happen. Once we are done with the configuration and save it we get a question if we are really sure about this.
That is it! we are done! If I log on using username and password we get this well-known error message.. which is a general connect failure which we have seen many times before.
We can troubleshoot and see why the authentication failed in the SmsAdminUI.log file, it clearly states “Description = “current thread is not authenticated with the minimal allowed level”
Call to action! Secure your Configuration Manager environment and sleep tight at night!
Orchestration Groups is a new feature in Configuration Manager 2002 and replaces Server Groups which never made it out of pre-release.. Orchestration Groups is a pre-release feature that you need to enable if you intend to use it. NOTE: Orchestration Groups will replace Server Groups if you are using that today and convert your Server Groups to Orchestration Groups.
I have been testing it out since MEMCM 2002 was released in fast-ring and it works really well and I love the new UI.
Orchestration Groups are basically a group of devices you want to install Software Updates to in a controlled way, with Pre and Post PowerShell Scripts that are executed on each device in the Orchestration Group. Could be for example SQL Servers, Clusters and multi layered applications. We simply deploy our Software Updates to our collections as we normally do if the server is a member of an Orchestration group the Orchestration Group starts and we can track the progress in the Admin Console! Really Nice!
Before we create an Orchestration group let’s look at the limitations. – A device can only be member of one Orchestration Group – Max 1000 devices per Orchestration Group – Make sure the Configuration Manager client is upgraded to at least MEMCM 2002 – If Software updates are installed from Software Center then Orchestration Groups are bypassed.
Create an Orchestration Group
We start with giving it a name.
Select the devices that should be members in the group.
We have three option: – Allow a precentage of the machines to be updated at the same time – Allow a number of machines to be updated at the same time – Specify the the maintenance sequence
We can add a Pre-script, I used a simple one that writes the date and time it started to a log file, C:\Orchestration.log file. It will be executed on all the devices in the group. Exit 0 = Success Exit Code 3010 = Success with Reboot
We can use a Post-script as well, same hear it adds stop to the same log file on C:\Orchestration.log file.
The we are done!
How does it work?
We can start the Orchestration group manually using the UI to test it out. When we use it in production the Orchestration Group we simply deploy the Software Updates as normal and when the installation of Software Updates start the Orchestration Group kicks off. When the Orchestration group starts we have nice UI to track the progress.
We can use Run Scripts for a server in a group and also start remote control to troubleshoot as well. Really nice!
What about log files then? On the Site server we can track the progress in the SMS_Orchestration.log file.
On each device in an Orchestration Group we can track and troubleshoot the process using the MaintenanceCoordinator.log file, where we can see the Pre-script being executed as shown below for example.
When looking in the file system on one of the target devices we can see that my pre/post script writes to the Orchestration.log file
Conclusion, Orchestration groups is a pre-release feature in MEMCM 2002 which looks really promising! Test it out send frowns and smileys with what you like and what you are missing to the product group!
Application groups in Configuration Manager is a pre-release feature which has evolved greatly from release to release. Configuration Manager 2002 is no different. Two of my three most wanted features are in the latest release, required uninstall and reverse uninstall order of applications. Let’s have a look at how it looks.
Let’s start with the basics Application Groups are group of applications that we can control the install order of and show them in Software Center as a single application. In my simple test scenario 7-Zip and CMpivot as shown below.
Required uninstall was something that we really needed and it is here, it was available in Technical Preview before and it adds a much needed feature.
Uninstall order has now changed so that the applications installed are uninstalled in a reverse order. When troubleshooting or monitoring Application groups we have a new log file we can use “AppGroupHandler.log”. We will also see the installation take place in “Appenforce.log”. But in this scenario we will use the “AppGroupHandler.log” file to see what is happening. I have deployed my Application Group as displayed earlier as available.
When we install my “Tools v2” application group we can see the following in “AppGroupHandler.log”
At the same time in the “AppEnforce.log” file we can see the applications being installed, 7-zip first and then CMpivot.
When we uninstall our Application Group we can see the change made in MEMCM 2002 and the applications are uninstalled in the reverse order.
We can once again track the progress in the AppGroupHandler.log file
And the Appenforce.log file, and we can clearly see that the Applications are uninstalled in the reverse order.
These new changes in MEMCM 2002 are great! The only thing I miss now to start using it fully instead of Task Sequences is the possibility to install app Groups during OS deployment in a Task Sequence. In Configuration Manager 2002 we also got Task Sequences as a Deployment Type in the App model! Which gives a tons of possibilities and also icons for those Task Sequences we use for Application installations which makes choosing between Application Groups and Task Sequences really hard.
