Perl on Windows Best Practices?

[KevinZwack]

Dear Monks,

A little background: In my last job, I developed engineering tools for my colleagues, mostly in Perl (for over ten years, started with Perl 3). Everyone had a SunOS and later Solaris workstation; we had an NFS drive called /tools, and /tools/bin was automatically added to everyone's PATH when they logged in. Life was good, myself and others could add tools, upgrade Perl versions, install or upgrade CPAN modules, etc. pretty transparently to the others users (provided that all tools were tested and any needed changes were made first).

Now I have a similar job at a different company where everyone has a Windows PC, and life is hell. We have some tools written and Perl, and myself and others are advocates of Perl. However, here are some examples of the problems we are running into:

1. About half the PCs are XP/x86, and the other half are Windows 7/x64. Some CPAN modules work on x86 but not x64 (e.g., Win32::SerialPort).
2. Most people have CYGWIN installed, as we make extensive use of xterm windows, plus there are a lot of Bash scripts (although once people learn Perl, they much prefer it). People also have Strawberry Perl installed, and having both on the same machine creates a lot of confusion.
3. We do not have a central repository for executing tools (let alone SCM, but that's other topic). We have various automated test runners, but file paths like \\server\foo\bar don't work. For some reason, they need paths like X:\bar to operate correctly. So various tools are mapped to various drive letters, but obviously this isn't a scalable solution, and not all drive letters are available on all PCs.
4. When we hire new employees, they generally get a new PC, and are told to install this and/or that Perl and a long list of CPAN modules which may or may not build correctly in their environment.
5. Our IT department is more hostile then helpful, so we cannot expect them to "push" anything out to PCs, or common login scripts, etc.
6. They tried deploying a virtual machine image with all the tools in place, but everyone hated that. Plus it made upgrades difficult.

Needless to say, we spend an inordinate amount of time trouble-shooting what I would call "infrastructure" problems, rather than working on the engineering problems at hand. I have pretty much been given carte blanche by management to come up with how our tools infrastructure should be implemented, provided the infrastructure problems are resolved once and for all. So my question is this: what are other people doing that works well to deploy Perl applications in a Windows environment?

I would like to standardize on a single Perl, but which one? (Cygwin, Strawberry, ActiveState?) The existing tools generally require Perl 5.12 or newer. I would like to feel confident that everyone is using the correct version of a tool by putting them in some common network drive location... I could probably get T: reserved for this purpose, provided we give up some of the other drive letters we are using... None of us are strong PC admins, we all have Unix backgrounds. We are stuck with using Windows since many of the products we make run on Windows. Any thoughts?

Update 8/1/2012

I have installed the 32-bit Strawberry Portable ZIP version on a network share. I have successfully installed all the CPAN modules we use and performed some basic tests on XP x86/Win7 x64. So far, everything seems to be working fine. I think if I provide our users with .bashrc files that set their environment variables appropriately, hopefully things will work from their xterm sessions. Thanks again for all the great suggestions.