Configuring FreeNAS 9.10 to communicate with an APC Network Management Card

These instructions should work for just about any APC Network Management card (NMC), but the one I’m using is the AP9631.

Step #1: Navigate to the UPS configuration options

There are two ways to get into the UPS configuration:

  1. Navigate to Services -> UPS in the sidebar, or …
  2. Click on Services at the top of the page, then click the wrench icon next to UPS

It makes no difference which one you choose.

There are two ways to open the UPS configuration options. The end result is the same no matter which you choose.

There are two ways to open the UPS configuration options. The end result is the same no matter which you choose.

Step #2: Configure the UPS

As stated earlier, I’m using an AP9631 so I’ll select the driver closest to that model. In this case, it is the APC ups 3 (various) AP9630 monitoring card (snmp-ups privProtocol=AES) driver:

Select the most appropriate driver

Select the most appropriate driver

… And then continue with the configuration.

UPS configuration options

UPS configuration options

  • Identifier is how FreeNAS will refer to your UPS.
  • Port is the IP address of the network management card
  • Shutdown mode can be one of the following (you’ll have to decide which one of these is appropriate for your environment):
    1. UPS reaches low battery
    2. UPS goes on battery
  • Monitor User is the username of the user that exists on the NMC that will be used to issue shutdown commands. The AP9631 ships with a user called “device”, but you need to change the password for this user when you configure your NMC.
  • Monitor Password is the corresponding password for the NMC user.
  • Remote Monitor this option allows other servers to monitor the UPS via the NAS. You may or may not need this functionality.
  • Send Email Status Updates and To email these should be self explanatory.

Once you’ve saved your configuration, start the service:

Start the UPS service

Start the UPS service

Step #3: Verify the UPS service is communicating with the NMC

Open a terminal and ssh to your NAS and run the following command (where APCNMC is the Identifier you entered in your UPS configuration):


You should see something like this:

ambient.1.humidity.alarm.high: 60.00
ambient.1.humidity.alarm.low: 30.00
ambient.1.temperature.alarm.high: 40.00
ambient.1.temperature.alarm.low: 10.00
ambient.humidity: 0.00
ambient.temperature: 34.0
battery.charge: 100.00 10/05/2014
battery.runtime: 2160.00
battery.runtime.low: 600
battery.voltage: 26.80
device.mfr: APC
device.model: Smart-UPS 1000
device.serial: AS1440225753
device.type: ups snmp-ups
driver.parameter.pollinterval: 2
driver.parameter.privProtocol: AES
driver.parameter.synchronous: no
driver.version: 2.7.3 apcc MIB 1.2
driver.version.internal: 0.72
input.frequency: 59.90
input.sensitivity: high
input.transfer.high: 127
input.transfer.low: 106
input.transfer.reason: noTransfer
input.voltage: 120.10
input.voltage.maximum: 120.10
input.voltage.minimum: 120.10
output.current: 2.70
output.frequency: 59.90
output.voltage: 120.10
output.voltage.nominal: 120
ups.delay.shutdown: 120
ups.delay.start: 10
ups.firmware: UPS 09.2 (ID18) APCUPS
ups.load: 43.50
ups.mfr: APC 10/05/2014
ups.model: Smart-UPS 1000
ups.serial: AS1440225753
ups.status: OL
ups.temperature: 34.10 Unknown
ups.test.result: Ok

Custom context menu actions for Unity on Ubuntu

I have this problem occasionally, (read: multiple times, daily) where I’ll be RDP’d into a server and Remmina decides to lock up. When this happens, it simply won’t respond to anything other than a good old-fashioned kill -9. Assuming it didn’t take Xorg with it when it crashed, which also happens sometimes, I normally open a terminal and issue the standard kill -9, restart remmina, log back into any RDP sessions, and anxiously wait for it to happen again. The remmina icon in Unity has a Quit context option, but that never seems to work when this happens.

Remmina's "Quit" context menu option

Remmina’s “Quit” context menu option

So in the interests of eliminating a step, and some keystrokes, I’ve added my own “quit” context menu option that runs the following command:

pgrep remmina | xargs kill -9

