Learn the fundamentals of Microsoft SQL Server, a relational database management system that stores and retrieves data when requested by other software applications.
Recently I had the chance to work on an interesting project, related to setting desktop wallpaper backgrounds for all users at a chosen date and time in the near future. At first this seemed like a very simple cut and dry exercise, just to update desktop wallpaper settings for users. But after reviewing the details of the environment and of the request, it seemed some more consideration was needed. This gave me a chance to take the out of box “login script” capabilities of Active Directory and have some fun with them.
First, the request. This is what matters, what the users are expecting…
Next, some details I noticed while planning how best to accomplish this…
Here is what I thought up of a way to accomplish the request…
My preferred method to accomplish this was to create a phone home / heartbeat type of script that ran within the user’s session, initially triggered by the existing Active Directory login script.
Typically the login script runs right away, and then terminates after the contents of the script have been completed. I needed to hold onto that ability to run command(s) at a specific time later on, so I needed to keep the script “awake” long after the user had logged on. The first problem I ran into here was that the login script was visible to the users when I put a sleep task in there. We definitely didn’t want to have a little minimized CMD window showing to them. After some digging around, I found a way to get around that. There’s a little thought in my mind that there may be a better way to do the same thing, but for this first attempt, here is how I got around that…
Instead of a typical one or two file login script (two for using a batch file to call a PowerShell file), I set out to use five files (yes five, I know) to make up the login script. But there’s a good reason. Here is why each file exists…
The first two files only exist to make the traditional login script invisible to the user. The third file exists only to call PowerShell. The fourth file is the actual login script. The fifth file gives the flexibility to make changes to the actual script along the way.
Why would I want to make changes along the way? Here are a few things that I found useful…
Now, let’s revisit those request details and verify that each one is being accomplished…
The dot source file is copying the file to the workstations ahead of time, day(s) before the actual change time, and is then making the changes when needed.
On the day of, the heartbeat is set to be every 5 minutes. All the computers will be able to perform the change within 5 minutes of each other. Afterwards the heartbeat is set back up to 1 hour.
User’s that logged in day(s) earlier without logging back out again are still phoning home, ensuring a successful wallpaper change on the desired time.
PowerShell is ensuring that the timestamp of each heartbeat is being used to actually apply the wallpaper. No early previews here, except for test users!
Wallpapers are copied gradually by the different computers. On the day of the action, all the heavy lifting was already done.
This luckily worked out very well. The “bones” of the project were put up quickly, while the actual wallpaper logic in the dot sourced file was figured out (and added) later on.
This ended up to be a pretty fun and successful project, and I’m finding other uses for it afterwards. If you may find it useful let me now, or if there’s some glaring oversight and much simpler way to do the same thing also (please) let me know. :-)
The files I've uploaded related to this project are on my GitHub section, the URL being: https://github.com/gregbesso/PerpetualLogonScript
|Password Synchronization from one Active Directory Domain to another using DSInternals||194|
|Review: File Viewer Plus - The ultimate file viewer and editor!||632|
|Microsoft Intune Windows Information Protection (WIP) for Windows 10 - Part I||265|
|How to create a file-based bitlocker protector for recovery and support purposes||60|