Windows 365 is a service that provides a Windows Cloud experience, allowing users to access a Windows desktop from anywhere. One of the key features of Windows 365 is the ability to create restore points, which are snapshots of the system at a specific point in time. Let’s take a look at what those mean!
Overview of Windows 365 Restore Points
Using restore points in Windows 365 offers several advantages. Firstly, they provide a safety net for system recovery, ensuring that users can quickly restore their system to a working state in case of any issues.
Secondly, restore points help protect data by preserving user settings and installed applications. This means that even if a system crash occurs, users can recover their data without losing important information.
Additionally, restore points can be used to test new software or updates, allowing users to revert to a previous state if the changes cause problems.
How to adapt the automatic Windows 365 Restore Points in Microsoft Intune
By default Microsoft Intune will create several restore points for each and every Cloud PC.
The amount of restore points will never change and is two bi-weekly restore points and ten restore points you can adapt the recurrence of, this is done through a “User Setting”:
Once you are here, you can adapt the recurrence.
What about Storage Accounts?
Storage accounts play a crucial role in managing restore points for Windows 365. These provide a secure solution for storing large amounts of data, including your restore points.
By utilizing storage accounts, users can ensure that their restore points are safely stored and easily accessible when needed. One of the key benefits of using storage accounts is the ability to manage data efficiently, with options for redundancy and backup to protect against data loss.
Additionally, storage accounts offer flexibility, allowing users to configure permissions and access controls to suit their needs. To use storage accounts for restore points, users can integrate their Windows 365 environment with Azure, setting up containers and blobs to store the restore points securely.
This integration ensures that restore points are preserved long-term and can be retrieved quickly in case of system recovery needs.
Creating the right Azure Storage Account
There a few requirements to be met when creating a Storage Account for the Restore Points of the Cloud PC. They are listed below and we will go over the steps needed in Azure after these.
Instance details
Region: Same region as Cloud PC is recommended because of performance. There is no restriction on which region you should choose.
Performance: Premium (supports hot access tier) or Standard (supports all access tiers).
Premium account type: Page blobs
Security
Minimum TLS version: Version 1.2.
Confirm Allow blob anonymous access is disabled (the default).
Disable Enable storage account key access.
Networking
Network access: Enable public access from all networks
Creating a manual Restore Point in Microsoft Intune
Once the Storage Account has been set up, you have the option to create a manual restore point in Microsoft Intune.
If this option is not visible, verify the requirements above as the Storage Account will not be visible if it does not meet these.
Conclusion
In summary, Windows 365 restore points are an essential feature. They provide a reliable way to recover from system issues, preserve user settings, and test new software or updates.
By creating and managing restore points effectively, users can safeguard their systems and minimize downtime.
Additionally, utilizing storage accounts for long-term storage of restore points offers a scalable and secure solution for preserving these critical backups. I encourage everyone to take advantage of them in Windows 365 to enhance system management and data protection strategies.
Managing local admin rights across a modern workplace is a delicate balance between empowering users and maintaining security. With the introduction of Endpoint Privilege Management (EPM) in the Microsoft Intune Suite, organizations can now grant Just-In-Time (JIT) and/or rule-based elevation for standard users—without compromising control or compliance.
However, when elevation requests require approval, IT teams need a fast and reliable way to respond.
In this post, we’ll walk through how to integrate EPM with Microsoft Teams using Azure Logic Apps. The goal? Automatically notify IT or security teams when a user requests elevation, streamlining the approval process and improving visibility. Whether you’re managing a large enterprise or a hybrid workforce, this solution helps reduce friction while keeping your endpoints secure.
What is Endpoint Privilege Management?
Endpoint Privilege Management (EPM) is a feature in the Microsoft Intune Suite that allows organizations to manage and control local administrator rights on Windows devices—without granting permanent admin access. It enables rule-based and Just-In-Time (JIT) elevation, ensuring users can perform privileged tasks only when necessary, and only under defined conditions.
Rules-Based Elevation: Three Options
EPM supports three types of elevation rules:
Automatic Elevation The application is elevated silently without user interaction, based on predefined rules.
User-Confirmed Elevation The user is prompted to confirm the elevation request, typically with a business justification and/or Windows authentication.
Support-Approved Elevation The user submits a request that must be approved by IT or support staff before elevation is granted. This is the model we’ll focus on in this post, as it allows integration with Microsoft Teams for real-time notifications and approvals.
Just-In-Time Elevation with Support Approval
Support-approved elevation is ideal for organizations that want to maintain strict control over admin rights while still enabling flexibility for end users. Essentially, when you are requesting elevation, the request is logged and routed for approval. Furthermore, by integrating this process with Microsoft Teams using Azure Logic Apps, IT teams can receive instant notifications and respond quickly—without switching tools or missing critical requests.
Currently, when approved, these requests remain valid for 24 hours. However, this is something I would like to tackle in another blog post somewhere down the road.
Benefits of Using EPM
Implementing Endpoint Privilege Management offers several key advantages:
User Empowerment: Allows users to perform necessary tasks without waiting for manual intervention—when policies allow it.
Improved Security: Reduces the attack surface by eliminating standing admin rights.
Operational Efficiency: Automates elevation workflows and reduces helpdesk overhead.
Compliance and Auditing: Provides detailed logs of elevation activity for auditing and compliance reporting.
Scenario Overview
It’s essential that IT or security teams are notified as soon as a user submits a request. This ensures timely responses and keeps the approval workflow efficient.
To achieve this, we use Azure Logic Apps to automate the process of sending a message to a Microsoft Teams channel the moment a request is made. The Logic App listens for elevation request events and posts a structured message (containing details like the user, device, application, and justification) directly into a designated Teams channel.
To monitor these requests, we leverage the Microsoft Graph API, which allows us to query and react to EPM-related events. This integration ensures that the notification is both real-time and secure, and it can be extended to include approval workflows or logging mechanisms if needed.
This setup bridges the gap between endpoint security and operational responsiveness, giving IT teams the visibility they need without manual overhead.
Step-by-Step Guide
Configure EPM
In my demo environment I want to enable all the people for the “Mark 8 Project Team” to be able to open Wireshark as an elevated user. For this I will create a “Elevation Rules Policy”, I am assuming here that EPM was already configured beforehand.
I start of in Microsoft Intune, where I navigate myself to the “Endpoint security”-blade. It is here we will find “Endpoint Privilege Management”. Where we will go to “Policies” and have the option to create a new “Elevation rules policy”.
After going through the basics, we will have to fill in more detailed information about the package we are going to add to the rule. This information can be collected using the “EpmTools.dll”.
Using this tool it is even possible to extract the publisher certificates out of the file. These can be added to the reusable library.
Finally, we will fill in all the necessary details about the file.
You can easily check if everything was configured correctly by checking it from a demo device. From the end-user perspective the “Run with elevated access”-option should be visible. After which, the elevation request should open.
For the Intune administrator the request should come into the “Elevation requests”-tab almost immediately.
This concludes the basic setup of EPM within this article. This is all we need to verify that there is date being picked up by the GraphAPI. To consume this data we will create an “App registration” in the next step.
Create App registration with correct permissions
First of all, we want to make sure that our data is being picked up in the GraphAPI. This should not be an issue as all components of the Intune Suite are connected to the GraphAPI.
Through the Graph Explorer, you can easily check the date under “deviceManagement/elevationRequests”.
Be aware to check that you are using the beta version of the api and that “DeviceManagementConfiguration.Read.All” has been granted to the Graph Explorer. Otherwise it will return a permission error.
Creating an app registration is quite easy, but will allow us to grant these permissions there and not have to worry about authentication in our EPMChatbot.
Once this is done, we will configure the API permissions. As said above, the only permission we need is the “DeviceManagementConfiguration.Read.All”.
Make sure to also “Grant admin consent for <yourOrganisation>”.
Our final step is to create the Client secret that can be used by our Azure Logic App.
Make sure to take note of the value and secret, as these will be redacted after the creation.
On to the last step, where we will create an Azure Logic App!
Create Azure Logic App
Finally, we will create an Azure Logic App that will poll the GraphAPI at a recurring interval for new approval requests. This will use the App registration we created before to make sure it has the right permissions. After this we get all the data from the GraphAPI, we will parse it and than use the Teams connector to send a formatted message in a Channel of our choice.
First things first, creating the Logic app. This is done through the Azure Portal.
We will opt for a Consumption-based Logic App to create our MVP.
At last, we will use the Logic app designer. Here we will start by adding a trigger. Here we chose to go with a recurring moment. You can specify the time between this however you want.
Afterwards, we will collect the data from the GraphAPI. Using the information we used in our test with the Graph Explorer. It is important here to also configure Authentication under the “Advanced parameters”. Otherwise, the Logic app will not have access to the right permissions.
Afterwards, we will Parse the JSON that is in the Body of our HTTP request. Here you can use the “Use sample payload to generate schema” option. Creating the schema for the JSON can be tedious task. By using the example output from our Graph Explorer test, we can do this in a heartbeat. Finally, we will use the “Post message in a chat or channel”-option from the Teams connector. You can see there are quite a few options like the UserPrincipalName, file name and so on. We have just used a minimum in this demo to make sure everything works as it should.
The result!
After all of these steps, the following message should appear within your Teams channel of choice, with a link that can send you straight to Intune portal.
Conclusion
To conclude, you can see that it is perfectly possible to automate your EPM approvals with Teams. In this article we have built an MVP to look into the possibilities. However, there is much more to look into! In the next few months I’ll take a look at what options we have to further integrate this in Teams to completely remove Intune out of the equation. Let’s see how far we can go!
As always, any questions, remarks or improvements spotted in here, feel free to reach out to me!
Welcome to this article about Entra ID authentication for Ubuntu devices. Entra ID authentication is a powerful way to authenticate on your devices. Additionally, you will learn how to enroll your Ubuntu device in Intune, a cloud-based service that helps you manage and secure your devices. By the end of this article, you will be able to use your Entra ID credentials to log in to your Ubuntu device. You will need some basic knowledge of Ubuntu, Microsoft Entra, and Microsoft Intune to follow along. I hope you enjoy this article and find it useful. Let’s get started!
Setting up an Entra ID Application
We start with the beginning! Using the Entra ID authentication with Ubuntu requires the creation of a Microsoft Entra application. This application needs to be able to retrieve the tenant ID and application ID required for the authentication.
Creating an Entra ID Application
We will create the application through the Entra portal. Going through the “Identity > Applications > App registrations” where we will select “New registration”. We will name the application “Ubuntu Entra ID Authentication”, so the purpose of the application within our tenant is clear. The remaining options you can leave as default and click “Register” at the bottom of the page. This will give you the “Application ID”. Together with the “Tenant ID” this forms the basis for the Entra ID authentication.
Using a Script to Get the Ubuntu Device to Use Entra ID Authentication
The first thing we got to do before enrolling the device to Microsoft Intune is to enable the authentication with Microsoft Entra ID. Unfortunately, this is something we still have to do manually, as for today there is no zero-touch provisioning with Microsoft Intune for Linux nor Ubuntu devices. However, as any good system administrator would do, we put this in a script.
Using a script to enable the authentication
Although support for Linux is still fairly limited at this point in time, we can already use the script we created to prepare everything for the Entra ID authentication.
The script can be seen below in its entirety. Make sure to adapt the Tenant ID and App ID.
#!/bin/bash
# Replace these two variables with your relevant Tenant ID and Client Secret Value
tenant_id="<tenant-id>"
app_id="<app-id>"
# Check if the script has already run
if [ -f /var/run/aad_ubuntu.lock ]; then
echo "Script has already run. Exiting..."
exit 0
fi
# Create lock file to indicate that the script has run
sudo touch /var/run/aad_ubuntu.lock
# Check Ubuntu version
if [[ $(lsb_release -sr 2>/dev/null) == "23.04" || $(lsb_release -sr 2>/dev/null) == "23.10" ]]; then
echo "Ubuntu version is supported."
else
echo "Unsupported Ubuntu version."
exit 1
fi
# Install required packages
sudo apt-get update
sudo apt-get install -y libpam-aad libnss-aad aad-cli
# Configure Azure Active Directory Authentication
echo "auth [success=1 default=ignore] pam_aad.so" | sudo tee -a /etc/pam.d/common-auth
# Enable home directory creation on login
sudo pam-auth-update --enable mkhomedir
# Add your tenant details to the configuration file
sudo truncate -s 0 /etc/aad.conf
echo "tenant_id = $tenant_id" | sudo tee -a /etc/aad.conf
echo "app_id = $app_id" | sudo tee -a /etc/aad.conf
echo "[cetsjdf.be]" | sudo tee -a /etc/aad.conf
echo "offline_credentials_expiration = 30" | sudo tee -a /etc/aad.conf
echo "homedir = /home/cetsjdf.be/%u" | sudo tee -a /etc/aad.conf
echo "shell = /bin/zsh" | sudo tee -a /etc/aad.conf
# Restart services
sudo systemctl restart systemd-logind.service
echo "Entra ID Authentication setup complete."
exit 0
After getting the successful prompt “Entra ID Authentication setup complete”, we can be certain that it is enabled. Or can we, as you can see below, we try to login with a user before enrolling the device, as that user in Microsoft Intune. This will be vital to further manage the device.
Testing the Entra ID Authentication
We are at the end of our journey! Great! But for the most important part, will it work? Testing it is easy, after rebooting the Ubuntu device, try to login with any user from your Entra ID tenant. If everything goes well, it should look something like below.
Enrolling an Ubuntu Device in Intune
The main question you can ask yourself here is “Why should we enroll a device to Microsoft Intune?”. Fairly simple, we will use Intune to further configure the device so that the local account created during the installation of Ubuntu is no longer to be used. Now there are a couple of things we have to do beforehand, which you can find in the prerequisites below.
Prerequisites
First of all, your device should be at least Ubuntu 22.04 or 20.04 LTS, with the GNOME graphical desktop environment. Be aware that all Ubuntu devices enrolled with Intune are considered corporate-owned devices.
Furthermore, the Microsoft Edge browser and Microsoft Intune app should be installed to the device. This you can do yourself or you can utilize the script that I have created below. All these scripts can also be found on my Github.
#!/bin/bash
# Check if the script has already run
if [ -f /var/run/aad_ubuntu_prereq.lock ]; then
echo "Script has already run. Exiting..."
exit 0
fi
# Create lock file to indicate that the script has run
sudo touch /var/run/aad_ubuntu_prereq.lock
# Check Ubuntu version
if [[ $(lsb_release -sr 2>/dev/null) == "23.04" || $(lsb_release -sr 2>/dev/null) == "23.10" ]]; then
echo "Ubuntu version is supported."
else
echo "Unsupported Ubuntu version."
exit 1
fi
# Install the Microsoft GPG key
wget -O - https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
sudo install -o root -g root -m 644 microsoft.gpg /usr/share/keyrings/
sudo sh -c 'echo "deb [arch=amd64 signed-by=/usr/share/keyrings/microsoft.gpg] https://packages.microsoft.com/ubuntu/22.04/prod jammy main" > /etc/apt/sources.list.d/microsoft-ubuntu-jammy-prod.list'
sudo sh -c 'echo "deb [arch=amd64 signed-by=/usr/share/keyrings/microsoft.gpg] https://packages.microsoft.com/repos/edge stable main" > /etc/apt/sources.list.d/microsoft-edge.list'
sudo rm microsoft.gpg
sudo apt update
# Update Java for Microsoft Intune
sudo apt install -y openjdk-11-jre
# Install Microsoft Edge
sudo apt install -y microsoft-edge-stable
# Install Microsoft Intune
sudo apt install -y intune-portal
echo "Installation complete."
It might be useful to know that I always include lock files in my scripts to make sure I don’t run them twice. This is not always necessary but is a precaution I take myself. You should end up with an “Installation complete.”-message, as you can see.
Enrolling the device in Microsoft Intune
This is a process we call user-driven enrollment into Microsoft Intune. The process is fairly simple, once the prerequisites are implemented. We will begin by opening Microsoft Edge and logging in.
It is easier to start with logging into Microsoft Edge, this is not a requirement, but it makes our lives easier in the long run.
Afterwards, we continue with the Intune enrollment. The user will need to sign-in and afterwards there will be an additional authentication prompt to apply the configuration.
Conclusion
In this post, I showed you how to set up Entra ID authentication for your Ubuntu 23.04 device, and how to enroll it in Microsoft Intune for further management. Entra ID is a powerful and secure way to authenticate your Linux device with your Microsoft account, and Intune is a cloud-based service that allows you to configure and monitor your device remotely.
By following the steps in this post, you can leverage the benefits of both Entra ID and Intune for your Ubuntu device.
If you have any questions or feedback, please leave a comment below. And if you found this post helpful, don’t forget to share it with your friends and colleagues who might be interested in Entra ID authentication for Ubuntu. Thank you for reading!
One of the features of Intune is Proactive Remediation. This allows administrators to create scripts that automatically fix issues on devices before users even notice them. Adding a language pack using Proactive Remediation script is a straightforward process. I will guide you through the steps in this article.
I have been using this method to add additional language packs to my Windows 365 deployments. This is from great use to organizations that are multi-geographical.
Creating the scripts
First, we will create a language pack installation script. This is split into two parts. One should be designed to detect the language currently in use on the device. The other installs the appropriate language pack.
The first script here uses some basic PowerShell to detect what languages are installed on a system and verifies if the one required is installed.
We will leverage the LanguagePackManagement Module to install the required languages. This downloads and installs the language components for the specified language.
Install-Language de-DE
Additionally, you have the option to directly enable the new language pack by using the following command:
Install-Language de-DE -CopyToSettings
Warning! Please verify that these scripts we created earlier are saved in UTF-8 encoding.
Creating the script package
After we created the language pack installation script , we should create the Proactive Remediation script in Microsoft Intune. To do this, log in to the Intune portal and navigate to Reports. Click on “Endpoint Analytics” and select “Proactive remediations”.
After clicking on “Create script package”, give the script a name and a description and Publisher.
The next step is to select the installation script that we created in the initial step. We do this for both the “Detection script file” and the “Remediation script file”.
Make sure to set the slider for “Run script in 64-bit PowerShell” to “Yes”.
Finally, we should assign the policy. To do this, navigate to the Assignments section of the policy and select the group that the policy should apply to.
Additionally, you can also change the schedule and filter for specific devices.
Conclusion
Adding a language pack using a Proactive Remediation script is a straightforward process that can save administrators time and ensure that devices are always running in the correct language.
By following the steps outlined in this article, administrators can easily create a language pack installation script and create a Proactive Remediation script to automate the installation process.