Here’s what it looks like, from the context menu:

My custom "Quit" context menu option

My custom “Quit” context menu option

Adding this option was surprisingly easy. I saw more than a few examples of how to accomplish this, and they all started with Install ubuntu-tweak as the first step, which feels a bit heavy-handed to me. Here’s how I did it:

  1. Find the remmina.desktop launcher file. Normally it is located here: /usr/share/applications/remmina.desktop
  2. Open it in your favorite text editor, find the following line:

    … and modify it to look like this:

  3. Then scroll down to the bottom of the file and insert these lines. The Name line determines how the option is displayed in the context menu. Modify it to your liking; I like it when programs swear at me, so mine looks like this:
    [Desktop Action Kill]
    Name=Kill -9 this muthafucka!
    Exec=sh -c "pgrep remmina | xargs kill -9"
  4. Save the file, and if you’ve followed my instructions to the letter, remmina’s context menu will now swear at you too.
  5. Here’s what my complete remmina.desktop file looks like after the modifications:
    [Desktop Entry]
    GenericName=Remote Desktop Client
    X-GNOME-FullName=Remmina Remote Desktop Client
    Comment=Connect to remote desktops
    [Desktop Action Profile]
    Name=Create a New Connection Profile
    Exec=remmina --new
    [Desktop Action Tray]
    Name=Start Remmina Minimized
    Exec=remmina --icon
    [Desktop Action Kill]
    Name=Kill -9 this muthafucka!
    Exec=sh -c "pgrep remmina | xargs kill -9"

Configuring CrashPlan 4.8.0 Pro -or- Home on FreeNAS 9.10

The bulk of this post has been pieced together from other bits of documentation on the web (see Additional Sources at the bottom of the post), but most of the available information applies specifically to CrashPlan “home” — not “pro”. Also, the included CrashPlan plugin in FreeNAS 9.10 is quite out of date so this guide will help you install and configure the most recent version of either the home or the pro version of CrashPlan. This how-to assumes that you’ve already installed FreeNAS.

Step #1: Install the included CrashPlan plugin

This will create the CrashPlan jail for you. Login to the admin interface of your FreeNAS box and navigate to Plugins:

Install the included CrashPlan plugin

Install the included CrashPlan plugin

Click OK to begin the installation

Click OK to begin the installation

Wait for the install process to complete

Wait for the install process to complete

Once the installation process has completed, verify that the plugin shows up under the Installed tab of the Plugins menu, but do not attempt to start the CrashPlan service just yet.

The CrashPlan plugin has been installed but is not yet running

The CrashPlan plugin has been installed but is not yet running

Step #2: Configure a gateway IP address for the CrashPlan jail

Navigate to Jails -> crashplan_1 -> Edit

Edit the crashplan_1 jail configuration

Edit the crashplan_1 jail configuration

Configure network settings

Configure the jail’s network settings

You’ll notice that FreeNAS has already assigned an IP address to this jail. You can change it now to suit your needs, or leave it alone. Click on Advanced Mode so that we can configure a gateway.

Configure your gateway and/or any other desired network settings

Configure your gateway and/or any other desired network settings

Configure any other settings you need and then scroll down to the bottom of the dialog box and click Save.

Step #3: Enable SSH

We’re actually going to enable SSH on both the NAS and the crashplan_1 jail. Navigate to Services and click the wrench icon next to SSH

Navigate to "Services"

Navigate to “Services”

Click the wrench icon to configure SSH Settings

Click the wrench icon to configure SSH Settings

Check the option to Login as Root with password and click OK. Later on, we’ll change this to only allow public key authentication.

Allow root logins with password

Allow root logins with password

Then start the SSH service:

Click the toggle switch to start the SSH service

Click the toggle switch to start the SSH service

If everything went well, you should be able to use secure shell to connect to your NAS.

Step #4: Enable SSH on the crashplan_1 jail

Connect to your NAS as root via ssh

Login to the NAS as root via ssh, then drop into the crashplan_1 jail via jexec

Login to the NAS as root via ssh, then drop into the crashplan_1 jail via jexec

Once logged in, type the following command and hit enter:


