HOW TO SET UP A NETWORKED WIN32 ACTIVESTATE PERL

Create a share on the appropriate server, e.g. "\\fileserver\perl". Make sure it's writeable from your PC as you, and you may want to make it read-only to all others. This is where the network perl will be served from. It's best if this fileserver is a UNIX system running Samba or TAS, or a NAS device. Any of these units will be capable of translating symbolic links which becomes of great value for shared maintenance between UNIX and Windows Perl setups (see below).
Mount this share to any drive letter; we'll use P: here. This mount is strictly temporary.
Go to the ActiveState web site (http://www.activestate.com/) and download the latest Perl-Win32 binary package.
Install the AS build to a TEMPORARY area on a local drive; we'll use C:\TmpPerl here. Accept the option to add Perl to the PATH; decline the option to register the .pl extension and all others. You may also want to suppress installation of the AS add-ons such as PerlScript and PerlISAPI as they aren't useful to a network perl. You're also given the choice of installing documentation and examples; be aware that PPM will complain if it can't find the documentation area, so I'd recommend installing at least the docs if only to suppress later warnings. In general we want to refuse all attempts to modify the local registry since the network perl cannot depend on local registry settings.
Unfortunately the MS/AS installer puts us between a rock and a hard place because it won't install directly to a UNC path. We could map that path to a drive letter and install there but it will "localize" the install by modifying many files such as Config.pm to hardwire the path containing the drive letter. We don't want this, since the drive probably won't be mapped on other PC's. We need Perl to know about its real UNC location. ActiveState uses an internal Perl script called reloc_perl to localize the installed files, so we can just rerun reloc_perl to de-localize them by replacing the local path with the UNC version. So:
Copy the entire install area under C:\TmpPerl to P:\. Now we have a working AS Perl build in a network share; the only problem is it still thinks it's in C:\TmpPerl.
Unmap the drive letter P:. Now let's summarize the situation: we have two identical copies of Perl, one in C:\TmpPerl and the other in \\fileserver\perl. The only difference is that the local one has been added to our PATH. We'll be using this local copy to modify the network copy.
Since the local Perl install was just added to PATH, you will need to open a new shell window to see the change. Close the old window and start a new one.
Try running "perl -V:prefix"; the prefix should be "C:\TmpPerl". Now run "\\fileserver\perl\bin\perl -V:prefix". We expect the result to remain "C:\TmpPerl" at this point because the copy doesn't yet know about its new location. This is what needs to be fixed.
Run the following command (suitably modified for your pathnames):
perl -S reloc_perl -a -i -v -t //fileserver/perl C:\TmpPerl
It's your call whether you want to use a Windows-style string "\\fileserver\perl" or UNIX-style "//fileserver/perl". There are arguments either way and it tends to be a religious issue.
Now rerun the -V:prefix command above. The UNC copy should report that prefix=\\fileserver\perl. If so, everything went right and we're done.
Go to the Control Panel and uninstall Perl from C:\TmpPerl. This should remove C:\TmpPerl\bin from your PATH as well.
Optionally, add \\fileserver\perl\bin to your PATH manually, using Control Panel. Like all UNC dirs it should go at the END of the path.
This is one setting which needs to be made per-client (if you use it - it's only a convenience feature and triggers and other scripts can be made to not depend on PATH). The registry entry is HKEY_CURRENT_USER\Environment\PATH. This setting can be automated as part of CC installation or in many other ways.

Note

UNIX perl builds actually compile the value of @INC into the binary perl program, so moving it would require recompilation or binary editing. ActiveState Win32 perl, however, has a feature such that it autodiscovers its install location at runtime. Thus, though reloc_perl is capable of modifying binaries, on AS Windows builds it will only need to modify text files such as Config.pm. Actually, I'm not sure if this autodiscovery is a property of AS perl or a feature of all recent (5.6.1+) Perls.

Maintenance

If using this in combination with an SMB interop solution such as Samba, and assuming you have a UNIX Perl instllation too, module maintenance can be greatly eased by creative use of symlinks. Let's say you make use of the ClearCase::ClearPrompt module. First install that to your UNIX perl. Let's say it ends up in /usr/local/lib/perl5/site_perl/5.6.0/ClearCase/ClearPrompt.pm. Now, on the UNIX box, go to your Win32 perl install area and symlink .../site/lib/ClearCase to /usr/local/lib/perl5/site_perl/5.6.0/ClearCase. From now on you can install updates to this module (or in fact to any modules in the ClearCase:: namespace) and they'll automatically apply to the Windows perl as well. You can symlink individual files or whole hierarchies as preferred.

To run scripts with a networked Win32 perl, I do not recommend using pl2bat or registering the .pl extension. Both of these present maintenance headaches. Instead, I use a tiny redirector program as follows:

@echo off
\\server\perl\bin\perl \\server\share\program %*

If you play your cards right this can point to the exact same script you use on UNIX. I.e. \\server\share\program can be SMB access to the same file accessed via UNIX NFS as (say) /usr/local/bin/program. Now when you update the UNIX script it will take effect on Windows automatically. The redirector itself should never need maintenance because it's 100% boilerplate.

Configuring and using the CPAN module or PPM (the ActiveState install mechanism) is left as an exercise for the reader. Be aware that both need some special config within firewalls.