I'm going to echo pcampbell here, but my tone is going to be even more grim and strong. Take it as "jaded early-30-something IT guy who thinks he has seen it all" talking, for what it's worth.
Walking in and asking to replace anything right out of the gate isn't a viable strategy. You need to have a very good understanging of what's there already before you attempt to even spec replacement infrastructure, let alone actually implementing it. I'll go out on a limb here and, brashly, suggest that you don't know as much about the needs of this business as you think you do. The comment you made re: "...can't wait to get my hands on a network of my own." speaks volumes. W/ no disrespect intended, I've been the contractor that follows-up these "grand re-architecting" efforts on several occasions, and usually I find that the new stuff is as much of a mess as whatever preceeded it.
I would put away any small, let alone grand, visions of replacement and start by documenting everything that's in place now. You need to understand the hardware, the software, and the business needs. You need to be able to keep things running as they are now while you make plans for improvement.
Here are the things that I'd tackle (with a nod to pcampbell for getting me started... I should've been reading Server Fault an hour ago instead of trying in vain to sleep):
Top to bottom documentation of server computer hardware, operating system configuration, network infrastructure hardware and protocol configuration, physical topology, logical topology. No one besides you may ever read it, but you need to document it so that you understand it yourself.
Identification of business-critical data and systems and planning steps to immediately insure that high-risk faulure modes (think servers w/o redundant disks, data that's not backed-up, etc) are mitigated ASAP. It's your butt on the line, once you take over, if things start failing. That's the last thing you need happening while you're still trying to "learn the ropes".
Identification of the shortcomings, challenges, and inefficiencies in the current system. You can't know what to improve until you know what's wrong to begin with. This means interviewing users, reviewing past trouble ticket history, benchmarking, and digging to find out where time and money are being sunk in the current infrastructure.
While you're doing all that, keep the current system running. You're going to learn a lot about what's going on there by dealing with day-to-day problems.
Build rapport with the users, the executives, and any third-parties that you have to deal with. From your very first day you need to cultivate your image of being a trusted advisor. You need to take a personal stake and act in such a manner that it's clear to everyone that you're working in the best interests of the Firm, and not because you like playing with technology.
To speak to some practical matters:
Call me curmudgenly, but I'm going to stick my neck out re: your proposed "solution" and suggest that you're buying into virtualization because you perceive a cost savings in hardware that may or may not exist, and because you don't understand the potential performance hurdles (especially with database-based applications) that you could be running into. I've spent a year watching a Customer (who came to my Firm unexpectedly in an emergency situation) struggle with performance problems from a pair of very expensive Dell 6950 server computers and an iSCSI SAN. Their VMware ESX cluster that the last "IT person" put in during a fit of "grand rearchitecting" works, but some of their applications are performing poorly and they're finding out that a few "traditional" server computers w/ non-trendy, non-exciting features like RAID and DASD would have performed far better for less money for some of their needs. Somebody was sold a bill of goods, though, and now they're stick with a lot of cost sunk into an inflexibile infrastructure.
Here are some practical items that I'd go after, arranged in somewhat of a priority order... but only somewhat:
I mentioned backup already-- that should be nearly first in your mind on day 1. Expanding to a larger view, though, what's the disaster recovery plan like? Does it even exist? Get a plan togeter, and get it tested. Interview the partners / owners and find out what their level of comfort is with spending money to deal with various kinds of disasters (loss of a server, loss of all the servers, etc). If there's any place that I don't feel guilty asking to spend money it's on disaster avoidance and recovery. 200 people losing their jobs because of an IT disaster sounds like a preventable tragedy to me.
What's the redundancy model like for Active Directory? Are there multiple DC's? If not, get that straightened out ASAP. You need multiple DC's... period. They're cheap, cheap, cheap insurance and having a replica of AD around after a disaster makes for much easier recovery.
Why aren't the client computers joined to the AD domain? Get them joined up. Get WSUS going for the client and server computers.
What's the anti-virus like? Anti-spam? Internet filtering / monitoring? Firewalls? VPN's? Are users running as "Administrator"-level accounts on their PCs? What are password policies like? What kind of notification do you have for attempted intrusion, unauthorized access?
What are the line-of-business applications? How well do they work? Can their performance / efficiency / availabiltiy be improved? What are the SLA's associated with these applications and availability? What are the vendor support relationships like? Can you recommend new applications in thei stead?
What's performance like in the branch offices? How can it be improved if it's poor? What's the WAN connectivity? Is it cost-effective or are there better alternatives out there? Would server computers in the branch offices help or hinder?
What does space usage look like on file servers? What is the space trend? Is data accessible and organized? How's the security with shared data (groups, permissions, etc)? How can you improve it?
What does the stored email look like? What kind of concerns are there for archiving / retention / destruction of email? What's the size trending here? What are the SLA's the business would like to see for disaster-recovery in the event of email server failure? Secondarily, what kind of replacement / enhancements would you suggest to meet those SLA's (clustering, addt'l servers to spread the load, etc)?
Are there specific pieces of server computer or network infrastructure hardware causing problemds with efficiency or security? Plan to replace / repurpose them.
What kind of instrumentation exists to provide notifications of errors, outages, etc? Why aren't you getting e-mail or SMS notifications of things like disk failures, temperatures out of spec, services becoming unavailable? You should be proactively managing outages by preventing them or, at the very least, knowing about them before users do.
What's the voice telephone infrastructure look like? Would unified messaging be a win? How does that tie into handheld computers / PDAs / wireless phones, if at all?
The list could go on and on. Replacement and retirement of infastructure happens as part of those items, but it isn't, to my mind, an item unto itself. No business buys IT for the sake of buying IT. You need to build a case for recommended replacements based on what the cusiness is going to realize in increased efficiency / productivity / revenue from the expense.
