Moving Data on D: drive to a new Hard drive 2

[davy2k]

Hi all,

I have an exchange server 2007 that on the C: drive it got to 4GB and the D: drive which contains the Exchange database and other log files. Since the C: drive got to 4GB emails from the internet was blocked but outgoing mails was fine.

I narrowed the problem down to this:

The resource pressure changed from Normal to MediumHigh. Statistics:

Queue database and disk space ("C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que") = 82% [MediumHigh] [Normal=80% MediumHigh=82% High=84%]

so I changed the queue to the D: drive which has 11GB free.

I want to purchase a 140GB (or more) hard drive and move the contents of the D: drive into it.

Please I need advice on how to go about this and its impact on the present production exchange pitfalls etc.

any link to tutorials will be helpful or someone who has done this before.

Thank you in advance.

 

[nelifecare]

Right-click your exchange DB using the Exchange Management Console and choose Move Database. Browse and place database where ever you'd like to.

 

[Zelandakh]

And keep the log files on a DIFFERENT drive to the database. This is important.

Then uninstall anything possible and review all large folders on all volumes and work out what else can go.

 

[davy2k]

Thank you for your advice. I also have another question which is:

Is it possible to have exchange 2007 in this scenario:

I am currently running Exchange using SMTP in an AD environment with abc.com and on the same Exchange install a POP3 connector to send emails and download emails from another ISP which uses another domain name say xyz.com

Thank you for your help.

 

[ShackDaddy]

It would usually (though not always) be best to "become" the ISP for the other domain and add that domain to the domains that your server handles and have it be the endpoint for that domain's mail, rather than trying to use something like a POP3 Connector.

But, yes, you could do this. But remember, POP3 connectors only download, they don't then upload mail to the original server, although you could set up a Send Connector to route mail destined for that domain straight back to that server. I've set that sort of thing up for franchise offices of a larger corporation.

Since Exchange 2007 doesn't have the POP3 Connector, you have to use something else to stand in for it, like this:

http://www.christensen-software.com/popcon.htm

Dave Shackelford
Shackelford Consulting

 

[xmsre]

When you talk about backpressure, then you're talking about a server with a hub transport role. In your case, I'd imagine you have a single server that is the mailbox/cas/hub.

On the boot partition (C, you have the OS, the page file, the Exchange binaries, the transport database (and the logs for it although circular logging is used), the system temp directory, and the directories used by your pop connector for content conversion in and out.

On the D: partition you have the exchange database and logs I'm assuming for a single storage group with a single store.

If the C: and D: partiotions may be logical ones sharing the same sindle(s) or they may be on seperate spindles; you didn't give any detail on the disk configuration.

Generally, you would want six spindles for a minimal exchange setup; a mirror for the OS, a mirror for the logs, and a mirror for the database. In situations where you see backpressure for the hub transport database significant enough to stall mailflow, I would locate the hub transport database on the partition with the first storage group database (like workloads).

Before you do that, take a moment to examine your boot partition. How was it created? Did you use a vendor's automated server build utility? Which one? What is the allocation unit or cluster size of the boot partition? You can analyze only - no need to actually defragment - with the disk defragmenter utility and then view the report to find your cluster size. Alternately, you can run chkdsk in readonly mode (no switches) to find the allocation unit size. Many of the automated build utilities start with a FAT partition that is later converted to NTFS during the unattended install process. This results in a cluster or allocation unit size of 512 bytes instead of the default 4KB.

An inappropriately small allocation unit size maximizes transactional overhead and negatively impacts performance. As an example, an 8K read or write request to the hub transport database which resides on an NTFS volume with a 512 byte allocation unit size will be split by the NTFS file system driver into 16 512byte IOs The can be readily viewed in perfmon with the physical disk counter split IOs/second. If you find that your cluster size is inappropriately small, you may want to consider rebuilding the server.

 

[58sniper]

Also keep in mind that the recommended allocation size for the TL volume (4kb) is different than that of the DB volume (64kb).

Look at

http://msexchangeteam.com/archive/2007/01/15/432199.aspx

for more info.

A star for XMSRE's awesome answer, which should be put into an FAQ here..... hint hint hint.

Pat Richard
Microsoft Exchange MVP
Contributing author Microsoft Exchange Server 2007: The Complete Reference

 

[Davetoo]

Crap...I made them both 64kb and aligned them!

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.