The other day, I was showing a friend how to set up Intune deployments. Then it hit me: I have unique scripts for script detections and things like that here on therandomadmin.com. However, I haven't really gone through the detection rules for built-in items. I was like, well now I have to fix that. So here we are going to fix that with the Intune Detection Rules. Let's get started.
Types of Intune Detection Rules
There are three built-in detection types that we will go over today. They are the MSI, File, and Registry.
MSI is like the easy button, (no not the staples one from the commercials... did I just age myself?)
File is my least favorite one, but it works for legacy apps
Registry is my favorite one and it's the one that I will spend some time on for you all.
Other than the built-in items, there are scripted items which is unique in it's own rights. You can take a look at how these scripts work here. Andrew has a good tutorial on his blog as well. Today will be all about the built-in items.
The Built-In MSI Rule
The MSI rule is the easy button of the detection scripts. If you are using an MSI, it will pull the information directly from the MSI. Once you get to the detection rule part you can follow these steps:
Click Add
Select MSI
And click save
Magic, right? The other thing you can do is select "MSI Product Version Check." Here you can select an operator like "greater than or equal to" and then give it the value. Which is the product version. This helps with auto-updated items. Which I always suggest using. Below is a screenshot.
File Detection Rule
Our next built-in detection rule is for files. This is good if you have an app that doesn't install like normal apps. Older apps or more niche apps are like this. For example. We installed a special Creo app. It installed in the C:\PTC location, and it didn't add itself to the registry uninstall strings. It didn't come in an MSI; it was an EXE with custom everything. This app was a pain in the backstracher. So we used the File location rule. Here is how you can set it up.
Inside your detection rule, click Add.
Rule type: File
Path: The folder that you want to check. In this case it was C:\PTC
File or Folder: Here we wanted to see if the creo.exe existed. So, that's what I put here.
Detection Method: We used file or folder existed.
Greater than or equal to string
As you will learn, I am all about the version numbers. If you select the string (version), you will need to get that version number from the file you are pulling from. You can do this with PowerShell pretty quickly.
Once you have this information, you will then proceed to input it into the value section once you select the string (version) and greater than or equal to options.
Built-In Intune Detection Rule for Registry
The registry key is the most common and the most useful as well. Most apps install themselves in this method. The script below is going to be your best friend. What it does is give you the information you need. Lets break down what each item is so we can look at the script and make this happen. I'm giving this the most focus because it's the most common.
Registry Type: The type we are using.
Key Path: The path of the uninstall string that we will be using
Value Name: What we are looking for, this case we will be looking for displayversion
Detection Method: Version Comparison
Operator: Greater than or equal to
Value: What value we are looking for
Assocated: Is it a 32 or 64.
Script
So you will have to go digging into the registry for this information. However, this registry area is just confussing and really hard to manually dig through. So powershell is once again, our friend.
All you have to do is replace the app name. It will provide you with everything you need inside the built-in detection rule. This is the output that it provides:
RuleType : Registry
KeyPath : HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{6EB73F60-E858-3AF3-913A-0C1783656B42}
ValueName : DisplayVersion
DetectionMethod : Version comparison
Operator : Greater than or equal to
Value : 143.0.7499.170
AssociatedWith32 : False
This script really makes finding apps easier. If the app installs in another place, good hunting, my friends.
What we can learn as a person
I am still missing my keys. I have the backup fob for my car, but I have no idea where my normal keys are. So no house key right now. Sometimes, I need to backtrace what I have done to find where I am going. Which is ok. This is why I document so much because I don't have the brain space to remember everything I have done. This is also why this blog post exists. I realized I never once really did explain how to use the built-in tools. Now I have a place to come and get the script I need and anyone else needs. So that will be nice later down the road, and I will thank myself later. Giving myself the little micro successes in the future is what I am going for here. The keys, on the other hand, I didn't set up a space for them to go with the new desk I have. Thus, they are in the ether somewhere, and when I find them, they will go into my little cubby on my new desk. So, set yourself up for micro successes, whether you know it or not, in the future. This will reduce a lot of stress and anxiety in the future. Remember, 80% of life is the systems that you have put into place. So, let's make good systems. Then you can set up your own Intune detection rules for your life to detect when you gave yourself successes. Like, when I see the wallet inside the new cubby. I can give myself a little thanks.
Ever feel like you’re just guessing which Intune policy to use?
You go into Microsoft Intune thinking, “I just want to block copy/paste from Teams to a student’s phone,” and suddenly you're knee-deep in device configs, app restrictions, compliance policies, and something called MAM-WE (which sounds like a failed robot uprising).
If you've ever been stumped by the difference between Intune device vs app policies, you're not alone. And you’re not doing it wrong — the naming is genuinely confusing.
So, let’s break it down the way it actually clicks — using real-world scenarios instead of theory and tech jargon. If you know what you want to do, you'll know what to use. Lets dive into intune devices vs app policies.
The Three Intune Policy Buckets
Device Configuration Policies – You Own It, You Control It
Think of this like setting the house rules — but only for houses you own.
Device configuration policies give you OS-level control. You can push BitLocker, set PIN rules, enforce Delivery Optimization, apply VPN profiles, and more. But they only work if the device is enrolled in Intune — like, actually enrolled. Not “kinda managed.” Full enrollment.
Lets take a look at a real world senerio. Imagine you have 200 windows 11 laptops and want to enable delivery optimization for windows updates. This would be a Device Configuration Profile. Another example would be if you have 1000 windows 11 laptops that you want to encrypt their fixed drive with bit-locker. Once again, this is another device configuration profile.
If the deivce is apersonal and not enrolled, this policy type is off-limits. No Bitlocker, no VPN, nothing. You don't own it, you don't get a say.
App Protection Policies – Protecting the Data, Not the Device
This one is magic for BYOD situations. Think of it like zipping up your company's data in a fireproff pouch, even if it'son someone else's device. App protection polcies don't care who owns the device. They care about your data. These policies apply to managed apps. Things like outlook, teams, onedrive, and lets you do things like bloc copy and paste. Require PINs to open apps, wipe work data and more.
Lets take a look at a few real world senerios. Students are copying teams messagers and pasting them into discord on their phones. You can block this using App Protection Policy. Lets say you have truck drivers with ipads with outlook on them. You can force the user to enter a pin each time they check their email. That's a App Protection Policy.
App Configuration Policies – Pre-setting the Knobs
Here we are putting the settings into place for different apps. We are not locking down the device. So, if you need a pin for the device, you do this with a device configuration policy. If you need chrome to open on a set website, that's the App Configuration Policy. App configuratin policies let you predefine how apps behave. It's not about control, but it's about consistency. You can push bookmarks, force outlook to use only work accounts, set default browsers for teams, and more.
Lets look at a real world. You have 500 Android Zebra scanners, you need to make sure they all open chrome to a local site. This can be done through the App Configuration Policy. One thing we did for was setup auto updates with zebra on our scanners. We did this with a App configuration profile.
The problem with it is the BYOD. App Configuration policies only work with managed apps. This means, if a user installs outlook through the company portal via intune, then you can manage it. However, if you install outlook through the store app, it just doesn't work.
Why it gets confussing
Let's be real, the names don't help. "App Protection" and "App Configuration" sound way to similar. So here's a simple mental hack to seperating devices vs app policies.
Device Configuration = Control the device itself.
App Configuration = Setup how the app works.
App Protection = Lock down the data inside the app.
Lets test this thinking out with a few senerios.
Possible Answers
Device Configuration Policy
App Configuration Policy
App Protection Policy
You want to prevent employees from copying data from teams to another non-company app.
Your factory has 300 kiosk devices. You want to make sure that the devices can't be logged into by non-it users.
Doctors are using outlook on their personal phones. You need to prevent attachments from being saved locally.
Your compamy users Android enterprise, and you want to push bookmarks to chrome.
You want to rotate the local admin password on all of your windows 11 devices using windows LAPS
Force outlook to only use work accounts
Encrypt phones and force a pin lock on bring your own devices.
Here is a nice little chart to help with these.
Do I manage the entire device?
↳ Yes ➡ Device Configuration
↳ No ➡ Do I want to protect corporate data?
↳ Yes ➡ App Protection
↳ No ➡ Do I want to change how the app behaves?
↳ Yes ➡ App Configuration
Here are the answers.
App Protection
Device Configuration
App Protection
App Configuration
Device Configuration
App Configuration
None of the above, Yep, I tricked you, maybe. If it wasn't a bring your own device, then you would be correct if you say device configruation profiles. Other than that, it's nothing really.
Final Thoughts – “You Know More Than You Think”
This stuff is confusing, and Microsoft doesn’t always make it easy. But now, you’ve got the mental framework:
Device Config = You own the device
App Protection = You own the data
App Config = You shape the experience
Don’t worry about getting it perfect on the first try. Intune is meant to be layered. Pilot first, then scale.
If you ever get stuck again, just ask: “What exactly am I trying to control here?” The answer will almost always tell you the policy you need.
You’ve got this, lets get those devices vs app policies.
What can we learn as a person
In IT, we have access to a lot. More than most people will ever know.
We can shut down Windows Hello, enforce biometric logins, or require ID badges scanned by a camera just to unlock a screen. As system administrators, we often hold keys to every digital door. I could, right now, grant myself full access to every mailbox in the company — all in the name of “making admin easier.” I could quietly assign myself as an owner on every user’s OneDrive and SharePoint site using policies that no one would even notice.
That level of control? It’s terrifying, if you’re honest about it.
Because with great power doesn’t just come great responsibility. It comes with weight. A psychological and emotional load that most people never talk about.
Knowing that you can access someone’s private data — and choosing not to — becomes a moral and mental burden. It sits on your nervous system like a background process you can’t kill. Over time, that mental load becomes stress. That stress becomes anxiety. That anxiety becomes burnout, or worse — panic attacks that don’t go away.
Let’s go back to those access examples:
If you make yourself owner of every mailbox, and something illegal ends up in one — say, child pornography in OneDrive — you’re now not just an admin. You’re a co-owner of that content. You’re legally implicated. That’s not just a technical decision. That’s jail time.
When you hold that kind of access, your body knows, even if your conscious mind tries to ignore it. It keeps a tally. And that tally eventually tips the scale — panic attacks, heart strain, and real, physical damage.
The Illusion of Total Control
I’ve seen brilliant people collapse under the pressure of trying to control everything — juggling complex networks, hybrid systems, countless endpoints, compliance rules, and impossible expectations.
They thought the job was about mastery. But really, it’s about boundaries.
Technology is growing faster than any one human can keep up with. We’re now expected to specialize and generalize. To know cloud, on-prem, security, devices, data — and also keep every system running 24/7 with no mistakes.
That pressure? It breaks people.
So What Can We Learn?
Here’s what I’ve learned — sometimes the hard way:
Control less. Not because you’re lazy — but because your health matters more than a perfect config.
Set boundaries. Just because you can access something doesn’t mean you should.
Say no to full access. Delegate. Distribute. Limit yourself.
Audit yourself. Regularly review what you have access to, and ask: Do I really need this?
Let go. Systems don’t have to be perfect. People don’t have to be flawless. Neither do you.
You’re not here to own everything. You’re here to protect what matters — and that includes you.
So the next time you feel the urge to control every setting, script every failover, and be the hero of the whole system… Pause. Breathe. And remember: the best admins don’t control everything. They know what not to control — and they sleep better because of it.
For the past few months, I have been working with zebra scanners. MC9300 and MC9400 to be more excat. These scanners are unique in the fact that they do not have any cameras. These scanners are Android OS devices. That means they can go into intune without to many issues. Normally, you scan a QR code with your camera and then it takes you to Google Play. However, there is no camera and no app store on these scanners by default. The idea with these units is you use a program called stagenow and have stagenow enroll them into Intune. So, how do you do that? The Zebra documentation is nice, but it has some issues. Enrolling Zebra Scanners into Intune is not for the faint of heart.
So, why? Why not use other MDMs. Good question. I like punishment, maybe? In this case, this is the option management wanted. Thus, I followed orders and made it happen. There are some things you will need before we get started.
Admin access to your Intune with the proper licensing. If you have E5 licenses and a P2 plan, you should be golden.
A wireless network that has access to the stage now computer and to the interent. At this stagenow computer will be running an FTP service.
Creating the Enrollment
Before we start our first steps, we want to create a Kisok scanner device. This will have one or two apps on it. Thats' important to think about. We can create a large number of deployment types, and not all of them fit with our goals. These devices will be used to scan boxes and nothing else. So we will be using corporate-owned dedicated devices. The first step is to create the enrollment in Intune.
Description: This policy is to enroll zebra devices into corporate-owned dedicated devices
Token Type: Corporate-Owned Dedicated devices
Token expiration data: Input a reasonable date
Click Next
Click Create
We will be taken to the policy screen. From here, we need to go into our new policy. Here we will see all the information you just put in. Now we need to get that token.
Click on the policy
Manage > Token > Show Token
Using your cell phone and a QR app, scan the QR to gather its information.
I have a Samsung phone. I just use the scan QR code feature. Then select the show text.
Inside this text, you will see a variety of links and something called "Extra_Enrollment_Token" You will need the string of numbers that follows this. You will also see a CHECKSUM, you will need this hash. Finally, you will see something called Provisioning_Device_Admin_Package_Download_Location followed by a link. Click this link. It will download an APK. This APK is very import and cannot be renamed. You will want to transfer this app to your stage now machine.
Stage Now Setup
Now that we have created the enrollment, downloaded our app and gotten our token, it's time to make the stage now profile. The stage now profile is going to consist of the following configurations.
Stager now Network
Wifi
FileMgr
AppMgr
Intent
Start your stage now application and log into the admin portal. You will need the average MX version of your zebra scanners. On average, I have seen a range from 8.4 all the way to 13.1 in my environment. Thus, we must select our lowest version. In my case, it will be 8.4. I will post a blog post in the future on how to standardize our MX versions with Intune.
Click Create New Profile
Click Xpert Mode
Name the policy. I like to have the mx version in the name and what it's doing. So for our example, I used "Enroll_Intune_8.4" Notice, no spaces.
Now we are sent to the add/edit window. Click Wizard.
Scroll down until you see the "StageNow Network" and click the plus sign. You will notice that it is added to the right-hand menu.
Click the settings tab
Add Wifi, Filemgr, AppMgr and Intent
Click ok
Now we will start creating the profile itself. We are thrilled with the first item in our list, "stageNow Network.". Here we will have drop-downs and other options. So follow along.
Connect a network
Drop Down: The devices I wish to provision are currently not connected to a network. I will define a network with this profile that can be used for staging.
Click Continue
Network Type > Drop Down: WiFi
Certificate Management: No
Please note that if your network uses a cert, you will need to set it up here.
Disconnect Networks: No
We select No because the next section disconnects the networks for us.
Disalbe Network: Yes
This will disconnect from all of the other networks
Click Continue
Add Network: Yes
SSID: Your SSID
Security Mode: Personal
In this example, we are going to use a basic wifi setup with a password.
WPA Mode: WPA/WPA2
Encryption Type: Do not change
We don't change because by default it is aes-ccmp/tkip
Key Type: Passphrase
Protected Key: Checked
Passphrase: <Enter your passphrase>
Use DHCP: Check
Keep everything else as default.
Click continue.
Connect Network: Confirm everything here and click continue
Wifi
After you click the continue button, you are brought to review. Let's click the StageNow Config button at the top. To get back into the configuration window. This is the network we will use for Enrolling Zebra Scanners into Intune. We are doing this here to change some basic settings. Like, is the wifi enabled? Is there a sleep policy? Stuff like that. We want to make sure we can get as much possible out of the way now before we deal with it later.
Target OS: Android
Wi-Fi Enable: Enabled
Sleep Policy: Never Sleep
Network Notification: Use Network Notifications
Enable Wi-Fi Verbose Logging: Do not change
If you want this feature, you can set it; however, it eats resources on the scanner.
Configure Country: Check
Country: USA
Notes: By leaving it unchecked, it will perform an auto setup. This can be a problem if you have scanners around the world.
RF Band: Unchanged
This is something you will need to communicate with your network team. Some places use 2.4, some use 5. You can tell it which channels to work with as well. This is a very advanced system for the most part.
Leave all the other settings the way they are.
The network action is do nothing because you are already connected to your staging network from the previous set.
FileMGR
The file manager area is import for us our Enrolling Zebra Scanners into Intune as it allows us to get the intune onto the device itself. After we click continue on the wifi, we will come into the new settings.
File Actions: Transfer/Copy File
Target Access Method: File in the device file system
Target Path and File Name: /sdcard/AndroidDevicePolicy.apk
Source Access Method: File on a remote server
Source File URL:
Click the three dots
Search for the file and add it.
Continue
AppMGR
Now the app is on the scanner from the stage now profile, it's time to install the app. We are going to select upgrade as upgrade is install and upgrade at the same time.
Action: Upgrade
APK Path and Name: /sdcard/AndroidDSevicePolicy.apk
Protected list action: Do nothing
Here you can add this app to the protected list, thus making it unchangeable. This could cause Intune to fail. You can also remove it from said list.
Access to app information action: Do nothing
Click Continue
Intent
This final stage joins it to intune. We will be creating a json file before we continue. Remember that code we got from the qr code. This is where we are going to be using it. This json is our butter for Enrolling Zebra Scanners into Intune. Here is the json.
{
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":"com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver",
"android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "<Oh a has code from ealier.> ",
"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":"https://play.google.com/managed/downloadManagingApp?identifier=setup",
"android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED": true,
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{"com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN":"<YourTokenYall>"}
}
Remember we grabbed the check sum and the token from before? Well, this is where we are going to use it. Replace where I have the <> and you should be good to go with the file. Make sure to save this in the same folder on the stagenow computer as the app from before and save the file as a.json file.
Class Name: com.google.android.apps.work.clouddpc.receivers.CloudDeviceAdminReceiver
Json Value: Json File
Json File:
Click the three dots and navigate to your newly created json file.
Click continue
Final steps of stage now
Once you click the stage now button, you will be set to the review screen. Here you can make sure all of your settings are correct by clicking the expand button. By default, the bar codes are encrypted. If you don't want that, this is where you can change it. I always suggest encryption. Once you have everything the way you want, all you have to do is click complete profile.
Now here is the next important aspect of the whole setup. Creating the barcodes to scan. After you click the Complete Profile, you will be taken to the bar code window. There will be options for linear and PDF417 barcodes. The linear is going to give you a lot of bar codes. So pick the PDF417.
CATCH! Android 11 and down use PDF417, for Android 13 and above, use JS PDF417.
So we want to click the StageNow client check for what we want to use. Then I like to test. You can click the test to generate the barcodes. Finally, you can click publish to publish the profile.
Using the barcodes
Once you have the bar codes, Enrolling Zebra Scanners into Intune is so much easier. From a recently wiped scanner, open stage now and scan the bar codes. The scanner will connect to your wifi of choice. Then, if the stage is now up and running, it will download the file. Then it will install the app. Finally, if the network is running correctly, it will join intune. From there, intune takes over and stage now is no longer needed.
Import gotchas at this stage is stagenow has to be active with this setup. The reason is because each time the application is active, it spins up an FTP. The FTP username and password are embedded into the QR code from where you encrypted it. So, if your network can't reach this server, this means it will not work as well. So make sure the network team is good to go.
What can we learn as a person?
Things don’t always go as planned, no matter how much we prepare. I spent six months perfecting an MDM transition while managing my regular duties. My Intune setup was nearly flawless: scanners were configured in under 30 minutes, upgraded to the optimal OS for our company (not Android 13), and everything seemed ready. I created detailed instructions and videos for end users, tested the process with multiple people, and received praise for how well it worked.
The rollout began smoothly at our northern office, where everything connected as expected. Then things unraveled. At other locations, wireless networks failed due to improperly configured DHCP, incomplete AP broadcasting, poisoned ARP tables on switches, and more. It felt like every fix led to another failure. Users blamed me since I handled the transition, but the root issue was network-related—something I had no access to or control over.
Despite my setup being perfect, it failed because of factors outside my control. And that’s okay. Failure doesn’t define us, even when others assign blame. IT is a team effort, and sometimes you must navigate challenges with colleagues who may not be as invested or responsive.
In this case, waiting for the network admin to confirm readiness and documenting everything (CYA!) saved me. It’s a reminder that our worth isn’t tied to mistakes—ours or others'. Sometimes, patience and accountability are the real wins.
Last month, I had an app that had some issues for a single end user. I wasn't sure why it was causing issues, but one of the troubleshooting steps we needed to do was uninstall it and have Intune reinstall it. We uninstalled the application. However, Intune, being Intune, sat there. We forced a sync, and nothing. I wish there was a redeploy option in the Intune interface, but there isn't. So what can you do? Well, there is a small secret. Intune has registry keys that keep track of the deployments on the machine itself. These linger even after uninstalling the app. So, removing them is the gravey. So today we are going to force Intune apps to redeploy.
Intune Registry Keys / App ID Number
Intune's registry keys are located in the Local Machine > Software > Microsoft > IntuneManagementExtension > Win32App. Let me tell you what now. My southern is going to come out some yall. This is where we can see the users. The system has it's own user, which is the all zeros, but each other user has it's own code.
When you open this folder, you will be taken to a beautiful list of what? Yeah, it's a mess. You need to know some things about this list in order to force intune apps to redeploy. You will need to have the app's ID number. To get this number, you will need to navigate to your Intune. We will be heading to the app you want to uninstall. I'm doing my 7zip today as an example. At the end of the url, you will see the appID. That's what you will need.
Once you have that code, you will be ready. What you will need to do now is delete the folder with that code. Then navigate to the GRS folder. It will have a bunch of hashes. No, not the drug, but math code. Wait, is hash still what people call it now days? I feel old. Anyway, you have two options here. One, you can go to the logs and search the logs for the hash. This can take a while, and shockingly, it is not reliable as logs get deleted. The other way is to go through this registry folder, folder by folder, until you find the key, as seen below. I prefer PowerShell. Once you delete the required registry keys, all you have to do is restart the Microsoft Intune Management Extension service.
Powershell To the Rescue
If you have read this blog long enough, you know PowerShell is coming somehow. Today's script will save you a crap ton of time. Let's dive right in.
There are many versions online for this script. Most use the logs, and that's cool. This script doesn't use the logs, and for a good cause. In my case, the logs were deleted. Why were they deleted, you shall ask? Humans, that's always going to be my answer until it's AI.
The break down
Let's break this bad boy down, shall we? The first part of the script is the path we are going to be playing with, followed by the code of the app. You will have to grab this from your intune.
Next, we want to grab all the users. So, remember I said the system uses all zeros. Well, we want to exclude those. However, users use the hypens. It's the Fantastic 4, hypens, not the Marvel characters. Using a basic where object, we sort through all of the ones that have our hypens and are not the system and drop their ID numbers into the users variable.
Now we start our loop. Everyone should like a good loop. Each user will have it's own path. The first thing we run into is that the above command gave us HKEY_Local_Machine instead of a searchable HKLM. So we change them using the replace. Then we grab the userID for later. Finally, we grab all the applications. Notice the name is the new name we made. It's important to have the HKLM: because without it, you will get an error with get-childitem. No candy was stolen from any children while writing this blog post.
Notice we are looking for the appid at the end. Sometimes, there will be more than one entry like this. To force Intune apps to redeploy, we must remove all of them. I liken them to bed bugs. Burn them all. With that said, we start our loop. For each App inside the applications. We will get the app name and then remove it. Once again, we used get-childitem. Goodness, I need to stop still items from kids. So we need to convert the name like we did before changing the HKEY_Local_machine to HKLM: with a nice replace. Once we have it, we delete the path and everything inside by force.
Now we need to handle the GRS side. The GRS keeps the datetime stamps. Like I said before, most people use the logs. Today we will navigate through the registry. The first thing we are going to do is set the path and get the kids on that path. This is where the UserID we made at the start of this big loop comes into play.
Now we have the children's items. We start our looping. The first thing we get is our GRS properties with the get-itemproperty commands. Now here is the magic. A standard check has only 1 or maybe 2 items inside the folder. While more advanced items will have more than that. So, if we convert the properties into a Powershell object, we can count them.
Yes, the second line works. You can pretty much convert anything into a PowerShell object. All we have to do now is count how many counts per object are there. When we convert the item property into a powershell object, we gain a few extra items. So, anything past 5 in this case will be our special stuff. So, if it is past 5, we get to work.
We first look at the keys, looking for our fantastic 4. We will do this by calling the psobject.properties.name because it will be the name of the property. Then we will compare it to the appid. If they are the same, we correct the hkey_local_machine and drop our nuke, remove-item. Nested ifs are fun, but can get complex quick if you don't watch out.
After the large loop of Fantastic Four, we have to restart the intune extension. So, using get service, we pipe it into restart service. Then we are done! Right? Well, kind of.
After the script has done it's thing and stolen candy for kids and nuked stuff, you will need to resync the computer. You can do this via the Accounts setting, or you can do this via Intune. In my case, the application we were redeploying was our remote application. So, I had to do it via Intune.
Navigate to the device under Windows > Device Name and hit the sync button. Now you are done. Force Intune apps to redeploy, check.
What can we learn as a person?
Restarting is sometimes the only option. Taking a step back, clearing things away, and starting new is good, whether you're troubleshooting an Intune app deployment or dealing with a hard time in life.
When an app in Intune stops working, we don't just sit around and hope it gets fixed (at least for a while). After we empty the registry and do some troubleshooting, we gently push it to redeploy. Life is no different. When things don't work out the way you expected, that's okay; setbacks are inevitable. Starting over equalizes the situation; it's not a sign of surrender.
Restarts, in reality, are chances for growth. By doing so, they demonstrate our flexibility, competence, determination and insight to put things right. Our fantasic four. When something feels stuck, whether it's an app or your thinking, don't be scared to reset. Do not be afraid, especially with our thinking. That's where real change happens.
Hi there! Have you ever scratched your head and wondered if you loaded software the right way? You're not by yourself. This gives a lot of system administrators a headache. This is especially hard to do when handling programs like AutoCAD 2022 in a variety of settings. That is where Microsoft Intune really shines. The fact that you can use your own recognition scripts makes it very useful. A custom Intune detection script is key.
These scripts save my life a lot. They help you check every network gadget. This makes sure that not only is there an app, but it's also the right version for you. Today, we're going to look in detail at a PowerShell script that can find AutoCAD 2022. This guide will help make your business life a little easier, no matter how much you know about Intune or how new you are to it. Allow us to begin on our Intune detection script!
How do I make a Intune Detection Script?
First, what does a custom Intune recognition script really mean? It's just a script for your control tool for Microsoft Intune. It checks automatically to make sure that all of your devices have the same version of software loaded. What makes this cool? Because it takes care of one of the most boring jobs in IT management automatically. Imagine making sure that software is compliant and installations are correct without having to check each machine by hand. Not interested!
PowerShell is used to make custom scripts like the one we're talking about today. It is a strong programming language that can do a lot with just a few lines of code. These scripts can get into the Windows Registry, find loaded programs, and check out different versions of installed programs. It's not just about saving time; it's also about making sure that your software deployments work well and stay stable. We all hate those crazy support calls, but this cuts down on them.
The Breakdown
Getting into the nitty-gritty of our PowerShell script, let’s break it down line by line. This will help you understand exactly what each part does. Let's get our geek on!
Lets go line by line in our Intune Detection script and break it down.
Line 1-2: Define the Product
These two lines allow you to define the product you want to search for and the Version you wish to check for. The product name can take wild cards, but I don't suggest it as it can cause more conflicts than be helpful.
The next line is where we look in the registry for the uninstall strings and product information. These registry keys is what win32_product looks at to get information. Thus, it's much faster than using the win32_product.
Here, we're grabbing a list of all items in the paths defined earlier. It's akin to gathering all the potential treasure chests. We will use these magical coins later to get what we need.
$apps = Get-ChildItem -Path $RegPath
Lines 5 - 7: filter and test for the product
In these lines, we loop through each app and check if it matches our product name. If it does, we take a closer look at its properties. Here we are checking for our gold coins vs the silver coins. We take each of the products we want, and put it into our test varaible, or chest.
Assuming you have chosen a name that will only show up once, we now check to see if the version matches up. If it does, then we say, yep, it's installed and exit with a code of ZERO, the big 0. If it doesn't, then we exit with the error code of 1. This is important as Intune is looking for a string and an error code of 0 for success.
Intune's custom detection script deployment requires more than copying and pasting code. Ensure the script operates smoothly on all targeted devices. Step-by-step instructions:
The first step in script preparation is to test it locally. You shouldn't distribute something without testing on your own machines.
Put the script in Intune:
Enter the Microsoft Endpoint Manager admin center.
Select Windows 10 under Devices > Scripts > Add.
PowerShell script upload and settings. This involves choosing a system or user context for the script based on access level.
Assign script:
After uploading your script, assign it to device groups. You can choose groups by organizational units or other deployment parameters.
Monitor script deployment:
Monitor script execution on the script profile's Device Status and User Status tabs after deployment. This shows if the script is executing properly or if any devices are failing.
Update as needed:
Monitoring feedback may need script or deployment parameters changes. Maintaining compatibility with new system updates or IT environment changes may need regular updates.
Effective script deployment guarantees that all network devices meet software standards. Assuring all machine parts are well-oiled and working together.
Common Issues and Troubleshooting Tips for a Intune Detection Script
Even with the best preparation, things might not always go as planned. Here are some common issues you might face with custom Intune scripts and how to troubleshoot them:
Script Fails to Execute:
Check Execution Policy: Ensure that the script's execution policy allows it to run. This policy can sometimes block scripts if not set to an appropriate level.
Review Script Permissions: Make sure the script has the necessary permissions to access the registry paths or any other resources it uses.
Incorrect Script Output:
Verify Script Logic: Double-check your script’s logic. Look for typos in variable names or incorrect operators in conditions.
Test Locally: Always run the script locally on a test machine before deploying it to avoid simple errors.
Issues with Script Deployment:
Assignment Errors: Make sure the script is assigned to the correct device groups. Incorrect assignments can lead to the script not being run where it’s needed.
Check Intune Logs: Use the logs provided by Intune to identify what’s going wrong when the script runs.
Troubleshooting is an integral part of managing scripts in a large environment. It’s a little like detective work, where you need to keep a keen eye on clues and sometimes think outside the box.
What can we learn as a person today?
Even though we don't always mean it that way, we frequently execute "scripts" in our day-to-day lives, much like a PowerShell script checks for certain conditions before proclaiming success or failure. These are the things we do on a regular basis without thinking, like automated checks on a computer system; they help us evaluate and respond to the many opportunities and threats that life presents.
When we look for patterns in our own lives, we can see what's working and what isn't. By exercising first thing in the morning, for instance, you may find that you get more done that day. This would be an example of a positive pattern, like a script that verifies everything is going according to plan. In contrast, if you find yourself feeling low after a session of social networking, it's a sign that something needs to be changed, similar to a script fault.
It is essential to listen to environmental feedback in order to make modifications. Our emotional and physiological responses, the opinions of others around us, and the outcomes we attain can all serve as sources of this type of feedback. Like adjusting a screenplay that isn't working as planned, when our life's routines bring about less ideal consequences, it's a warning to halt and re-calibrate. Perhaps it necessitates reevaluating our current habits and deciding how much time is best spent on specific pursuits.
The idea is to embrace learning and refining as a process, just like scripts that are updated over time. There is no instruction manual for life, and sometimes the only way to learn is by making mistakes. Being self-aware and willing to make adjustments for the better is more important than striving for perfection.
Over the years of Intune deployments, I have searched for a way to let my end users know that an application is being installed or uninstalled from their computer. I have used things ranging from notification bubbles to blanking a screen. All of these methodologies are poor at best. I found a few paid items that companies just didn't want to pay for due to the insanity of the pricing. For example, one company wanted us to pay 150 USD per deployment. Times that by 1500 devices, that adds up quickly. It wasn't until I found the PowerShell App Deployment Toolkit that I found what I was finally looking for.
What is the PowerShell App Deployment Toolkit?
This toolkit is an immensely powerful and amazingly simple setup. You can download the tool kit here. It provides a framework to install and uninstall applications using PowerShell through a signed application. This allows us to deploy complex and confusing deployments as a single package. A good example would be AutoCAD. Recently, I was tasked with standardizing AutoCAD in a single department. Some members used AutoCAD 2016, some used 2024. This was a problem as the 2024 files did not work with the 2016 AutoCAD. Thus, I needed to uninstall the previous versions of AutoCAD before I installed the current version. As all files are backed up, I didn't have to worry about them losing any files. The toolkit was perfect for this.
Key items I like of the toolkit
Simple packaging
Many application toolkits come with complex packaging. It's normally an application that wraps itself around another application that keeps doing this until it's all transparent. With the PowerShell App Deployment Toolkit, all you need to interact with is the deploy-application.ps1 file. That's assuming you are doing more than an a MSI file. If you are only using an MSI file, all you need to do is drop the file in.
As you can see in the screen shot, this is the package. When you download the zip file, you will be greeted with this amazing structure. The Deploy-Application.ps1 is where our code will go. The Files folder is where the installer files would go. Following our auto cad example, the installer and updates would all be placed inside the Files folder.
Deploy-Application.ps1
This file has an amazing setup. It first has a wall of documentation inside the file itself. The file explains each step along the way. It is broken up into installation, uninstallation, and repair. Each section has a Pre, during and post process in each section. This is great if you need to kill some services, send a message or more. It's also helpful because it gives you a structure to work within.
The Commands
Inside this packaging there are many useful commands. As I stated in the intro, it's full of ways to communicate what you are doing with the end user. During an application install, you can show which applications needs to be turned off for the install to work by using the show-installationwelcome command.
This example shows us it wants to close the applications and gives the user a 60 second window to do so. This isn't the only thing this command can do.
Other commands like execute-process, will launch processes that you need from the file directory and more. All while logging what's going on. You can find a full help system for all the unique commands inside the tool kit. Navigate to the tool kit > AppDeployToolkit > AppDeployToolkithelp.ps1 will bring up a gui that allows you to read all about the commands.
Using the Toolkit with Intune
If you want the tool kit to work with the end user profile, then you will need to grab a unique little tool from MDT. We will need the ServiceUI.exe from the MDT software. You can download MDT here. Once you have the MDT installed. we need to pull the ServiceUI.exe out of the MDT install. Navigate to, C:\Program Files\Microsoft Deployment Toolkit\Templates\Distribution\Tools\x64 and copy the ServiceUI.exe file. Place this file in the home of your PowerShell App Deployment Toolkit file structure.
As you can see, the ServiceUI.exe is in the root folder. Now we need to create the package. We can create a win32 app package. I covered this here. This is the same concept.
The folder would be the folder with your toolkit
The setup file would be the Deploy-Application.exe
The output file would be wherever you want the Intune app to be dumped.
and we don't need to catalog the folder.
Once you have your application built, it's time to see how it works inside Intune. We start by building your application package. As stated in the previous blog, we start the application by uploading. The big difference here is our install and uninstall commands.
Understanding the commands
Our install command will be the using the ServiceUI.exe and the deploy-application.exe
By default, the Deploy-application.exe will be interactive. There are two flags for the Deploy-Application and here are what they are.
DeploymentType: (Super Straight forward)
Install: Installs the application
Uninstall: Uninstalls the application
Repair: repairs the application.
DeployMode:
Interactive: Shows all of the prompts needed.
NonInteractive: Only shows the required prompts.
Silent: Shows no prompts.
We can translate the command above by using these flags. By default the Deploy-application.exe is install and interactive. So, we know that the application would be prompted and the end user will see the command. The uninstall command will uninstall and it will be interactive. The ServiceUI.exe allows you to run applications as the user in and the system at the same time. The biggest issue with the ServiceUI.exe is the application will not install until someone logs in. No flags are needed here.
Over all, PSappdeploytoolkit changes the ball game with deployments. I encourage anyone and everyone to dig deeper into it.
What can we learn as a person today?
I live in the south of United states. From time to time I will hear people battling over belief systems. In my life time I have come to an understanding of how these systems work. I liken "objective truth" as fish in a sea. Our belief systems is the net we use to capture those fish. Some nets are better than others. The water of the sea is useless, distracting, or misinformation. It only makes it harder to bring those pieces of the objective truth into ourselves. A good net can capture a lot of fish, and let the water out at the same time. A bad net, like a tarp, captures some but becomes unmanageable due to the water. This is the same way with our beliefs. We are only strong enough to lift so much at different points in our lives.
Premade Nets
I see organized religions as premade nets. Think of it like a tool kit. It's a format that is easy to use and allows you to do stuff with it. Does the toolkit work for everyone, no. Just like this PowerShell toolkit, it would be useless in a world without powershell. So chromeOS, this toolkit isn't useful. This is the same with some beliefs. They are useful where they are, but not useful in other places. Sometimes these toolkits/nets, are useful for some but not others. If you don't know PowerShell, this toolkit wouldn't be useful to you. If you are shame sensitive, some religions are not for you.
Everyone has their own tool set or net. No single tool set is inherently bad. It's how we use them and where we use them. If you take a net to a small pond, get ready to waste your time and damage your net. If you throw your net aggressively into a aggressive sea, get ready to lose that net.
Homemade Nets
Once someone understands how the nets are made and how to repair them, It's always best for them to start building their own nets using the techniques they have used on their previous nets. By having a net/toolset of your own, this allows you to have full knowledge and be able to repair quickly. This belief system would be uniquely yours and different from others. So, when it breaks, you can grow it, replace parts, and more without having any problems. It's yours and no one elses.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
