Author Archives: Michael Kuron

OpenWRT on TP-Link TL-WDR3600: enabling Wifi channel 12+13 and higher power on 5 GHz

A few months ago I recommended the TP-Link TL-WDR3600 as an OpenWRT router. I did complain that it unnecessarily limits me to 50 mW in the 5 GHz. After I discovered that it also prevents me from using channel 12 and 13 (which are only available in Europe an Japan, but not in the US), I looked around for a solution.

The in-kernel regulatory database is not the issue. Running iw reg get on the router shows:

country DE:
 (2400 - 2483 @ 40), (N/A, 20)
 (5150 - 5250 @ 40), (N/A, 20), NO-OUTDOOR
 (5250 - 5350 @ 40), (N/A, 20), NO-OUTDOOR, DFS
 (5470 - 5725 @ 40), (N/A, 27), DFS

Some googling around reveals that the ath9k wireless chips have a bit in EEPROM that may be set to either US or worldwide. Apparently, there is a law in the US or an FCC regulation that requires all Wifi devices shipped to determine on the hardware level (in this case, in the driver) whether the desired frequency and power level is allowed.

Unfortunately, TP-Link simply sets the bit to US mode on all devices shipped worldwide. The stock firmware simply ignores it and offers frequency and power choice based on the selected country code. OpenWRT however (as would a stock Linux kernel) respects the bit and applies a logic AND over the selected regulatory domain and the US regulatory domain.

If you run iw phy phyX info, you can see the result:

* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
* 5180 MHz [36] (17.0 dBm)
* 5200 MHz [40] (17.0 dBm)
* 5220 MHz [44] (17.0 dBm)
* 5240 MHz [48] (17.0 dBm)
* 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5500 MHz [100] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5520 MHz [104] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5540 MHz [108] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5560 MHz [112] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5580 MHz [116] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5680 MHz [136] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5700 MHz [140] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)

Some earlier fixes that no longer work with the current OpenWRT involved editing the US regulatory domain in the userland regulatory database. Nowadays that’s part of the kernel itself and no longer easily possible.

Luckily, someone created a binary patch called reghack that replaces the in-driver US regulations with unrestricted ones by (as far as I can tell from the source code) permitting both 2400-2483 and 5140-5860 MHz with 40 MHz wide channels at up to 30 dBm and without any restriction flags. Only channel 14 still seems to be unavailable, but that’s not a big deal as it is only available in Japan for use with 802.11b (that 14-year-old protocol that did a maximum of 11 Mbit/s). Applying the patch is simple (it is downloadable in both source code and binary form), though I needed to perform a cold reboot after the reboot.

In Germany (country code DE), this gives me the following channel map:

* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
* 5180 MHz [36] (20.0 dBm)
* 5200 MHz [40] (20.0 dBm)
* 5220 MHz [44] (20.0 dBm)
* 5240 MHz [48] (20.0 dBm)
* 5260 MHz [52] (20.0 dBm) (radar detection)
* 5280 MHz [56] (20.0 dBm) (radar detection)
* 5300 MHz [60] (20.0 dBm) (radar detection)
* 5320 MHz [64] (20.0 dBm) (radar detection)
* 5500 MHz [100] (27.0 dBm) (radar detection)
* 5520 MHz [104] (27.0 dBm) (radar detection)
* 5540 MHz [108] (27.0 dBm) (radar detection)
* 5560 MHz [112] (27.0 dBm) (radar detection)
* 5580 MHz [116] (27.0 dBm) (radar detection)
* 5600 MHz [120] (27.0 dBm) (radar detection)
* 5620 MHz [124] (27.0 dBm) (radar detection)
* 5640 MHz [128] (27.0 dBm) (radar detection)
* 5660 MHz [132] (27.0 dBm) (radar detection)
* 5680 MHz [136] (27.0 dBm) (radar detection)
* 5700 MHz [140] (27.0 dBm) (radar detection)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)

Note that this is still not entirely what is permitted in Germany: 5150-5250 and 5250-5350 MHz may go up to 200 mW and 5470-5725 even up to 1 W. Since radar detection is not currently supported on the OpenWRT, the latter two ranges are not usable anyway. I’d have liked to turn up transmission power to 200 mW, but as it turns out, TP-Link saved a few cents on the 5 GHz power amplifier, which doesn’t even do more than 63 mW…

