With the release of Exchange Server 2010 Beta 1, many of you have been asking where you can access a 32-bit version of the product.  While Exchange 2007 marked the first version of Exchange which is supported only in its 64-bit version, we did offer a 32-bit evaluation version of Exchange 2007 for use in lab environments and evaluation in virtual machine environments that didn't support 64-bit guest operating systems and for installation of Exchange management tools on 32-bit clients. We are not shipping a 32-bit evaluation version of Exchange Server 2010.  So where does that leave you for the following scenarios?

  • Lab Environments - Utilizing a 32-bit version in the lab environments allowed you to potentially utilize older hardware for feature/functionality evaluation, but did not allow you to perform any scalability or performance testing.  Going forward, in your lab environments, you will need to use hardware that is comparable to your production environment. This will allow you to validate all scenarios prior to production roll-out.  In addition, you can leverage Hyper-V or other virtualization platforms found on the Windows Server Virtualization Validation Program (http://www.windowsservercatalog.com/svvp.aspx) to provide support for 64-bit guest operating systems. For rapid evaluation, we will provide pre-configured VHD images for use with Hyper-V.
  • Demo machines - Exchange Server 2010 will require a 64-bit server operating system. In addition, you can employ virtualization technology that supports 64-bit guest operating systems to support demo environments.
  • Forest/Domain Preparation - With Exchange Server 2010, you will need to leverage a 64-bit operating system to perform the schema extension and forest/domain preparation work. Hopefully you have 64-bit Active Directory servers deployed (or are planning to deploy them) and this won't be an issue. In the event that you do not have 64-bit Active Directory servers, you can install a 64-bit member server (physical or virtual) into the forest root domain, place it in the schema master's AD site, and apply the schema and forest preparations; for domain preparation, you can either update all domains by leveraging the /preparealldomains setup switch, or by removing/joining the 64-bit member server to each domain in the forest that you need to update.
  • Management Tools - For Exchange Server 2010, you have several options for managing your messaging infrastructure, 1) you can have a 64-bit application terminal server that has the management tools installed, 2) you can manage the Exchange 2010 server directly via terminal services, 3) you can deploy 64-bit Windows Vista SP1, Windows Server 2008 SP2 / R2, and Windows 7 workstations, once released, for your administrators, 4) you can leverage the remote PowerShell capabilities that are built into Exchange Server 2010 by using either the 32-bit version or 64-bit version of PowerShell 2.0 (in other words, when leveraging remote PowerShell, the system where you launch PowerShell doesn't require the management tools to be installed as all cmdlets are executing on the server you are remoting).
  • Data Import/Export - With Exchange Server 2007, administrators leveraged the 32-bit version of the management tools and Outlook 2007 to perform data imports and exports to PST.  With Exchange Server 2010, administrators will have to leverage the 64-bit version of Exchange Server 2010 management tools and the 64-bit version of Outlook 2010 to perform PST import/export. This requirement is due to the fact that the 64-bit cmdlets cannot interoperate with the 32-bit version of MAPI. While Office 2010 does not ship until after Exchange Server 2010 releases, export functionality is not broken, as you can still export data to a target e-discovery mailbox. Once the data has been exported to the e-discovery mailbox, you can open that mailbox via Outlook 2003 or later and then use Outlook to export the data to PST.
Hope this helps you prepare for Exchange 2010 better. Let us know if you have any questions.  

Not applicable
I think that this is good and bad. It is a good step in the direction of integration but, not making a 32 bit test eviroment is a bad step because for some companies it may take them a much laonger time period to move to the newest version because of the current economy and the cost of all new hardware and software, just to run a test box.
Not applicable
Microsoft is finally (and thankfully) pushing us forward into the 64-bit computing world. It's about time, and yet, even in my own environment I have a number of apps that don't (and won't soon) support 64-bit. Fortunately, however, my AD and Exchange servers are already 64-bit, so I don't have to worry about it much. I'll just continue to run a few 32-bit servers until my vendors get off their technological butts.
Not applicable
While I agree all servers should now be 64-bit, it would be nice if there was a 32-bit version of the EMC. Most corp aren't going to upgrade their support staff's PC's to Vista x64 just to use the management console.
Not applicable
All of us are privileged with Silver Spoon (64bit Hardware), 32 bit version of 2010 would have been great help.
Not applicable
People really need to stop crying and quit holding up the advancement of technology by dragging their feet in a 32bit world. Truth is there isn't a computer you can buy without a 64bit processor these days
It’s not a silver spoon it’s the fact following facts:
A. Get a notebook or desktop and run 64bit VMs (that’s what I do 8GB Mac book) and I’m in Iraq
B. Hit up eBay and get some old servers for testing, it’s not a full blown lab, its testing.
C. If you need a fully functional test lab then your company has money and is trying to do it right, then you should have the right hardware and software to match the production environment

Those who didn’t see this coming 3 years ago when the production version was only 64bit are just blind, I’d rather the Exchange team spend more time coding and testing the real 64bit product, than wasting time on a 32bit version for demos.
Not applicable
errr i completely agree about the server components being 64bit only but surely the management tools should be released for 32bit pcs??.
I’ve got absolutely no chance of getting our service desk up to 64bit and TS can be a real pain!!
Come on guys, I think without the tools a LOT of people will not upgrade!!


Not applicable
I'd rather have resources devoted exclusively to 64-bit than squander them with 32-bit dead-end development.

Good Decision.
Not applicable
If your only desire for 32-bit is for the management console services, you have two FREE options... remote desktop/terminal services and/or Windows PowerShell. Personally, I already use a combination of both...

And don't start pouting about wanting the GUI, because 2007's GUI doesn't even support all the available configuration options anyway, so you already have to dump to PowerShell frequently anyway.

The alternative, as pointed out, is to run 64-bit Vista or Windows 7, and frankly Windows 7 is fantastic in 64-bit!

You're system administrators for crying out loud, step-up and take control of your environments!
Not applicable
Not applicable
I’m not asking for all the fancy server options, but things like changing email address's / quotas / etc (basically what used to be in AD users and computers) really need to be readily available.
I can understand how this will not be a problem for some people with smaller implementations but when you have service desk staff housed in several buildings,  cities and countries and some even employed by different companies it changes the upgrade from a smallish central project into a companywide mammoth undertaking!!.

Come on Microsoft at least provide something!!
Not applicable
DJ...I agree.  It looks like Exchange will require either a terminal server or a desktop upgrade for all of our help desk staff (did someone forget that people beside Exchange administrators use these tools?)  Or, the more likely case, is that we will have to take the time to write some managment tools that actually work under both 32bit and 64bit platforms.

Oh wait, we won't be able to export to PST when Exchange is released? I guess we won't be deploying anytime soon then.

I would encourage the Exchange Team to step down from their cloud in the sky to see how real people use their software for once.
Not applicable
Русская версия поста (Russian mirror of this post is here) здесь: http://www.maximumexchange.ru/2009/05/21/where-to-get-exchange-2010-32-bit/
Not applicable
64bit tools are fine so long as I gain the capability of archiving my terminated user's email to pst (something I have to do in 32 bit right now btw).
Not applicable
Here is something I don't understand with all the people complaining about not having a 32 bit version. You really have had to make an effort to buy a PC >NOT< capable of running a 64 bit Windows OS in the last 3+ years.
So your desktop hardware 64 bit capabilty as administrators should not be an issue unless you are using a 5+ year old machine. In which case I have to question why you are trying to upgrade your email system every 3 years when you can't seem to upgrade your management machines as frequently.
Remember - most of the cool new end user features require Office 2010 (like mailtips), and I really hope you all aren't planning to run that on Windows XP (which came out in 2002 - 8 years prior to Office 2010).

So really - if you plan to be agressive in upgrading your email system every time Microsoft releases a new version of the product, then you should plan on upgrading you management machines as well. Doing one and not the other is just plain silly.
And no I am not saying you have to upgrade every desktop in the enterprise, but generally it's a good idea to keep your management machines in sync with your servers.

I would also like to HIGHLY recommend that enterprises start moving to dedicated management terminal servers. Not only does this give you centralized locations to apply service packs and rollups, but it allows admins to more easily separate their normal user accounts from their admin accounts, while also being able to give them the ability to disconnect and reconnect from anywhere they have connectivity (like VPN'ing in from home).
Trying to install Exchange management tools accross 100 management machines in an enterprise, and keep them all up to date (this is often key with service packs and roll ups), is really last decade's way of doing administration.

Really - the writing was on the wall when they 64 bit production only version of Exchange 2007 was announced years ago, and it's only logical that the product group drop support for the 32 bit version altogether.
You really don't have an excuse not to keep your management machines in sync with the production version of the email product you are rolling out to your end users.
Not applicable
I think moving to 64-Bit only is a giant step forward, for many people it will give them the tools and oppurtunity to step up and go
"Hey, MS are ONLY doing 64-Bit apps now, we NEED 64-Bit hardware. I need cash to spend on this. Deal with it"
Not applicable
I agree, what ever the points you pointed out above, but all these will work out for Enterprises who got 64bit plartforms,

As a implementer i don;t user 64bit machines for my learning, I do not have option to learn the 2010, because no 32bit version avilable.

I hope Exchange team will understand the need of Exchange 32bit for learners.
Not applicable
I agree with Kaliyan, because the only way that implementers can test (and learn by the way), probe several designs is with the 32 versions only.

I think that is very unfair that Exchange Team doesn't have a 32 bits version for Testing Purpouses only.

I'm implementing Exchange 2007 right now, but I don't have the posibility to test Exchange 2010 only because isn't available a 32bits version of Exchange 2010.  Damn this is to bad, because How I suppouse that I'm going to implement a Step by Step transition from Exchange 2007 to Exchange 2010 if I don't have a 64bits machine for testing purpouses.

Exchange Team Hope that you reconsider the release of a 32bits version only for testing pourpouses in the same manner that you did with Exchange 2007, that was really very helpfully.
Not applicable
At first, I was surprised that Microsoft would consider not having 32-bit management tools, then I remembered this was the same Microsoft the decided that Powershell was the only interface into Exchange, even if all Enterprise developers could not even use it from C/C++.  

ISV developers absolutely have to have all admin interfaces available in 32-bit DLLs, otherwise you cut off our air supply, unless that is your intent.  I hate to break it to Microsoft, but as long as they keep making 32-bit computers, admins are going to use them as their desktop, and Windows XP is still the #1 choice for most.  Using remote desktop and these other solutions are a JOKE, as how does that help the ISV that is trying to sell a solution to a customer ?
Not applicable
No 32 bit management tools is my only gripe.
Not applicable
Why will the Import/Export still rely on Outlook to be installed?  It seems silly not to build the PST capability into the management tools natively.  Exmerge has allowed us for years to do import/export directly at the server.  The 2007 process has been a complete pain and the 2010 process will only be marginally better in my opinion.
Not applicable
I agree that the lack of 32bit support for even management apps is a bad choice.

MS thinks companies have tons of money to upgrade computers every three years and server software every two years.  They are really disconnected from reality in most shops with less than a thousand users.

My local bank is still running Windows 2000 Pro on Workstations that are 6 years old.  They perform the functions that they are currently using.  I can't begin to imagine the amount of work it would be to rip and replace everything just because MS is on a 64bit trip.

64bit is the future, but they need to provide options for 32bit if they want to drag people to the newest versions.
Not applicable
I also agree that the lack of 32bit support for even management apps is a bad choice.
Not applicable
I think that making the management apps 64 bit only is definitely the right direction. I work in  a school, and even the machines that we bought 4 years ago are capable of running 64 bit software (although presently they don't). Any of our newer machines run 64 bit software wherever possible.

We did have a small problem with our test machines not running, but we took a different approach, got a small server and installed VM's. Not the greatest performance, but for proving concepts, and testing upgrades, etc, it is perfect.

I can't believe that we are complaining that future software is going to be 64-bit only. Surely we should be driving things forward as much as possible?

We do have a dedicated management console, and that works great. It is only 32 bit and we TS to all of the servers when we need to do management. For us it gives us greater security, as we can limit both what machines and what users can access the servers for management.

I think sometimes we need to step back from the day to day, take a good look and ask if we have got our upgrade priorities right. I know there may be some great new features, but if the rest of the system can't support those features, there isn't much point in having them.
Not applicable
we made the move in 1996 and never looked back...
Not applicable
If they are going to always make 32bit software when will 64bit become standard? Already fed up of software not wanting to work on 64bit system. New Netgear, went to look at the manual and the autorun said you can't run, please use 32bit computer. How useful.

64bit is more common now so it's time to upgrade for the future. If you can't afford the hardware then how can you afford brand new software ever few years.
Not applicable
Can we PLEASE have an exmerge tool back?   The Outlook method is an absolute pain and migrations of mailboxes are a fact of life in many companies; every time we get bought out or merged it's a nightmare.   It's also great when someone uses but you know an executive will ask for a copy of their mailbox eight months from now.