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.

Deploying custom Microsoft Word 2010 registry settings at logon

In december I added a blog post entited "Deploying custom Microsoft Word 2007 registry settings at logon" in which I detailed how to select, export and apply custom advanced settings for Word 2007. Since then I have moved to Office 2010 in my enviroment and to my surprise the process has changed, there are a few more steps involved in the process.



I am applying my exported settings but they arn't working

You not alone, it took me a while to work out what was going on here.

In Word 2007 the process was to open Word, set the custom advanced settings you wanted (such as picture in front of text), close word, jump into the registry and export the [HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Data\Settings] value. Then you could subsequently import it during the logon process with a logon script.

The first part of the process remains the same, but  began havinb problems when I applied the .reg file during logon. When I opened Word the settings were not applied, yet if I re-ran the patch it worked, the settings applied perfectly.

After 15 minutes of chasing my tail, I finally realized that the issue was Word needed to be started before the .reg file could be applied. This is caused by Word writing a number of registry values (and overriding the above value) when it starts for the first time per user account. So if you apply the settings before Word is launched they are resultantly wiped on the first launch.

The Resolution

The fix is quite easy, but it did take some messing around with settings combinations to work out which settings I needed and which I didn't. Obviously I don't want to export the whole Office 2010 HKCU  key as there is some imformation regarding licensing, user names, etc, that I don't want to apply to every account.

The following base settings need to be applied, they stop Word from overriding your customizations.

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\General]

"ShownOptIn"=dword:00000001

"FirstRunTime"=dword:0151d1bc

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Migration]

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Migration\Office]

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Migration\Word]

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Options]

"FirstRun"=dword:00000000

"BkgrndPag"=dword:00000001

"ATUserAdded"=dword:00000001

Furthermore to the above base settings you need you apply your customizations. For example, if you wanted to apply word advanced options such as "insert/paste picture as: in front of text", you would create a .reg file with both the above settings AND the exported [HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Data\Settings] key.

For "insert/paste picture as: in front of text" option you also need the following value.

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Options]

"InsertFloating"=dword:00000001

Then you can safely apply that .reg file using a logon script and regardless if a user has started Word 2010 before or not, the settings will be applied

Certain advanced settings have additional registry values that also need applying, such as the "insert/paste picture as: in front of text" example above. If you have other settings you want to apply that arn't working when you export [HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Data\Settings] I would recommend getting regshot and comparing before and after snapshots of the "HKCU\Software\Microsoft\Office\14.0 key or using a tool like procmon for live registry monitoring.

Deploying Adobe Premiere Elements 10 in a network environment

Adobe Premiere is an essential tool in an educational environment, especially one with a huge recent spike in video usage like ours. I was recently lucky enough to receive a number of Adobe Premiere Elements 10 (PE10) licenses to deploy throughout my network.

I know Adobe products are always horrible to deploy, but PE10 takes something bad to a whole new level.



The Problem

Unfortunately PE10 seems to have a serious incomparability with network based profile directories, like the ones most schools would be using. The product installs without issue, but when you get to the "New Project" screen the "Save In:" field is blank. Once you click "browse" to find a path to save your project, PE10 complains of a serious error and then crashes.

The exact error message is "Sorry, a serious error has occured that requires Adobe Premiere Elements to shut down. We will attempt to save your current project."

If I login to a local account (with no network based profile, obviously) everything works perfectly.

As per this thread it seems Adobe's official position is that PE10 is designed to be used locally and running it in a network environment is unsupported. This is once again a failure by Adobe in the deployment space, it seems they just can't understand we just want to "install.exe /s" their products, what is so hard about that? I don't want to learn a whole new language to deploy a product and then have to put together dodgy fixes to get it working. OK, rant over!



The Solution

There are a few parts to this solution but the core of the fix revolves around a file called "Adobe Premiere Elements Prefs" that sits in "%appdata%\Adobe\Premiere Elements\10.0". This file contains a number of user based preferences, including the paths.

The specific line in the configuration we want to set is as below. This is the line that's populated in the "Save in:" box that is giving us all the problems.

<BE.Prefs.MRU.Document.0></BE.Prefs.MRU.Document.0>

Instead of creating this file by hand we are going to do a little bit of Adobe hacking.

1. Log into a computer with PE10 installed as a local administrator.

2. Create a local folder, ensure all users have permission to read/write. I have created a folder called c:\pe10scratch and given the "Users" group permissions to this folder.

3. Launch PE10.

4. Save your "New Project" in the c:\pe10scatch folder. (You must do this)

5. It is also a good idea to go to change the paths of all scratch disks to local disks. If network paths are used this can mean massive amounts of data moving across the network and slow performance for the user. Once in PE10 select the "Edit" menu, select "Preferences" and select "scratch disks". Set a local path for all of the available option.

6. Close PE10.

Now we need to grab the "%appdata%\Adobe\Premiere Elements\10.0\Adobe Premiere Elements Prefs" file and all of the files in the c:\pe10scratch folder (or whatever you may have called it).

At this point you may also like to grab some of the registry settings from "HKEY_CURRENT_USER\Software\Adobe". Some of the interesting ones that might save your users time are:

[HKEY_CURRENT_USER\Software\Adobe\Elements Organizer\10.0]

"Locale"=

[HKEY_CURRENT_USER\Software\Adobe\Premiere Elements\10.0]

"Language"="

"ShowDriverUpdateMsg"=

"DriverUpdateMsgCount"=