This will output a listing of available jails:

[root@freenas] ~# jls
   JID  IP Address      Hostname                      Path
     1  -               crashplan_1                   /mnt/tank/jails/crashplan_1

To drop into the crashplan_1 jail, you need to run jexec followed by the number of the desired jail from the output of the previous command:

jexec 1

After you’ve executed that last command, your shell should look something like that last screenshot. Now we can continue with configuring ssh on the jail:

vi /etc/ssh/sshd_config

We need to change the value of the PermitRootLogin setting to without-password and verify that the value of PasswordAuthentication is set to no. Additionally, we need to ensure that the values of AllowTcpForwarding and PubkeyAuthentication are yes. The only option that you should have to change is the first one; the latter three should have the correct setting by default, but check them just in case. Make sure they match the following:

PermitRootLogin without-password
PasswordAuthentication no
AllowTcpForwarding yes
PubkeyAuthentication yes
Set "PermitRootLogin" to "without-password" to enable public key authentication via ssh

Set “PermitRootLogin” to “without-password” to enable public key authentication via ssh

Verify that TCP forwarding is enabled. If this is not enabled, then we won't be able to connect to the CrashPlan engine from the CrashPlan app later on.

Verify that TCP forwarding is enabled. If this is not enabled, then we won’t be able to connect to the CrashPlan engine from the CrashPlan app later on.

Save the file and quit, then execute the following commands:

sysrc sshd_enable=YES
service sshd keygen
service sshd start
Enabling and starting ssh in the crashplan_1 jail

Enabling and starting ssh in the crashplan_1 jail

Next, make sure to insert your public key into the .ssh/authorized_keys file:

mkdir .ssh
vi .ssh/authorized_keys
Create an authorized_keys file and paste your public key into it.

Create an authorized_keys file and paste your public key into it.

Paste your key into .ssh/authorized_keys, then save and quit and execute the following command:

chmod -R 600 .ssh

Optionally, update some stuff:

pkg clean; pkg update; pkg upgrade

Let’s also restrict root logins to public key authentication on the NAS (i.e., outside of the jail). Assuming you’re still logged into the jail, execute the following commands:

vi /etc/ssh/sshd_config

Then change the PasswordAuthentication, PubkeyAuthentication and PermitRootLogin options to match the following (just like before):

PasswordAuthentication no
PermitRootLogin without-password
PubkeyAuthentication yes

Save and quit, but whatever you do, do not reboot or restart the ssh service — not yet. Next, you’ll need to create an authorized_keys file just like you did for the crashplan_1 jail:

mkdir .ssh
vi .ssh/authorized_keys

Once again, paste your public key into this file and then save and quit and execute the following command:

chmod -R 600 .ssh

… And then either restart the ssh daemon:

service sshd restart

Or, reboot the NAS via the web interface or by executing the reboot command.

Reboot. This step isn't strictly necessary, but you may receive the following error: "Crashplan data did not validate, configure it first" when attempting to start the service (even after accepting the java EULA.) If this happens to you, reboot before proceeding.

Reboot. This step isn’t strictly necessary, but you may receive the following error: “CrashPlan data did not validate, configure it first” when attempting to start the service (even after accepting the java EULA.) If this happens to you, reboot before proceeding.

Step #5: Install the FreeNAS CrashPlan Plugin

Login to the web interface and navigate to Plugins -> CrashPlan.

Navigate to "Plugins" -> "CrashPlan"

Navigate to “Plugins” -> “CrashPlan”

As soon as you click on the CrashPlan icon, an EULA for Java will appear. Scroll all the way down to the bottom and Click “Yes, I accept”:

Accept the EULA

Accept the EULA

And then click the X icon (cancel) on in the upper-right corner of the next window that appears.

Click 'cancel' in this dialog box

Click ‘cancel’ in this dialog box

If you’re curious, here’s where the link mentioned in the dialog box takes you, currently: We’re going to cover all of this stuff in the next few steps.

Now we need to download the most recent version of CrashPlan (4.8.0 at the time of this writing.) There are two versions we’re concerned with: Home and Pro. I’m using the Pro version but the steps to install and configure either version are mostly the same. Download whichever version you require:

