Exchange Server 2007 has some very useful replication features such as Local Continuous Replication (in RTM and SP1) and Standby Continuous Replication (in SP1 only). These features can provide nice and simple disaster recovery options by replicating your storage group logs and databases to another location, be it another disk/LUN with LCR or another mailbox server with SCR.
However, if you choose to implement LCR or SCR you should be aware of the implications for your backups. A normal Exchange backup will truncate the transaction logs for your storage group, however when LCR or SCR are deployed this truncation may not work as you first expect.
One example of this is when using SCR to replicate your storage group to another mailbox server. The source mailbox server ships each transaction log to the SCR target where it is replayed into a replica of the database. In this scenario there are two queues created – the copy queue and the replay queue.
The copy queue length is the number of transaction log files yet to be shipped to the standby server. The replay queue length is the number of transaction log files yet to be replayed into the replica database (in this case the default 24 hour replay delay has been used).
Now that the source server knows it is shipping logs to a standby server it will be sure not to remove any transaction logs that are yet to be shipped. This would mean that if replication is suspended or fails for any particular reason, and the copy queue length begins to grow quite long, that the source server will not truncate the logs during a normal backup.
However, even when SCR appears healthy and has a zero length copy queue there may be problems with the RPC calls between the servers to notify of log truncation events. If the source and target cannot verify with each other that the logs have shipped and replayed then the source server will not truncate the logs during a normal backup.
To monitor for these types of scenarios it is wise to check for MSExchangeRepl warnings and errors on the target server. For example:
Event Type: Warning
Event Source: MSExchangeRepl
Event Category: Service
Event ID: 2137
Time: 6:31:25 AM
Log truncation request to the Information Store using RPC has failed for storage group ‘SERVER1First Storage Group’. Error code: 4294966264.
In the near future I’d like to nail down some more specific scenarios, causes and remedies, but for now I’ll just summarise by saying if you are having backup problems in an environment where LCR or SCR are deployed, look to your event logs for MSExchangeRepl errors and consider reseeding your replicas to get your backups behaving normally again.
In some companies different departments or branch offices require different primary SMTP addresses. You can configure these for users with Email Address Policies. In this example the company wants all users to have an @company.com address, but each branch office’s users have a primary email address representing that branch.
First we must make sure each of the domains is included as an Accepted Domain, using the New-AcceptedDomain cmdlet.
Exchange Server 2007 installation is a very complex process, but both the GUI and command line methods reveal little about what is actually going on during the installation process.
The installation process writes all of the actions and outcomes to a log file at C:ExchangeSetupLogsExchangeSetup.log. This is helpful for troubleshooting errors during installation, but can also be used to watch the install as it running. Since Notepad is no good for this you will want to use a utility such as Baretail.
Baretail is a Windows utility that works in a similar fashion to the Linux command “tail -f”. You can open a log file and it will automatically display new entries as they are written to the file.
If you enjoy seeing the full details of complex setup routines, or just like to see things ticking over to reassure you that nothing has stalled, then Baretail is for you.
The title might make no sense, but it comes from a conversation that went on in the office today. There seemed to be three things that are heard from customers on a regular basis that can be paraphrased like this:
I don’t want a proposal, I just want you to tell me what you’re going to do and how much it will cost.
Yes, thats what the proposal does. It tells you what we’re going to do, in the process defining the boundaries of the work (what is in and out of scope) and the price (broken down into hardware, software and labor components).
I don’t want a design, just stick it in and configure it up.
Okay, but if it doesn’t work you promise not to get upset?
I don’t want a project manager, just get someone to let me know how things are going each day.
So of the five engineers doing the work, which one do you want to down tools every day, talk to the other engineers, and then report the progress to you? That engineer might fall a bit behind, especially if you send him back with follow up questions, but thats okay right? He might need to take a little more time each week to keep the project plan updated and circulate and follow up on minutes from meetings. Oh you don’t want a project plan or meeting minutes? No problem, we’ll just cover each decision point over and over at every meeting, and rehash the entire task list and dependencies as well. I could go on and on about this one…
Often customers want these things and only realise it when things go wrong. Then again, sometimes a project can go completely off the rails and they still don’t realise what they want.