A developer's thoughts, stories and ideas

Built-in Languages?

The last built-in language I used for scripting in Windows 10 was batch. I never used it past a few shallow gimmicks such as playing pranks with friends (fun with those notepad typing scripts). PowerShell is completely different. It's certainly a powerful shell. The range of it's power in automation practically makes it the best language to use for Windows 10. There are other languages like Python that can just as easily build similar and more powerful automation, but for my use case, PowerShell was easiest and fastest. As someone who works in IT, there are a lot of repetitions. Especially in the case of setting up the equipment for the employees. It doesn't take long to go through the checklist on software that needs to be installed and the settings that need to be configured. However, the time adds up when there are a lot of devices to set up. As a result, I've created and am currently working on a PowerShell script that automates a large part of this process.

The Idea

The goal for me, with using PowerShell, is to create an automation that can completely set up the devices without much interaction from the technician. It shouldn't require a keyboard, mouse, or monitor to set up the computer. This is actually quite possible to do. The first step is to set up the Windows OOBE (Out of box experience) automatically. At first, I thought this would be difficult. After all, unattended installations usually start from a completely new installation of Windows and carries on to the setup process afterwards. However, after some searching, I found a solution which was to use Sysprep to activate an answers file that can complete the OOBE process automatically. This required the generation of the answers file as well as a provision package. According to what I've read, the provision package will activate upon the initial setup of the Windows setup. This provision package will call upon the script that starts Sysprep to begin the answering process. I have yet to fully test this setup process. However, from my very limited testing of probably 2 times, it does work kinda. Anyways, the next part was to have it automatically run the powershell script on the first logon. This is easy. However, this causes another issue to pop up, literally. UAC is left on, which interrupts the script that require administrative privileges. Looking for a UAC bypass, it turns out that it isn't too difficult to bypass UAC. As long as the user is administrator (obviously the first account to log on will my local admin account), I can do something similar to a sudo. This works perfectly, so another hurdle is complete.

How It's Done

Now onto the script itself. It does a few things that aren't special or unique. For example, renaming the computer, joining the computer to the domain, adding the device user to the administrative group, and silently installing software (Office and other stuff). There are also a few fun things I added to help with installing specific software, such as detecting laptop vs desktop (our desktops don't have batteries right, just gotta check for that Windows flyout thing). However, there's a problem here. How does the script know who the user is and how will it know the credentials required for domain access? If it's supposed to be automated, the technician will not see any prompts for this info and neither will they be expecting it. So, I have a solution that will be implemented very soon. For credentials, since this entire automation is meant to be hosted on a USB stick, we can just encrypt the credentials and store it on the USB. Powershell has ways to store the credentials so that only the user account of the specific computer can decrypt it, yet also use it within the script. That's good enough for me. Next problem is to figure out who the user is. I could have the technician write it down in a file somewhere, but that'd require plugging in the USB. I could have the script check on a file server, but would still require that extra effort to update the file. But how about the inventory system? Practically all IT departments have something like that, which we do. It's something that's required of technicians, so it's not extra work. All that has to be done is to have the script check with the inventory system. Easy right? Except that I don't know of an API for the system. However, I'm a programmer who has had experience with headless browser automation. That can solve the issue of navigating this inventory system. Powershell has the ability to send REST API requests, I could put up a server for these requests to be processed and have the headless browser match the required info. Almost there, except how would the script tell the server what user should be set for the device? Well turns out there's a way to check the serial number of the device, which can be matched to the inventory system to find out the user. That's the end of that... once I implement it. I've outlined the entire automation that I've come up with. However, I've still yet to add the REST server, headless browsing, and credentials support. I'm sure I can complete it within a day or 2, but testing might make it take longer. Luckily, I've got a Windows snapshot ready to go for testing the full extent of the script.

Automation might not be the same as software/website programming, but it's certainly refreshing after only doing support work!

You’ve successfully subscribed to Jason's Blog
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Success! Your email is updated.
Your link has expired
Success! Check your email for magic link to sign-in.