Automate Windows 11 Upgrade

Automate Windows 11 Upgrade

Upgrading Windows 11 across multiple machines is one of those tasks that sounds simple—until you realize you need to manually download the ISO, mount it, and run the upgrade for every single computer. If you’re managing a fleet of devices, that’s a lot of clicking and waiting. Thankfully, PowerShell can help automate this process, saving IT admins from hours of repetitive work. So today, we will Automate Windows 11 Upgrade with PowerShell.

But before we jump in, there’s one crucial step: Microsoft requires you to manually generate the download link for the Windows 11 ISO. That’s right—no direct API calls or magic URLs here. You’ll need to visit the Microsoft website and grab the link yourself. Don’t worry, we’ll walk you through that part.

And hey, if you’re wondering why Microsoft makes you do this manually… well, let’s just say it’s like trying to convince a cat to use the expensive bed you bought instead of the random cardboard box it found in the corner. Some things just don’t make sense, but we roll with it anyway.

Alright, let’s dive in! First up: generating that all-important download link.

The Script

Write-Host "Go to: https://www.microsoft.com/en-us/software-download/windows11"
Write-Host "Select Windows 11 (multi-edition ISO for x64 devices)"
Write-Host "Click Download"
Write-Host "Select English (United States)"
Write-Host "Click Confirm"
Write-Host "Right Click '64-bit Download' and click 'Copy link'"

$DownloadURL = Read-Host "Enter the Windows 11 ISO download link (in quotes)"
$ComputerName = Read-Host "Enter the target Computer Name"

# Check if the computer is online
if ($null -ne (Test-Connection -ComputerName $ComputerName -Count 1 -Quiet)) {  
    
    # Start a remote PowerShell session
    Enter-PSSession -ComputerName $ComputerName  
    
    # Ensure C:\temp exists
    if (!(Test-Path C:\temp)) {New-Item -Path C:\ -Name temp -ItemType Directory -Force}  

    # Set download path
    $DownloadPath = "C:\temp\win11.iso"

    # Download Windows 11 ISO
    Invoke-WebRequest -Uri $DownloadURL -OutFile $DownloadPath  

    # Mount the ISO
    $DiskImage = Mount-DiskImage -ImagePath $DownloadPath -StorageType ISO -NoDriveLetter -PassThru  
    $ISOPath = (Get-Volume -DiskImage $DiskImage).UniqueId

    # Create a PSDrive for the mounted ISO
    New-PSDrive -Name ISOFile -PSProvider FileSystem -Root $ISOPath  
    Push-Location ISOFile:

    # Find and run Setup.exe with upgrade parameters
    $SetupExe = (Get-ChildItem | Where-Object {$_.Name -like "*Setup.exe*"}).FullName  
    $Arguments = "/auto upgrade /DynamicUpdate Disable /quiet /eula accept /noreboot"  
    Start-Process -Wait -FilePath $SetupExe -ArgumentList "$Arguments" -PassThru  

    # Clean up: Unmount ISO and remove PSDrive  
    Pop-Location  
    Remove-PSDrive ISOFile  
    Dismount-DiskImage -DevicePath $DiskImage.DevicePath  

    # Ask for a restart decision  
    $YN = Read-Host "Do you want to restart? (Y/N)"  
    if ($YN -like "*Y*") {Restart-Computer -Force}  
    elseif ($YN -like "*N*") {Write-Host "Ask the user to restart."}  
    else {Write-Host "Ok, whatever, ask the user to restart."}  

} else {  
    Write-Host "The target computer is not reachable. Check the network or hostname and try again."  
}

Step 1: Generate the Windows 11 ISO Download Link

Before we can automate the upgrade, we need the direct download link for the Windows 11 ISO. Microsoft doesn’t make this easy—there’s no simple API to fetch it. Instead, you have to manually grab the link from their website.

This step is non-negotiable because Microsoft generates a unique download link each time, which expires after 24 hours. So if you’re thinking, “Can’t I just reuse an old link?”—nope, Microsoft shut that door. But don’t worry, it’s a quick process:

How to Get the Windows 11 Download Link

  1. Go to the official Microsoft download page:
  2. Scroll down to ‘Download Windows 11 Disk Image (ISO)’
    • Select Windows 11 (multi-edition ISO for x64 devices) from the dropdown.
  3. Click ‘Download’ and select English (United States) as the language.
  4. Click ‘Confirm’—Microsoft will generate a download button.
  5. Right-click ‘64-bit Download’ and select ‘Copy link’ (This is the direct ISO link).

You’ll need this URL when running the PowerShell script, so paste it somewhere handy.

Now that we have the link, let’s move on to running the script!

Step 2: Running the PowerShell Script