[HKEY_CURRENT_USER\Software\Adobe\Premiere Elements\10.0\WelcomeScreen]
"QuickLaunchApp"=

"LaunchCount"=

 [HKEY_CURRENT_USER\Software\Adobe\CommonFiles\Usage\Elements10]
"OptIn"=

"Date"=

These specific registry settings and possibly some others, can be deployed on login to ensure your users don't see annoying "feedback program" and "your VGA driver isn't up to date" type messages when launching the program.



User Based Settings Deployment

Now that you have your registry settings, preferences and the empty project we need to deploy them somehow.

For the registry settings and the preferences file I am using my existing kixtart based login script. A simple script as below will do the job. The following script deploys the HKCU registry changes and the preferences file if PE10 is installed on the machine.

;setup premiere elements 10
if (exist("%programfiles%\Adobe\Adobe Premiere Elements 10")) and (exist("%appdata%\premel10.tch")=0)
  SHELL "regedit /s $logonpath\registry\premel10\premel10.reg"
  SHELL '%COMSPEC% /C xcopy "$logonpath\registry\premel10\Adobe Premiere Elements Prefs" "%appdata%\Adobe\Premiere Elements\10.0\" /E /Y /C'
  Copy ("$logonpath\generic.tch") ("%appdata%\premel10.tch") /H
endif

That is one piece of the puzzle, the other is deploying the empty project we created in step 4. Unfortunately unless this project exists on the target system, the "Save In:" box will still be empty and crash when you click browse.



Deploying PE10 and the empty project

I won't cover the actual silent deployment process because Adobe has a good write up available here (yes I just did compliment Adobe for once)

I have chosen to deploy the C:\pe10scratch folder and the empty project as part of my SCCM deployment of PE10. My deployment batch file reads as follows:

vcredist_x86.exe /Q
start /wait oem.exe /UL1033 /V"SERIALNUMBER=1111-1111-1111-1111-1111-1111"
xcopy "custom\elements" "c:\pe10scratch" /E /Y /C

Extremely simply but effective. You may also choose to deploy HKLM registry settings at the same time.

Please Adobe, think about your end users before releasing a product that requires dodgy fixes to work.

Sequencing Adobe Premiere Elements 10 with App-V 4.6 SP1

I recently received a number of licenses for premiere elements 10 and due to licensing restrictions decided the best way to move forward would be to use App-V for license management.

I began the package sequencing and towards the end of the installation I recieved an error message when the "Shared Technologies" were installing.

After this installation failure, the Adobe installer kindly begins rolling back the rest of the installation, resulting in a sequencing failure.


The Resolution

This one is extremely easy but took some digging with procmon and working through logs to work it out. The installer is looking for Visual C++ 2008 SP1 x86 and as my sequencing machine didn't have it, the sequencing failed.

Specifically you need version 9.0.30729.17, without this specific version the installation won't proceed. You need to perform this installation BEFORE you start your sequencing and the package must also be installed on any App-V clients that will be accessing the application. If you miss any of these steps the application wont sequence or wont launch.

Microsoft Visual C++ 2008 SP1 x86 is available here

If you require additional information on the silent installation process itself, please check out the Adobe website http://kb2.adobe.com/cps/922/cpsid_92294.html

Deploying custom Microsoft Word 2007 registry settings at logon

As a systems administrator in a reception to 12 school (K to 12 for any non-aussie's reading) I get allot of requests for settings delivery, much more than I ever experienced in the corporate world. These settings range from printers, network drives to office templates, application configuration and anything else you can think of.

Recently I was asked to deliver some Microsoft Word 2007 settings for our younger students, the requests from staff were that the "picture in front of text", "hide formatting" and "search everywhere in clipart" options were automatically deployed. For students as young as 5 logging onto the computer and opening Word can be a challenge, let alone going into options and manually configuring these options.

All of these settings are buried deep in Office 2007's registry entries but with some trial and error and the ever trusty procmon from sysinternals, it is easy to work out.


Setting clipart to search web collections

This one is fairly easy, the key in question is:

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Clip Organizer\Search\Last Query\Extra]

The easiest way to get the setting you want is to open Word, tick the appropriate boxes and then export the above key with regedit.

Applying the setting is as simple as importing it into the users HKCU store as part of your login script, below is an example of a kixtart script.

if ($isUserReception)
   SHELL "regedit /s $logonpath\registry\word2007pictureinfront_hideformat.reg"
   SHELL "regedit /s $logonpath\registry\word2007clipartcollections.reg"
endif


Keeping picture in front of text and hiding formatting

Changing these two settings are slightly more difficult but can be extracted in exactly the same way. Both of these settings are controlled by a large value named:
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Data\Settings]

This REG_BINARY value is unconfigured by default and is only set when the user specifies some non-default settings in Word, such as the "keep picture in front of text" and "hide formatting" from the options menu.

1. Before we try to capture the settings it is best to start wish a fresh [HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Data\Settings] value, you can do this by deleting the value in regedit.


2. Next open Word 2007 and set your options. For me those options are "keep picture in front of text" and "hide formatting" but you can set as many settings as you want. You may need to do this multiple times for multiple settings "packages" as its not possible to export individual settings as most are contained within this single value.

3. Close Word, this is when the settings are written to the registry.


4. You can now export the key and deploy it with a logon script. Remember this is a HKCU key, so it must be deployed in a user based script.


Hopefully these couple easy processes will help you deploy more advanced settings for your users.

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.