Introduction
As an information technology intern at Sikorsky, a Lockheed Martin Company, one of my goals was to increase the efficiency of essential IT tasks. This project was not directly assigned to me by any superior and was actually self-assigned. My superiors found the solutions viable and continued to support me throughout its development and distribution.
Why Powershell?
One key time-consuming task was the onboarding process for new assets. This included the mapping of network drives, setting default printer queues, importing facility needed shortcuts, and more. These tasks required lots of manual entry and were operating system based. Automating windows with common languages would often require the installation of IDEs and the languages had to be set up in the environment variables. I needed a language that came with Windows and was efficient in automating Windows tasks. I eventually found that Powershell was more streamlined than batch scripts and were directly supported by modern Microsoft Documentation and official Windows Administration.
Project Goals
-Create a clickable solution to automate simple Windows tasks
-Distribute the solution to the entire facility
-Maintain security and integrity of Lockheed Martin assets
-(optional) create a GUI for each script to increase usability
-Document scripts to ensure proper future maintenance
Scripts and What They Automate
-Set Shortcuts and Favorites on either the desktop or User profile Favorites-Set Default Printer
-Set Time zone to local region
-Create an email that grabs hostname and ID of user to send to IT
-Display common computer info needed whenever user needed to report an issue with their assets
-Copy User's files and upload them to a cloud server as a backup
-Download the backup onto a new asset
-Count the amount of User profiles that have been made for each asset
-Enable selection of different monitor display options
-Map Common drive and other department drives
-Update an atomsvc file to current date
Visibility and Usability
Most end-users do not know anything about Powershell scripts. There are couple of things preventing its easy use as a layer of security employed by Microsoft to prevent the running of unwanted and possibly dangerous scripts. Powershell (.ps1) files do not open with Powershell by default and instead open with notepad. This means users must right click the file and run with it with Powershell instead of double clicking the file. Additionally, if the script originates outside the organization, User account control might ask if the user wants to run this file. Even further, if the user runs the script, they must confirm the execution policy. Providing all of these instructions to an end-user would reduce their desire to use the tools in the first place. The solution I found was to launch Powershell scripts from a batch script. Batch scripts can be double clicked and launched by default and have the functionality to bypass the execution policy in Powershell. Now the scripts acted just like any other file on Windows, but neither Batch nor Powershell scripts can be emailed. The solution to increasing visibility and awareness was to upload the scripts onto the newly created Sharepoint site I made, and have buttons under the IT department pointing directly to the file. Later, I improved the scripts to be in the form of a GUI so the scripts would look much less intimidating to the untrained eye.
Security
I managed to bypass all of the security measures Microsoft put in but those measures were there for a reason. Users shouldn't just trust every batch script they see. However, users will have to download the scripts in order to run them. I solved this problem by having the batch script delete itself after the Powershell window is closed. This way, users won't see batch scripts laying around in their Downloads folder. The problem hasn't been totally resolved but this means the user won't go in and edit it. Additionally, since the Batch scripts are located on Sharepoint, users will need access to the Sharepoint site to access the scripts. This means they will be trusted employees. Even further, the Batch scripts are locked for editing to administrators only. Note that the Batch scripts are only used to call the Powershell scripts, which are stored in a cloud server that a user must also have access to. If a malicious user accessed the Powershell script on the cloud server, there would be a problem, however, these scripts are locked for read only and are in a hidden folder. Only users who really know what they are doing will be able to find and edit the Powershell scripts.
Conclusion
This project is still being worked on today. Onboarding processes usually occur whenever a new employee arrives or a user receives a replacement asset. These scripts have not found an active place in their daily workflow. However, these scripts do help reduce the IT department's concerns in remembering exact print queues, links, drive names, and more. Especially in the time of this pandemic, these scripts offer real solutions that a real IT personnel would provide, all while being online and in the hands of the user alone. The development process is over but my role now is to advocate the use of these automated solutions.
