Distributing Adobe Acrobat 9.x updates in an enterprise

I will save you my Adobe hate rant, but if you ever look at my twitter its well documented I am not a fan of the Adobe update model. It's slow, updates need to be run consecutively and it uses lots of CPU cycles and bandwidth.

I am sure administrators that are pushed for time just ignore Acrobat updates, after all, end-users will never notice the benefits of security patches, right? I prefer to play it safe and try to stay best practice where possible, I have chosen a simple Kixtart script to manage the update process.


The script explained

The code is very simple, providing a step-by-step update from 9.0.0 right up to version 9.5.3, the current version in the 9.x stream as of the time this article was written.

At very least you need to set the $repopath variable to a network location your user/computer accounts can access. You also must populate all the Acrobat .msp updates into the $repopath.

I am using a SCCM "Whether or not a user is logged on" deployment, this means the SYSTEM account is used to during the installation, resultantly I permission-ed my update repository to allow the "Domain Computer" group read access. I decided on installing from network as opposed to downloading all the updates local due to sheer size. The repo is 1.5gb and some computers may only need 100 MB of updates, adding an un-required load onto the network.

I won't paste the whole script here, but below is an example of the update process I am using. It checks the version, installs the next update inline, then checks the version again, repeat, repeat.

Install Update, Check Version
  if ($ver = "9.1.0")
    gosub installAcro911
    gosub acroVerCheck
  endif

Example update install
:installAcro911  ? "Installing Acrobat 9.1.1 upgrade"  SHELL '%comspec% /c msiexec /p "$repopath\AcrobatUpd911_all_incr.msp" /qn /norestart REINSTALL=ALL REINSTALLMODE=omus'  Copy ("generic.tch") ("$touchpath\adobeupgrade911.tch") /H  ? "Acrobat 9.1.1 upgrade complete"return

In the above code I use a "copy generic.tch" command, this is just an empty file I copy to the local file system, it allows me to quickly check the current the update level of Acrobat 9.x, you can remove this step if you wish.

I'm using the "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" registry key to check for the current version. I tried reading versions from files in the Acrobat folder and checking the Acrobat registry key but both were unreliable.

The script is available here from my github enjoy!

How to upgrade SCCM 2007 clients to SCCM 2012

You would think upgrading from SCCM 2007 to 2012 would be a relatively easy task, but I've found it a mammoth process. Not only is there no way to "upgrade" to server itself, there is also no clean way to upgrade the clients directly from 2007 to 2012. I am not a big fan of the SCCM client "push" technique, so below is a process that is working for me.

I have put together the following kixtart/batch script combination to uninstall 2007 and then install 2012 in my environment. This might not work for everyone, but I use a combination of computer startup/login scripts and SCCM to carry out maintenance tasks in my environment.



The pre-launch script

Firstly I am calling the main batch script from my kixtart computer startup script. This could all be done in kixtart, but I want this to happen in the background. If I were to use commands like "start /wait" (which I use to ensure the SCCM 2007 client is installed before the 2012 install begins) within the kixtart script itself, this would make computer startup process take way too long.

