Microsoft Intune – New Updates in PowerShell Scripts

Microsoft Intune is one of those brilliant products that has helped to optimize IT infrastructure for many businesses. It’s a platform that can transform your business into a modern workplace. And its capabilities are almost without limit. If you want to upload PowerShell scripts in Intune, there is the Microsoft Intune management extension (IME) that you can use for that. This management extension can enhance Mobile Device Management (MDM) resulting in a simpler move to modern management. With all this done, you can then run these scripts on Windows 10 devices. PowerShell scripts are important in a lot of different use cases and this blog is going to take a look at what this technology can do.

What is PowerShell?

PowerShell is a scripting and automation platform belonging to Microsoft. It’s an amazing product that is both a scripting language as well as an interactive command environment that is built on the .NET framework. Released back in 2006, PowerShell was basically a replacement for Command Prompt as the default method for automation of batch processes and creation of customized system management tools. PowerShell can easily automate laborious admin tasks by combining commands known as cmdlets and creating scripts. Available in all Windows OS starting with Windows 2008R2, PowerShell plays a huge role in helping IT professionals configure systems.

Adopting modern management

Modern workplaces now have plenty of user and business-owned platforms allowing users to work from anywhere. With MDM services like Microsoft Intune, you can manage devices that are running Windows 10. The Windows 10 management client will communicate with Intune to run enterprise management tasks. Windows 10 MDM features will be supplemented by IME. With this in place, you can create PowerShell scripts to run on Windows 10 devices e.g, creating a PowerShell script that does advanced device configurations. Having done this, you can upload the script to Intune and assign the script to an Azure AD group. Then run the script. Moreover, you can monitor the run status of the script from start to finish.

Latest updates from Microsoft

In November 2020, Microsoft announced the general availability of PowerShell 7.1 which is built on the foundation of PowerShell 7.0. The goal was to bring about improvements and fixes to the existing technology. Some of these features, updates, and breaking changes include:

  • PSReadLine 2.1.0, including Predictive IntelliSense
  • PowerShell 7.1 has been published to the Microsoft Store
  • Installer packages have been updated for new operating system versions with support for ARM64
  • 4 new experimental features and 2 experimental features promoted to mainstream
  • A number of breaking changes that improve usability

Using scripts in Intune

Before IME can automatically install when a PowerShell script or Win32 app is assigned to the user or device, a few prerequisites should be met:

  • Windows 10 version 1607 or later, Windows 10 version 1709 or later for devices enrolled using bulk auto-enrollment.
  • Devices joined to Azure AD including Hybrid Azure AD-joined which consists of devices that are joined to Azure AD, and are also joined to on-premises Active Directory (AD).
  • Devices enrolled in Intune namely devices enrolled in a group policy, devices that are manually enrolled in Intune, and co-managed devices that use both Configuration Manager and Intune.

Script policy creation

Start by signing in to the Microsoft Endpoint Manager admin center. From there you’ll select Devices then PowerShell scripts then add. Under Basics, you will then have to provide a name and a description for the PowerShell script. Next, you go to Script settings and you’ll have to enter the required properties. After that, you select Scope tags, however, these are optional. And then select Assignments > Select groups to include and an existing list of Azure AD groups will be shown. Lastly, in Review + add, you’ll see a summary of the settings you configured. Select Add to save the script. When you have done so, the policy is deployed to the groups you chose.

Important considerations

If you have scripts that are set to user context with the end-user having admin rights, by default, the PowerShell script runs under the administrator privilege. Also, end-users don’t need to sign in to the device to execute PowerShell scripts. The IME agent checks with Intune once per hour and after every reboot for any new scripts or changes. In the event of a script failing, the agent attempts to retry the script three times for the next 3 consecutive IME agent check-ins. And as far as shared devices are concerned, the PowerShell script runs for every new user that signs in.

PowerShell scripts limitations

Although with Microsoft Intune you can deploy PowerShell scripts to Windows 10 devices, there are a few limitations worth noting. These include: 

  • You won’t get support for running PowerShell scripts on a scheduled basis.
  • Although you can see whether the PowerShell script execution succeeded or failed, the output generated is only available on the endpoint that executes it and is not returned to the MEM Admin Portal.
  • Since executed PowerShell scripts are visible in the Intune Management Extension log file as plain text, credentials can’t be passed securely.
  • The Intune Management Extension agent responsible for executing PowerShell scripts on the endpoints only checks once an hour for new scripts so there is a delay with execution.

