Everything can be done automatically, as long as you configure it manually :-)
Following up on my previous post about the new Outlook client, I want to share a quick update. The new Outlook now comes preinstalled on Windows 11 version 23H2 and later. In this post, I’ll provide a PowerShell script to help you uninstall it automatically across your devices using Microsoft Intune.
More details on the preinstalled new Outlook: Control installation and use of new Outlook – Microsoft 365 Apps | Microsoft Learn
The new Outlook transitioned from preview to general availability (GA) in August 2024. If you’re using Microsoft 365 apps for Enterprise (formerly known as Microsoft Office) on the current channel, you might be automatically switched from the classic Outlook to the new Outlook starting January 2025, unless you take action now!
I’m already leveraging some comprehensive PowerShell scripts to manage parts of the registry within our environment, so it didn’t take long for me to add the necessary registry keys and values to:
In this post, I’ll share the PowerShell script I’m using to prevent users from migrating to the new Outlook if your environment isn’t quite ready for it. If the script seem too complex for your needs, let this post serve as both inspiration and a reminder about the new Outlook.
In this brief post, I will share the solution to a recurring issue within our environment where a Microsoft 365 add-in (also known as an integrated app) deployed from the Microsoft 365 admin center was frequently missing in Outlook.
The custom integrated app in question is deployed by uploading an add-in manifest to the Microsoft 365 admin center. From there, it is assigned to either the entire organization or a selected group of users.
In this instance, the add-in manifest was updated with a new version. However, the changes were not properly reflected in Outlook for our users.
It appears that Outlook does not effectively clear cached content from the add-in. Therefore, it is recommended to manually clear this cache if any issues arise.
Approximately two years ago, I authored a blog post detailing how to customize the taskbar in Windows 11. You can find that post here: Customize your Windows 11 taskbar during OSD with ConfigMgr using just PowerShell – imab.dk
Since then, there have been some changes from Microsoft, and the method I previously described is no longer supported. For more information on these changes, please refer to: Configure the applications pinned to the taskbar | Microsoft Learn
In summary, the cmdlet Import-StartLayout is no longer supported and does not accept the .xml file, resulting in the following error: Import-StartLayout : The file C:\WINDOWS\Taskbar.xml is not a valid layout file
To address this, I have modified the solution I used back then, and the new approach is outlined in this blog post.
Disclaimer! Following introduction has been written using Copilot, because time is of the essence and AI is or will be an inevitable thing – also in regard to writing blogs. The script and the rest of the post is written by me. 🙂
In the ever-evolving landscape of cybersecurity, staying one step ahead is crucial. Today, we delve into a PowerShell script designed to enhance your system’s security by removing the Quick Assist app from Windows 11.
As highlighted in this Microsoft Security Blog, threat actors have been misusing Quick Assist in social engineering attacks leading to ransomware. Quick Assist, a built-in remote control app in Windows 11, has been exploited by cybercriminals, notably the financially motivated group Storm-1811, known for deploying Black Basta ransomware.
To counter this threat, our featured PowerShell script, removes the Quick Assist app from your system. This script is a proactive measure to mitigate the risk of such attacks, especially for environments where Quick Assist is not in use.
In the following sections, we’ll walk you through the script and its usage with Microsoft Intune. Let’s get started!
I know Microsoft Intune has the ability to configure this particular user rights assignment natively already. At time of writing, the new security baseline for Windows 11 23H2 in Intune configure this as well, restricting local logons to the built-in groups: Users and Administrators.
This solution does something else. This solution grabs the currently logged on user and configures the ‘Allow logon locally‘ policy to ONLY allow this very user as well as Administrators to be able to log on locally. A custom group is added as well for backup reasons. If no user is logged on, the script does nothing. More details down below.
The solution is made to prevent ‘stealing’ credentials from one user/device and be able to use it on another device within the same environment.
If you are working with device management and IT security in general, you have probably heard about the recommendation to disable the legacy protocol NetBIOS in Windows.
If this is news to you, there’s some interesting reading for you in this article: Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay, Sub-technique T1557.001 – Enterprise | MITRE ATT&CK
NOTE: Before disabling anything, make sure you do your due diligence and monitor your environment for NetBIOS traffic, so you don’t accidently break stuff! Wireshark can help you with this. 🙂
This post is a just a quick follow up on my previous post: Uninstall any application in a jiffy using PowerShell and Configuration Manager
I received a few questions whether the PowerShell script can be used with Microsoft Intune instead of Microsoft Configuration Manager. And sure! This post will explain one of many approaches available with Intune. 🙂
PowerShell version 2 is to this day still preinstalled on Windows 11 and all Windows Server versions with the exception of Windows Server 2022.
As the reader may know, PowerShell is a powerful tool that plays an important role in administering Windows systems. However, it also contains various features that can be leveraged by attackers with ill intentions.
If PowerShell version 2 is installed, it’s possible to bypass the constrained language mode, which normally is being enforced by application control solutions like AppLocker and similar.
PowerShell Constrained Language is a language mode of PowerShell designed to support day-to-day administrative tasks, yet restrict access to sensitive language elements that can be used to invoke arbitrary Windows APIs
If you haven’t removed PowerShell version 2 already, you should consider looking into it today as an early Christmas present. 🙂
Ps. this solution is only targeting workstations. If you need to remove PowerShell version 2 from servers, you cannot leverage Microsoft Intune. You should instead look into Configuration Manager or similar.
Active Directory is a prime target for attackers – and for most organizations something that’s considered the crown jewels. This is due to Active Directory still being the bread and butter for most organizations in regard to authentication and authorization.
When it comes to security, automation is your best friend and keeping a close eye on privileged group membership should be on top of your list.
This post will walk you through, how you can make sure no unwelcome objects make their way into privileged groups in on-premises AD, by leveraging Microsoft Sentinel and its option to run playbooks automated.
This breaks down to Microsoft Sentinel generating an alert, which triggers the associated Playbook, which triggers a Logic app, which triggers a Runbook in an Automation Account, which ultimately runs a PowerShell script on an on-premises server.
Big shout out to my colleague Christian Frohn Petersen who assisted in setting up the prerequisites for this solution. 🙂