Alright, you’ve got your Windows 11 ISO download link. Now it’s time to run the PowerShell script and start the upgrade. But before we do that, let’s talk about remote execution. This is part of the process to Automate Windows 11 Upgrade with PowerShell.

PowerShell remoting (aka WinRM) needs to be enabled on the target machine. If you’ve never set it up before, it’s kind of like getting a cat to sit still for a vet visit—it might resist at first, but once it’s done, life is easier.

Prerequisites for Running the Script

Make sure the following are true before running the script:

  • Your user account has admin privileges on both the local and remote machine.
  • WinRM (Windows Remote Management) is enabled on the target machine. Run this command on the remote PC to check:
winrm quickconfig

If WinRM isn’t enabled, you’ll need to set it up first.

  • PowerShell Execution Policy allows scripts to run. If needed, you can temporarily bypass restrictions with:
Set-ExecutionPolicy Bypass -Scope Process -Force

Running the Script

Once the prerequisites are in place, open PowerShell as Administrator on your local machine and run the script. When prompted:

  1. Paste the Windows 11 ISO download link (from Step 1).
  2. Enter the target computer’s name (the one you want to upgrade).

If all goes well, PowerShell will initiate a remote session, create a C:\temp folder, and start downloading the ISO to the remote machine.

Just like how a cat will eventually use the new bed if you keep putting treats in it, the script will do its job—as long as everything is set up correctly.

Next up: Downloading and Mounting the ISO!

Step 3: Downloading and Mounting the ISO

At this point, the PowerShell script is running, and the target computer is ready. Now comes the fun part—actually downloading and mounting the Windows 11 ISO.

If you’ve ever tried downloading a large file over a shaky network, you know it can be as frustrating as a cat deciding to sprint across the house at 3 AM for no reason. But don’t worry, the script handles it all automatically.

How the Script Handles the Download

Once you enter the download link and the computer name, the script:

  1. Creates a C:\temp folder (if it doesn’t already exist).
  2. Uses Invoke-WebRequest to download the ISO to C:\temp\win11.iso.

Here’s the key part of the script doing the work:

if (!(Test-Path C:\temp)) {New-Item -Path c:\ -Name temp -ItemType Directory -Force}  
$DownloadPath = "C:\temp\win11.iso"  
Invoke-WebRequest -Uri $DownloadURL -OutFile $DownloadPath

Mounting the ISO

Once the ISO is downloaded, PowerShell mounts it like a virtual disk, allowing access to the installation files.

$DiskImage = Mount-DiskImage -ImagePath $DownloadPath -StorageType ISO -NoDriveLetter -PassThru  
New-PSDrive -Name ISOFile -PSProvider FileSystem -Root (Get-Volume -DiskImage $DiskImage).UniqueId  
Push-Location ISOFile:

At this point, the Windows 11 setup files are accessible.

If you check File Explorer on the target computer, you should see a new virtual drive containing the ISO contents—like when a cat suddenly appears on your keyboard, except this time, it’s actually doing something useful.

Now that we have the ISO mounted, it’s time for the real action: starting the upgrade!

Step 4: Starting the Upgrade Process

Alright, the ISO is mounted, and we’re at the final stretch—actually running the Windows 11 upgrade. If everything has gone smoothly so far, congratulations! You’re officially ahead of the game.

Now, instead of manually clicking through the Windows setup (which is about as exciting as watching a cat stare at a wall for hours), PowerShell will automate the upgrade process using Setup.exe and a few command-line arguments.

Finding and Running Setup.exe

Since we mounted the ISO in the previous step, we now need to:

  1. Find Setup.exe inside the mounted ISO
  2. Run it with automation flags to start the upgrade silently

The script takes care of that with:

$FileList = Get-ChildItem  
$SetupExe = ($FileList | Where-Object {$_.name -like "*Setup.exe*"}).FullName  
$Arguments = "/auto upgrade /DynamicUpdate Disable /quiet /eula accept /noreboot"  
Start-Process -Wait -FilePath $SetupExe -ArgumentList "$Arguments" -PassThru 

Breaking Down the Command-Line Arguments

Here’s what each flag does when running Setup.exe:

  • /auto upgrade → Tells Windows to start an upgrade instead of a fresh install.
  • /DynamicUpdate Disable → Skips downloading the latest updates during the install (useful for speeding things up).
  • /quiet → Runs the installer in the background, so no annoying pop-ups.
  • /eula accept → Automatically accepts Microsoft’s End User License Agreement (because let’s be real, no one reads it).
  • /noreboot → Prevents an automatic restart so we can control when it happens.

What Happens Next?

