How Microsoft Endpoint Manager is Bringing Intune and Configuration Manager Together

Posted on August 2, 2021 by Thomas.Marcussen

As people get access to more and more devices, the way that businesses operate has been rapidly evolving to keep up with the technology. And with more of these devices having access to a business’ data, this can help to improve productivity. Microsoft Endpoint Manager may have been designed with these dynamics in mind.

The problem, however, is that this can easily create a situation that puts the entire organization’s network at risk. So, a solution is necessary.

One that can enable a business to get the most it can from the devices that are available to its employees without compromising data security. This is why you need a platform like Microsoft Endpoint Manager that can bring together the most effective device management tools.

Creating the solution

Microsoft already had plenty of products available to help businesses with device management. And these products included the two that we’ll be focusing on today: Intune and Configuration Manager. So why did they feel the need to change things, to add yet another product?

What Microsoft Endpoint Manager (MEM) seeks to address is the need for a comprehensive management solution. MEM can help to reduce client confusion over the multiple products that are available by giving you a unified platform for all your devices including Windows 10, macOS, iOS, and Android. By using MEM, businesses can among other things:

proactively manage all of their devices,
maintain systems and software,
limit exposure and respond to security threats,
distribute settings, and much more.

Microsoft Intune

With Intune, what you are getting is a 100% cloud-based mobile device management (MDM) and mobile application management (MAM) provider for your apps and devices. Using it enables you to have control over the features and settings on Windows 10, Apple, and Android devices.

Also, if you have on-prem infrastructure, there will be Intune connectors available. Namely the Intune Connector for Active Directory and the Intune certificate connector.

And by making it a part of MEM, Microsoft allows you to use Intune to create and check for compliance, as well as deploy apps, features, and settings to your devices using the cloud.

Configuration Manager

Whereas Intune is a 100% cloud-based solution, Configuration Manager gives you the on-premises management solution. With this, businesses can manage desktops, servers, and laptops that are on their network or internet-based. It is a flexible solution that you can cloud-enable if you want to integrate with Intune, Azure Active Directory (AD), Microsoft Defender for Endpoint, and other cloud services.

Furthermore, Configuration Manager gives you a great tool for the deployment of apps, software updates, and operating systems. Not only that, but you can also stay on top of queries and compliance issues so that you can act in real-time.

What are the requirements for Microsoft Endpoint Manager?

The beauty of Microsoft Endpoint Manager is that there is no complicated configuration or migration that you need to worry about. And this goes for the licensing as well.

If you have an existing Configuration Manager license then you can continue to use it, while simultaneously taking advantage of the Microsoft cloud-based security and compliance benefits of Intune.

Combining these two solutions has allowed Microsoft to avail Configuration Manager to clients with Intune licenses and vice versa. All of this without the usual roadblocks that you previously had to deal with.

This simplifies the process of giving clients a more comprehensive management platform. For management of non-Windows devices, however, you will need an Intune license, an Enterprise Mobility & Security (EMS) license, or a Microsoft 365 E3 or higher license

Taking advantage of MEM

There are plenty of reasons why any business should consider using MEM to improve the way it operates. As mentioned above, people now have access to plenty of different devices and businesses should benefit from that.

But, with the complexities that are involved in device management, there is no single tool that can meet all the requirements.

This is why bringing together Intune and Configuration Manager can work so well. By supporting a diverse BYOD ecosystem, MEM makes it easy to manage all endpoints. Whether they are on-premises and remote, corporate-owned and personal, desktop and mobile, MEM can handle them.

In addition, MEM is flexible enough to meet you where you are in your cloud journey and will not disrupt your existing processes. Your business can also leverage the integrations with other platforms such as Microsoft 365 and Azure AD to enhance productivity.

Combining products gives clients a lot to look forward to. Especially when you consider the simplified licensing arrangement. Overall, this combination will vastly improve the end-user experience and also allow IT teams to save costs and function more efficiently.

Addressing concerns about Microsoft Endpoint Manager

We all have our preferred tools that we use and that enable our businesses to operate optimally. So naturally, there will be concerns about combining Intune and Configuration Manager. What exactly does it mean for these products?