Wrap up

Maximizing the time we have is increasingly a massive concern for most organizations. Technological innovation has made it such that we can have more productive time on our hands. PowerShell is a product that is very useful to IT professionals for overall system management. By being able to automate the administration of Windows OS and other applications, organizations can operate more efficiently. The evolution of this platform since its release fourteen years ago has seen it grow from strength to strength. Undoubtedly, this is a product that can easily boost your productivity.        

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

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 Galleryhttps://gallery.technet.microsoft.com/Generate-a-list-of-d8778d4c?redir=0



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

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 Get_Application_USER_Context_List



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/



Setting up the lab environment – Hyper-V

The host was installed with Windows Server 2016.
This means Hyper-V is a feature that we just need to enable – yay!

  1. Open a elevated PowerShell prompt
  2. Run the command: Install-WindowsFeature -Name Hyper-v -IncludeManagementTools -Restart

The command will automatically reboot once installed
NOTE: In some cases you will have to enable Intel-VT in BIOS.
You can read more about the system requirements here: Systems Requirements for Hyper-V on Windows Server 2016

For the actual setup of guests machines, I will be running mostly Windows Server 2016, Windows 10 and maybe a Linux guest or two.
Don’t forget to review: Supported Windows guest operating systems

Now to the Hyper-V Switch configuration:

I am going to add an external switch, as my client is already connected to the network on the correct vlan.
Keep in mind I got a seperat USB NIC with 2 Ports (USB 3.0 to Dual Port Gigabit Ethernet Adapter NIC w/ USB Port)
This means i will be able to have my on-board primary NIC only for management and use one of the other free ports only for VMs.

  1. Open Hyper-V Manger
  2. Mark your server
  3. Click Virtual Switch Manager in the actions pane
  4. Mark External
  5. Click Create Virtual Switch
  6. Name your switch – Example: External – 254 (254 indicating the vlan)
  7. Remove the checkbox in Allow management operating system to share this network adapter
  8. Mark: Enable single-root I/O virtualization (SR-IOV)
    Not familiar with SR-IOV? Read this blog post by John Howard: Everything you wanted to know about SR-IOV
  9. Click Ok
    You might get a warning that pending network configuration will prevent remote access to this computer – If your connected to the server using another NIC, you will not be disconnected.

This concludes the basic configuration of the Hyper-V host.
We installed Hyper-V and configured a switch with external access.

The next post will be more detailed with the actual Hyper-V guest installations

Setting up the lab environment – Deduplication

The next step for the lab or so-called home data center: Installing and Configuring Deduplication

I was going to use a USB stick for the Windows Server 2016 OS.
The main reason for this: DEDUPLICATION.

I did start out with a USB stick, but due to performance issues this was changed – read the follow-up post (http://blog.thomasmarcussen.com/follow-up-on-the-home-datacenter-hardware/)

The reason for having the OS on a separate volume: Deduplication is not supported on system or boot volumes. Read more about Deduplication here: About Data Deduplication

Let’s get started

Installing and Configuring Deduplication

  1. Open an elevated PowerShell prompt
  2. Execute: Import-Module ServerManager
  3. Execute: Add-WindowsFeature -Name FS-Data-Deduplication
  4. Execute: Import-Module Deduplication

Installing Deduplication

Now we installed data Deduplication and it’s ready for configuration.

My Raid 0 volume is D:
The volume will primarily hold Virtual Machines (Hyper-V)
I’m going to execute the following command: Enable-DedupVolume D: -UsageType HyperV

Enable Deduplication for volume

You can read more about the different usage types here: Understanding Data Deduplication

Some quick info for the usage type Hyper-V:

  • Background optimization
  • Default optimization policy:
    • Minimum file age = 3 days
    • Optimize in-use files = Yes
    • Optimize partial files = Yes
  • “Under-the-hood” tweaks for Hyper-V interop

You can start the optimization job and limited (if needed) the amount of consumed memory for the process: Start-DedupJob -Volume “D:” -Type Optimization -Memory 50

 

 

 

You can get the deduplication status with the command: Get-DedupStatus

 

 

 

 

The currently saved space on my volume is 46.17 GB
That is for a 2 ISO files and a reference machine for Windows Server 2016 and the reference disks copied to separate folder.

More usefull powershell cmdlets here: Deduplication Cmdlets in Windows PowerShell

I do love deduplication especially for virtual machines, hence most of the basic data is the same.
The disks are also rather expensive so getting the most out of them is preferred.