Warning: Before you change channels and transmission power on your Wifi devices, check with the regulation authority what is legally allowed in your location. The hardware is capable of things that can interfere with radar etc. and you should never set it to a country code other than your current location. Even then, you might be able to choose options that are not legal to operate.

For Germany, the Bundesnetzagentur has the official frequency allocation documents on their website: 2.4 GHz and 5 GHz. Other European countries should have similar authorities and similar allocations. If you’re in the US, don’t even bother applying these changes as the FCC does not permit anything beyond what OpenWRT is already capable by itself.

HP StorageWorks P2000 G3

5 Replies

Hardware

To replace a 2006 Xserve and a 7TB Xserve RAID at the university, we recently got a Mac mini server, an ATTO ThunderLink FC 1082 Thunderbolt to 8Gbit Fibre Channel adapter, and a HP StorageWorks P2000 G3 MSA FC Dual Controller LFF (specifically, model number AP845B).

The P2000 is not explicitly on ATTO’s compatibility matrix, but when I asked their tech support about it, they said it was compatible and provided me with a pre-release version of their Multi Path Director driver for the Thunderlink which is officially compatible.

Evidently, the P2000 G3 is an OEM’d version of the Dot Hill AssuredSAN 3000 Series (specifically, the 3730), which is on ATTO’s compatibility list, so I assume the standard driver would work just as well. Update 2018: Since Dot Hill has in the meantime been sold, their support page has moved to Seagate.

We chose the Thunderlink/P2000 combo over a Promise solution because it was cheaper, fully 8Gbit capable and had four host ports. Also, I know that HP’s tech support is good and they’ll have spare parts around for many years. Plus, the P2000 is VMWare ESXi certified.

The obvious downside to the P2000 is that the disk bays do not have standard SAS connectors but require an interposer board to convert to a SCA-2/SCA-40 connector. The included slot blinds are in fact blinds and cannot be used to mount an actual drive. You can get empty caddies/trays for the P2000 on eBay or from some used SAN equipment dealer for around 100 euros, or buy your hard drives from HP for a premium of around 100-150 euros over the plain drives. (The interposer board itself appears to get sold under the model numbers 371595-001 or 60-272-02 on eBay, but I haven’t found a model number for the caddy frame yet.) If you’re buying plain drives, you can check HP’s hard drive model matrix to see what model of drive an HP part number corresponds to. For example, the 3TB SAS drive QK703A is a Seagate Constellation ES.2 ST33000650SS and the 2TB SAS drive AW555A, which we ordered, is a Seagate Constellation ES ST2000NM0001).

Firmware

I have verified that the firmwares are interchangeable between the AssuredSAN 3000 and the P2000 G3: I downloaded and extracted the TS250R023 from both Dot Hill and HP and both contain a file named TS250R023.bin with an MD5 sum of 7b267cc4178aef53f7d3487e356f8435. I assume that’s the file that can be uploaded through the web interface.

To extract the HP firmware, download the Linux updater (e.g. CP020030.scexe) and use a hex editor to find the offset of the line break after the end of the shell script at the beginning, then use dd to skip the plain text: dd if=CP020030.scexe bs=1 skip=8602 of=scexe_tmp24664.tar.gz. Now you can tar zxf scexe_tmp24664.tar.gz and pull out the TS250R023.bin.

To extract the TS250R023.bin, simply tar xf TS250R023.bin. If you want to poke around the root filesystem of the Management Controller, unsquashfs mc/components/app.squashfs. You may need to compile squashfs-tools yourself to get LZMA support (edit squashfs-tools/Makefile, set LZMA_SUPPORT=1 or LZMA_XZ_SUPPORT=1 and apt-get install liblzma-dev zlib1g-dev liblz-dev).

Setup and configuration

After unpacking the device, I first updated the firmware to the most recent version available from HP. Before you do that (I used the Windows utility), make sure to set static IP addresses or DHCP static mappings (otherwise the update might fail due to changing addresses). After you set the password for the manage user, you’ll need to SSH into the device to change the password on a hidden admin account about which HP issued a security advisory back in December 2010 (but still hasn’t fixed it in the firmware).

I created a RAID5 out of 4x 2TB drives and dedicated a fifth one as a global spare. In the global disk settings, I enabled spindown so the spare would not be running unnecessarily. The RAID initialization took close to two days, but as that runs in the background, you can already start using it.

