I recently started a new job where I inherited an Exchange 2007 server in pretty bad shape. I noticed that when I did a sum of all the mailboxes there was about 80GB of mail, and no public folders in use since SharePoint is preferred over it. The main mail edb is currently at 380GB with event id 1221 reporting 300GB of white space, which is with my estimates of how big the edb should be if it were healthy. The transaction log files are taking 300GB for a total of 680GB on a quickly filling up 750GB drive. A full back up with Backup Exec and the built-in Server 2003 backup utility do not flush those logs. I did a bit of research and found a VM of an additional Exchange server, loaded it, and it appears that replication had been configured at some point, which is why I think the logs are now piling up and not being flushed with a back up. Even on our unused Public Folders, on a different drive, there are 20MB of data in the edb, but 24GB of transaction logs over the last two years. A bit insane. Basically, I can get the white space and all that sorted out but I'm having trouble with figuring out how to correct the replication issue. My main concern is to get the log files flushed, the mail edb healthy again, and to not even bother with replication for now. It appears to me that replication is off on the main mail server, but it must still be waiting for it because of the transaction logs. I'm tempted to just rebuild an exchange server but I need to do something quick as the main disk is filling up at about a rate of 200MB a day. Quite a mess. Thanks in advance.

Is this a cluster? If not, then you think SCR was enabled? If your server is running SP1 or later, enter this command: Test-ReplicationHealth This should help you figure out what's going on. If it shows that SCR-type storage group copy is configured, then you can run Disable-StorageGroupCopy using the StandbyMachine parameter. At that point a successful backup should trigger the transaction logs to be purged. When you can take some downtime, you can run ESEUTIL /D on the database to shrink it down to around 80GB, if you want. It isn't necessary, but the amount of bloat you're seeing, where 73% of your database is white space, is one of the rare times that it makes sense to run ESEUTIL /D. -- Ed Crowley MVP "There are seldom good technological solutions to behavioral problems." . "VanPower" wrote in message news:fc2e7104-e3d1-4095-af14-2df513cf9103... I recently started a new job where I inherited an Exchange 2007 server in pretty bad shape. I noticed that when I did a sum of all the mailboxes there was about 80GB of mail, and no public folders in use since SharePoint is preferred over it. The main mail edb is currently at 380GB with event id 1221 reporting 300GB of white space, which is with my estimates of how big the edb should be if it were healthy. The transaction log files are taking 300GB for a total of 680GB on a quickly filling up 750GB drive. A full back up with Backup Exec and the built-in Server 2003 backup utility do not flush those logs. I did a bit of research and found a VM of an additional Exchange server, loaded it, and it appears that replication had been configured at some point, which is why I think the logs are now piling up and not being flushed with a back up. Even on our unused Public Folders, on a different drive, there are 20MB of data in the edb, but 24GB of transaction logs over the last two years. A bit insane. Basically, I can get the white space and all that sorted out but I'm having trouble with figuring out how to correct the replication issue. My main concern is to get the log files flushed, the mail edb healthy again, and to not even bother with replication for now. It appears to me that replication is off on the main mail server, but it must still be waiting for it because of the transaction logs. I'm tempted to just rebuild an exchange server but I need to do something quick as the main disk is filling up at about a rate of 200MB a day. Quite a mess. Thanks in advance. Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Thanks Ed, I ran that command on the main server and it returned "WARNING: The local server does not have local continuous replication enabled for any storage groups. No diagnostic checks will be performed." but on the secondary machine it returned errors against all the storage groups that said the same thing: Standby Continuous Replication for storage group 'SERVER01\First_Exchange_2007_Storage_Group' is in a 'Failed' state on server 'SERVER02'. The error message is: The Microsoft Exchange Replication Service encountered an error while inspecting thelogs and database for SERVER01\First_Exchange_2007 _Storage_Group on startup. The specific error code returned is: Microsoft.Exchange.Cluster.Replay.Fi leCheckLogfileMissingException: File check failed: Logfile 'M:\Exchange\Log\E0200000001.log' was no t found. at Microsoft.Exchange.Cluster.Replay.FileChecker.CheckLogfiles(Int64 minimumGeneration, Int64 maximumGeneration) at Microsoft.Exchange.Cluster.Replay.FileChecker.RunChecks() at Microsoft.Exchange.Cluster.Replay.ReplicaInstance.ConfigurationChecker(Object stateIgnored). Does this matter since it's not enabled on the first server?

Oh and to answer your question I believe it was a cluster at some point, and I think it was about 20 months ago as that's how far back the logs go and that was the date on the VM I discovered of the secondary Exchange Server. These logs aren't safe to delete on their own are they? I've heard doing so could make the server unstable...

I don't know about Ed, but I know what I would do. Remove Exchange from that second server using add/remove programs, clearing any errors that it may well flag up so that it comes out gracefully. Then drop the machine from the domain and delete it. I would then build a new VM, Exchange 2007 SP3 and move all the user to it, so you get a clean installation. No public folders to worry about, so that means the move is pretty simple. On the old server, turn on circular logging to give yourself some space with the logs. Once you have the data off, remove Exchange from the original server, again using add/remove programs. You can then rebuild it and move everything back if you wish. The key is leaving both the old and the new systems up long enough so that Outlook redirects, although if you are on Outlook 2007, autodiscover should deal with that for you. Bit of a mess you have there! Simon.Simon Butler, Exchange MVP. http://blog.sembee.co.uk , http://exbpa.com/

That's a pretty good idea also Simon, make it pure while I can. The guy before me just did NOT seem to care. Good news is that for the short term Ed's suggestion seemed to work! I ran a backup just against the non-used public folders and they're back to 55MB where it should be. Anyway, thanks again, I'll post more on here if anything goes wrong but it looks like I'm back on track. Thanks again guys.

Try: Disable-StorageGroupCopy -Identity 'SERVER01\First_Exchange_2007_Storage_Group' -StandbyMachine SERVER02 if you do not want SCR to be running. It seems from your description that your predecessor didn't stop the replication before removing the SCR server. -- Ed Crowley MVP "There are seldom good technological solutions to behavioral problems." . "VanPower" wrote in message news:f30a043c-2a03-4105-bdbb-7711f6745237... Thanks Ed, I ran that command on the main server and it returned "WARNING: The local server does not have local continuous replication enabled for any storage groups. No diagnostic checks will be performed." but on the secondary machine it returned errors against all the storage groups that said the same thing: Standby Continuous Replication for storage group 'SERVER01\First_Exchange_2007_Storage_Group' is in a 'Failed' state on server 'SERVER02'. The error message is: The Microsoft Exchange Replication Service encountered an error while inspecting thelogs and database for SERVER01\First_Exchange_2007 _Storage_Group on startup. The specific error code returned is: Microsoft.Exchange.Cluster.Replay.Fi leCheckLogfileMissingException: File check failed: Logfile 'M:\Exchange\Log\E0200000001.log' was no t found. at Microsoft.Exchange.Cluster.Replay.FileChecker.CheckLogfiles(Int64 minimumGeneration, Int64 maximumGeneration) at Microsoft.Exchange.Cluster.Replay.FileChecker.RunChecks() at Microsoft.Exchange.Cluster.Replay.ReplicaInstance.ConfigurationChecker(Object stateIgnored). Does this matter since it's not enabled on the first server? Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."