Exchange 2007 hardware requirements

SWM

Hi
I have been searching through the MS articles attempting to get a good estimate on how much memory my new Exchange 2007 server will need. Due to budget issues we will probably install ONE server with all the exchange 2007 roles looking after around 100 mailboxes.

Our current Exchange 2003 sp2 server with 4GB ram is coping well, so I am really after a estimate from experienced 2007 users on the ram requirements.

From what I can see 16GB should be ample, but as we all know what MS recommend V what actually runs well is normally a differnet thing (try running Vista with the minimum spec).

Your thoughts and experience would be appreciated.

Thanks

royal

16GB would definitely be enough for 100 users.

SWM

thanks royal its nice to get real world answers instead of sales hype

CoryS

http://www.tek-tips.com/viewthread.cfm?qid=1416915&page=1

I dont know if that will get sanitized but its a link of a convo I had with 2 MVPs about my potential MB design. It really gave me a straight forward idea of where to head. When I was looking again the other day at sizing in regards to RAM on MS's site I remember the new specs at around 8GB of RAM recommended for a 1000 mailbox server including the HT AND CAS role, of course more is always better it seems like 8-12GB is more then ample for 1000MB and for 100 I really doubt you need to spend all those oodles of dollars on that much RAM unless you have it coming out of your ears.

Of course Royal would be able to speak to more real life scenarios as he as dealt with multiple roll outs...

I am curious as well anyway so hopefully he will comment

royal

Ya, I'm planning to elaborate, but it's a bit hard to do so when you're in a hotel with a connection speed that makes me wish I was on dialup. I'll provide some more information early next week. At least I get to be in Universal Orlando Florida for training instead of Chicago! Sucks I have to fly back into Chicago tomorrow though.

royal

Planning for Memory:
http://technet.microsoft.com/en-us/library/bb738124.aspx

4GB minimum

8GB recommended plus 2-5MB per mailbox (I always recommend 5MB in any case). So 100 users = an extra 500MB of memory.

Hence 16GB would definitely be enough and would be good for scalability.

Make sure to set the pagefile at Memory + 10MB. So if you do get 16GB of memory, set your pagefile to 1610MB (1.61GB).

There are other considerations to make depending on amount of Storage Groups, Local Continous Replication, Etc... I'd advise you to read that planning page and adjust accordingly, but 16GB should definitely take into account anything you plan to do with 100 users.

SWM

Thanks guys.

I plan to install 4 x 4GB modules leaving space for extra modules if required. I will let you know how it performs early in the new year

hypnotoad

Exchange 2007 on 1 server...

We have 1700 mailboxes, users on Outlook 2007, Outlook web access, and activesync devices. We have 4 gigs of RAM. We have a 400 megabyte limit for mailbox sizes.

Are we crazy? I've been wondering that lately, since the pagefile is sitting at about 8 gigabytes right now.

The mail gets delivered right away and none of the user's connections are ever dropped. How bad is this? Should we be upgrading just in case?

SWM

Exchange 2007 on 1 server...

We have 1700 mailboxes, users on Outlook 2007, Outlook web access, and activesync devices. We have 4 gigs of RAM. We have a 400 megabyte limit for mailbox sizes.

Are we crazy? I've been wondering that lately, since the pagefile is sitting at about 8 gigabytes right now.

How big is your Database, you mentioned 400mb limit X 1700 users = max 680GB database. WOW

hypnotoad

It's about 120 gigabytes. Not everyone has their mailbox full.

Claymoore

nlabelle wrote:

It's about 120 gigabytes. Not everyone has their mailbox full.

All in one information store or is this all of your stores combined?

Various reports I read caution that you should not allow a store to grow beyond 100 GB or a database restore can be problematic. You should consider splitting your mailboxes into separate storage groups for better performance and better reliability. You can split your single information store into separate stores in the the same storage group, but splitting into separate storage groups gives you the advantage of additional transaction logs (one transaction log per storage group).

Splitting your information stores also allows you to use disk space more efficiently. You must have free space equal to 110% of the size of the message store available in order to run an offline defrag. Right now that means you need 132 GB free space for a total of 252 GB on that volume (inefficiently using only 47% of your disk space). Separating your store into 4 30 GB stores means you only need 33 GB free space for an offline defrag. Therefore the volume only needs to be 153 GB and you are using 78% of the disk space for mailbox stores rather than wasting most of it on free space.

Splitting your stores can cause an overall increase in size due to some loss of single instance storage. If an email was sent to all your users, there will now be one copy in each store rather than one copy for the entire company. Single instance storage can reduce the size of your stores by 20% on average - although in the analysis I did for my company it was saving us 35%. I can't give you a good before and after example because we made our users clean up their mailboxes before we split our stores.