Then I created a couple volumes (setting the default mapping to not mapped) and mapped two of them to our Mac mini server (on the Thunderlink) and a third to our two VMWare ESXi servers (on Qlogic QLE2460 HBAs). This was much easier to do than on our old Xserve RAID and I love that I can start out with smaller volumes (sized appropriately that they’ll last for the next year) and expand them later on. The P2000 does not do thin provisioning, but you can’t really expect that at this price point.

Tracking DHL Freight packages

2 Replies

I recently got a shipment notification with a tracking number starting with JND and followed by 17 digits, half of them zero. After searching around for a while, I figured it was shipped by DHL Freight. It’s kind of hard to find the tracking page for that and it’s not supported by Delivery Status, so here’s the link: https://activetracing.dhl.com/. It’s hidden on the DHL web site; you can find it by going to the Logistics tab in the tracking section and clicking “Road and rail”.

Ich habe kürzlich eine Versandbenachrichtigung mit einer Trackingnummer erhalten, die mit JND anfängt. Wie sich herausstellt, gehören solche Trackingnummern zu DHL Freight. Die Tracking-Seite ist etwas schwierig zu finden und Delivery Status unterstützt DHL Freight auch nicht. Der Direktlink ist https://activetracing.dhl.com/ und er ist recht versteckt auf der DHL-Webseite: Man muss auf das Logistik-Tab gehen und dort auf “Land- und Schienenverkehre” klicken.

Two-legged OAuth between PHP and JIRA

7 Replies

If you want to use the JIRA REST API without storing plain-text passwords in your application, you need to use OAuth. If you want the application to directly talk to JIRA without binding it to a JIRA user account, you need to use 2-legged OAuth. JIRA requires RSA keys for 2-legged OAuth. Zend_OAuth supports RSA-signed requests, but this is somewhat undocumented. Also, the Java OAuth library used by JIRA appears to have a bug that requires the field oauth_token in the Authorization header to be present but blank for 2-legged authentication (if it’s not present, it raises uncaught exceptions…). Lastly, you have to use the exact server name that JIRA thinks it has. Finding out all this took me quite a while, so here is the full code:

PHP Code

require_once 'Zend/Oauth.php';
require_once 'Zend/Oauth/Consumer.php';
require_once 'Zend/Crypt/Rsa/Key/Private.php';
require_once 'Zend/Crypt/Rsa/Key/Public.php';

$jql = 'project = KB';
$max = 50;
$server = 'https://www.example.com/jira/'; // this must not be http://localhost:8080. It must match the proxyName, proxyPort and Context configured in ./conf/server.xml in JIRA. Otherwise you get signature_invalid exceptions
$query = array('jql' => $jql, 'startAt' => '0', 'maxResults' => $max, 'fields' => 'summary,assignee,duedate,priority')

$privkey = new Zend_Crypt_Rsa_Key_Private('jira.pem');
$pubkey = new Zend_Crypt_Rsa_Key_Public('jira.pub');
$consumer = 'samplescript';

$query['oauth_token'] = ''; // otherwise you get uncaught net.oauth.OAuthProblemException: signature_invalid exceptions
$oauth_config = array(
 'consumerKey' => $consumer,
 'rsaPrivateKey' => $privkey,
 'rsaPublicKey' => $pubkey,
 'signatureMethod' => 'RSA-SHA1',
 'siteUrl' => $server . '/plugins/servlet/oauth',
 'requestScheme' => Zend_Oauth::REQUEST_SCHEME_QUERYSTRING,
 );

$oauth = new Zend_Oauth_Consumer($oauth_config);
$oauth->setSignatureMethod('RSA-SHA1');
$oauth->setRsaPrivateKey($privkey);
$oauth->setRsaPublicKey($pubkey);

$token = new Zend_Oauth_Token_Access(); // 2-legged authentication doesn't use tokens, but this is the only way to get a HTTP Client that sets the proper Authorization headers
$oauth->setToken($token);
$client = $token->getHttpClient($oauth_config, $url);

$client->setUri(sprintf('%s/search', $url));
$client->setMethod(Zend_Http_Client::GET);
$client->setParameterGet($query);
$json = json_decode($client->request()->getBody());

