See you soon (hopefully!)

As you can see I have woefully neglected this blog. Work is so busy that I just don’t have the time to dedicate to quality blog entries.

Therefore this blog is now archived. Hopefully in the future I will revive it and be able to continue to write about applications packaging and deployment.

Darren.

Posted in Work | Comments Off

I Love Adobe

Well knock me down with a feather: Adobe have produced an excellent administration tool that is brilliant for apps packagers and sys admins.

The tool can be downloaded from here http://kb2.adobe.com/cps/837/cpsid_83709.html (click the Administrator’s Information Manager link).

Once installed (it is an Air application grrr)  it is an encyclopaedia of information for people that need to distribute Adobe Acrobat and Adobe Reader.

Like many apps packagers I use, amongst others,  http://www.appdeploy.com/ to get information on software that other packagers out there have already unearthed.  The Adobe Reader pages have had many contributors over  the years (including me), and they have many registry settings that people have set to control their installations and make them more professional (e.g. losing Acrobat.com integration, switching off auto-updates, opting out of the opt-in etc.).

But not all the settings are explained, and I ended up being guilty of bunging in registry values that I didn’t have time to fully investigate because everybody else was.

But now the new tool has a complete reference of all* the registry values that can be used to amend the installation.  Some of the information has typos, e.g. the bDisplaySplash setting should say bDisplayedSplash and LoadOnStart should be bLoadOnStart, but the information is still extensive and explains what each setting is for.

Adobe’s own packagers have also pulled their socks up – they offer the msi as a direct download now and the files are no longer in an external data1.cab file.  Let’s hope they keep that up.

And more good news!  The Adobe Customization Wizard X is actually really useful.  When I used it and installed the result, I found that it put down many of the HKCU settings on first run that I used to add-in manually.  In fact I only ended up adding two more: one for bDisplayedSplash = 0 and the second for OptIn = 0.

SO: well done so far Adobe, keep up the good work!

* all ?  Really?  Well certainly a boatload of settings!

Posted in Work | Comments Off

I Hate Adobe

Anyone who’s ever done any serious apps packaging and deployment will probably share this sentiment.  I am not going into any detail on this now: this post is mostly a comic prelude to the next post … http://blogs.it.ox.ac.uk/darrencollins/2011/06/17/i-love-adobe/

Posted in Work | Comments Off

MiKTeX 2.9 – Packaging and Deployment

Quote from http://miktex.org/about:

About MiKTeX

MiKTeX (pronounced mick-tech) is an up-to-date implementation of TeX and related programs for Windows (all current variants).

I’m afraid I don’t know how to use the software, but later on I’ll you’ll see the simple test I did to check the software was working at a basic level.

1. Download

First I downloaded the MiKTeX setup [setup-2.9.3959.exe] from here:
http://miktex.org/2.9/setup
… using the “Installing the complete MiKTeX system” link (5.51MB).

Then to download all the MiKTeX packages, I ran:

"path\to\setup-2.9.3959.exe" --download-only