Once this runs, the Windows 11 upgrade process kicks off in the background. There won’t be any flashy UI—just PowerShell doing its thing. You can check progress by looking at Task Manager on the target machine.

At this point, it’s like when a cat finally decides to nap on that expensive bed instead of the cardboard box—you’ve done all the hard work, and now it just has to finish on its own.

But there’s one last decision to make: When do we restart?

How are we feeling about Automate Windows 11 Upgrade with PowerShell so far?

Step 5: Restarting the Machine

At this point, the Windows 11 upgrade is in motion, but the installation won’t complete until the target machine restarts. Now, we could just force a reboot, but let’s be real—no one likes unexpected restarts (especially end users in the middle of something important).

So, instead of pulling the plug immediately, the script politely asks whether to restart now or later. Here’s how that works:

$YN = Read-Host "Do you want to restart"  

if ($YN -like "*Y*") {  
    Restart-Computer -Force  
} elseif ($YN -like "*N*") {  
    Write-Host "Ask the user to restart"  
} else {  
    Write-Host "Ok, whatever, ask the user to restart."  
}  

Breaking It Down

  • If the admin enters Y → The system restarts immediately.
  • If the admin enters N → A message reminds them to tell the user to restart manually.
  • If they enter anything else → The script shrugs and tells them to figure it out.

This gives IT teams a bit of flexibility, which is crucial in environments where timing matters—like avoiding a forced reboot during an important meeting (unless it’s for that one guy who never restarts his PC… then maybe it’s justified).

What Happens After Restart?

Once the machine reboots, Windows 11 will finish the upgrade process. The whole thing usually takes 30-90 minutes depending on the hardware. During this time, users will see the “Working on updates” screen—so if they call asking why their PC is taking forever, just tell them “It’s optimizing performance” (it sounds fancier than “it’s just installing”).

Final Thoughts

And that’s it! With this script, you can automate Windows 11 upgrades remotely with minimal effort. No more manual downloads, no more sitting through setup screens—just a smooth, scripted process. To Automate Windows 11 Upgrade with PowerShell makes life much easier.

Recap of the key steps:

  • Generate the ISO link manually from Microsoft’s website (because they make us).
  • Run the PowerShell script and provide the ISO link + target computer name.
  • Download and mount the ISO automatically.
  • Start the Windows 11 upgrade silently using Setup.exe.
  • Decide when to restart—now or later.

Now, go forth and upgrade with confidence! And if anything goes wrong, well… let’s just say this script is less stubborn than a cat, so it’s probably not the script’s fault.

What can we learn as a person?

Upgrading an operating system is a big change, but it’s the small steps that make it happen. You don’t just magically jump to Windows 11—first, you grab the ISO, then you run the script, then you mount the image, and finally, the upgrade takes place. One step at a time.

Turns out, our mental health works the same way.

A lot of us get caught up in the idea that improving our mood or reducing stress requires some huge effort—taking a long vacation, completely overhauling our routines, or mastering meditation overnight. But that’s just not how it works. Big upgrades don’t happen all at once.

Instead, try small upgrades for yourself, just like how we upgrade Windows in steps:

  • Clear out junk files → Declutter one small space
    • Just like a clean drive helps performance, tidying up one small area can help clear your mind.
  • Run a quick system check → Check in with yourself
    • Pause for a moment and ask: How am I feeling today? Just acknowledging your emotions can help.
  • Disable unnecessary background processes → Say “no” to one unnecessary thing
    • Reduce mental load by cutting out one thing that’s draining you—whether it’s skipping an unimportant meeting or ignoring a toxic group chat.
  • Reboot when needed → Take a short break
    • A quick restart helps a computer, and sometimes, five minutes away from your screen can work wonders for you too.

No Need for a Full Reinstall

You don’t need a full personality reboot or a total life upgrade to feel better. Small tweaks, small wins—they add up.

So while you’re waiting for that Windows 11 install to finish, maybe take just one small action for yourself. It doesn’t have to be big. Just enough to upgrade your mood one step at a time.

Zebra Kiosk Mode

Zebra Kiosk Mode

Last time we talked about how to get our Zebra scanners into Intune. Today we are going to talk about how to set this unit as a kiosk scanner with a web link and a store app. This setup will be in such a way that we control the wireless networks and access to the device all from one configuration policy. The configuration policy is where we will be making our Zebra Kiosk Mode.

Creating a web app