print_r($json);

Generating the keys

openssl genrsa -out jira.pem 1024
openssl rsa -in jira.pem -pubout -out jira.pub

Registering them with JIRA

Go to the JIRA Administration, click Plugins, then Application Links.

Click Add Application Link, enter your server URL, enter the name of your application and select Generic Application.

Now configure it: got to Incoming Authentication, set a Consumer Key (I used samplescript above), set a name and paste the contents of jira.pub into the box. Now check Allow 2-Legged OAuth and enter a user name to which you want to map the key (i.e. which user’s permissions the OAuth client should have).

OpenWRT hardware recommendation: TP-Link TL-WDR3600

23 Replies

I recently replaced my WiFi access point, an ancient Linksys WRT54G v3.1. I was looking for something that supported simultaneous dualband, multiple SSIDs, and VLANs. I also wanted something that could run OpenWRT.

I ended up buying the TP-Link TL-WDR3600 because it met all these criteria and was available for less than 50 €. After using it for a few months, I can definitely recommend it: The wireless coverage is good, it supports Multi-SSID just fine, and the internal switch is fully VLAN-capable (and easy to configure using the OpenWRT LuCI web interface).

My only complaint is that in the 5 GHz band (5150 MHz – 5250 MHz), OpenWRT limits me to 50 mW of output power (the Linux kernel has a limit of 100 mW), even though I could legally run up to 200 mW. These lowest four channels of the 5 GHz Wifi band don’t even require TPC (transmission power control) or DFS (radar detection) in Germany, making the limitation completely unnecessary.

The TL-WDR3500, TL-WDR4300 and TL-WDR4310 are identical to the TL-WDR3600 save the radio module, so the instructions here should apply to them as well.

Here’s a short how-to on getting started with OpenWRT on the WDR3600:

Installing OpenWRT

Hook up your computer to an Ethernet port on the WDR3600.

Download openwrt-ar71xx-generic-tl-wdr3600-v1-squashfs-factory.bin and upload it using the factory web interface at http://192.168.0.1 (do not rename the file or it might not update).

After it reboots, renew your DHCP lease (OpenWRT uses a different subnet by default) and telnet 192.168.1.1. There, run passwd to set a password, then hit Ctrl-D to disconnect. Now you can ssh root@192.168.1.1.

