Partager via


PowerShell Mouse Mover

IT Politics!!!  Ughh!!  I see it all the time but I was working with a customer who seemed to have it worse than others.  The customer's environment consisted of multiple networks that their IT staff had to administer at any given time.  Multiple networks with different levels of importance and thus, different security policies relative to the defined level of importance -- I don't know how they keep it together.  While I was on-site, one of the biggest issues of frustration the admins voiced was trying to work within relatively short timeframes between different computers, on different networks due to the Screensaver Timeout policy (~5 minutes) and constantly having to unlock their workstations while they were sitting at their desks.  Their IT Security team would not support changing the setting, allowing a mouse mover (because of freeware downloaded from the Internet), and their Dev shop didn't have the availability to build them a custom mouse mover so... they asked if there was anything that I could think of that they could do.

I told them that the obvious answer was to request an exemption from the screen saver policy and provided documentation on how to do so using an AD Security Group with Security Filtering applied to a GPO but their IT Security team shot it down.  So, I offered the last alternative:  a very easy little PowerShell script that simulates mouse movement to keep the screen from locking due to inactivity.  Once their Network Security team approved the idea for their "less important" networks, I sat down and got to work.

As it turns out, user32.dll has a function that was perfect for my needs:  mouse_event*.  It's function is to "Synthesizes keystrokes, mouse motions, and button clicks".  So all we need to do is figure out how to use it in a PowerShell script.  Well, PowerShell, because it's really just .NET, has this really cool ability to access native Win32 API through a feature called Platform Invocation Services (or 'PInvoke' for short) that allows managed code to access functions native to DLLs that are present on a system.  The key to using a DLL's native functions is knowing the signature of each function you want to invoke.  That's where an incredible resource surfaces:  pinvoke.net.  pinvoke.net is a sort of wiki that documents known DLLs, their associated known functions, and their associated function signatures in a number of different languages.  Looking at the user32, mouse_event function on pinvoke.net, we can see the following two signatures for C#:

With this information and a little easy PowerShell magic, we can easily complete the project!  Please see the attached code:

Download:  [View:~/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-04-07/Move_2D00_Mouse.ps1:550:0] ** ,***

Sample Usage: 

Move-Mouse -Secs 10 -LoopInfinite $true

Move-Mouse -XY 10 -Secs 5 -LoopInfinite $true -DisplayPosition $true

 

* Note that the MSDN page identifies the mouse_event function as deprecated and recommends using SendInput instead. The next version of this script will use the SendInput function instead.

** Note that if you're using software on your computer that takes control of the mouse (e.g. virtualization software while interacting with a guest), this script will not work until you "unlock" the mouse from that application.

*** If you're using the DisplayPosition parameter and are wondering why the X/Y coords are not making the mouse visibly move, it's because mouse_event uses absolute or relative normalized coordinates between 0 and 65535 but the emitted mouse location from the script uses pixels so unless you use a value for the mouse to move that is large enough for it to move an actual pixel, you will not see the mouse actually move.  I prefer it this way so my mouse isn't jumping all over the screen while I'm trying to use it.