;spawn SCCM client upgrade into background
IF (EXIST ("c:\windows\system32\ccm\") AND EXIST ("c:\windows\ccm\AAProv.dll")=0)
  SHELL "%comspec% /c start contoso/local\software\sccmclient2012\sccmupgrade.cmd"
endif

The above script simply checks that the SCCM 2007 folder "c:\windows\system32\ccm\" exists on the system and that a SCCM 2012 file "c:\windows\ccm\AAProv.dll" is not installed. It then launches the main upgrade script. You could use any file, I just picked AAProv.dll as it was one of the first files I saw in the directory.



The upgrade batch script

1. Create a new folder and copy the SCCM 2012 client and ccmclean.exe. CCMCLEAN has been floating around since SMS 2003 and while not officially supported, still works well to irradicate unwated SCCM 2007 client installs.

2. Create an empty batch script and enter the following. Obviously you need to replace the consolo.local lines with the relavent paths and MP fqdn in your environment.

REM ensure 2007 is installed properly (can prevent uninstall)
start /wait %windir%\system32\ccmsetup\ccmsetup.exe /logon

REM uninstall sccm 2007
start /wait %windir%\system32\ccmsetup\ccmsetup.exe /uninstall

REM ccm clean
start /wait \\contoso.local\software\sccmclient2012\ccmclean.exe /all /q

REM 2012 client install
if not exist "c:\windows\ccm\AAprov.dll" (
  if not exist "c:\windows\system32\ccm\core\bin\clicore.exe" (
    \\contoso.local\software\sccmclient2012\ccmsetup.exe /service SMSSITECODE=SDC SMSCACHESIZE=6144 SMSMP=mpfqdn.contoso.local /UsePKICert
  )
)

REM clean exit
exit 0

The above script works as follows. First I run an INSTALL (yes an install, not uninstall) of the 2007 client with the /logon flag, this will ensure that the 2007 client is installed properly, as an improper install can cause the uninstall to fail.

Next I attempt to do a clean uninstall with the native SCCM /uninstall command, this often fails, so it is followed up with the CCMCLEAN /all command which will remove anything that the native installer misses.

After the uninstall of the 2007 client, two checks are run to ensure the 2007 client is uninstalled and the 2012 client isn't already installed. Then the 2012 client is installed. I use "start /wait" commands to ensure the uninstall steps occur before the 2012 install starts.

I have used this script on a mixed environment of Windows XP SP3 32bit and Windows 7 SP1 32bit with no problems, 99.9% of clients uninstalled and upgraded clean.

This entire process probably won't suit your environment, but hopefully you can take some ideas and apply them to your deployment techniques.

How to silently install Microsoft Mathematics 4.0

The installation options of Microsoft Maths 4.0 are very unusual. Its seemingly designed for use in schools yet it doesn't have the ability to be silent installed. The only option for network admins is a Citrix Xendesktop or Microsoft App-V style deployment.

Through trial, error and research I was able to find a set of silent installation commands that work.



The Process

1. Download Microsoft Math 4.0 x86 from here >> http://www.microsoft.com/en-au/download/details.aspx?id=15702

2. Extract the contents of MSetup_x86.exe to a folder. This can be easily done with winrar

3. Create an install.cmd with notepad++ or your favourite text editor

4. Into your install.cmd add the below deployment commands.

start /wait msiexec /i MSMath_x86.msi FROMSETUP=1 ALREADYRUNNING=0 DOTNET35=1 SKIPDXINSTALL=0 SXSOFF=0 D3DOFF=0 /qn

regedit /s eula.reg

exit 0

These commands are a combination of silent install, tricking the MSI into thinking its running from setup.exe and a selection of other options. I also apply a eula.reg (as seen below) that accepts the EULA and prevents it from popping up to the end user.

You may be able to further optimize the silent install string, but the above string works perfectly from my experience.

5. Save install.cmd

6. Paste the below text into a new file named eula.reg and save it into the same folder

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Mathematics\Standalone\4.0]
"MsltAccepted"=dword:00000001

 7. Create your package and program with SCCM (or your favourite deployment technique) and trigger install.cmd


The most important part of this article are the silent install strings for MSMath_x86.msi, the other deployment options are up to you. This took me a while to find a solution to and it seems by a quick google search that many other administrators are in the same boat.

Enterprise deployment of the Adobe Photoshop CS6 6.0.1 security update - CVE-2012-4170

There is no denying Adobe probably have the most convoluted enterprise processes in the industry but luckily the latest CS 6.0.1 security update deployment isn't too bad at all, if you know where to look that is.

The official Adobe blog post simply mentions going to Help > Update from within Photoshop, which is OK for updating a single client but doesn't suffice for enterprise upgrades.

This update probably isn't blog worthy, but I had trouble finding both the update itself and the silent install strings for the update, so I thought it might save someone else a few minutes.



Obtaining the update

The Adobe blog post doesn't mention the update can be downloaded in a redistributable format from the Adobe support downloads page - available here http://www.adobe.com/support/downloads/new.jsp

The above address is the location for all the latest Adobe network deployable updates/security fixes. You can also grab the Photoshop CS6 6.0.1 update for Windows directly from here http://www.adobe.com/support/downloads/detail.jsp?ftpID=5408



Silently installing the update

Again this is REALLY easy, but I saw a number of syntax errors on other blogs that complicated things.

1. Extract the Update zip file.

2. Create a install.cmd with the following text inside

start /wait AdobePatchInstaller.exe --mode=silent

Please note the "--mode=silent" has a small s, a capital S will cause this process to fail.


3. This next line is totally up to you, but I also deploy a blank file to the file system. This file allows me to easily evaluate the patch version of Photoshop when deploying future updates.

copy /Y adobecs6_13_0_1.tch c:\windows\deployment\adobecs6_13_0_1.tch

Your done! You can now deploy the install.cmd with SCCM or your favourite deployment tools. Hopefully these simple tips/references save you a few minutes.

Microsoft Research Worldwide Telescope deployment and custom proxy settings

Microsoft Research really have done a great job of creating an amazing research and educational tool in Microsoft Research Worldwide Telescope  (WWT), but where they have fallen down is the network installation and settings deployment for this application. Regardless of deployment deficiencies, staff see this as a "must have" for their classrooms, so we need to find a way to make it work.

Unfortunately while WWT is available in a MSI format, you have to jump through a number of hoops to get it to deploy successfully via SCCM or computer startup scripts. Not to mention that it doesn't "ask" internet explorer for the system proxy settings, it just does its own thing, so proxy settings also need to be specified in deployment process.




The Process

1. Create a folder for your SCCM package named "microsoft_worldwide_telescope_Penumbra"
and create another folder named "WWT" inside it.

2. Extract the contents of the WWT installer into the WWT folder you just created.



3. Next we need to do some modifications to the WWTExplorer.exe.config file, this is where all the proxy and banner suppression magic happens. If you want to change the proxy settings, change the below values.

            <setting name="ProxyServer" serializeAs="String">
                <value>YOURPROXYHERE</value>
            </setting>
            <setting name="ProxyPort" serializeAs="String">
                <value>8080</value>
            </setting>

and setting the following two settings will ensure no upgrade or banner messages appear when you start the program.

            <setting name="ShowNavHelp" serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="UpgradeNeeded" serializeAs="String">
                <value>False</value>
            </setting>

You can just copy and paste the above sections over the top of the corresponding sections of your WWTExplorer.exe.config file.


4. Next we will create our installation batch file, go back to the "microsoft_worldwide_telescope_Penumbra" directory and create a file called "install.cmd", into that file put the following code.

xcopy /Y /E WWT c:\windows\WWT\
start /wait msiexec /x c:\windows\WWT\WWTSetupPenumbra.msi /quiet
start /wait c:\windows\WWT\dxsetup.exe /silent
start /wait msiexec /i c:\windows\WWT\install.msi /quiet /norestart

This will first uninstall any previous installation you might have (that might have a bad configuration), then install Direct X 11 and finally installs WWT itself. You might wonder why I am copying the installation folder to the local file system before I install it, good question! Every time a different user launches WWT, it calls upon the original MSI and briefly reruns the MSI install (the user doesn't need administrative privileges to do this). This means if you deploy the package from a network location it will fail to launch if the end user doesn't have access to that same network location and original MSI. You could (if you have an SCCM environment in place) use the SCCM package "Windows Installer" functionality.

If you already have DirectX 9.0C installed (which  my Windows 7 clients didn't), you can simply remove the dxsetup.exe line from the installation.

5. Stick all that in a SCCM package, running install.cmd as the program and advertise it to the appropriate machines. There is no reason you couldn't deploy it with a group policy based computer start-up script either.



Network Based Cache Location Issues

Unfortunately you can't successfully change the cache location (funnily called the cahce location in the configuration file) to a shared network location, which is a shame as it could significantly increase content access speeds and lower bandwidth usage.

If multiple users are viewing the same "already downloaded" content it works flawlessly, but when multiple users try to download the same content at the same time both instances of the program fail and throw error messages.

The only situation where this could work is if you pre-download ALL of the WWT content to ensure no user is ever downloading to this shared location. I have instead opted to leave the cache location as default, which is %userprofile%\AppData\Local\Microsoft\WorldWideTelescope" to avoid any potential drama.