The first thing to do is backup the bootloader and ART partition, just in case:
dd if=/dev/$(grep '"art"' /proc/mtd | cut -c 1-4) of=/tmp/art.backup dd if=/dev/$(grep '"u-boot"' /proc/mtd | cut -c 1-4) of=/tmp/u-boot.backup
Now you can scp root@192.168.1.1:/tmp/*.backup ~/Desktop to get them off the device.

Next, install the web interface:
opkg update opkg install luci /etc/init.d/uhttpd enable /etc/init.d/uhttpd start
Now you can easily configure everything the way you want it (but please don’t ask questions in the comments about the specific configuration: the OpenWRT forums are a much better place for that).

Upgrading OpenWRT

cd /tmp wget http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-generic-tl-wdr3600-v1-squashfs-sysupgrade.bin md5sum openwrt-ar71xx-generic-tl-wdr3600-v1-squashfs-sysupgrade.bin # compare it against http://downloads.openwrt.org/snapshots/trunk/ar71xx/md5sums

sysupgrade -v openwrt-ar71xx-generic-tl-wdr3600-v1-squashfs-sysupgrade.bin
The device will eventually reboot and come up with the new firmware. Your configuration should still be present.

Failsafe mode

If you’ve locked yourself out, it’s easy to get back in: unplug the device, plug it back in and as soon as one of the LEDs on the front starts flashing, push and hold the WDS button. Release it when that LED starts flashing a lot faster.

Now, set your computer to a static IP of 192.168.1.x with a subnet mask of 255.255.255.0 and telnet 192.168.1.1. Now you can reset your password (passwd), change configuration variables (uci), or do a factory reset (firstboot). When you’re done, reboot -f to return to the normal operation mode.

Warning

It is possible to brick your device with OpenWRT. All the commands above are provided without warranty, so use at your own risk; if you don’t know what your doing, don’t do it.

Also, it’s not that easy to get back to the original TP-Link firmware (which you would definitely need to to if you wanted to return the device to TP-Link for warranty repair.

Note that depending on local laws, flashing an alternative firmware may void your warranty altogether. Even if it does not, screwing up such a flash process yourself is sure to void the warranty anywhere…

Xserve RAID and Atto Thunderlink FC 1082 are incompatible if used without an FC switch

Using C++11 on Mac OS X 10.8

OpenVPN for iOS

10 Replies

Today, OpenVPN Technologies released OpenVPN Connect for iOS. Finally, we can use OpenVPN on all major platforms. I know many of my blog readers have been waiting for this: my article on the iOS VPN API is one of the most popular articles on my blog.

OpenVPN Connect is not based on the classic GPL OpenVPN software (supposedly GPL and App Store are not compatible), but supposed to be fully compatible with any OpenVPN server running version 2.1 or higher (including IPv6 support with servers running the recently-released version 2.3). Supposedly it can even be managed using the “Custom SSL” option in iPhone Configuration Utility.

Two points I’d like to mention which might temporarily disappoint some people:

~~It currently requires client certificates (but the help promises that that’ll change soon).~~
Layer 2 tap interfaces are not supported. As I noted in my VPN API blog post, iOS provides a utun interface, which only does layer 3.

Go check it out on the App Store or have a look at Gert Döring’s Google+ post.

Update December 2013: Version 1.0.2 (just released) finally works for me. 1.0.0 didn’t work without client certificates and 1.0.1 had some weird SSL library issue where it would reject my server certificate. In 1.0.2 I was able to just drop my .ovpn file into iTunes and was up and running immediately, including IPv6 support.

VMWare ESXi 5.1.0 breaks PCI Passthrough (Update: fixed in ESXi510-201212001)

14 Replies

After I upgraded to VMWare ESXi 5.1.0, my server crashed with a purple screen of death as soon as I fired up a VM that was using a passed-through PCI device (1244:0e00, an AVM GmbH Fritz!Card PCI v2.0 ISDN (rev 01)).I have been running the original version of ESXi 5.0.0 for a year and everything worked fine. In fact, I have never ever seen such a purple screen of death.

VMware ESXi 5.1.0 [Releasebuild-799733 x86_64]
#PF Exception 14 in world 4077:vmx IP 0x418039cf095c addr 0xl4
cr0=0x80010031 cr2=0x14 cr3=0x15c0d6000 cr4=0x42768
Frame=0x41221fb5bc00 ip=0x418039cf095c err=0 rflags=0x10202
rax=0x0 rbx=0x10 rcx=0x417ff9f084d0
rdx=0x41000168e5b0 rbp=0x41221fb5bcd8 rsi=0x41000168ee90
rdi=0x417ff9f084d0 r8=0x0 r9=0x1
r10=0x3ffd81972a9 r11=0x0 r12=0x41221fb5bd58
r13=0x41000168e350 r14=0xB r15=0x0
*PCPU3:4077/vmx
PCPU B: UUVU
Code start: 0x418039a00000 VMK uptime: 0:00:06:21.499
0x41221fb5bcd8:[0x418039cf095c]PCI_GetExtCapIdx@vmkernel#nover+0x2b stack: 0x41221fb5bd38
0x41221fb5bd48:[0x418039abadd2]VMKPCIPassthru_GetPCIInfo@vmkernel#nover+0x335 stack: 0x29000030e001
0x41221fb5beb8:[0x418B39ea2c51]UW64VMKSyscallUnpackPCIPassthruGetPCIInfo@<None>#<None>+0x28 stack:
0x41221fb5bef8:[0x4l8039e79791]User_LinuxSyscallHandler@<None>#<None>+0x17c stack: 0x418039a4cc70
0x41221fb5bf18:[0x4l8039aa82be]User_LinuxSyscallHandler@vmkernel#nover+0x19 stack: 0x3ffd8197490
0x41221fb5bf28:[0x418039b10064]gate_entry@vmkernel#nover+0x63 stack: 0x10b
base fs=0x0 gs=0x418040c00000 Kgs=0x0
Coredump to disk. Slot 1 of 1.
Finalized dump header (9/9) DiskDunp: Successful.
Debugger waiting(world 4077) -- no port for remote debugger. "Escape" For local debugger.

Turns out that is a bug in ESXi. Luckily, downgrading an ESXi is simple enough: just hit Shift-R at the boot prompt and tell it to revert to the previous version.

Update: Patch ESXi510-201212401-BG in version ESXi510-201212001 (build 914609), released on December 20th, fixes the PCI passthrough issue (PR924167) according to KB2039030.

Fixing Microsoft Office 2011 SP2 Volume licensing

4 Replies

UPDATE 2012-11-15: The 14.2.5 installer no longer has this weird behavior (it does not include removables.txt files at all, however the postinstall script would still process them if they were there). Since it requires 14.2.3 as a prerequisite, you’ll still need to apply the fix mentioned below to 14.2.3 when chaining updates.

UPDATE 2012-11-30: I just obtained a copy of the 14.2.3 installer ISO from Microsoft VLSC. Copies of Office installed from it (or probably any 14.2.0+ installer ISO) do not exhibit the behavior explained here. The newer installer ships with flat-file Main.nib files that do not get removed by the removables.txt script.

UPDATE 2013-03-13: The 14.3.2 updater again contains a removables.txt which breaks Microsoft Office Setup Assistant.app. If you didn’t replace your installer ISO with a newer version, you will again need to apply the fix mentioned below when installing this update.

When you run Word, Excel, PowerPoint or Outlook 2011, it checks /Library/Preferences/com.microsoft.office.licensing.plist . If that file is not valid (such as after doing a fresh install of Microsoft Office 2011), it launches /Applications/Microsoft Office 2011/Office/Microsoft Office Setup Assistant.app. Microsoft Office Setup Assistant checks whether the DVD from which you installed is a volume licensed copy; if it is, it silently populates that plist and quits (allowing the app you initially started to start up); if it is not, it prompts you for a product key and activation.

If you install from the DVD, launch one of the Office apps to activate the license, quit it and then install all the available updates from Microsoft, everything is fine.

If you update to version 14.2.0, 14.2.1, 14.2.2, 14.2.3, 14.2.4 (or possibly future versions) right after installing from the DVD however, Microsoft Office Setup Assistant.app gets corrupted. This is due to ./Office 2011 14.2.X Update.mpkg/Contents/Packages/Office2011_all_core_14.2.X.combo.pkg/Contents/Resources/removables.txt, which gets run by ./Office 2011 14.2.X Update.mpkg/Contents/Packages/Office2011_all_core_14.2.X.combo.pkg/Contents/Resources/postflight. It deletes the contents of /Applications/Microsoft Office 2011/Office/Microsoft Office Setup Assistant.app/Contents/Resources/XX.lproj/Main.nib (which is a bundle-style NIB), however (unlike probably everything else listed in removables.txt) the update does not contain updated versions of them.

If you’re running an individually-licensed copy of Office 2011, that is no big deal: the Office apps themselves are able to prompt for a license key and activation.

If you’re running a volume licensed copy of Office 2011, you’re in trouble: You now get prompted for a product key by every Office app, which you obviously don’t have.

To fix this situation, you have two options:

1. Copying /Library/Preferences/com.microsoft.office.licensing.plist from a working install. You can do this using your favorite software depolyment tool, such as Munki. Please note that importing it as a Managed Preference (MCX) into Workgroup Manager (and probably Profile Manager) does not help. The file needs to be physically present on the client machine.

2. Move Microsoft Office Setup Assistant.app out of the way before updating. You can do this if your software deployment tool supports adding custom pre- and post-install scripts (Munki allows you to do that).

Here’s my pre-install script:

#!/bin/bash
cd "/Applications/Microsoft Office 2011/Office"
mv "Microsoft Office Setup Assistant.app" "SetupAssistantBackup.app"
exit 0

And my post-install script:

#!/bin/bash
cd "/Applications/Microsoft Office 2011/Office"
mv "SetupAssistantBackup.app" "Microsoft Office Setup Assistant.app"
exit 0

To find out whether you still need to do this on future updates (such as 14.2.5), open the installer package in a tool like Pacifist and check the following: a) Did they remove the Microsoft Office Setup Assistant.app lines from removables.txt (go to the Resources tab and enter removables.txt into the search box to locate the file)? b) Does the update contain a new version of Microsoft Office Setup Assistant.app (go to the Package Contents tab and enter setup assistant into the search box to check for its existence)? If either one is true, Microsoft decided to fix the problem and you no longer need to use my pre-/post-install scripts.