Kaseya Community

Removing Windows Lock from Start Menu options

This question has suggested answer(s)

A bit of a strange request, but let me explain so its clear.

We use Box (rather than Sharepoint) for political reasons I cannot explain.
We use its app BoxDrive (ability to see folders/files under windows file explorer rather than website)
The only problem is that if a user uses a shared PC, locks their account, and another walks up to use the PC with their personal credentials, Box Drive will not function.
Essentially the app only works on 1 user account at a time. The current solution is to reboot. 

However I've found a solution, just having a hard time implementing it.

The solution is to Remove the Lock option from Windows 10. Simple, but again deployment is not easy.
This way users cannot lock the pc, only sign out. (this is a great solution given the field of work these PCs are setup, no user should ever need to lock the PC and come back)

Using Kaseya I have a batch file with command:

Powershell.exe -noprofile -executionpolicy bypass -file C:\ITAdmin\RemoveLock.ps1

The Powershell script is as follows: 

New-Item -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies -Name System
New-ItemProperty -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\System -Name DisableLockWorkstation -PropertyType Dword -Value '1'

This works, you can try it manually by adding the reg key, or running the powershell command manually.

However I need to do this to ~200 PCs that are in multiple remote locations. I am working for a company that does not have a traditional domain, simply Office365/Microsoft Azure AD. Kaseya fills the gaps that AzureAD lacks.

If I add those two files into a procedure to be written, and then executed it does not work.

I've got Kaseya creating the folder C:\ITAdmin, and putting RemoveLock.Bat and .ps1 into them. .Bat should call ps1 and run it with no issue.
The only thing I can think is problem is that the .ps1 writes a reg key to current user....can this be it? Or is there another solution to what I am looking for.

All Replies
  • Hi Doug,

    I would like to preface my answer with the fact that I am fairly new to Kaseya and using many features, but as the community has been so helpful, I thought I would try and answer since it seems like one I might know.

    Being a believer in simple answers, it seems to me like the easiest way to accomplish this is to write an agent procedure.  Agent procedures should have no issue writing to the HKCU part of the hive and once the procedure is written, you can schedule it across any view with a distribution period.  So, you could run across a small segment to test, and then move to other departments, clients, however you happen to have your views set up.

    Hope that helps.

  • Doug,

    Take a look at this site. I would suggest method 2.


  • I found the solution myself yesterday.

    Instead of writing to HKCU, just created the same path via script under HKLM and all is working.

    Marked as suggested answer.
    [edited by: Doug.Herring at 8:10 AM (GMT -7) on Mar 13, 2018]
  • From a Kaseya scripting standpoint, the most likely issue with why what you are trying to do not working is the fact that you need to touch the Hkey_Current_user hive for those scripts above.  Kaseya scripting does indeed have no issue writing to HKEY_CURRENT_USER.  however it'a matter of *which* HKEY_CURRENT_USER hive it's writing to.  

    If what you really need to change is under HKEY_Current_user, then you actually need to change that for each and every user who might have a profile on the machine... That's something better done as a logon script or Group Policy.  

    Also keep in mind that which user a kaseya procedure runs as depends on your script commands.  For both powershell and commandline options there are options to run as the current logged in user, or as the System user.  If you run as the system user then writing to HKCU will really have no effect, as no one ever logs in as the system user.  If you run as the currently logged in user, and you happen to run it while someone is logged in, then you will successfully set the registry key *for that user only*, but not for any other user who might log in later.

    The better option would be to write a procedure around the registry key mentioned in OPtion 2 of the page linked to by above.  That key is in the HKEY_LOCAL_MACHINE hive, and thus would apply for *all* users on that machine.

    In fact that particular script would be a simple one liner. 

    setRegistryValue("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableLockWorkstation", "1", "REG_DWORD", "All Operating Systems", "Halt on Fail")

    Make suggested answer.
    [edited by: Jonathan at 12:15 PM (GMT -7) on Mar 13, 2018]