(All the command line options are documented here: http://docs.miktex.org/manual/setupwiz.html)
I used the FTP ‘mirror.ox.ac.uk’ option and pointed the GUI at a folder to download ALL the files to.
The download halted a couple of times, but I just reran the command line above.  One time I thought it froze (on the ‘cm-super.tar.lzma’ package), so I hit cancel and the restarted it.  The downloader automatically picked up from where it left off.  BUT after I restarted it, that file took a really long time to download for some reason.  It is about 64MB but the length of time it took still doesn’t seem justified.

2. Unattended Installation Command

The first major milestone of any packaging is to end up with a scriptable unattended installation.  The command line I last used when I packaged version 2.7 was:

"setup-2.7.3224.exe" --local-package-repository="path\to\Packages" --unattended --package-set=complete

.

… but looking at the command line web page I think that we may need a couple more:

"setup-2.9.3959.exe" --install-from-local-repository --local-package-repository="path\to\Packages" --shared --unattended --package-set=complete

.

4. Testing MiKTeX 2.9 is working

In order to test that MiKTeX is working I needed a test file.  I downloaded and installed GhostScript and GhostView from here, http://pages.cs.wisc.edu/~ghost/, then I found a test Tex file here: http://no-paste.ch/download/code_183.txt and saved it as ‘samplefile.tex’ (although the same file is available from many sources).

I double-clicked the sample Tex file and hit the ‘play’ button on the toolbar.  Within a few seconds I had a nice PDF showing me the delights of Tex.

I should just add here that we already have working versions of GhostScript and GSView packaged in an unattended installation.  I included the above download link for completeness.

.

3. Deployment of the Unattended Installation

I now have a package folder containing the following:

packages                          <folder>
setup-2.9.3959.exe                5779.46KB      04/04/2011 12:26:09

The packages folder contains  over 2,100 files that were downloaded as a result of the ‘–download-only’ command in step (1) above.

I have an installation wrapper I wrote (General Installer) that I have used to call the setup.exe command line in (2) above and log to a central server.  This now  perfectly performs an unattended installation.

We use Altiris Deployment Server 6.9 to deploy our packages and I have a job on there that will install MiKTeX without user interaction.

One problem I’ve had is that MiKTeX 2.7 is already installed on the computers that this needs to go to.  There is not (that I could find) an unattended uninstallation for any MiKTeX installations, so for the time being I am just deleting the MiKTeX 2.7 icon group from the Start menu at the end of the MiKTeX 2.9 installation.


Posted in Work | Tagged , , , , , | Leave a comment

The General Installer (GInstaller)

I have finished the main coding of my ‘General Installer’.  Now we are applying it to live packages and it looks like it will become very useful indeed.

We refer to it as ‘GInstaller’ so that is now the name: GInstaller, short for General Installer.

Some more information on GInstaller:

What is it?

GInstaller is a deployment tool to intelligently install programs and applications with full logging.  It is a VBScript that acts on an input ini file.  It can:

  • Check if the install is required
  • Check a number of pre-install conditions against criteria specified
  • Execute a sequence of command lines acting on specific exit codes
  • Set up a user self-install icon for them to install at their convenience
  • Generate a ‘hidden’ re-install icon for IT Support staff
  • Comprehensively log each step of the installation
  • Email the log at the end to a specified email account
  • Perform simple post install tasks such as creating / deleting registry values, deleting files and folders (e.g. delete extra shortcuts installed but not desired)

GInstaller is designed to enable complex intelligent deployment of programs and applications without complex scripting knowledge (or any scripting knowledge at all!).

How is it used?

The GInstaller.vbs script and the associated, configured, GInstaller.ini file are placed into the folder with the packaged unattended installation files.

The package folder should then be deployed to the local computer using the deployment tool of choice and the GInstaller.vbs called by the deployment tool from the local folder.

General Installer use

ICTST deploy the source locally prior to installation.  There are pros and cons to this method, but we have found that for reducing problems and improving supportability, this is the best option for us.

Show me!

An example ini file can be viewed here:

http://users.ox.ac.uk/~oucs0058/res/blog_oucs/Sample_GInstaller.ini

This is not a working sample just a reference of all the options that can be used.  In practice a real example is less than half the length of this example.

GInstaller is fully documented, but at this stage I can’t release the document to everyone.  (If you work for Oxford then I can let you have a copy of the document – just email me).

As for releasing the GInstaller script itself – this is still very early days and little bugs are still popping up regularly.  In  the future I plan to release for open use.  Please contact me either by email or the comments section below if you are interested in hearing more.

Below is an outline process flow chart of the General Installer:

General Installer flowchart

General Installer flowchart

Posted in Work | Tagged , , , | 2 Comments

The ‘General Installer’ – Installation Wrapper

Now I’m working on something interesting.  It’s working title is the ‘General Installer’ script.

The script is basically a universal wrapper to install applications or anything else, but also give you the flexibility of pre-process scripting without the scripting, as well as logging and recording the exit of each install process.

Let me take an example: PDF Converter Pro version 5.  This installation is msi based from the vendor, and to install you need to:

  1. Install .NET Framework 3.5 if required
  2. Install MS Virtual C Runtime if required
  3. Install PDF Converter Pro itself

… but ideally you need to do this:

  1. Check if PDF Converter Pro 5 or newer is already installed
  2. If above is true, log it and send log to central location.  If not …
  3. Install .NET Framework 3.5
  4. Record exit code of above
  5. If .NET install failed, log it and send log to central location.  If not …
  6. Install MS Virtual C Runtime
  7. Record exit code of above
  8. If above install fail, log it and alert somehow.  If not …
  9. Install PDF Converter Pro 5
  10. Check exit code: was a restart required?
  11. Log result and send log to central repository.

Here’s another (fictional-but-based-on-fact) one: a Firefox plug-in that will only work if Firefox 3.1 or newer is installed, but will not work if Firefox 3.6 or newer is installed.  In this case we need:

  1. Check if this plug-in is already installed – log etc.
  2. Check if Firefox is installed
  3. Perform a programmatic version check if Firefox is installed that is newer than 3.1.0.0 but older than 3.6.0.0 (not as easy as you think)
  4. Install plug-in
  5. Log result etc.

All of this checking and logging can be added on into an mst transform – but that means you have to launch the installer, and wait for it to go through the checks, and then get it to abort if needs be.  Have you ever tried to get an msi installation to abort nicely and report back a friendly (custom?) exit code?  It is not possible to get it to return that sort of information to a wrapper or, for example, an Altiris DS server.  You can get nice custom messages into the event log of the computer, but as for custom meaningful exit codes, forget it.  And what if you have a non-msi based application and you don’t want or need to repackage it as an msi?

So I wrote nice wrappers.

Over the last two-and-a-half years I’ve been here, I’ve written a wrapper VBScript for every installation I’ve performed: these install the pre-requisites, do the pre- or post-scripting checks and tasks, logging, alerting, aborting and returning custom exit codes back to Altiris DS or NS.  Ok, most of the scripts are merely tweaked versions of  previous scripts, which was fine, because I was the only packager, they were my scripts and I could amend one and knock out a new one really quickly.

But now the work has increased and we have another packager.  Over the last many months he has got used to my way of doing things with tweaking and amending VBScripts for every installation.

But now there is a short term project and a couple of contractors will be packaging to our standards.  Therefore to train these guys to our way of doing this is a waste of their time and our money.

So I need a way to perform these pre- and post-tasks without amending and re-saving an actual script.  Ideally no VBScripting skills should be required at all.  That’s when I came up with the idea of the General Installer.

The General Installer is a VBScript, but a static one, that can cope with any (?) situation you need it to cope with.  And all the criteria, and logging options, and multiple pre-requisite commandlines etc. can be entered into an ini file that is read by the installer.

The ini file is very simple to understand to do simple installer tasks, like:  check if already installed, install and log.  But is necessarily quite complex if the more complex tasks are required.

For example: An application has .NET Framework as a pre-requisite, but a hotfix to install after the main install.  So I need to ensure that each part is successful but ideally I want the main app install exit code to be reported back to Altiris, not the hotfix one – the main install might return 3010 (restart required) but the hotfix then returns 0.  I want to see the 3010.

Therefore I made it possible for within the General Installer ini file to choose which install commandline out of many to use as the ‘Master Process Return’ code.

This is still a work in progress and I hope to elucidate further as I go on.

Posted in Work | Tagged , , , , , , | 2 Comments

Automate IP printer port and driver install

I’ve just had a nice little scripting challenge to solve:

ICTST have all moved recently to nice offices off of the High Street.  We have a nice new printer here and no print server, so we needed to automate the installation of a local printer IP port and the driver for the printer.

After a bit of testing I came up with the following method.  I’ve used WMI to create a local IP port and then used PrintUI.dll to deliver the driver and setup the printer on the new IP port.  I could have used various WMI queries to do all of it, but I like the fact that PrintUI.dll was created for just this purpose and it does it very well indeed.

As I’ve scripted it below, the script needs to be in the same folder as the driver including the .inf file.  It has been tested on Windows XP SP3 only so far.

The script also outputs a message box if it finds a printer already on the IP address port specified.

I’ve generalised some of the details:

Set wshShell = CreateObject("WScript.Shell")
strCurrDir = Replace(WScript.ScriptFullName, WScript.ScriptName, "")
strIPAddress = "111.1.222.333"
strComputer = "."
strPrinterName = "RICOH MFP Office 2nd Floor"  '## Can be any text you want, this shows print dialogs.
strDriverName = "RICOH Aficio MP C3300 PCL 6"  '## MUST be the exact text as in the printer driver .inf file.
strLocation = "New Office 2nd Floor"           '## Can be anything
strInfFile = strCurrDir & "OEMSETUP.INF"       '## the full path to the printer driver .inf file.  In my example the VBScript was in the same folder as the driver & inf file.

Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colPrinters = objWMIService.ExecQuery("Select * From Win32_Printer Where PortName = 'IP_" & strIPAddress & "' ")
For Each objPrinter in colPrinters
    MsgBox "Unable to install printer, printer already found on port 'IP_" & strIPAddress & "'." & VbCrlf & VbCrlf & "Found:  " & objPrinter.DeviceID, vbExclamation + vbSystemModal, "Printer Port already assigned"
    WSCript.Quit 114001
Next

Set objNewPort = objWMIService.Get("Win32_TCPIPPrinterPort").SpawnInstance_
objNewPort.Name = "IP_" & strIPAddress
objNewPort.Protocol = 1
objNewPort.HostAddress = strIPAddress
objNewPort.PortNumber = "9100"
objNewPort.SNMPEnabled = False
objNewPort.Put_

wshShell.Run "rundll32 printui.dll,PrintUIEntry /if /b """ & strPrinterName & """ /f """ & strInfFile & """ /r ""IP_" & strIPAddress & """ /m """ & strDriverName & """", 1, True

Set colPrinters = objWMIService.ExecQuery("Select * From Win32_Printer Where DeviceID = '" & strPrinterName & "' ")
For Each objPrinter in colPrinters
    objPrinter.Location = strLocation
    objPrinter.Put_
Next
WScript.Quit 0
Posted in Work | Tagged , , , , | 2 Comments

Sophos Anti-virus upgrade to Endpoint 9.5

I am currently deploying, to a schedule, a Sophos Endpoint upgrade to ICTST managed computers using Altiris Notification Server.

The installation has already deployed to OUCS computers managed by ICTST, so far with no failures and no negative reports.

Today I started piloting it on ICTST managed computers in Libraries and OUED (Estates).  I think it should be Ok but the install is not completely silent: annoyingly there are a couple of windows that pop up briefly towards the end, but they don’t take focus off of the user’s active window.

More information:

1. New Upgrade

From the end of November 2010, ICTST will be deploying a new version of the Sophos Anti-Virus client. The current version 7 will very soon be end of life and the Sophos support for it will end on 31st March 2011.

The new Sophos anti-virus client used by the ICT Support Team to protect their managed Windows computers is called “Sophos Endpoint Security and Control, version 9.5”, or simply “Endpoint 9.5”.

2. Roll-out to Windows computers managed by the ICT Support Team

During the roll-out the installation is mostly silent, but some small progress windows will flash up briefly during update activity towards the end.

The whole installation should be finished in around 10 minutes.

Depending on the configuration of your computer you will see some or all of the following icons and notifications during and after the installation and auto-update processes. It is important that if the “Your computer might be at risk” message / icon is not cleared automatically within a few minutes that you log an Incident with the helpdesk at itsupport@ict.ox.ac.uk

3. Errors

If any errors are encountered during the upgrade, or if the shield icon is not visible at all after about 15 minutes, please take a screenshot of any errors and log an incident with the helpdesk at itsupport@ict.ox.ac.uk.

Posted in Work | Tagged , , , , | Comments Off

OUCS Help Centre PCs Image

Currently I’m working on a new image for the OUCS Help Centre PCs.  Each year the Lecture room images in OUCS are updated, and a couple of months later the Help Centre ones are too: the image is very closely based on the Lecture room one.

The process, very roughly is:

1.  Using Altiris DS, create a folder containing all the updates and software that is to be included in the main image that will be delivered to every computer.  Therefore nothing that has unique GUIDs, or per unique per-computer settings, like the KeyServer client and WSUS ID (although actually I do setup the WSUS and run the Updates from a script before the image is taken, I do re-generate a unique WSUS ID afterwards) .  Also Anti-Virus is not stored in the main image, because major engine updates can cause problems to an image that is re-delivered in the future.

2.  Deliver a scripted XP install to an example of the Help Centre hardware.  Follow this with all the software collated in [1] above.

3.  Reduce the newly created main disk partition by 51GB (I use GParted), then use the Altiris hidden partition creator to create a 50GB partition and install WinPE 2 bootworks into it.

4.  Sysprep and take an image of the disk, ensuring that Slots 1 & 2 are both included in the image – the default image upload will only take the first partition into the image.

5.  Create a folder in Altiris DS containing the job to deliver the new main image, then deliver per machine or post image components, including Anti-Virus.  The next job in this folder is to automatically upload an image using the bootworks partition to the hidden partition.  This makes rebuilding the computers a doddle and means minimum network usage required when rebuilding.  The last jobs in this folder are post build tasks, such as updating Adobe Reader / plug-ins etc, updating AV, WSUS settings, any other post build automated tasks.  The tasks at the end will grow throughout the year as more things are required, but some of them will be assimilated into the main build the following year, as some will be this year from last year.

6.  At this stage the new folder of jobs can be delivered to all the Help Centre computers.

7.  A new set of jobs will be created as well that will just tell the bootworks partition to deliver the hidden image back to the main partition, then deliver the same extra jobs added to the end of the delivery at [5] above.

Blimey it sounds simple when you say it quick, but each build and image stage test [2], [3] and [4] above, can take nearly a whole day per attempt, so forgetting to include that little thing can cost a whole days effort.  This is another reason why there is the opportunity to add jobs to the build delivery at the later stages.

That’s me busy for the next week or so!

Darren.

Posted in Work | Tagged , , , , , | Leave a comment

Hello world!

Hi, the intention of this blog is to brain-dump things to do with my role in the University, which is mainly providing apps packaging and deployment services to OUCS, Libraries and UAS.

Hope to speak again soon!

Darren.

Posted in Play, Work | Leave a comment