Despite its shortcomings like missing rough cut editor, no native tape support for archives, lack of decent UTF-8 level 3 support when importing and exporting XML files, even today, almost two years after its last update and more than six months after Apple has dropped it, Final Cut Server seems to be the best asset management and workflow automation system for FCP7 clients.

Yet, though Apple still sells Final Cut Studio (FCS), sooner or later it won’t run on the latest Apple hardware anymore, so we need to consider switching over to FCPX, Adobe Premiere, or probably Avid Media Composer as soon as Apple drops FCS support with their latest hardware.

Final Cut Server doesn’t support project files of these editors (apart from Premiere using FCP7 XML structures), so a big part of its functionality can’t be used with the latest editors. In addition, Apple won’t fix any FCSvr bugs anymore, so you can’t really add functionality to your FCSvr based workflows.

Long story short, you might want to consider replacing FCSvr with a modern Asset Management and Workflow Automation solution sooner or later.

There are a couple of tools you might wanna look at, e.g. Cantemo Portal DAM, CatDV, ConSol* FocalPoint, Flavoursys Strawberry.

Strawberry and FocalPoint focus on sharing project files, both FCP7 and Media Composer, but –at the time of this writing– don’t allow to preview individual media files. Both tools are absolutely great in what they do, especially because they are so easy to learn and to use.

CatDV and Cantemo try to cover more functionality, and in addition to sharing project files you can share and preview individual media files.

There are other MAMs as well, which might fit your needs, and it’s up to you to choose the best fit as successor of your existing FCSvr environment.
(Or ask me to help you finding the right MAM).

In most environments, you might want to migrate your existing FCSvr installation to your new system.
This might include at least these things:

• Link new MAM to your media files
• Copy metadata of all your media files into the new MAM

Optionally you might want to preserve information which assets belong to which FCP projects and FCSvr productions as well as reuse existing proxy files.

Squarebox provides a migration tool, which helps you migrate all these data from Final Cut Server to CatDV.

Most other vendors don’t provide a migration tool, so you need to extract data from FCSvr on your own and prepare them for an import to your new solution.

If for instance you’d like to migrate from FCSvr to Cantemo Portal DAM, one way to do this looks like this:

