Having been in the IT industry for over 20 years, I’ve seen a lot of the everyday issues that many other IT professionals are faced with. Over the course of my career, I’ve been tasked with many mundane tasks, as well as some challenging ones. Enter automation. Automation can be used for a number of different tasks like running everyday reports, health checks, and even easing the pain of domain migrations. One of the first major tasks where I used automation was to convert permissions from a Novell volume to a Windows share for migration purposes. At the time of this migration, I wasn’t lucky enough to have third-party tools that would automatically handle the migration aspect of this. For this task, I introduced a Linux server on which I wrote a Linux shell script that would convert the Novell permissions to Windows share permissions. The Novell permissions file was generated using an already owned 3rd party utility called JRB Utilities (http://www.jrbsoftware.com/). The Linux script would read in the file and parse it line by line, and output the new respective permissions for each line for the Windows share in a format using the Microsoft XCACLS command. The resulting file would be in a .txt format, which I would then copy over to the Windows server, rename the file to a .bat file, and execute it on the new Windows server to apply the permissions to the data which was copied using the xcopy command. The end result was that writing a script to automate the translation of the file permissions resulted in being able to migrate the data from Novell to Windows ahead of schedule, and at no additional cost to the company. Now, with that being said, and having the experience of using other third-party migration tools since then, yes, it got the job done, but in my experience, the third-party migration tools are worth the investment. At another job, the team that I was a member of had the task of running a daily health report. This task rotated on a weekly basis between all of the team members, and would take approximately 1 hour to login to each Novell server’s portal and verify the health. This of course left us with the ability to say that everything was fine at the time we checked, but not having any evidence to prove it. At this time, I had already been dabbling with an automation utility called AutoIt, and had the idea to use it to automate the task of running these daily reports. Using AutoIt, I was able to create a script that would prompt the user for credentials, and then using a list of the servers, login to each server and grab a copy of the HTML page reporting that server’s health. The script then would parse each individual server’s page, and combine the information into a single HTML file, and highlight in red any areas that were of concern. The end result was that this task that would normally take 1 hour for person to run, could be ran in 15 minutes or less, and would produce individual health check files for each server, as well as a summary report, that could be referred to if needed. Most recently, I’ve been tasked with doing multiple domain consolidations for a customer using the Quest Migration Manager for Active Directory (QMMAD) utility. The QMMAD utility has the advantage of being able to search through the target Active Directory and automatically match users based on 3 pieces of criteria–account name, email, & SID history. In this case, the customer had already populated the target active directory with user accounts for the purpose of email; however, they did not wish to take the chance of having QMMAD automatically identify the “best” match for the user based on the criteria above, as we already knew that most accounts would not match up based on it. This created a challenge of trying to figure out a way to match the source user objects to their respective target user objects. To solve this challenge, I used a PowerShell script to generate a list of enabled users, and a list of all groups for the source domain, and a list of all users, and a list of all groups for the target domain. I then imported each of these 4 files into an Access Database, each residing in their own table, and then created a query to match accounts based on SamAccountName or Name attributes. This often yielded a result of approximately a 70 – 80% match. For the account where there was no match, it was often the result of a service account in the source domain, or a person who had gotten married, and their last names were different in both domains. This resulted in an exportable report of the match objects that I could then send off to the administrator of the source domain for validation, and to get the other account information populated. And, because this customer had multiple domains to migrate into the target domain, it was something that could be re-produced for each migration with minimal effort.