XSI Command line install

December 11th, 2005 by Kim Aldis - Viewed 19076 times -


Installing XSI isn”t hard but it does involve a lot of button pressing, input of port numbers, confirmations and stuff that make it impractical if you”re installing across a number of machines, particularly if the installs are on render nodes that probably don”t have monitors and keyboards. There”s a better way, though; Xsi”s Windows setup executable, setup.exe, can take command line switches that point to a profile that contains all the information for an install that needs no user input.

The executable that you download from the softimage site, latest setup_XSI_5.0-1_MSWin32.exe, is actually just a self-extracting archive. You”ll need to extract the files it contains in order to get to setup.exe and the files it needs. You can use either Winzip or Winrar to do this. We”ll be using Winrar in this article.

Setting up

* Extract the downloaded XSI install exe from the setup programme. You can use winrar or winzip to do this. Winrar ”extract files here” doesn”t create a subfolder so you should put the downloaded install exe in a folder of it”s own. Call it ”XSI_5.0_RemoteInstall”

* Now you need a profile. The remote install process will do this for you but it”s takes you through the whole install thing, which is time consuming and you could probably do without it. So, here”s a profile to get you going:

Type=Custom install
XSI Guides=YES

Cut out the text above and paste it into a file called ”profile.ini” in the root of the ”XSI_5.0_RemoteInstall” directory. Most of what”s in this file is self explanatory but most obviously you”ll need to change the name of your spm server.

* Next you need an install script, a .bat file that runs setup with a couple of command line options. The important ones are -profile and -installpath. Note also, there”s a line that sets up the workgroup for you by calling XSI”s xsibatch -w with the workgroup as it”s argument. Change this to the path to your workgroup if you”re using one. Paste the text below into a file, ”install.bat” that should be in your ”XSI_5.0_RemoteInstall” root.

set INSTALLERPATH=\\kicker\Downloads\xsi\XSI_5.01_remoteInstall

:: Run setup
%INSTALLERPATH%\XSI_5.0\setup.exe -profile:%PROFILE% -installpath:c:\softimage -noreboot

:: Set up the workgroup
call c:\softimage\XSI_5.0\application\bin\setenv.bat
xsibatch -w \\kicker\XSIWorkgroup

:: Wait for return before hiding everything that went wrong.
echo RETURN to finish
set /p Input=

* You should now have an install directory structure that looks something like this:

XSI Install Directory Structure

* You”re now set up to install XSI from a command line, either locally or on remote machines by running install.bat.


* I”ve tried running install.bat remotely by using psexec from sysinternals but some machines seem not to allow the running of applications on remote file servers when run from psexec. I”ve yet to find time to work this one out, although a workaround is outlined below

* Note, the XSI install is pretty dim when it comes across errors. If it sees anything it doesn”t like it doesn”t tell you, it just carrys on with an interactive install. It can be fuggy trying to figure out what”s going on.

* It may not be such a bad idea to set the userRoot to something on your network rather than the default c:\users if you want some consistency when working on several machines. This isn”t a substitute for a workgroup but it”s neater.

* You should make sure that the XSI install directory has been deleted before starting the install else there”ll be overwrite query dialogs on the remote machine when you install.

* I think, but I”m not sure, that spaces in the -profile: path can give problems.

* (fuggy is a word I made up).

Some tips on remote administration

Windows Admin Shares

Windows makes available some shares on all machines for the administration purposes. Arguably they”re a security hole and although they can be turned off they”ll always re-appear when Windows is rebooted. These shares are like back doors to a remote filing system that are always there, allowing you access to files on machines without actually logging on. Admin shares are postfixed with a ”$” and are invisible in the network neighbourhood but you can see them in the section of the Computer Management tool (Control Panel->Admin Tools->Computer Management; System Tools->Shared Folders->Shares.

The most useful is the <drive>$ hidden share. All drives on Windows machines are shared as hidden shares under <drivename>$. For example C$, D$, etc. They can be accessed using the path \\<remotemachine>\C$. One use of these shares is copying install exedcutables to desktops for fater install if you”re stuck with an interactive install. Copy the install executable to the remote machine desktop – COPY foo.exe \\<remote>\c$\documents and settings\administrator\Desktop – then use Remote Desktop or VNC to logon and run the executable which is on the desktop where you can get at it quickly. If you”re installing on many machines this simple trick will save you a lot of time.

Remember also that some restrictive security environments won”t allow remote execute tools such as psexec (see below) or rsh execute files that are not held locally. One way around this is to copy executables to a remote TEMP directory, using the hidden share, before having PSexec run them.

Running installs and admin executables using a Renderfarm

Renderfarms aren”t just for rendering. Most render management software allows you to submit .bat files and executables. Submitting install scripts and executables to the renderfarm is a very quick way to update and install software across a large network of machines.

The PS tools: Remote execution

That very nice and very clever guy, Mark Russinovich, who pulled the rug out from under Sony and their rootkit disaster, has written a cool set of command line admin tools for windows, the PS Tools. You can find these at www.Sysinternals.com. There”s a number of really handy remote admin tools in this kit but the most useful is PSexec which runs commands on remote machines. What makes this reall useful to an administrator is the fact that nothing needs to be installed on the remote machine. You can run executable on any remote machine with absolutely no preparation at all. There are sometimes some security issues but for the most part copying executables locally via a hidden share and running local files will work around these.

Watch Folders

This one”s a touch less straightforward but it”s handy, sometimes. I have a small service I have run on all machines that sits and watches a folder on a shared, central machine, a folder that the entire network can see. If the service sees anything in the folder it tries to execute it. It sounds complicated but actually it”s really easy to set up if you have some knowledge of Perl and access to the ActiveState Perl Dev kit. This has a couple of tools that let you convert perl script into executables or services. Once you have this the perl script that watches and executes is trivial.

UNC paths

I *never* use drive maps because there”s so many ways for them not to be there; it”s easy to forget to map them on new machines and they”re user based so you need to share them for all users and if no-one”s logged on there”s no share. Try to avoid them by using UNC style pathnames – \\<machine>\<sharename>. You can always get to a UNC path so long as the machine is alive. The only disadvantage is that from a default Windows command prompt you can”t CD to a UNC path. There”s a couple of workarounds, though. I use the Cygwin tools, a *NIX like environment that gives you a shell from which you can cd to a UNC path. Alternatively you could hack the registry:

  1. Start a registry editor (e.g., regedit.exe).
  2. Navigate to the HKEY_CURRENT_USER\Software\Microsoft\Command Processor registry subkey.
  3. From the Edit menu, select New, DWORD Value; enter the name DisableUNCCheck; then press Enter.
  4. Double-click the new value, set it to 1, then click OK.
  5. Close the registry editor.
  6. Log off and log on for the change to take effect.

One Response to “XSI Command line install”

  1. DAN says:

    Cheers Kim, I”ve been doing remote installs for a while now on our farm (using Smedge), but there are definately some gems in there that I”ll be taking advantage of now! Great stuff!