Everything can be done automatically, as long as you configure it manually :-)
Remote help is the new sought-after feature, which provides classic remote assistance capabilities to Windows. Remote help was announced during this years Microsoft Ignite, and started its public preview rollout last week.
Remote help is integrated with Microsoft Endpoint Manager, and this blog post serves as my first look into getting started and using this new feature.
TL:DR: Find a short video recording of the Remote help workflow down in the post. 🙂
I find this highly relevant to share at this day. Especially in regards to yesterday’s ‘false positive’ situation, where a lot of system admins got a good scare, when Defender for Endpoint reported that “Suspicious ‘PowEmotet’ behavior was blocked’ on a high percentage of the enrolled devices.
What I really mean by this, is that when you have the option to reduce the attack surface of your environment, you should look into doing so ASAP.
Let’s say yesterdays situation was real, and you for whatever reason didn’t have behavior monitoring enabled in Microsoft Defender Antivirus. You would regret that pretty soon after being hit, when you realize that it could have been prevented.
Same goes for above. Rather look into enabling this new ASR (Attack Surface Reduction) rule today, rather than later after being compromised.
Back in the days, when I started out being a newbie in the software deployment world, I had no real grasp about the different contexts (USER vs. SYSTEM), and I found it to be a trivial task to combine the two.
Today I find it an obvious approach, and in this post, I will give a quick example of how to modify registry for the CURRENTLY logged on user, while delivering an installation in SYSTEM context.
Oftentimes the scenario is, that you need to deploy software which requires local SYSTEM permissions, and while doing so, you’d like to modify the registry for the CURRENTLY logged on user.
This is something that I’ve wanted to do for a while; to always install the latest BIOS and drivers automatically during OSD.
Keeping BIOS and driver versions up to date, can be a tedious and time consuming task, and I wanted to take on a more cloud-like approach.
For that reason, I’ve spent some time on Lenovo Thin Installer as well as Lenovo System Update, but they didn’t quite live up to my expectations and need for flexibility.
Instead – and by coincident – I stumbled upon this awesome PowerShell module: jantari/LSUClient
It does exactly what Thin Installer and System Update offers, as well as giving you the flexibility of PowerShell. What’s not to like?
I think most IT-professionals who’s working with software delivery in some sort, has dealt with software and software installers in general, that puts a shortcut on the desktop by default. Annoying indeed.
Typically you’re in for a treat, when trying to figure out how to customize the installer, to prevent the shortcut on the desktop from being created. It’s not rare either, that the installer simply doesn’t support that.
And finally, we are all aware of the desktop-shortcut-mess, when using OneDrive PC folder backup (formerly known as ‘Known Folder Move’), where shortcuts are duplicated and synced between devices. Yikes.
Long story short, I was tired of spending time on desktop shortcuts, so I figured it was time to create my own solution to the problem.
So, I’m quite far behind in my blogging schedule, and I’m merely picking up on a feature which released in preview back some time in May. Luckily, this doesn’t impact the importance of the topic, and therefore I’m still putting it out there.
A neat example of putting Filters to use with Conditional Access, is by protecting your privileged users, like your Global Administrators, with an additional layer, only allowing access to resources if coming from specific devices.
Curious? This post will walk you through how to achieve just that. 🙂
Another kickstarting blog post, getting into the swing of things again after a somewhat lacking period.
Now, RDCman has been revived and arrived last week in a new version 2.8.
For fun and giggles, I did a short PowerShell script which uninstalls the old version (2.7, registered with windows installer) and downloads the new version 2.8 directly from live.sysinternals.com.
This is a little something on the script itself and how to put that to use with ConfigMgr.
A quick post, serving as a kickstarter for my blogging activities, here (almost) post the covid-19 situation.
Today’s topic is probably not something new for a lot of the amazing IT-pros, who’s already familiar with PowerShell ISE and the Configuration Manager PowerShell module.
Nonetheless, I figured this would be a great way to kickstart my blogging activities, while someone else hopefully will learn something new along the way.
A new version of the Windows 10 Toast Notification Script is here. The script is now being on version 2.2.0.
This version brings the option to run the script and thus display toast notifications coming from SYSTEM context.
A requirement has been so far, that the script is being run with the logged on user’s credentials. This is still recommended, but for scenarios where this is not possible, like running this with a task sequence (task sequences always run as local system), this new ability will give you the option to display toast notification for the logged on user, even if coming from local system context.
The work done here, with running the script under SYSTEM, is entirely done by Andrew. Thank you!
Also, with a built-in prevention of having multiple toast notifications being displayed in a row, the script is now also better at handling the re-run behavior in ConfigMgr. Having multiple toast notification displayed in a row, is something that can happen, if a device misses a deployment schedule. The nature of ConfigMgr is to catch up on the missed schedule, and this can lead to multiple toast notifications being displayed.
Almost a year ago, I wrote a blog post on how to configure Microsoft Teams application settings using Configuration Manager and Powershell. For good measures, find this post in the link below:
Not too long ago, I started getting some reports on, that Teams is no longer picking up the changes made to the config.json and that Teams is hanging at the loading screen. I initially tried to reproduce, but was unable to.
I decided to invest some more time into the issue, and ended up being able to reproduce and find the cause. In the process of troubleshooting, I decided to try and move this into Proactive Remediations in Microsoft Endpoint Manager as well. The result made up this blog post.
Below a quick illustration of running the solution manually. The detection script detects that Microsoft Teams needs its settings configured, and the configure script carries out the configuration.
