FULLY WORKING AND NATIVE LOGON SCRIPTS IN INTUNE (Not seen documented anywhere else)

[cdwyersandysecondary]

Hi all.

 

Had a breakthrough today.

 

Went full azure, Intune and autopilot last year. All has been good apart from one thing... no native logon script support.

 

We've tried all the janky methods and settled on Task Scheduler for some time, but it's unreliable.

 

Queue last week, I thought 'There must be a better way!'

 

Lo and behold, there is. I've also not seen anyone else try this, not even in obscure forums deep on the internet (I tried everything to find a good method before!) so this may be the first documented method for this and it's also the BEST way hands down.

 

1. Firstly, you need to configure Logon Scripts in Local Group Policy on a test/admin PC, by going to: User Configuration > Policies > Windows Settings > Scripts.

 

2. Add all your logon scripts in here, the same way you used to when you managed your site with Group Policy (except locally) then hit apply.

 

3. Once you manually add those logon scripts via local GP on a test machine, it will create and populate a folder in "C:\Windows\System32" called "GroupPolicy"

 

4. Copy the entire "GroupPolicy" folder somewhere else. I copied to Desktop and put it into a folder called "LogonScriptsApp"

 

5. Open the "GroupPolicy" folder you copied off and make sure the scripts you added can be found in "GroupPolicy\User\Scripts\Logon" if not, move them into this folder.

 

6. If you had to manually add the scripts to the "Logon" folder, navigate to "GroupPolicy\User\Scripts" and open the file "psscripts.ini"

 

7. Ensure the .ini file is laid out in this format (I have called the scripts "yourscript1" and "yourscript2" for the purpose of the demonstration):

 

[Logon]0CmdLine=yourscript1.ps10Parameters=1CmdLine=yourscript2.ps11Parameters=

 

8. As you can see, it should just say CmdLine=*scriptname* - if it has a path before the name of the script, it's not looking in the "Logon" folder discussed above. It must be looking in the Logon directory because we are going to wrap all of this into a Win32 app.

 

9. If you need to, once those scripts are copied into the "Logon" folder, edit the .ini file and ensure there isn't a path string before the script name and then save the .ini file.

 

10. Now, you need to make a PowerShell script that will copy all the files from the script root into the "Windows\System32" folder and create/replace the "GroupPolicy" folder and all it's contents, taking ownership of it and setting permissions to allow the file replace to take place.

 

 

 

Here is the script below I used to do this, you can copy this exactly as is:

 

# Take ownership and set full control permissions for 'Everyone' on the GroupPolicy folder$destinationFolder = "$env:windir\System32\GroupPolicy"takeown /f $destinationFolder /r /d yicacls $destinationFolder /grant Everyone:(OI)(CI)F /t# Define the source folder based on the script's location$sourceFolder = Join-Path -Path $PSScriptRoot -ChildPath "GroupPolicy"# Use robocopy to mirror the directory structure and files, replacing the destination contentsrobocopy $sourceFolder $destinationFolder /MIR /COPYALL /R:5 /W:1$GroupPolicyFolder = "C:\Windows\System32\GroupPolicy"$acl = Get-Acl $GroupPolicyFolder$perms = New-Object System.Security.AccessControl.FileSystemAccessRule("Everyone","FullControl","Allow")$acl.SetAccessRule($perms)$perms = New-Object System.Security.AccessControl.FileSystemAccessRule("Administrators","FullControl","Allow")$acl.SetAccessRule($perms)$perms = New-Object System.Security.AccessControl.FileSystemAccessRule("SYSTEM","FullControl","Allow")$acl.SetAccessRule($perms)Set-Acl $GroupPolicyFolder $acl

 

 

 