A web app is super easy to build out. Remember, the scanner should be able to access said app.

  1. Navigate to intune.microsoft.com
  2. On the left-hand side, click Apps
  3. Click Android
  4. Click the Add button.
  5. Under Select app type, we will click Web link, which is under Other.
  6. Then Click Select
  7. This is where you can edit properties.
    • Name: The web link name
    • Description: I like to put the address of the web link here and what it’s for. Some people don’t. It’s up to you.
    • Publisher: I put my company’s name, unless I know for sure who it is.
    • App URL: This is where you will put your link. For example. https://therandomadmin.com
    • Require a managed browser to open this link:
      • This is special as it will require you to have edge or another managed browser like zebra’s managed browser. In our case, this isn’t a needed feature and can cause more issues down the road.
      • Doing a managed browser would force the user into a single tab. This is great for some apps, but others not so much. So, if you want a lockdown on the tabs, this is the way to go, and you will have to make sure you set the system defaults to that browser instead of Chrome.
    • Category: That’s for you to choose
    • Show this as a featured app in the company portal: Once again, not really needed since these will be kiosk machines.
    • Information URL: If the site has an information URL, this is where it would go.
    • Privacy URL: Most websites have a privacy link; this is where you would put that.
    • Developer: Who built it? Maybe a link if you feel like it.
    • Owner: Who is the owner, once again, Maybe a link?
    • Notes: I don’t use this personally, but I have seen where people will put who all should have it.
    • Logo: A good logo for the site; now I have seen a 512×512 PNG file work best for this.
  8. Click Next
  9. Assign your groups
  10. Review and create.

That’s all it takes to make a web link. It’s nothing special.

Other Apps

Create Device Restriction Configuration

This is where we will be doing our Zebra Kiosk Mode. Based on our Microsoft Managed Home Screen, we will create a device restriction, and this app will give us unique controls over the device.

  1. Navigate to Intune.microsoft.com
  2. Navigate to Devices > Android > Configuration
  3. Create a new policy
    • Platform: Android Enterprise
    • Profile Type: Device Restrictions
    • Click Next
  4. Name the policy and give it a good description. Then hit next
  5. These are the settings I am using:
    • General
      • Default Permissions Policy (Work Profile Level) Auto Grant
      • System Update: Automatic
      • Skip first Use Hint: Enabled
      • Locate Device: Allow
      • System Error Warning: Allow
      • Enabled System Navigation Features: Home and overview buttons
      • System Notifications and Information: Show system notifications and information in device status bar

Device Experience

  1. Device Experience Type: Kiosk Mode
  2. Kiosk Mode: Multi App
  3. Custom app layout: Enabled
    • This is where we will place items on the screen. I like having the main web link and the intune app. It looks real nice with a 3×4
  4. Grid Size: 3 Columns x 4 rows
  5. Home Screen.
    • Here you can click each plus button and add the app you want, and it will show up on the machine.
  6. Lock Home Screen: Enabled
  7. App Notification Badges: Enabled
    • I enable these because it lets the end user know what’s happening with the device itself. This is important for updates and the like.
  8. Leave Kiosk Mode: Enabled
  9. Leave Kiosk Mode Code: Make a 4-6 digit pin.
  10. Set a custom URL background:
    • This background for the MC9300 is 480×800.
    • The image must be accessible from the network on its own. If it is not, then we will have issues.
  11. Shortcut to settings menu: Disabled
  12. Quick access to the debug menu: Enable
  13. Wi-fi Allow List
    • This is where you can put the SSID of the networks you want the scanner to connect to. If it’s not in this list, they will not be able to connect to it while in kiosk mode.
  14. Media Volume Controls: Enabled
    • I do this to allow them to control how loud the beeps are. Note that your DataWedge profile needs to be set to media to make this happen.
  15. Quick Access to device information: enabled
    • This bad boy has saved me so many times. It has the device’s serial number. The MC9300 serial numbers are printed on the back, but old eyes just can’t read it. So, having this information at the user’s fingertips really adds to troubleshooting.
  16. Everything else in device restrictions is default.

Users and Accounts

This area is set to block. What that does is it forces the users to only be the kiosk user.

  • Add users: Block
  • User can configure credentials: block
  • User removal: block
  • personal google account: block
  • Account changes: block.

We don’t want you to edit anything with this profile. Hand slap, please.

Customer Support Information

This is where you would place all the customer support information. Like your helpdesk number or emails. I like to have the contact for your IT admins at XYZ. The lock screen message is important because even though we didn’t set it here, if you tell the system to lock via Intune, this message will appear.

Groups and why it’s important

The next area is the groups. So, this is very important. You cannot have two device restriction policies that do kiosk items applied to the same machine! This is very important and can look very weird. So I’m going to give you a simple scenario for you to fully understand.

  • There are three policies.
    • Zebra_Default
      • Assigned Group: Zebra-MC9300-Default
        • Dynamic assignment of android zebra mc9300
    • Zebra_Redzone
      • Assigned Group: Zebra-RedZone
        • Static Assignment
    • Zebra_Bluezone
      • Assigned Group: Zebra-BlueZone
        • Static Assignment