By bringing these products together under one umbrella, Microsoft is not doing away with Configuration Manager as many think. And the choice of name allows Microsoft to keep adding features to the platform.

Therefore if you have solutions that are built on Configuration Manager and want to continue using it, you are free to do so. But, the difference is that you’ll also get to leverage the intelligence of the Microsoft 365 cloud.

Basically, starting in version 1910 Configuration Manager now falls under the Microsoft Endpoint Manager branding. And as for the other components of the System Center suite, there are no changes to report.

Wrap up & Microsoft Endpoint Manager

The solutions that businesses use need to continuously evolve to allow us to boost productivity and enhance data security. We need solutions that can offer the deployment of a seamless, end-to-end management solution.

And by combining Microsoft Intune and Configuration Manager into Microsoft Endpoint Manager, we can get just that. A solution that gives clients modern management and security while integrating with other Microsoft products in a way that optimizes device management.

List Packages that run in user context (Run with user’s rights)

Posted on April 26, 2019 by Thomas.Marcussen

Introduction

After last weeks post with the script sample to list Packages that run in user context, there where some good feedback from people still using packages, and requiring a list of packages that install within the user context (Run with user’s rights / Execution mode as user)

It seemed that many was still using Packages, either as a result of legacy migration or to avoid some application re-packaging.

So here is the followup post, with a new script to list all packages and package with programs that run in user context.

From my point of view, its still the same; Using PSADT pretty much any package can be converted to be installed as system, and the needed stuff (registry keys, files etc) in the user context can be added in a structured and controlled way.

I do still come across some applications that i would prefer to have in MSI with all settings etc added, at least for simplicity, for those packages I still prefer to use Advanced Installer.
When talking Advanced Installer, they also have a great support for MSIX, that makes to process so much easier and cost efficient.

This script will list all packages with programs, that is configured to install as user (within the user context)

All you need to do is configure the path to your import module and set the site code.

A file will be created in “C:\TEMP\Packages_and_Programs_Run_Mode_List.csv” with the following format:

“Package Name”,”Package ID”,”Program Name”,”Run with USER’s right”
“My Application”,”BB10001D”,”execute”,”TRUE

With the example above we have a package ‘My Application’ that has a run mode configured: Run with user’s rights

Properties on the program, where the program run enviroment is configured to Run with Users’s rights

Download the script from TechNet Gallery – https://gallery.technet.microsoft.com/Generate-a-list-of-d8778d4c?redir=0

List Applications that run in user context (Install for User)

Posted on April 23, 2019 by Thomas.Marcussen

Introduction

When deploying applications sometimes they are created to install within the active users context.
This means that the actual installation requires the users to have the needed permissions to the filesystem, registry and etc.
In some cases local administrative rights are needed to perform the application installation, this is not a good practice.

As applications mature for the modern design of the Windows Operating System or we choose to remove the users administrative rights due to security reasons, we may need to list and change the behavior of existing Applications.

This script was created to list applications that is configured to run with Installation behavior: Install for User

The actual output will end up in the export csv file

Script Download [download id=”893″]

Today with the modern management tools and applications, the users should not have local administrative rights on a permanent basis.
Most, if not all applications can be repackaged to deploy without the need for administrative rights.

Useful links:

PowerShell Application Deployment Toolkit: https://psappdeploytoolkit.com
Advanced Installer: https://www.advancedinstaller.com/
Access Director Enterprise: https://ctglobalservices.com/access-director-enterprise/

Using SCCM CI Baseline to check for expiring user certificates

Posted on June 11, 2018 by Thomas.Marcussen

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

Create Configuration Item

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

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

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

To create Configuration Item, click New:

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”

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

$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: [download id=”787″]

and click OK

Click Next

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

Type in the compliance 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):

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

Click OK

Click Next

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

Configuration Item is ready now.

Next step is to create Configuration Baseline.

Create Configuration Baseline

Right click Configuration baseline and 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.

Please make sure that Purpose set to Required!

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

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

Deploy the Configuration Baseline

Go to configuration baseline and right click and select Deploy.

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!

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.

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

Unified Extensible Firmware Interface (UEFI)

Posted on May 13, 2016 by Thomas.Marcussen

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).

Thomas Marcussen

Everything System Center Professional with a passion for technology

Tag Archives: SCCM