11. Save this script as "install.ps1" and put it into the "LogonScriptsApp" folder on the Desktop (Which should also contain the copied off "GroupPolicy" folder and all it's contents as discussed earlier)

 

12. Now use the win32 app packaging tool to package the app. The source folder is the "LogonScriptsApp" folder on the Desktop and the setup file is the script we just saved as "install.ps1"

 

13. Upload the new app to Intune, name it etc. and then use this for the install command:

 

 

 

%windir%\Sysnative\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File "install.ps1"

 

 

This is super important because if you don't run PowerShell from the "sysnative" directory, the script will run and move the files into the SysWOW64 folder instead of System32 because of file redirection restrictions in Windows.

 

14. Ensure you deploy in system context and not user and also in the 64 bit context, then use one of the script files in the "Logon" folder as the detection rule.

15. You will now have fully native logon scripts using local GP on every machine you deploy to.

 

 

This method simply uses the native logon scripts functionality from Local Group Policy/Group Policy and so is very reliable. So far, for us it has worked every single time.

 

I really hope this helps somebody and if you have any questions please ask.

[thimon]

This is not selling the move to InTune to me [emoji846]

[cdwyersandysecondary]

This is not selling the move to InTune to me [emoji846]

 

Oh absolutely, there are certain things in Intune that just make absolutely 0 sense. Not including native recurring login scripts within intune is one of those things.

 

For the most part, everything I need to do I have now figured out in intune, but is a lot of it easy? Nope. Could a lot of it be done far simpler in group policy on prem? Yep.

 

I moved to Intune and full azure so that our system is available from anywhere on our devices with no need for a VPN or remote system.

 

Just open laptop, connect to wifi, login and get the full experience as if you were on site.

 

For me, that makes it worth the hassle, but other peoples requirements will be different!

[localzuk]

May I ask what you're in need of running as a script at logon? We've not had login scripts for years now.

[cdwyersandysecondary]

May I ask what you're in need of running as a script at logon? We've not had login scripts for years now.

 

Sure! Our login script:

 

- clears public desktop (removes any app shortcuts that get added when apps install themselves)

- creates a ‘My Files’ and ‘Google Chrome’ shortcut on to the public desktop once cleared.

- left aligns task bar

- sets dark mode In the taskbar only (not explorer)

- starts some necessary applications

- adds a reg key and proxy setting for our internet filtering solution.

 

Think that’s about it. May be a few other minor tweaks in there but they’re the key ones.

[Chris_Cook]

Is step 10 (setting full control for Everyone) not a bit of a security risk? Or is this just on your development machine?

 

What's to stop a student from modifying/adding to your scripts? I'm not a powershell expert, so please forgive me if I have missed something.

[cdwyersandysecondary]

Is step 10 (setting full control for Everyone) not a bit of a security risk? Or is this just on your development machine?

 

What's to stop a student from modifying/adding to your scripts? I'm not a powershell expert, so please forgive me if I have missed something.

 

Yes, it would be.

 

The script and whole process works without that part, it’s only the detection rule that doesn’t for whatever reason. Detection fails in Intune but everything still works.

 

I should state here in the post that you should either:

 

- add a part to remove the everyone permission as soon as the script ends.

 

- not use the everyone permission at all and use a different detection policy.

 

 

They can’t actually traverse to the folder that has the scripts in as inheritance isn’t enabled on it, they will get a UAC prompt if they go any further than just the top level directory folder, but I have yet to mess around and see how easy this is to break as a student, so the points above still apply.

[thimon]

All of the steps that the script does can be done via group policy, I wouldn’t use a login script. Are there InTune policies that can do the same?

[cdwyersandysecondary]

All of the steps that the script does can be done via group policy, I wouldn’t use a login script. Are there InTune policies that can do the same?

 

Intune doesn’t use group policy. Intune is built around scripts and win32 apps, it’s a lot harder to manage and maintain.

[XiJ]

Surely you can do all that in a power shell script and deploy from intune ?

[cdwyersandysecondary]

Surely you can do all that in a power shell script and deploy from intune ?

 

Do all what?

[XiJ]

Do all what?

 

- clears public desktop (removes any app shortcuts that get added when apps install themselves)

- creates a ‘My Files’ and ‘Google Chrome’ shortcut on to the public desktop once cleared.

- left aligns task bar

- sets dark mode In the taskbar only (not explorer)

- starts some necessary applications

- adds a reg key and proxy setting for our internet filtering solution.

 

 

 

The above that you want your login script to do.

[cdwyersandysecondary]

- clears public desktop (removes any app shortcuts that get added when apps install themselves)

- creates a ‘My Files’ and ‘Google Chrome’ shortcut on to the public desktop once cleared.

- left aligns task bar

- sets dark mode In the taskbar only (not explorer)

- starts some necessary applications

- adds a reg key and proxy setting for our internet filtering solution.

 

 

 

The above that you want your login script to do.

 

No, because powershell scripts in Intune only run once per user/per device.

 

I need my script to run every time a user logs in.

 

As apps get pushed out/installed, their shortcut appears on public desktop, the login script clears it every time and only puts back the files and chrome shortcut.

 

Applications that get started from a server location also need to reliably start on every login.

 

I do wish they made this functionality natively in Intune but it’s just not there, for whatever reason.

[XiJ]

Ah I’d forgot about the run once unless changed

[Ratcliffepg]

Have you got an example of the script you are using to create the below ?

 

- creates a ‘My Files’ and ‘Google Chrome’ shortcut on to the public desktop once cleared.

 

Thank you

[cdwyersandysecondary]

Have you got an example of the script you are using to create the below ?

 

- creates a ‘My Files’ and ‘Google Chrome’ shortcut on to the public desktop once cleared.

 

Thank you

 

I am back in work tomorrow, I’ll simplify the whole process and send over a package containing the login script that has this in, as well as the rest for you to use if you want to!

[Ratcliffepg]

Thank you !

[cdwyersandysecondary]

I have now uploaded everything needed to Github: GitHub - cdwyer-240395/Intune-Scripts-Packages

 

I have adjusted the install script so that once the logon scripts are deployed, it changes the permissions back to read only, as per some people's concerns about the 'Everyone' permission on the folders.

 

Enjoy!

[KK20]

For people who dont use this method or scheduled task etc, I am curious as to how you perform user registry settings etc that you would like to apply or reapply per logon (perhaps you dont want people messing with user acrobat settings etc). I am aware that if you have the licensing you can use remediation.

[cdwyersandysecondary]

For people who dont use this method or scheduled task etc, I am curious as to how you perform user registry settings etc that you would like to apply or reapply per logon (perhaps you dont want people messing with user acrobat settings etc). I am aware that if you have the licensing you can use remediation.

 

Hi. If you want recurring reg keys to change via a script, you need to use the task scheduler or this method I’ve provided.

 

Remediations can work but can only be set to per hour at a minimum so is not quick enough for what we need.

 

There is no other way to run recurring scripts on login unfortunately, that’s why I created this method.

[KK20]

Indeed, I do something similar. I was more wondering what others do. I too found that user WIN32 installations were too slow and unpredictable for items that were needed on logon. At least with system WIN32 you can white glove/pre provision.

[cdwyersandysecondary]

Indeed, I do something similar. I was more wondering what others do. I too found that user WIN32 installations were too slow and unpredictable for items that were needed on logon. At least with system WIN32 you can white glove/pre provision.

 

Yes It’s very frustrating that they haven’t included functionality for login and startup scripts in Intune, the fact it has to be done in a janky way is ridiculous.