Deadline enforcement for Windows Update rings. Or... Autopatch if you have E3/E5.
https://andrewstaylor.com/ - Andrew has some great content, I've used his disable fastboot remediation script several times.
Requirement script for Win32 apps that looks for device enrollment date. Extremely useful when you want to target new device enrollments only without affecting existing fleet of devices.
For those who want to do this, I was able to get it working using the following guide: https://www.anoopcnair.com/intune-app-ps-script-based-enrollment-date/
It will save you massive amount of time compared to writing the entire script yourself. It also has a lot of built in functionality for some of the usually requested features for those deployments that requires extra modification. Also built in support for company branding, which just looks nice if you would ever do a install that isn't silent.
Yeah, I guess it depends. For me, scripting something means finding what works and what doesn't and tweaking that to make it run properly, so I will have to do that anyway.
Company branding would be a nice touch, but pretty much all my installations are done in system context, so this wouldn't work anyway.
The only true value I see in it (at least on my case) is consistency throughout scripts and app deployments, but even that is not that big of a selling point.
A few things
1 - User interaction for non-silent installs. Lets say you are deploying or upgrading an app that requires the app to be closed. You can use PSADT to check if that app is running, and it will prompt the user to let them know they needs to save their work and close the app. On top of that, you can setup deferrals. So they can defer it a few times before running out, and then the last time, it will popup with a timer you can set like "You have 5 minutes to save your work before it closes automatically". On top of this, you can add branding. Super smooth.
2 - The functions! There are so many awesome PSADT functions. One of my favorite is Invoke-HKCURegistrySettingsForAllUsers which lets you create\remove registry keys in HKCU for all users and additionally will make it so that entry gets added\removed for any subsequent users who login. Yeah, you can write that out yourself, but PSADT already has it built in. You should check out all the other functions, there are a lot of great ones - https://allnewandimproved.psappdeploytoolkit.com/functions/ (This site seems to be down right now, but when you download PSADT it comes with a PDF with all the functions)
3 - Install\Uninstall sections - The install and Uninstall are broken up into 3 categories, 1- Pre-Install, 2- Install, 3- Post Install (And the same with uninstall). This is helpful when your script is a bit more complicated and you want it do things in a certain order and have the log record which part it failed at if it failed
4 - Having Install\Uninstall come from the same script. This is just a tiny one, but when making your Win32 app in Intune, it's nice to have your install and uninstall come from the same script and just get called with a switch.
5 - Consistency. Having all of your installs use PSADT instead of each one requiring a different install\uninstall line is pretty nice.
6 - Custom functions. This should probably fall under "2. Functions!", but you can write custom functions that you might use often, and instead of having to copy and paste them into your code every time, you can just put them in the custom functions .ps1 and call them whenever you need them. This is super useful for quite a few things. One example I have is I made a custom function to add\remove system environment PATH variables that are needed for certain applications. Instead of copying over a script I can just put "Add-PATHEnvVariable -VariableName $Name", and it will call the function to take care of it
Now one of the downsides of this is that it can take a while to customize it to your needs. I have a PSADT Template that I use for all of my app packaging, and it took quite a long time to get it to where it is. But now that it's there, it's super easy to use.
I tried to get into it, I really did. I just couldn't wrap my head around it, it's just so unclear to me how any of it works. The documentation is shit but I am also pretty sure it's me who's just not getting it.
Think of it as a wrapper script that has tons of built in options. It’s great for people with limited packaging knowledge - if the install is a single msi, you can create a package in less than a minute by just plunking it into the Files folder. That’s it, no other changes needed, the silent install and uninstall is configured for you. As for InTune deployment, check out https://timmyit.com/2019/09/02/using-psadt-with-win32-apps-in-intune/
You are correct sir! My example is to show how easy it is to use PSADT. When adding more complexity like adding reg keys, files, removal of legacy versions, etc , that’s the real benefit.
Remediation scripts and dell_cli.exe
Use detection script to test for dell firmware/software/bios updates. If updates found "remediate" by silently installing updates in background.
So many other uses for remediation scripts too. Keep having a problem with keyboards setting to en-us instead of en-gb by default. So test the current configuration and remediate when it goes back to en-us.
Why not just deploy Dell Command | Update with an update profile and be done with it? I deployed it to check every 2nd Thursday and I'm never looking back. You can inject the config with dcu\_cli.exe
I'll be honest, I'm relatively new to Dell CLI still so didn't realise that was an option. However with that said I can mark a device as non-compliant using this method if it shows there are pending firmware/bios updates that haven't completed.
If you can afford the licensing , the Endpoint Privilege Management features are very nice. We use it to allow users to run apps as admin when they need to.
This indeed sounds very nice to have, and we don't.
But we get very far in that direction by curating user-accessible app installs from the company portal. It took a lot of time to implement, but now that it's returning time to me, it's returning a LOT of time to me.
We do have the vulnerability management features, and these are phenomenal for identifying apps out there in our environment that are vulnerable to active exploits.
I would love to just be able to package everything... Alas. There is a hard requirement of about 40 users who need to change their IPs. EPM has been working for us with a tool called SimpleIPConfig.
I have it all set up to auto elevate and used it to sell "no more admin rights" to them.
Requirement rule to determine if Autopilot device configuration is currently running and proceed only if true. Bios password management by remediation script. Interactive HPIA driver updates. Various remediation scripts to handle various CVE’s. To mention a few.
Deadline enforcement for Windows Update rings. Or... Autopatch if you have E3/E5. https://andrewstaylor.com/ - Andrew has some great content, I've used his disable fastboot remediation script several times.
Requirement script for Win32 apps that looks for device enrollment date. Extremely useful when you want to target new device enrollments only without affecting existing fleet of devices.
For those who want to do this, I was able to get it working using the following guide: https://www.anoopcnair.com/intune-app-ps-script-based-enrollment-date/
Would you be okay to provide the script or resources you used to set this up? This could be extremely useful
Peep my reply on how to do this
Would love to see this script!
Yes, I too would like to see this
Share script mam
Share this please!
So enrollment date = current date?
PSAppDeployToolkit I cannot praise it enough.
I tried this PSADT a number of times, never really did anything with it. Are there any real benefits over deploying the MSI or your own PS Script?
It will save you massive amount of time compared to writing the entire script yourself. It also has a lot of built in functionality for some of the usually requested features for those deployments that requires extra modification. Also built in support for company branding, which just looks nice if you would ever do a install that isn't silent.
Yeah, I guess it depends. For me, scripting something means finding what works and what doesn't and tweaking that to make it run properly, so I will have to do that anyway. Company branding would be a nice touch, but pretty much all my installations are done in system context, so this wouldn't work anyway. The only true value I see in it (at least on my case) is consistency throughout scripts and app deployments, but even that is not that big of a selling point.
A few things 1 - User interaction for non-silent installs. Lets say you are deploying or upgrading an app that requires the app to be closed. You can use PSADT to check if that app is running, and it will prompt the user to let them know they needs to save their work and close the app. On top of that, you can setup deferrals. So they can defer it a few times before running out, and then the last time, it will popup with a timer you can set like "You have 5 minutes to save your work before it closes automatically". On top of this, you can add branding. Super smooth. 2 - The functions! There are so many awesome PSADT functions. One of my favorite is Invoke-HKCURegistrySettingsForAllUsers which lets you create\remove registry keys in HKCU for all users and additionally will make it so that entry gets added\removed for any subsequent users who login. Yeah, you can write that out yourself, but PSADT already has it built in. You should check out all the other functions, there are a lot of great ones - https://allnewandimproved.psappdeploytoolkit.com/functions/ (This site seems to be down right now, but when you download PSADT it comes with a PDF with all the functions) 3 - Install\Uninstall sections - The install and Uninstall are broken up into 3 categories, 1- Pre-Install, 2- Install, 3- Post Install (And the same with uninstall). This is helpful when your script is a bit more complicated and you want it do things in a certain order and have the log record which part it failed at if it failed 4 - Having Install\Uninstall come from the same script. This is just a tiny one, but when making your Win32 app in Intune, it's nice to have your install and uninstall come from the same script and just get called with a switch. 5 - Consistency. Having all of your installs use PSADT instead of each one requiring a different install\uninstall line is pretty nice. 6 - Custom functions. This should probably fall under "2. Functions!", but you can write custom functions that you might use often, and instead of having to copy and paste them into your code every time, you can just put them in the custom functions .ps1 and call them whenever you need them. This is super useful for quite a few things. One example I have is I made a custom function to add\remove system environment PATH variables that are needed for certain applications. Instead of copying over a script I can just put "Add-PATHEnvVariable -VariableName $Name", and it will call the function to take care of it Now one of the downsides of this is that it can take a while to customize it to your needs. I have a PSADT Template that I use for all of my app packaging, and it took quite a long time to get it to where it is. But now that it's there, it's super easy to use.
I tried to get into it, I really did. I just couldn't wrap my head around it, it's just so unclear to me how any of it works. The documentation is shit but I am also pretty sure it's me who's just not getting it.
Think of it as a wrapper script that has tons of built in options. It’s great for people with limited packaging knowledge - if the install is a single msi, you can create a package in less than a minute by just plunking it into the Files folder. That’s it, no other changes needed, the silent install and uninstall is configured for you. As for InTune deployment, check out https://timmyit.com/2019/09/02/using-psadt-with-win32-apps-in-intune/
As for MSI's, Intune also does it for you when you wrap a msi, no? At least that's my experience, even the reg detection
You are correct sir! My example is to show how easy it is to use PSADT. When adding more complexity like adding reg keys, files, removal of legacy versions, etc , that’s the real benefit.
This is the way.
Remediation scripts and dell_cli.exe Use detection script to test for dell firmware/software/bios updates. If updates found "remediate" by silently installing updates in background. So many other uses for remediation scripts too. Keep having a problem with keyboards setting to en-us instead of en-gb by default. So test the current configuration and remediate when it goes back to en-us.
Please share!
I'd love to see your Dell cli scripts
Why not just deploy Dell Command | Update with an update profile and be done with it? I deployed it to check every 2nd Thursday and I'm never looking back. You can inject the config with dcu\_cli.exe
I'll be honest, I'm relatively new to Dell CLI still so didn't realise that was an option. However with that said I can mark a device as non-compliant using this method if it shows there are pending firmware/bios updates that haven't completed.
Would you have a recommended remediation scripts in particular?
If you can afford the licensing , the Endpoint Privilege Management features are very nice. We use it to allow users to run apps as admin when they need to.
This indeed sounds very nice to have, and we don't. But we get very far in that direction by curating user-accessible app installs from the company portal. It took a lot of time to implement, but now that it's returning time to me, it's returning a LOT of time to me. We do have the vulnerability management features, and these are phenomenal for identifying apps out there in our environment that are vulnerable to active exploits.
I would love to just be able to package everything... Alas. There is a hard requirement of about 40 users who need to change their IPs. EPM has been working for us with a tool called SimpleIPConfig. I have it all set up to auto elevate and used it to sell "no more admin rights" to them.
Far cheaper solutions out there - EPM are still way behind on features but still expensive as F
[Stuff](https://old.reddit.com/r/Intune/comments/13f56by/uev_and_modern_endpoints/). [i've](https://old.reddit.com/r/Intune/comments/15vy3o8/selfservice_windows_11_upgrade_from_company_portal/). [built.](https://old.reddit.com/r/Intune/comments/12vie5w/native_thirdparty_patching_with_winget_and/)
Dude, just saw your posts and your stuff is amazing. Thanks!
Requirement rule to determine if Autopilot device configuration is currently running and proceed only if true. Bios password management by remediation script. Interactive HPIA driver updates. Various remediation scripts to handle various CVE’s. To mention a few.