Adobe Premiere Elements takes a long time to load in a firewalled environment

After going through the pain that is packaging Adobe Premiere Elements for a domain environment, we found ourselves faced with another issue.

On any machines that don't have direct access to the internet, the Premiere Elements initial load took a very long time.

However Adobe does provide some logging to diagnose start-up problems, which can be found under \Users\[username]\AppData\Local\Temp\amt3.log (Windows 7 and above).



The Solution

An analysis of the logs identified a request for "Activating License" and shortly after a "HTTP Request Status code 502" which indicates a bad gateway.

The line after the license activation begins gives us some clues to the solution. "License server is https://activate.adobe.com/servlets/inet_sl/sl_v1_7_rclient (protocol=slcore)"

The easiest way to get rid of the Premiere Elements delay is to simply allow activate.adobe.com:443 to pass directly to the internet. Premiere is smart enough to use the OS proxy, so you may need to add a proxy exclusion to Internet Explorer.

If you have no way of allowing traffic directly out, then some form of proxy server may be your only option.

Recovering corrupt Adobe Flash CS6 FLA files

Adobe Flash CS6 is an application widely used in both in secondary and tertiary design classes. However Adobe doesn't support saving files to the network, in fact they don't even support installing CS6 on domain joined computers. This is short sighted of Adobe, surely a large component of their CS business is driven by education sales, all of which would implement some form of domain or networked environment. After having continued errors with saving Photoshop and Flash files to the network we implemented a policy stating that users should save to the local drive then backup to the network.

Flash FLA files are zips containing a number individual files inside. Often during the drawn out process of saving individual files and then zipping them, flash has a tendency to corrupt saves, especially when saving to network storage.

We recently spent time trying to recover a FLA file and came up with a process that can often recovery corrupt files.


The Solution

1. Install and open Winrar.  

2. Take a copy of your corrupted FLA file and open it with Winrar. File > Open Archive 

3. Repair the archive. This option is available from the Tools menu.

4. Choose a location to save the repaired archive to.
 

5. Use Winrar to open the file you saved in step 4.
File > Open Archive > select the location you saved the repaired archive to > select the archive 

6. Click "Extract To" and choose a location to extract the repaired FLA file to. This will unzip the FLA zip file into the individual files that are contained inside. 

Accept any errors, it may complain of CRC errors or say some files can't be extracted.  

7. Go to the location you extracted the archive to in step 6. Open the XFL file with Flash, it should have the same name as your original FLA file.  

On a computer with flash you should be able to double click it.

Your file should open damage free! Depending how damaged the archive is this may not work, however we found on most occasions it does and saves you a heap of time.

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!

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 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.