Working with Limitations

The Limitations

  • No policy-driven deployment method at the time.
  • Management wants to keep it simple, “We ARE NOT a development shop.”
  • Do NOT use programming language so unskilled administrators can update code, use a scripting language only.
  • Must be windows based.

Scope of project

  • Find a way to install and configure the application.

Additional Analysis

  • Batch files are not secure and allow editing, Compiled code is more secure.
  • Administration does not always understand coding

Solution

  • Use freeware software scripting language, AutoIt.
    • AutoIt

      AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages.
  • Management accepted this “Scripting” tool.
  • AutoIt is very robust and can perform many if not all required functions to automate the installation and configurations.

Working with the vendor’s installation….

The assignment was a simple statement, “Working with the vendor’s installation, find a way to install the application.” At the time, we did not have the infrastructure in place using an application deployment method such as SCCM (System Center Configuration Manager). The installation was not too difficult to do, but the configuration required hands-on administration with each installation. This meant a lot of FTE’s to roll out the initial installation and configuration of the applications. Not an acceptable means for “Total Cost of Ownership” (TCO). Some analysis went into installing a centralized system such as SCCM, but this was not a budgeted expense at the time.

We had to use freeware or native windows scripting.

I knew that with the simple statement of Scope that there would definitely be “Scope Creep”, or at a minimum, additional requests to add more functionality and I would not be able to accomplish this task without some programming. Researching and finding something without cost, and acceptable to management, to perform the task was the next step.

During the research, I looked into and used some of the following software: InstallShield, WinInstaller, Admin Studio, AutoIt. Even though management did not want us to be a development shop, per se, I was able to demonstrate with AutoIt the benefits and simplicity of using this software. AutoIt allowed me to use simple code that management could understand and comes with full documentation for the software, allowing other administrators to learn and use it. AutoIt also allowed me to compile the script in order to make it more secure from end-user modifications. Although I started with a simple demonstration of installation with AutoIt, over the years it became more of a program than a script.

We started with a simple capture of the application using an MSI building software to create an MSI with the configurations required to connect to the database and application servers. This helped to minimise the needed configuration on each workstation. Not a bad compromise at the time, but when we began to require assistance from the application vendor, we always got the company line, “If you did not install the application with our install program, we can’t help you. Please install our application on a clean workstation using our install program.” You can see this causes a dilemma. If I install the program on a clean workstation, and it works, I will never find the conflicts it is having with other applications. But I conceded and began installing the software using the vendor’s installation media, then using AutoIt, I would program the configurations, post-installation, and began to get the support needed from the vendor.

“If you did not install the application with our install program, we can’t help you. Please install our application on a clean workstation using our install program.” 

You can see this causes a dilemma. If I install the program on a clean workstation, and it works, I will never find the conflicts it is having with other applications. But I conceded and began installing the software using the vendor’s installation media, then using AutoIt, I would program the configurations, post-installation, and began to get the support needed from the vendor.

To install the application without user intervention I used the code below.

Global $Software_Install = 'setup.msi'
Global $Application_Directory = $Application_Vendor & '\' & $Application_Name
Global $Software_Install_Directory = $NT_Server_Share & '\' & $Application_Directory & '\' & $Application_Version
Func __Vendor_MSI_Install ()
	SplashOff()
	RunWait('MsiExec.exe /I ' & $Software_Install_Directory & '\' & $Software_Install' /qb!')
EndFunc

I will continue with the “Network setup for the application installation” in my next blog.

Thank you for reading.

Process Flow

I would like to begin with the fact that technology is always changing rapidly and I may not always be up to the latest with acronyms and the latest buzzwords in the industry.

I just want to begin blogging about some of my experiences, so I pulled out an old production program that I wrote and thought I may shed some light on how I came about using it to keep third party software running on desktops that had conflicting configurations. These conflicts did not allow the programs to run smoothly together, but I found a way.

The programs would sometimes use outdated dll files to display information. The dlls would conflict with the security updates that were installed on the workstations but the fact remained that the programs were integral systems that were necessary for the business. Put simply, they could not be replaced. They were the backbone of day to day operations. Other than the dll’s that caused conflict, there was the process of installation and configuration that needed to be considered. Along with the life cycle of the applications also came the upgrades, changes and how to control the ability of the users to connect with the systems.

I will be dissecting my application in further articles for anyone that would like to follow along, but In the end, It all comes down to process flow…

1. Identify the scope of the process(s).
2. Dissect the scope into manageable pieces.
3. Create functions for each so modifications are easier to make.
4. Test, Test, Test
5. Present to management.
6. Place into production.
7. Monitor Service Desk tickets for the application.
8. Make improvements if needed.
9. Repeat steps 5-6-7-8, and continue the dance.