*Note: CrashPlan Pro needs to be downloaded from your account’s Administration Console.

In the following steps, I will refer to the tarball as CrashPlan-<version>.tgz.

Make sure to download it to your local machine as it will need to be installed locally as well. Once it’s downloaded (assuming you saved the file in ~/Downloads) use scp to copy it to the crashplan_1 jail. In the following example, my pool is named tank, my crashplan jail index is 1, and the IP of my FreeNAS box (not the jail) is, so be sure to modify the following steps to suit your environment.

Execute the following commands from a terminal on your local machine; make sure you type the correct filename:

cd ~/Downloads
scp CrashPlan-<version>.tgz root@

Then ssh to your NAS. Remember to change the IP in the following command to the IP of your NAS:

ssh root@

Get the jail index of your CrashPlan jail:


Drop into the jail using the jexec command, followed by the index of your CrashPlan jail. In the following example, my CrashPlan jail index is 1:

jexec 1

Once you’re in the correct jail, execute the following commands:

cd /usr/pbi/crashplan-amd64/share/crashplan/
tar -xf CrashPlan-<version>.tgz
cd crashplan-install
cpio -idv < CrashPlan-<version>.cpi
cd ..
rm -r lib*
cp -r crashplan-install/lib* .
sysrc crashplan_enable=YES

If you are using the Pro version, the following step is absolutely necessary; continuing from above:

sed -i .backup 's/<orgType>CONSUMER<\/orgType>/<orgType>BUSINESS<\/orgType>/g; s/' conf/default.service.xml conf/my.service.xml

Step #6: Update Java