1. Extract data from FCSvr. I use a script I wrote, which relies on fcsvr_client and exports an individual XML file per Asset. This XML file includes any metadata related to an asset. As an alternative you could set up an automation within FCSvr. (E.g. using “schedule”, which triggers a “Search Expired” response to find all assets and then triggers a “Write XML” response for each asset. This would give you the same result without using external scripts. See http://www.andre-aulich.de/en/perm/export-asset-metadata-from-final-cut-server-using-builtin-tools-only for more details.)
2. -optional- If you need information which asset belongs to which FCP project and FCSvr production, I use a second script which gets this information from FCSvr, too.
3. I use another script which transforms the FCSvr generated XML files into XML files Cantemo Portal DAM understands. (Or to be correct: Portal DAM relies on Vidispine as its backend, and the XML files will be interpreted by Vidispine).
4. I rename each XML file (automated, of course), to match the name of the related media file, and place it in the same folder like the original media. This means that a file called mediafile1.mov will have an accompanying XML file called mediafile1.xml in the same folder.
5. Now I point Portal DAM to the FCSvr media storage and tell it to automatically add all files found on that storage to its database. PortalDAM will automatically detect media related xml files and add the contained metadata to the assets.

Please note, that I don’t mention migrating existing proxy files, here. This is because Portal DAM works with an HTML5 interface, so we need our proxies to be in another format than on Final Cut Server (only if you need a preview, of course, but hey, that’s what proxy files are for).

If you need information where your proxy files reside, please get in touch with me, and I can calculate the paths to your proxy files for you, so that these proxies can either be linked to your new MAM or automatically moved to a place better suited for your new MAM.

While vi, emacs and nano are nice tools and are available on most Mac and UNIX/Linux machines, using them remotely means that all your personal editor settings might not be available on the remote machine, and if you share a common admin account to connect to the remote machine, you might not be allowed to copy your personal setting files over to the remote machine.

If you prefer your personal editing environment, you either need an editor application which supports opening an ssh connection to the target machine and then opening the file with the local editor settings (like BBEdit), or you need to mount the remote ssh system as a local filesystem and then use any local text editor you prefer (like vi, emacs, TextMate, etc.). The latter can be done using Fuse4X and sshfs. There are plenty of tutorials on the net how to set up Fuse4X and sshfs.

In BBEdit instead, just choose File -> Open from FTP/SFTP Server, then enter your ssh connection details:

Make sure you activate “SFTP”, as this tells BBEdit to use ssh instead of ftp.
Now you can browse the remote file system the same way you could using an ssh connection in Terminal:

Just browse to the file you are looking for and edit it the same way as it was a local file.

The tool is called WingFS and can be found on the brand new Archiware Technical Blog.

The tool is available for Mac OS X and is going to be released for Windows and Linux in Q1/2012, too.

While WingFS is cool as it is, I wonder if this is Archiware’s first step towards cloud integration of their commercial tools, too.

Both Rumpus and Kerio come with their own builtin webserver, so you can’t run all three services on the default port 80.

Your website should probably run on port 80 to make sure, everyone can access it without firewalls blocking access to it.

Rumpus and Kerio on the other hand, should better provide their web interfaces through an SSL secured connection, as people need to enter their passwords on these sites.

One thing you can do now, is to let Apache run on port 80 and serve your website only, while the Rumpus web interface runs on port 443 (the default SSL website), and the Kerio web interface on a non-default port.

Yet, if you want to make sure that both Rumpus and Kerio don’t get blocked by a firewall, you can use Apache as a reverse proxy, meaning, that Apache answers any port 80 and port 443 web requests, and then either answers requests itself (if someone asks for your website), or forwards requests to Rumpus or Kerio.

To do that, you can e.g. configure Kerio to serve its plain http web interface on port 81, while Rumpus serves its SSL web interface on port 8181.
We are going to serve Rumpus using the URL https://rumpus.example.com, while Kerio will reply to https://kerio.example.com.
We can’t use the same name for both services, as they use the same port, 443. Either the port or the site name need to be different.

Now create the SSL certificates for rumpus.example.com and kerio.example.com. Make sure, that your internal and external DNS resolve these names and point them to your server.

Write down the paths to the SSL keys. In my setup they look something like this:

webserver:~ root# cd /etc/certificates/
webserver:certificates root# ls -al
-rw-r--r-- 1 root wheel 1196 Jan 18 11:32 rumpus.example.com.1BA4694BA149ABABE6991681AEA863B9980D6CCD.cert.pem
-rw-r--r-- 1 root wheel 1196 Jan 18 11:32 rumpus.example.com.1BA4694BA149ABABE6991681AEA863B9980D6CCD.chain.pem
-rw-r----- 1 root certusers 2939 Jan 18 11:32 rumpus.example.com.1BA4694BA149ABABE6991681AEA863B9980D6CCD.concat.pem
-rw-r----- 1 root certusers 1743 Jan 18 11:32 rumpus.example.com.1BA4694BA149ABABE6991681AEA863B9980D6CCD.key.pem
-rw-r--r-- 1 root wheel 977 Jan 17 22:37 kerio.example.com.A62BDDC503EC429F48F6AD7DA83BDE4584D9DF35.cert.pem
-rw-r--r-- 1 root wheel 977 Jan 17 22:37 kerio.example.com.A62BDDC503EC429F48F6AD7DA83BDE4584D9DF35.chain.pem
-rw-r----- 1 root certusers 1940 Jan 17 22:37 kerio.example.com.A62BDDC503EC429F48F6AD7DA83BDE4584D9DF35.concat.pem
-rw-r----- 1 root certusers 963 Jan 17 22:37 kerio.example.com.A62BDDC503EC429F48F6AD7DA83BDE4584D9DF35.key.pem


Now create two empty websites in Server Admin => Web named kerio.example.com and rumpus.example.com. Make sure they use port 443 and the SSL certificates we just created.

On Mac OS X Server 10.6 change to /etc/apache2/sites and open the file 0002_any_443_rumpus.example.com.conf. Instead of 0002 you might find another number, but the rest of the file name should match.

Change the content to match 0002_any_443_rumpus.example.com.

Make sure you use the correct paths to your SSL certificate files. If you run Rumpus on any other port than 8181, make sure to reflect that in this config file.

Please notice, that this way Apache maintains an SSL connection to your web client, and it talks to Rumpus using SSL, too.

Now open the file 0003_any_443_kerio.example.com.conf. Again, instead of 0003 you might find another number. Change the content to match 0003_any_443_kerio.example.com.

Now Apache accepts SSL secured connections from the outside world and forwards them to Kerio using plain http.

Now type

sudo serveradmin stop web
sudo serveradmin start web

and try to connect.

If you got questions setting this up, please feel free to hire my services

I will answer my emails before that, though…

Yet, I had to learn, that Adobe’s version management tool Version CUE does not run on this machine. While I was already prepared to use Subversion instead, finally I set up Version Cue on a PowerPC-based Mac – the Intel machine can still access a Version CUE server, it’s only the server that doesn’t run on the Mac Pro.

I’ve got no experience so far if Version Cue does run on Intel-based mobile Macs or the new iMac.

Yet: you can still use a PowerPC-based Mac as a Version CUE server and then access it from an Intel-based Mac.

If you use Xsan and StorNext oder Mac OS X Server’s SMB service to share video files across your heterogeneous network, you might look for an easy solution to do so.
You could use the little AppleScript included with Mac OS X, which allows you to add the suffix of choice to files you select in the Finder. Yet, this is slow and has the disadvantage that Final Cut will consider your original files offline as their names change during the process.

So what I did was to write a little UNIX shell script that creates a hard link to your files. The new hard link has the appropriate suffix and doesn’t need disk space. I also created a little droppable application which allows you to just drag your files and folders onto it to create the hardlinks.

The application can be easily downloaded, then you can copy it to your Applications folder, and drag it into your Dock. Now you just drag the files of choice onto the app symbol in the Dock and get the results you are looking for.

If you are interested, here is the source of the underlying shell script:

#!/bin/bash
#
# =======================================================
#
# written in 12/2005 by Andre Aulich, www.andre-aulich.de
#
# WHAT IS THIS SCRIPT GOOD FOR?
# This script is meant to create hardlinks to your
# QuickTime files created with Final Cut Pro. As FCP
# doesn't attach the suffix .mov to your files, operating
# systems like Windows XP don't recognize the files as
# QuickTime files. Simply adding .mov to the files would
# make these files being offline for FCP, so we decided to
# create hard links to the files that include the
# appropriate suffix.
#
# HOW TO USE THE SCRIPT
# Enter the Terminal, drag the script onto it, then drag
# one or more files or folders into the Terminal and press
# ENTER. If you drag files, the script will simply create a
# hard link in the same folder to the original file and
# add the suffix _hl.mov.
# If you drag a folder into the Terminal, the script
# creates a second folder in the original folder's parent
# directory named like the original folder plus the suffix
# _MOV. Within the folder you will find hardlinks to all
# files in the original folder, yet, they will have the
# suffix _hl.mov. If the original folder includes
# directories, the script simply ignores them as FCP
# doesn't create folders within a capture directory.
# You can also drag a combination of files and folders
# onto the script, it is intelligent enough to understand
# what's going on.
#
# ========================================================

ls -1 "$i" | while read Filename; do ln "$Filename" "$NEWFOLDERNAME"/"$Filename"_hl.mov; done
fi
done


I used Platypus to create a droppable application out of this script.

The script is just a fast hack, and I guess that sooner or later Apple will offer an update to FCP that uses .mov suffixes for captured files, but until that day, I hope this little script is of some use for you.