As for your transaction logs, they were already on a separate physical disk, right?

I know the OP was in regards to the amount of RAM necessary, but if the budget is so tight that you have to argue for an extra 4 or 8 GB of RAM then it's unlikely you have an unlimited budget for disk space. The Sybex Mastering Exchange Server 2007 book claims that disk space is hardly ever an issue - by the time you add enough drive spindles to get the performance you want you end up with more disk space than you need. I take exception to that beacuse there is a price difference between 15 72GB drives and 15 146GB drives. If you are using a SAN instead of DAS storage, the Exchange project budget may have to cover some additional drives for the SAN and that isn't cheap either.

hypnotoad

I have been avoiding exchange issues while I work on switching and routing. Seems like exchange has been running fine in our organization. We upgraded in May to 2007 and haven't had too many issues. 1700 users on a single dell poweredge 2950 with 4 gigs RAM, 8 processing cores, and a terabyte of direct-attached storage (several 300 gig SAS drives).

I have noticed a performance hit since our barracuda is no longer filtering invalid recipients before they hit the exchange server. I need to fix that The server seems to keep up just fine though -- my users don't notice any lag, no disconnects, and messages arrive quickly.

Maybe I am just asking for trouble?

Claymoore

Sorry for the delay, but it's SAN kickoff week here and I have been swamped with planning and design meetings. Good news - lots of shiny new storage space for all our data. Bad news - many future weekends spent migrating said data.

Splitting a single large message store into smaller stores should improve performance - certainly the indexing jobs will run faster beacuse they are searching smaller databases. Our users also reported faster response times after our split, but some of that has to be attributed to them cleaning up their mailboxes. As an aside, we had a hard time getting our execs to embrace mailbox (or file server) quotas until we presented them a million dollar quote for a new SAN - then they thought quotas were a great idea.

IMO, the best reason to implement multiple stores is for disaster recovery. I have never experienced a failure with Exchange, but I have only been administering it for a couple of years. For argument's sake, let's assume it can happen. If your exchange database were to encounter a problem and need to be restored or repaired, your entire organization is without email during that process if you only have one store. With larger files taking longer to restore, plus all the transaction logs that would need to be applied, you could be facing some serious downtime. Separating the message stores would localize any failures - you won't be faced with all of your users hunting you down with torches and pitchforks. The recovery time is also faster because of the smaller file size and fewer transaction logs that need to be applied (if you have separate storage groups and not just separate information stores).

One warning - if you are going to separate your information stores, be prepared for insane transaction log growth. You will be creating at least two transactions for every message you move, and that adds up to a lot of 5 MB files. We keep our transaction logs on a separtate logical volume (everything exists on the SAN), and I almost filled the 70 GB volume. Halfway through the project I had to dismount the stores to make sure they were clean and then delete the transaction logs so I could continue.

hypnotoad

I spoke too soon about our memory usage...sunday night at 2 AM our server started rejecting all SMTP connections (weird - hardly any usage and backups ran a different day). I rebooted it and it worked so far. I ordered another 8 gigs of RAM to get it up to 12 total.

Here is event log:

OALGen encountered error 8007000e (internal ID 503072c) allocating memory. Please check the virtual memory settings. - OAB

The transport process failed during message processing with the following call stack: System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
at Microsoft.Exchange.Net.BufferManager.FindNextAvailableFragment()
at Microsoft.Exchange.Net.BufferManager.AllocateNewFragment()
at Microsoft.Exchange.Net.BufferManager.Alloc(Byte[]& fragment, Int32& offset)
at Microsoft.Exchange.Net.NetworkBuffer.BufferFactory.Allocate(Int32 size, Byte[]& buffer, Int32& offset)
at Microsoft.Exchange.Net.NetworkBuffer.AllocateBuffer(Int32 bufferSize)
at Microsoft.Exchange.Net.NetworkBuffer..ctor(Int32 bufferSize)
at Microsoft.Exchange.Net.NetworkConnection.BeginWrite(Stream stream, AsyncCallback callback, Object state)
at Microsoft.Exchange.Protocols.Smtp.SmtpOutSession.SendDataStream(Stream stream)
at Microsoft.Exchange.Protocols.Smtp.SmtpOutSession.InvokeCommandHandler(SmtpCommand command)
at Microsoft.Exchange.Protocols.Smtp.SmtpOutSession.HandlePostParseResponse(SmtpCommand command)
at Microsoft.Exchange.Protocols.Smtp.SmtpOutSession.InvokeResponseHandler(SmtpCommand command)
at Microsoft.Exchange.Protocols.Smtp.SmtpOutSession.StartProcessingResponse(Byte[] buffer, Int32 offset, Int32 size, Boolean overflow)
at Microsoft.Exchange.Protocols.Smtp.SmtpOutSession.ReadLineComplete(IAsyncResult asyncResult)
at Microsoft.Exchange.Net.LazyAsyncResult.Complete(IntPtr userToken)
at Microsoft.Exchange.Net.NetworkConnection.InvokeRecvCallback(LazyAsyncResultWithTimeout asyncResult, Object result)
at Microsoft.Exchange.Net.NetworkConnection.ReadLineDataAvailable(IAsyncResult asyncResult)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Net.ContextAwareResult.Complete(IntPtr userToken)
at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)



