Perl won't work well if it thinks it was installed to a different place than it now is being seen at. Perl won't work properly if its bin is not in your PATH. Beyond that follow your regular OS-specific instructions for how to run Perl.

1. Install the machine that your intranet will run on. I would suggest thinking about your addressing and naming schemes, too. You could have two IP addresses for the machine, if it will be doing things as well as being your intranet server. Have the second ip address mapped to the host name "intranet" or whatever is meaningful. I assume you have an internal DNS machine. A good suggestion, if your internal network has more that 50 machines, is to have a dedicated "network management" box - this would be your internal DNS master, your DHCP sever, Radius server (if you have it), NIS master (if you use NIS), and so on. Ideally, don't make this an application server as well (so don't use this as your intranet server). It doesn't have to be a big machine - where I use to work we use an old Sun Sparcstation 10, if you are a Linux shop, any old pentium machine will do.
2. Install the web server software. Get the latest versions of Perl, Apache, mod_perl, and anything else you need. Read instructions and install. Again, the installation and configuration of this software is not difficult, but some parts of Apache can be confusing, particularly if you are using virtual hosts. Since you want to use perl (as CGI programs), you should work out where you will locate the perl programs within your document tree. The "standard" way is to have a cgi-bin directory outside the document tree. However, if you are planning on having a lot of perl programs, you may want to consider having the cgi program within the same directory as the HTML files, to avoid confusion. You will need to set the "EXECCGI" value appropriately to allow this - by default, Apache does not allow CGI programs to be executed from any directory, unless explicitly allowed. Read the documentation on this.
3. You may need to check the internet proxy settings on all the browser installations. A quick check - make sure none of your Windows machines have a hosts file hanging around in the C:/Windows directory (or maybe C:/Windows/system ?), and their TCP/IP network configs are right. If you are using DHCP (you are, aren't you?), then the DHCP server can set the DNS server and gateway addresses as well as allocating each machine its IP address.
4. Consider having a second intranet server - on a second machine - as your "development and testing" platform. This is where you can make sure Perl 5.6.2 will not crash your CGI programs, or you can experiment with Mason, or whatever.

What you are going to do is not difficult or complex, just spend a day or two planning it all out first. Good change management on config files is important too - you may want to consider using some version control software on these files.

For our intranet, we simply designated another computer as our intranet server, and kept it behind the firewall. Our main webserver (for external use) is outside the firewall, and our intranet server - being inside the firewall - can be accessed by anyone within the company. Once you leave the company, the firewall keeps your intranet secure.

You just install ActivePerl or whatever you're using the same way as you would for a normal webserver - the firewall keeps the intranet from being accessed by anyone outside the company. That's presuming you don't want your intranet to be accessed by employees at home - if you /do/ want your intranet access at home - while keeping it away from J. Random User, then you'd need to set up a VPN or something, which is /way/ beyond my scope of explanation :)

"I don't want the world; I just want your half"