If I have a scanner, and I assign it to group zebra-RedZone. It will get the red zone and the default. The default links the bluezone if it’s assigned to a policy. Thus, now it gets two policies and starts conflicts. So what you have to do for each policy is place all other groups, excluding your default group into the exclude assignment. So, if you want the redzone, place the zebra-redzone inside the zebra_redzone policy assignment and place zebra-bluezone in zebras_redzone exclusion assignment. The Zebra_default will need to have the two zone groups added to it’s exclusion list as well. This makes everyone happy.

Once you have everything assigned, click create. Add the scanner to your group that you want, and it will be applied. We have a few departments like this; by doing it this way, I can give out a passcode to an end user for troubleshooting and not effect any other departments. Plus, I can push out a password change for the kiosk without effecting other departments. I personally set each background to that department name. So they know when scanners float between departments. This has stopped so many fights.

What can we learn as a person?

There is a flow to things in this life. Whether it makes sense or not is a different story. The first time I set up these profiles, I was confused about why I kept getting just one icon. Instead of the four I selected. Then it locked down to the point where it was super Zebra Kiosk Mode and not a usable version. After tracking where things went, I finally figured it out. It was like watching a flow. Sometimes we have that in our lives. Things come up, and they leave you left in the what-happened mode.

I’ll give a great example from my life: car keys. I come home late the night before and place my keys in front of my bed instead of on my nightstand. The next morning, I wake up late, and I’m rushing around. I pull everything out of the nightstand, but the keys are missing. This makes me freak out. Rather than searching frantically, I’ve learned to focus on the events of the previous day. What did I do when I got home? I follow each step until I find where I put my keys. Most of the time, the cat knocked it off. He likes my chest in front of the bed. It’s always a good thing to stop and look at the flow. What’s happening, and where did things go wrong? I hope you go with your flow. You deserve it.

Additional Resources:

Enrolling Zebra Scanners into Intune

Enrolling Zebra Scanners into Intune

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.

  1. Admin access to your Intune with the proper licensing. If you have E5 licenses and a P2 plan, you should be golden.
  2. A computer with stage now.
  3. 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.

  1. We navigate to your intune instance.
  2. Devices > Android > Enrollment > Corporate-owned Dedicated devices
  3. Click Create Policy
    • Name: Zebra Enrollment
    • 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
  4. Click Next
  5. 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.

  1. Click on the policy
  2. Manage > Token > Show Token
  3. 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.
  4. Send this text to yourself. I used teams.
  5. Below is what the code will look like.
{"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":"com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver","android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":"<Hash Number>","android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":"https://play.google.com/managed/downloadManagingApp?identifier=setup
","android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{"com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN":"<Your Token>"}}

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.

  1. Click Create New Profile
  2. Click Xpert Mode
  3. 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.
  4. Now we are sent to the add/edit window. Click Wizard.
  5. 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.
  6. Click the settings tab
  7. Add Wifi, Filemgr, AppMgr and Intent
  8. 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

  1. 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.
  2. Click Continue
  3. Network Type > Drop Down: WiFi
  4. Certificate Management: No
    • Please note that if your network uses a cert, you will need to set it up here.
  5. Disconnect Networks: No
    • We select No because the next section disconnects the networks for us.
  6. Disalbe Network: Yes
    • This will disconnect from all of the other networks
  7. Click Continue
  8. Add Network: Yes
  9. SSID: Your SSID
  10. Security Mode: Personal
    • In this example, we are going to use a basic wifi setup with a password.
  11. WPA Mode: WPA/WPA2
  12. Encryption Type: Do not change
    • We don’t change because by default it is aes-ccmp/tkip
  13. Key Type: Passphrase
  14. Protected Key: Checked
  15. Passphrase: <Enter your passphrase>
  16. Use DHCP: Check
  17. Keep everything else as default.
  18. Click continue.
  19. 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.

  1. Target OS: Android
  2. Wi-Fi Enable: Enabled
  3. Sleep Policy: Never Sleep
  4. Network Notification: Use Network Notifications
  5. Enable Wi-Fi Verbose Logging: Do not change
    • If you want this feature, you can set it; however, it eats resources on the scanner.
  6. 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.
  7. 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.
  8. 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.

  1. File Actions: Transfer/Copy File
  2. Target Access Method: File in the device file system
  3. Target Path and File Name: /sdcard/AndroidDevicePolicy.apk
  4. Source Access Method: File on a remote server
  5. Source File URL:
    • Click the three dots
    • Search for the file and add it.
  6. 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.

  1. Action: Upgrade
  2. APK Path and Name: /sdcard/AndroidDSevicePolicy.apk
  3. 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.
  4. Access to app information action: Do nothing
  5. 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.