The transport process failed during message processing with the following call stack: System.InvalidProgramException: Common Language Runtime detected an invalid program.
at System.Collections.Generic.Dictionary`2.Enumerator.MoveNext()
at Microsoft.Exchange.Net.NetworkTimer.CheckTimeouts(Object ignored)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading._TimerCallback.PerformTimerCallback(Object state)


Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1616). Topology discovery failed, error 0x8004095a (LDAP_NO_MEMORY (The system is out of memory)). Look up the Lightweight Directory Access Protocol (LDAP) error code specified in the event description. To do this, use Microsoft Knowledge Base article 218185, "Microsoft LDAP Error Codes." Use the information in that article to learn more about the cause and resolution to this error. Use the Ping or PathPing command-line tools to test network connectivity to local domain controllers.


Process MSEXCHANGEADTOPOLOGY (PID=1616). When updating security for a remote procedure call (RPC) access for the Microsoft Exchange Active Directory Topology service, Exchange could not retrieve the security descriptor for Exchange server object ANTHONY - Error code=80040934. The Microsoft Exchange Active Directory Topology service will continue starting with limited permissions.



The transport process failed during message processing with the following call stack: System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
at Microsoft.Exchange.MessagingPolicies.Journaling.MessageChecker.CheckJournalReport()
at Microsoft.Exchange.MessagingPolicies.Journaling.JournalAgent.OnSubmitEvent(SubmittedMessageEventSource source, QueuedMessageEventArgs args)
at Microsoft.Exchange.Data.Transport.Routing.RoutingAgent.Invoke(String eventTopic, Object source, Object e)
at Microsoft.Exchange.Data.Transport.Internal.MExRuntime.Dispatcher.Invoke(MExSession session)
at Microsoft.Exchange.Data.Transport.Internal.MExRuntime.MExSession.AsyncInvoke(Object state)
at Microsoft.Exchange.Data.Transport.Internal.MExRuntime.MExSession.BeginInvoke(String topic, Object source, Object e, AsyncCallback callback, Object callbackState)
at Microsoft.Exchange.Transport.Categorizer.MExEvents.RaiseEvent(MExSession mexSession, String eventTopic, AsyncCallback callback, Object state, Object[] contexts)
at Microsoft.Exchange.Transport.Categorizer.MExEvents.RaiseOnSubmittedMessage(TaskContext context, AsyncCallback callback, MailItem mailItem)
at Microsoft.Exchange.Transport.Categorizer.CategorizerComponent.Stage1OnSubmitted(TransportMailItem transportMailItem, TaskContext taskContext)
at Microsoft.Exchange.Transport.Categorizer.TaskContext.Invoke()
at Microsoft.Exchange.Transport.Categorizer.CatScheduler.JobThreadEntry(Object ignored)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)

famosbrown

Before you rebooted, are you sure you checked the Current Sessions for SMTP and to ensure you weren't being DOS attacked with Relays? It could even be a few machines on your network if you have the checkbox for Allow Authenticated computer to relay regardless. I've seen refused SMTP connections due to that since nothing was left...no memory, no processor, etc.

Claymoore

famosbrown wrote:

Before you rebooted, are you sure you checked the Current Sessions for SMTP and to ensure you weren't being DOS attacked with Relays? It could even be a few machines on your network if you have the checkbox for Allow Authenticated computer to relay regardless. I've seen refused SMTP connections due to that since nothing was left...no memory, no processor, etc.

+1

Check the size of the SMTP logs to see if they have grown abnormally large. We had a web server with the SMTP service running and our webmaster turned off the relay restrictions on that server while troubleshooting a problem. He forget to turn them back on which allowed mail to relay through my exchange box since the web server could authenticate with the exchange server. The SMTP logs went from their usual 25 MB to 900 MB before the server crashed.