I can confirm, yes, you will only be able to deploy Exchange 12 on amd64 (well x64, i.e. including EMTWhatever) hardware.
Now, I must confess something ... A bit over one and a half years ago (~Mar 2004, give or take a couple months), there was this "Focus 64" campaign, posters showed up everwhere "Focus 64 ... Shift to the power of 64-bit ... <picture of rear view mirror, with tailgating Semi-Truck with "64" on the grill, mirror reads:> Objects in mirror are closer than they appear." It was just some internal propaganda to get the development teams to be thinking and taking into consideration 64-bit ... there are always a few of these campaign's going on ... Around the same time or shortly before this Exchange was still asking if we could add PAE/AWE support to ESE like SQL. At one point, I vaguely remember yelling across the room, "PAE? PAE?!? Are you kidding me?! We have 64-bit desktops today! PAE will be mueseums in five years!" (the exact wording probably involved swear words). I also mentioned that PAE is a horrible hack, it makes me nauseous. Hack up ESE because they didn't want to port to 64-bits? Shortly after they were waffling again!! Wondering if they could just make it run as a 32-bit app on 64-bit OSs, large memory aware so they could go from the ~3GB they got today to the 3.9GB of address space a large aware app gets on a amd64 based Windows OS (that'd be a 30% increase in available memory). They could get this if they only ported the IFS driver to 64-bit, or removed it. BTW, the IFS driver is what prevents running 32-bit Exch2k3 on 64-bit OSs. 64-bit OSs require 64-bit drivers / kernel mode components. At which point I made a clarifying comment to the effect of, "No, no, I want to see 48 GBs of ESE buffer cache! Only a native 64-bit store.exe will do. Get off your ..." (perhpas I felt more swear words were necessary, I don't remember) Anyway, with all this debate on "what 64-bit support means", I just wasn't 100% convinced that Exchange was compelled enough ... So I arranged with the guy in charge of the Focus 64 campaign to reserve 50 posters for the Exchange mailbox team's floor exclusively, and one night I snuck over in the dead of night (or early early morning I think) and plastered these posters up and down the mailbox team's hall, I put 64-bit posters in thier regular reserved War team room, on the back of the dev manager's chair, and even on the back of the bathroom stall doors, just so when they're really "concentrating", they'd be thinking 64-bit. I mean what was I supposed to do <grin>!?, they were making JET Blue look bad. We've servers 1 TB worth of databases attached, and only .09 to .12% of DB buffer cache, and email is kind of weird load, kind of 4/5ths OLTP and 1/5th DSS, and well basically Exchange is _starved_ for memory today. JET had multiple 64-bit binaries (the Win2k DEC Alpha binary - Sept 1999 [last shipped in Beta 3, never made it to RTM], the ia64 binaries in Sept 2001, the amd64 binaries in Mar 2003). We had tested 64-bit Itanium DCs, with on the order of 32 GBs of RAM, to great effectiveness for huge DIT files. Anyway, I'm not going to claim my persistent nagging of the mailbox team swung the tide, I honestly think they would've come to the decision naturally on thier own (it was the only real choice). But did walking by a couple hall ways of posters make them _only_ Focus 64?? I personally don't think so, but I've confessed, so I have a clear conciousness. :) If you need someone to blame, you can blame me personally if you like ... Overall ... I'm quite happy, the Exchange team stepped up to the plate, and is going to release IMO, the killer 64-bit app. They deserve accolades. There are actuallly several details besides this one that make an inplace upgrade a more difficult thing to do/support, and together these details embolden the forced migration option. If you read the notes from people at the IT Forum close enough, I saw at least 2 of the other reasons that increase the difficulty of doing in place upgrades. We rigorously debate these things, there are more aspects to the decision than has been mentioned so far. joe, I run my desktop heavily loaded, and frequently run with 200 to 300 windows open, and persistently run out of desktop heap (a kernel mode resource, I've even increased this several times), I'm greatly anticipating having a 64-bit desktop for "whizbang GUI stuff". I had some comments on the cost debate, but I'll put that on another fork of the thread ... Cheers, BrettSh [msft] ESE Developer This posting is provided "AS IS" with no warranties, and confers no rights. On Wed, 16 Nov 2005, Rich Milburn wrote: > Makes me wonder if MS is not betting at least some of the farm on the quick > 64 bit transition that Gates is certain is going to happen. If anyone has > the potential to influence that switch, MS has got it. The switch to 32 bit > was overdue, so everyone realized the benefits and it happened fast. But > we've currently got a memory model that will allow us to quite comfortably > handle reading parts of programs and files and caching to disk - even though > it's common knowledge that caching to disk, or reading the next parts of > files, is a huge speed bottleneck. Memory price was a barrier before - who > could afford 1GB of RAM?? But that barrier is diminishing, when you can buy a > fully functional PC for a couple/few hundred bucks. What if I did editing, > or ran some kind of server software, that could load itself, or its working > space, or its database, entirely into memory?? With a 3GB per app current > limit, it doesn't happen now, so it's hard to imagine what kind of > functionality could be possible in that model. The question I'm curious > about is what is Microsoft's reasoning behind doing it - is it because they > are too lazy to program 2 platforms, because they are too lazy to write > efficient code, or because there is a feature set they want to use that is > only possible with the extended memory space? There are a lot of > applications (uses) that are pretty tough to tackle because of the datasets > they require (i.e. genetic algorithms/neural networking/predictive analysis) > but those might become more commonplace with the address space to handle them > - with multiple processors yes but also with a TB limit on physical RAM. > > Does all that help me read my list mail better? Probably not. At least not > until I can set up rules that can research questions for me automatically and > present me with a proven response I can sign and click send :) > > Rich > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Wednesday, November 16, 2005 11:47 AM > To: [email protected] > Subject: RE: [ActiveDir] Microsofts Exchange Server 12 64 bit announcement > > The first thing I thought of when I read the announcement that it was to > test the waters and MS would recall it as a "the person spoke out of turn". > Then I heard it was Muglia which shored it up quite bit. Now I am hearing > more in dept info from various places and fully believe that MS is > definitely intending to do this. > > Regardless of what MS or Intel or AMD does, I am not so sure I expect the > death of 32 bit machines any time soon. They will just go to more lower end > uses than running a big bad GUI OS. Even if AMD and Intel drop production > completely, I expect you will see some Chinese/Korean Chip manufacturer > cranking them out. If at the same price or the 32 bit was cheaper I would > take the MP 32 bit system over a single processor 64 bit for a home system. > I previously bought the 64 bit system to do some eventual testing versus > thinking it was going to be so much better. I like 64 bit so much I am > running a 32 bit OS on it. ;o) I expect at some point someone will complain > that I need to make my tools 64 bit. I don't expect it to happen whole hog > or probably even at all for quite some time. > > Without all of the whizbang GUI stuff, 32 bit is quite fine for many many > many and let me just say probably most applications. It would be for even > longer though the push is to go 64 bit because some apps have hit ceilings > in easy use of the memory they need. 64 bit is about memory and available > address space for resource allocation, etc. There are extended memory > schemes available for 32 bit just like there were for 16 bit and 8 bit. They > are a pain to code around though and no one likes to do it. When we go to > 128 bit procs it will be the same issue, the apps are too fat to easily fit > in the memory space we have available at the time. I wouldn't even be close > to being stupid enough to say we won't ever need 128 bit... > > Who was it that allegedly said "640KB ought to enough for anybody."? > > > For pure speed, multiprocessing, not 64 bit, is where we are and need to be > going. That also requires extensive work in the coding side of things > because code not properly written for MP purposes can perform very badly in > MP machines. This involved coding techniqus and smart compilers that can > generate good MP code. I have seen some in house apps in previous jobs that > failed in a stellar fashion once loaded onto production MP servers while the > test environment was entirely single processor. I expect there are folks in > software companies who have experienced the same with their apps. I also > expect we will have fun with some 32 bit apps that perform in quite unique > ways under 64 bit. Shouldn't happen, but lots of things that shouldn't > happen, do. That is just the way this stuff works or else we would all be > out of jobs. > > > joe > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Wednesday, November 16, 2005 12:19 AM > To: [email protected] > Subject: RE: [ActiveDir] Microsofts Exchange Server 12 64 bit announcement > > I agree with you. This is one stupid [1] business decision that will > ultimately hurt E12 adoption. We reached the plateau of 5.5 to E2K3 mass > migration a long time ago. Most people still on 5.5 are waiting to see "the > Next Thing" and we can't seem to move them from their standoffish position. > Erecting a roadblock at this point (in the name of 64-bit innovation) will > create a huge disincentive to the adoption of this "Next Thing". The > customers have enough reason to not want to adopt new technologies "just > because......". Now MS is giving them more ammunition to not even bother. > > I do not know what this was predicated on. Perhaps MS is going to pressure > the OEM into abandoning 32-bit machines. Perhaps they will succeed, perhaps > not. My hope is that this is merely a feeler from MS to gauge the industry's > reaction to the plan. I am guessing somewhere in someone's back pocket is a > card that reads "Hehehe....just kidding". If those guesses are wrong, then > let me hazard one more guess - MS is not REALLY interested in getting a lot > of people onto E12 because E12 is just a transitional platform (like WinME) > and will be abandoned as soon as it escapes from the Redmond lab. > > OK, maybe I'm seriously wrong on all my guesses. In which case, I would have > to conclude that someone somewhere is seriously deluded. I don't see a lot > of customers clamoring for 64-bit. Not yesterday, not today, and 95% of the > clients I interface with don't have it in their 2-year plans. Drawing an > imaginary line and proclaiming "64-bit or die" will only lead to one outcome > - a premature death for all the hard work so far invested in E12. In the > absence of death, MS will surely run into the adoption roadblock [2] they > are currently contending with in the XP space - people see no need to move > off of Win2K (thank you very much), especially now that Vista is looming > large. > > [1] I guess one of the perks of being a partial observer is being able to > call MS decisions "stupid" > [2] Unlike a lot of people, I get paid to push MS technologies, so I have a > vested interested in getting maximum adoptions. > > > Sincerely, > > D?j? Ak?m?l?f?, MCSE+M MCSA+M MCT > Microsoft MVP - Directory Services > www.readymaids.com - we know IT > www.akomolafe.com > Do you now realize that Today is the Tomorrow you were worried about > Yesterday? -anon > > ________________________________ > > From: [EMAIL PROTECTED] on behalf of joe > Sent: Tue 11/15/2005 6:21 PM > To: [email protected] > Subject: RE: [ActiveDir] Microsofts Exchange Server 12 64 bit announcement > > > > They aren't dropping backwards compatability, they are dropping a platform, > this isn't going to clean up security issues or remove some nasty functional > problem. It is sort of like they dropped the Alpha and the PowerPC. They > just aren't doing it whole hog for the OS yet. You still hear occasional > complaints about those being dropped though you hear a lot more of "what are > those platforms". > > It is easier to utilize more memory on 64 bit than on 32 bit. Exchange Dev > must feel that a lot of their problems will go away going to 64 bit so that > is the decision. Maybe it is true, I think good coding and design decisions > would go a long way in solving a lot of the problems as well, probably help > considerably more in fact. 64 bit wouldn't have helped the DSACCESS > problems, it wouldn't have fixed the security design and AD integration. > Wouldn't help 9548. Etc. Plus just going 64 bit isn't going to fix much of > anything I don't think. You start getting "fixes" since they are able to use > the more and more memory that you throw at it without having to use the > complicated memory management mechanisms in 32 bit. Some might call that > covering up the issues versus fixing them. :o) > > Windows sucks because it is slow and bloated, oh just buy bigger/faster > hardware and you are fine... If you can get an older version of Windows to > run on your newer hardware, try it. It can be amazing how fast it is. The > hardware companies instead of bitching at MS should be paying them dividends > and praising them for driving the hardware industry. > > Plus we need the faster bigger memory machines, more stuff is going .NET.... > > > joe > > > ;o) > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA > aka Ebitz - SBS Rocks [MVP] > Sent: Tuesday, November 15, 2005 8:37 PM > To: [email protected] > Subject: Re: [ActiveDir] Microsofts Exchange Server 12 64 bit announcement > > We got SBS 2003 6 months after Windows 2003. > > We don't even have Vista yet folks... how relatively short is short to you > guys? > > Vista is possibly Christmas 2006 yes? Server after that...remember we're > just now getting R2 in late 2005, we'll hit Longhorn in 2007.... SBS after > that. > > I find this thread kinda funny... Security folks have argued for MS to drop > backwards compatibility... Mac's did after all....to get better security. > So here they are dropping backwards compatibility for the benefits of 64 > bit, right? And look at us.... it's business side talking again, isn't it? > > More small firms are leasing or buying over time. More small firms are > looking into hosted solutions...we're tired of the patch it and break it. > > 2003 is solid..unlike NT and yet look at the NT still deployed.. And > when that compelling story of why a business should upgrade occurs because > of the productivity gains... I'll bet that will push folks. > > Hopefully then we can finally rip out all the lanman stuff...ya think? > > Do they need to get the migration documentation, guidance ready to go...yeah > ...that they need to do. > > Tomasz Onyszko wrote: > > joe wrote: > >> I don't believe Exchange 12 is waiting for Longhorn. > >> > >> Also SBS Longhorn is in the scope due to Exchange 12. > > > > Yes, You are right - I just replied to Your post where you mentioned > > specific about longhorn. I don't feel very well with this announcement > > too. I'm not sure if it is good step especially with exchange 12 which > > will be released in relatively short time. > > > > > > -- > Letting your vendors set your risk analysis these days? > http://www.threatcode.com > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > > -------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY NOTICE------- > PRIVILEGED / > CONFIDENTIAL INFORMATION may be contained in this message or any attachments. > This information is strictly confidential and may be subject to > attorney-client > privilege. This message is intended only for the use of the named addressee. > If > you are not the intended recipient of this message, unauthorized forwarding, > printing, copying, distribution, or using such information is strictly > prohibited and may be unlawful. If you have received this in error, you > should > kindly notify the sender by reply e-mail and immediately destroy this > message. > Unauthorized interception of this e-mail is a violation of federal criminal > law. > Applebee's International, Inc. reserves the right to monitor and review the > content of all messages sent to and from this e-mail address. Messages sent > to > or from this e-mail address may be stored on the Applebee's International, > Inc. > e-mail system. > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