The latest version of CrashPlan requires a Java update. Since this CrashPlan will be running in a FreeNAS jail, you will need the 32-bit version of the JRE. Run the following commands (continuing from step #5):

cd /usr/pbi/crashplan-amd64
wget `cat /usr/pbi/crashplan-amd64/share/crashplan/crashplan-install/install.defaults | grep I586 | cut -d'=' -f2`

Create a directory for the new version of Java. For example, if the tarball downloaded in the previous step was named: jre-linux-i586-1.8.0_72.tgz, then create a directory named: jre-linux-i586-1.8.0_72 and move the file into that directory.

mkdir jre-linux-i586-1.8.0_72
mv jre-linux-i586-1.8.0_72.tgz jre-linux-i586-1.8.0_72/
cd jre-linux-i586-1.8.0_72
tar -xf jre-linux-i586-1.8.0_72.tgz

Next, you’ll need to reconfigure CrashPlan to use this version of Java. Start by editing /usr/pbi/crashplan-amd64/share/crashplan/bin/CrashPlanEngine and inserting the following text, near the very top of the file:

## Point to new version of Java
## See also: "JAVACOMMON" in: /usr/pbi/crashplan-amd64/share/crashplan/install.vars
export LD_LIBRARY_PATH="/usr/pbi/crashplan-amd64/jre-linux-i586-1.8.0_72/jre/lib/i386/jli"

For example, here’s what mine looks like:


Next, we need to edit /usr/pbi/crashplan-amd64/share/crashplan/install.vars and change the path of the JAVACOMMON variable so that it points to our new version of Java:



Now before we start the service, there is an issue you should be aware of. The CrashPlan service may not connect to CrashPlan’s servers. If you tail the log, and then start the service you might see an error about Java not being able to resolve the FQDN of any of CrashPlan’s servers:

service crashplan start
tail -f /var/log/crashplan/engine_output.log | grep UnresolvedAddressException

Here’s a snippet: Unexpected Exception in connect() for, java.nio.channels.UnresolvedAddressException

I have yet to find an adequate explanation as to why this happens, but here’s how you fix it (from this post in the FreeNAS forums). Basically, you need to add the IP addresses of CrashPlan’s servers to /etc/hosts. Run the following commands (copy paste the following block into your terminal) to do this in a single step:

echo "" >> /etc/hosts
host | awk '{print $4 "\t" $1}' >> /etc/hosts
host | awk '{print $4 "\t" $1}' >> /etc/hosts
host | awk '{print $4 "\t" $1 ""}' >> /etc/hosts
host | awk '{print $4 "\t" $1}' >> /etc/hosts
echo "" >> /etc/hosts

And then restart the service:

service crashplan restart

Verify that the service is running and connecting to CrashPlan’s servers with the following command:

sockstat -4 | grep java

You should see output similar to the following ( is the IP of my CrashPlan jail):

root@crashplan_1:/usr/pbi/crashplan-amd64/jre-linux-i586-1.8.0_72 # sockstat -4 | grep java
root     java       860   142 tcp4
root     java       860   149 tcp4        *:*
root     java       860   152 tcp4
root     java       860   153 tcp4

Step #7: Install CrashPlan on your local machine

Again, I’m assuming the CrashPlan tarball was saved to ~/Downloads on your local machine:

cd ~/Downloads
tar -xf CrashPlan-<version>.tgz
cd crashplan-install/
sudo ./

Accept all of the default settings when prompted. Since we don’t want the CrashPlan service running locally, we need to disable it on our local machine. This next step is not universal across all distros. For example, I’m using Ubuntu 15.10; to stop and disable (i.e., prevent from starting on boot) CrashPlan, I need to do the following:

sudo service crashplan stop
sudo sh -c 'echo "manual" > /etc/init/crashplan.override'

As you can see from the method used to disable the CrashPlan service, the init script for CrashPlan on Ubuntu 15.10 is an upstart job. In 15.04 and later, both systemd and upstart are installed by default. Notice to future readers using Ubuntu: this will most likely change in the near future, given Ubuntu’s adoption of systemd as the default init system in 15.04.

Now we need to grab the auth token from the jail. The IP address of my jail is; yours will probably be different. Modify as necessary.

ssh root@ "cat /var/lib/crashplan/.ui_info"

The output will look similar to this:

Retrieving the auth token from /var/lib/crashplan/.ui_info

Retrieving the auth token from /var/lib/crashplan/.ui_info

The format of the .ui_info file is:

port|-------------auth token-------------|loopback

You need to modify the port and the auth token in your local /var/lib/crashplan/.ui_info. The port needs to be 4200, and the auth token needs to be replaced with the one from the previous command. You can simply overwrite the local .ui_info:

sudo sh -c 'echo "4200,eeeb3f1a-b426-4a78-b70c-460a36da9381," > /var/lib/crashplan/.ui_info

Any time the CrashPlan service is restarted on the NAS, this auth token could potentially change. There’s nothing you can really do about it except be aware that it happens. If the desktop app has trouble connecting to the backup engine, be sure to check this.

Step #8: Starting the CrashPlanDesktop app on your local machine

First, setup an ssh tunnel. You will need to use the IP address of the crashplan_1 jail in this command. Mine is; modify yours as necessary:

ssh -L 4200:localhost:4243 root@ -Nv

Then, on your local machine, start the CrashPlanDesktop app either by clicking the icon on your desktop (if there is one) or by starting the app from the terminal:

Two ways to start the CrashPlanDesktop app

Two ways to start the CrashPlanDesktop app

If everything went as planned, the desktop app should connect to the backup engine via the tunnel, and you should be able to configure your CrashPlan backup.

Step #9: Optionally, create a custom CrashPlan startup command

Remember how I said that the token in the .ui_info file changes occasionally? Do you manage multiple headless CrashPlan instances? The following might be incredibly convenient for you. Simply append the following to your .bashrc. Make sure the value of LOCALPORT is correct for your environment. Optionally, change DEFAULTHOST to the hostname or IP of a CrashPlan jail you connect to most frequently:

### Connect to a headless CrashPlan instance
crashplan() {
    if [ -z "${1}" ]; then
    ui_info=(`ssh $USER@$HOST "cat /var/lib/crashplan/.ui_info" | sed -e 's/,/ /g'`);
    echo "$LOCALPORT,${ui_info[1]},${ui_info[2]}" > /var/lib/crashplan/.ui_info
    ((sleep 3; CrashPlanDesktop)&); ssh -L $LOCALPORT:localhost:${ui_info[0]} $USER@$HOST -Nv

Save and close .bashrc then open another terminal and run the following command, replacing CRASHPLANHOST with the host name or IP address of the jail that the CrashPlan instance is running on:


Or, if you set a “default” host:


This will handle updating the auth token in your local .ui_info file to match whatever exists on the server, while also setting up the ssh tunnel and starting CrashPlan.

Additional Sources:

Configure a VirtualBox VM for a different VLAN than its Host

Scenario: You need a new staging VM to test out some Group Policy settings for a domain that resides on a different VLAN than the host that will store your staging VM. For example, let’s say that you wanted to run this VM using VirtualBox on your local machine. Your machine is on the I.T. Department VLAN (5), but the target domain resides on VLAN 3.

Example network diagram

Your machine is running Ubuntu — any recent version (I used 15.10 for this post) will work for this example. The 10,000ft view of what needs to be done is as follows:

  1. Ensure that the switchport that your workstation is connected to is a member of both VLANs. In my scenario, I have the following settings:
    switchport trunk native vlan 5
    switchport trunk allowed vlan 3
    switchport trunk allowed vlan 99
  2. Install the vlan package on your machine
  3. Configure a virtual interface with the appropriate VLAN info
  4. Configure your VM to use that interface exclusively

This post assumes you already have the VM up and running — in this example we’re using VirtualBox but pretty much any virtualization software should work. Go ahead and install the vlan package:

you@localhost:~$ sudo apt-get install vlan
you@localhost:~$ sudo modprobe 8021q
you@localhost:~$ sudo echo "8021q" >> /etc/modules

Add the virtual interface(s). On my machine, I have one interface named enp9s0; yours will probably be different. Adjust as necessary.

you@localhost:~$ sudo vi /etc/network/interfaces

Add your configuration. Mine is as follows:

auto lo
iface lo inet loopback

auto enp9s0
iface enp9s0 inet dhcp

## Target hosts/domain VLAN
## FYI: IPv4 addressing scheme is
auto vlan3
iface vlan3 inet dhcp
vlan-raw-device enp9s0

## Example VLAN w/ static IP assignment
auto vlan99
iface vlan99 static

See The basic syntax of “/etc/network/interfaces” for more information on the available configuration options for /etc/network/interfaces

Once you’ve added your configuration, either reboot your computer or restart the networking service:

you@localhost:~$ sudo /etc/init.d/networking restart

I did run into some trouble during this configuration, mainly because there are some conflicting instructions on the net. You do not have to use vconfig to create the interface before adding it to /etc/network/interfaces … you can if you like, but it isn’t necessary. During this process, if you run into issues with interfaces not being brought up, you should take a look in /sys/class/net to see which interfaces have actually been created:

you@localhost:~$ ls /sys/class/net
enp9s0  lo  vlan3  vlan99

To remove any of your virtual interfaces, simply run the following command (where ‘vlan99’ is the interface you wish to remove):

you@localhost:~$ sudo vconfig rem vlan99
Removed VLAN -:vlan99:-

Now that you have your VLAN interface configured on your local host, we need to tell your VM to use it. This is trivial — in VirtualBox, navigate to the network settings of the VM and make sure that:

  • “Bridged Adapter” is selected in the “Attached to:” dropdown box
  • Select the appropriate adapter in the “Name:” dropdown box

Note: the VM can either be running or not … it makes no difference):

Staging Workstation - Settings

Then check your network settings in the VM (assuming DHCP — if not you’ll have to reconfigure them manually):

Staging Workstation [Running] - Oracle VM VirtualBox

Deploying Adobe Acrobat DC via Group Policy

This post assumes that you’ve already downloaded the Adobe Acrobat DC package from Adobe LWS and you’ve downloaded and installed the Acrobat Customization Wizard DC if not, go do those first.

  1. Once you’ve downloaded the package, double click it to extract its contents — do not run the installer after the package has been extracted.15-07-2015_000115-07-2015_0002
  2. Assuming you’ve extracted the package contents to C:\Users\Administrator\Desktop\Adobe Acrobat, you’ll have a directory within that directory, titled Adobe Acrobat, in addition to some other files that we won’t concern ourselves with for the purposes of this post:15-07-2015_0003
  3. Now start the Acrobat Customization Wizard DC:15-07-2015_0004
  4. Navigate to File -> Open Package and select the AcroPro.msi file.15-07-2015_0005
  5. Configure your deployment options. For example, enter the package’s serial number in the Serial Number field, under the Personalization Options category. Please refer to Adobe’s documentation for details on all of the available configuration options and their uses. One particularly frustrating issue I ran into had to do with the installer looking for Visual C++ x64 2013 Runtime (VC); if this package wasn’t installed, the installation would fail and the only thing logged in event viewer would be a group policy failure. The total lack of useful error messages made this issue a pain to overcome, but after reading every single option and description (more or less) on this page I eventually figured it out. I needed to set an attribute in the Property table via the Direct Editor function in the Customization Wizard.Add AttributeI had to add this attribute manually (just right-click anywhere in the attributes pane), as it does not exist in the Property table by default. The attribute name needed to be IGNOREVCRT64 and it’s value needed to be 1.IGNOREVCRT64You can probably guess at what this does but for the official explanation, refer to Adobe’s Documentation on Property attributes and values. The short explanation is that I needed this installation to succeed regardless of whether the target machine already had the Visual C++ x64 2013 Runtime package installed. As of this writing, here is the explanation, for posterity:

    Since Acrobat looks for Visual C++ x64 2013 Runtime (VC) by default, set IGNOREVCRT64 to 1 if it is not present AND not needed. IGNOREVCRT64 need only be used when all of the following are true:

    • During Acrobat installs on 64-bit machines
    • When Visual C++ x64 2010 SP1 Runtime is not installed
    • Installation is NOT done via setup.exe.
    • The following functionality is NOT needed:
      • Acrobat PDF Creation add-on (PDFMaker plugin) for Microsoft Office 64-bit applications (viz. Word, Excel, PowerPoint & Outlook) and
      • sending emails or resolving addresses via 64-bit Microsoft Outlook.

    Since Acrobat looks for Visual C++ x64 2013 Runtime (VC) by default, set to 1 if it is not present AND not needed. During non-setup.exe installs when VC is not present, installation behavior is as follows:

    • Command line installs abort if IGNOREVCRT64=1 is not passed.
    • UI installs display a dialog asking the user whether they would like to continue or cancel.
    • Setup.exe installs succeed. Installs never abort as the property is passed while spawning the MSI.

    For MSI installs, use Require64BitVC10RT in the Setup.ini file under the Startup section.

  6. Once you’ve configured all of your desired options, navigate to File -> Save Package. This will create a transform (.mst) file (… in addition to doing a few other things): 15-07-2015_0007
  7. To deploy this package, it will need to be accessible from the network. Create a network-accessible directory — something like:
    \\fileserver.domain.local\Deployed Files

    and copy the entire Adobe Acrobat directory — the one containing the transform file created in the previous step — to that directory.

  8. Open GPMC and create a GPO (or modify an existing GPO):
  9. Right click on any blank space in the right panel and create a new package: 15-07-2015_0010
  10. Select Advanced deployment method:15-07-2015_0009
  11. Navigate to the network accessible location of the package and select it (note: it might take a while for any dialogs to appear after selecting the file … just be patient): 15-07-2015_0011
  12. Then add your transform (.mst) file in the Modifications tab of the package properties (the transform file will be in the same directory as the package file.) Then click OK: 15-07-2015_0012
  13. Bonus! Configure some administrative templates.
    1. First, download the templates from Adobe.
    2. Save them somewhere on your computer and unzip them.
    3. Open GPMC and edit the GPO you’d like to use with the templates.
    4. In the policy editor, navigate to Administrative Templates in either Computer or User configuration
    5. Right click on the Administrative Templates folder and select Add/Remove Templates Add/Remove Templates
    6. Navigate to the directory where you unzipped the templates and select the file named AcrobatDC.adm Select the .adm file AcrobatDC
    7. Then configure your options:Adobe "Computer Configuration" optionsAdobe "User Configuration" options