Now back to stage now.

  1. Action: Enroll a Device Owner
  2. Package name: com.google.android.apps.work.clouddpc
  3. Class Name: com.google.android.apps.work.clouddpc.receivers.CloudDeviceAdminReceiver
  4. Json Value: Json File
  5. Json File:
    • Click the three dots and navigate to your newly created json file.
  6. 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.

Additional Reading

Force Intune apps to redeploy

Force Intune apps to redeploy

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.

$Path = "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps"
$AppID = "Your-App-Code-Goes-Here"

$Users = (Get-ChildItem -Path "$Path").name | Where-Object {($_ -like "*-*-*-*-*") -and ($_ -notlike "*00000000-0000-0000-0000-*")}

foreach ($user in $Users) {
    $Name = $User -replace "HKEY_LOCAL_MACHINE","HKLM:"
    $UserID = $user.split("\")[-1]
    $Applications = Get-ChildItem -Path $Name | Where-Object {$_.name -like "*$($AppID)*"}
    foreach ($App in $Applications) {
        $AppName = $App -replace "HKEY_LOCAL_MACHINE","HKLM:"
        Write-Host "App Name: $AppName"
        remove-item -Path $AppName -Recurse -Verbose -force
    }
    $GRSPath = "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\$UserID\GRS"
    $GRSes = Get-childitem -path $GRSPath
    foreach ($GRS in $GRSes) {
        $GRSProps = $GRS | Get-ItemProperty
        $Count = $GRSProps.psobject.Properties.count 
        if ($Count.count -gt 5) {
            $TotalKey = $GRSProps.psobject.Properties.name | where-object {$_ -like "*-*-*-*-*"}
            if ($TotalKey -like "*$($AppID)*") {
                $PathToRemove = $GRS.name -replace "HKEY_LOCAL_MACHINE","HKLM:"
                Remove-Item -Path $PathToRemove -Recurse -Force -Verbose
            }
        }
    }
}
Get-Service -DisplayName "Microsoft Intune Management Extension" | Restart-Service -Verbose

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.

$Path = "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps"
$AppID = "Your-App-Code-Goes-Here"

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.

$Users = (Get-ChildItem -Path "$Path").name | Where-Object {($_ -like "*-*-*-*") -and ($_ -notlike "*00000000-0000-0000-0000-*")}

Handling the App Side

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.

    $Name = $User -replace "HKEY_LOCAL_MACHINE","HKLM:"
    $UserID = $user.split("\")[-1]
    $Applications = Get-ChildItem -Path $Name | Where-Object {$_.name -like "*$($AppID)*"}

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.

foreach ($App in $Applications) {
        $AppName = $App -replace "HKEY_LOCAL_MACHINE","HKLM:"
        Write-Host "App Name: $AppName"
        remove-item -Path $AppName -Recurse -Verbose
 }

Handling GRS Side

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.

$GRSPath = "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\$UserID\GRS"
$GRSes = Get-childitem -path $GRSPath

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.

$GRSProps = $GRS | Get-ItemProperty
$Count = $GRSProps.psobject.Properties.count 

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.

if ($Count.count -gt 5) {
        $TotalKey = $GRSProps.psobject.Properties.name | where-object {$_ -like "*-*-*-*-*"}
        if ($TotalKey -like "*$($AppID)*") {
            $PathToRemove = $GRS.name -replace "HKEY_LOCAL_MACHINE","HKLM:"
            Remove-Item -Path $PathToRemove -Recurse -Force -Verbose
        }
}

The GRS has been removed after this.

Restarting the service

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.

Get-Service -DisplayName "Microsoft Intune Management Extension" | Restart-Service -Verbose

Final Step

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.

Scheduled Tasks with PowerShell

Scheduled Tasks with PowerShell

Last week we went over how to do audits using PowerShell (Link). Today we will use scheduled tasks with PowerShell to have the audit script run hour by hour. We do this because we don’t want to be manually running the PowerShell script every hour. Let the computer handle all of that for us. We will go over how to manually build the Scheduled Task and the PowerShell way.

Manual Process – Scheduled Tasks

Lets take a look at the manual process. We are placing our AuditDisabledAccounts.ps1 script on the computer. I like placing things in the c:\scripts or c:\temp folder. Sometimes this is good, sometimes this is bad. It depends on the world you are working in.

  1. Start Task Scheduler
  2. Click Task Scheduler Library.
  3. Right Click and select basic task
  4. Name it accordingly. I am naming mine “Hourly Disabled AD Audit.”
  5. Under Triggers, I selected When the computer starts.
    • This scheduled task will repeat itself with another setting. It’s best to get it started when the computer starts. This way if the system restarts, it will start again. It can become confusing over time.
  6. The action will be start a program
    • Program: Powershell
    • Arguments: -NoProfile -ExecutionPolicy Bypass -HoursBack 1 -Servers AD1,AD2,AD3 -OutCSVfile “C:\Reports\DisabledAccountsAudit.csv”
    • Start In: c:\temp\AuditDisabledAccounts.ps1
  7. To finish, you want to open the properties dialog

Now we have a basic scheduled task setup. Next we want to have it trigger every hour. Sense we opened the properites you can now do just this.

  1. On the general tab
  2. Radio check: “Run whether the user is logged on or not.”
    • If you need to change the user, this is where you will do that.
  3. Click the Triggers tab.
  4. You will see at startup, click edit
  5. Under advanced Settings
    • Check Repeat task every
    • Select 1 hour
    • Duration: Indefinitely
  6. Click ok

That’s how you manually setup a Scheduled Task for PowerShell.

Powershell Method

Now we can do a Scheduled Tasks with PowerShell. We will be using the scheduledtask commands to create the task accordingly. Lets take a look at the script itself.

The script – Scheduled Tasks with PowerShell

# Variables
$ScriptPath = "C:\temp\AuditDisabledAccounts.ps1"
$TaskName = "Audit Disabled Accounts"
$OutCSVfile = "C:\Reports\DisabledAccountsAudit.csv"
$Servers = "AD1,AD2,AD3"
$HoursBack = 1
$User = Read-Host -Prompt "Domain\Username"
$Creds = Read-Host -AsSecureString -Prompt "Enter Password" 

$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($Creds)
$UnsecurePassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
[Runtime.InteropServices.Marshal]::ZeroFreeBSTR($BSTR)


$triggers = 0..23 | ForEach-Object {
    New-ScheduledTaskTrigger -At "$($_):00" -Daily
}


$principal = New-ScheduledTaskPrincipal `
    -id 'Author' `
    -UserId "$User" `
    -LogonType Password `
    -RunLevel Limited
    

$Action = New-ScheduledTaskAction `
    -Execute "PowerShell" `
    -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$ScriptPath`" -HoursBack $HoursBack -Servers $Servers -OutCSVfile `"$OutCSVfile`"" `
    -WorkingDirectory 'C:\temp\'

$Task = New-ScheduledTask `
    -Description 'Usered To Audit Disabled Accounts' `
    -Action $Action `
    -Principal $principal `
    -Trigger $triggers

Register-ScheduledTask `
    -TaskName "$TaskName" `
    -TaskPath '\' `
    -Action $Action `
    -Trigger $triggers `
    -User $User `
    -Password "$UnsecurePassword"

The breakdown

The first thing we do is setup. We want to have the script, the name, the out file for our audit report, our servers, and the hours back we want to go.

Veriables

# Variables
$ScriptPath = "C:\temp\AuditDisabledAccounts.ps1"
$TaskName = "Audit Disabled Accounts"
$OutCSVfile = "C:\Reports\DisabledAccountsAudit.csv"
$Servers = "AD1,AD2,AD3"
$HoursBack = 1
$User = Read-Host -Prompt "Domain\Username"
$Creds = Read-Host -AsSecureString -Prompt "Enter Password" 

The first thing we want is the veriables. We want the path of the script. We want it’s name. Where our CSV files will be dropped, the servers, how many hours back, usernames and passwords. Notice that the User is using a read-host and creds is using a secure string. This is to help stop shoulder surfers and powershell memory. This way you password isn’t passed around. Basicly, we input the password as a secure string, and it becomes a veraible. Thus, if someone is looking through the powershell history, or is monitoring it with something like defender, then they will not see the password. Only the veraible from this point on.

Decoding Passwords as Veriables

Part of the Scheduled Tasks with PowerShell is we need to register the task later. This means that the password needs to be plain text. However, we don’t want a password to ever exist in the shell visability. So we want to decode it directly into a Veriable.

$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($Creds)
$UnsecurePassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
[Runtime.InteropServices.Marshal]::ZeroFreeBSTR($BSTR)

The code above allows you to convert the secure string to normal text in Powershell 5. If you are using powershell 7, this isn’t a problem. But most servers are still defaulting at 5. The new veriable name is UnsecurePassword which has the password as plain text for the register command.

Triggers – Scheduled Task for powershell

We need to start making the triggers. Unlike the gui, we can’t setup a startup with a hourly repeat. Instead, the safeist way is to do an hourly thing for repeating the hour. We do this using the new-scheduledtasktrigger command.

$triggers = 0..23 | ForEach-Object {
    New-ScheduledTaskTrigger -At "$($_):00" -Daily
}

Since we have 24 hours in a day, we want to repeate a foreach-object loop 24 times. We start at 0 and go to 23 which makes 24. Wow… Anyways, As we loop, the $_ will be the number. So we create a new trigger at that time and set it to daily. All of this will be dumped into the $triggers array.

Principal

Next we want to setup a user account. The command for this is…. Yep, you guessed it, New-ScheduledTaskPrincipal. Here we are setting the ID to the author, using our user flag, doing the logontype as password, and the runlevel is limited. We don’t want it to have full access to anything since it’s not doing anything on the local PC. Notice the ` symbol. This allows you to do mulitlple lines with one command. It’s like break here and continue to the next line. It makes reading code so much easier.

$principal = New-ScheduledTaskPrincipal `
    -id 'Author' `
    -UserId "$User" `
    -LogonType Password `
    -RunLevel Limited

Actions

Next we need to do our actions. AKA, what’s it going to do. Using the New-scheduledTaskAction we want to execute with powershell and push our arguments in. Using our Veriables, we fill in the blanks. It’s very straight forward. The secret sause here is the arguments will be like you did with the gui approach.

$Action = New-ScheduledTaskAction `
    -Execute "PowerShell" `
    -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$ScriptPath`" -HoursBack $HoursBack -Servers $Servers -OutCSVfile `"$OutCSVfile`"" `
    -WorkingDirectory 'C:\temp\'

Tasks

Next we need to make the task itself. We are going to use the New-ScheduledTask command. This part of the command creates a task object that will need to be registered. We give it the description we want. The Actions from above. The user inside the principal names and the triggers we built out.

$Task = New-ScheduledTask `
    -Description 'Usered To Audit Disabled Accounts' `
    -Action $Action `
    -Principal $principal `
    -Trigger $triggers

Register The Task

Finally, we want to register the task in question. We are going to use “Register-scheduledTask” to do this. Notice that this is where we are using that password we used at the start. It’s used as a variable, and thus it’s never shown in the PowerShell history.

Register-ScheduledTask `
    -TaskName "$TaskName" `
    -TaskPath '\' `
    -Action $Action `
    -Trigger $triggers `
    -User $User `
    -Password "$UnsecurePassword"

Additional Thoughts on Scheduled Tasks with PowerShell

This technique is very powerful. I built out a script that scanned the local network via Get-NetNeighbor. The script was a scheduled task and it grabbed all the devices. Imagine having admin rights, pushing out a script that scans the local network drops a scheduled task on another computer that scans that network. You could map out a whole network within a few minutes. This could be used as a worm and it’s a good reason to block WMI on the network except from the machines that does the administration.

What can we learn as a person?

It’s always a good idea to have routine. Having a Scheduled task in your life that you like tends to improve our lives. For example, I like going to a monthly meetup with my friends. It’s something I look forward to. Having it on my calendar helps. This is why vacations are important. We need to have those things on our calendar. It’s ok to have them on the calendar. So, find something you can look forward to, and put it on the calendar.

Additional Resources

Intune Detection Script

Intune Detection Script

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!

The Script

$ProductName = "AutoCAD 2022"
$ProductVersion = "24.1.173.0"
$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall", "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall"
$apps = Get-ChildItem -Path $RegPath 
$Test = foreach ($app in $apps) {
    $app | Get-ItemProperty | Where-Object {($_.DisplayName -like "$ProductName")} | select-object *
}
if ($Test.displayversion -ge "$ProductVersion") {
    write-host "Installed - $($test.DisplayVersion)"
    exit 0
} else {
    exit 1
}

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.

$ProductName = "AutoCAD 2022"
$ProductVersion = "24.1.173.0"

Line 3: Setting the Registry Path

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.

$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall", "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall"

Line 4: Gather Installed Applications

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.

$Test = foreach ($app in $apps) {
    $app | Get-ItemProperty | Where-Object {($_.DisplayName -like "$ProductName")} | select-object *
}

Lines 8-12: Check Version and Provide Output

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.

if ($Test.displayversion -ge "$ProductVersion") {
    write-host "Installed - $($test.DisplayVersion)"
    exit 0
} else {
    exit 1
}

To Deploy Your Script with Intune

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:

  1. The first step in script preparation is to test it locally. You shouldn’t distribute something without testing on your own machines.
  2. 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.
  3. Assign script:
    • After uploading your script, assign it to device groups. You can choose groups by organizational units or other deployment parameters.
  4. 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.
  5. 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:

    1. 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.
    2. 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.
    3. 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.

    Additional Resources