January 2012 Entries
Troubleshooting for Microsoft Exchange

Exchange is a complex and large product which can have one thousand and one possible issues, one more obscure as the next. The purpose of this guide is to shed some light, where possible, to how things work in Exchange (and outlook), how they can break and how you should approach the issue at hand. Unfortunately it is very time consuming to create a complete troubleshooting guide where every dependency is explained in detail. But that is not the aim of this document anyways.

What is the aim? Give you, the engineer, a way to solve the most common of scenarios and information on how that piece of technology actually works. Note that there are a significant number of differences between the different versions of Exchange, which could give you a different solution for each problem.

Where to start?

In troubleshooting we need as much information as we can get. Not only do we need product knowledge but we also need to know what the problem is! Who, what, where and when would be the main pillars of that knowledge and the following items will allow you to question the client and narrow down the problem…

Getting information from the user

A number of questions (and follow ups) can be asked when contacting the user that will help you determine the scope, depth and impact of the issue. The following questions should give you an insight in to what is going on and help you determine where to look.

Who has the issue?

Maybe the most pinnacle of questions for troubleshooting an issue! With this you can add depth to the impact of the issue (CEO vs. cleaning lady) and if it is limited to only a number of users you know that similarities must exist, on some level, to have the issue occurring to a defined number of users. On the other hand, if everybody is having the issue, you can determine if the issue is occurring on the client or on the server level.

What is the impact?

Determining the impact will help you prioritizing. It should also give you a level of understanding in what kind of solutions you can apply. If everyone is down, well, there is no real issue with going for disruptive actions as no one can currently access the system anyway…

When did the issue first occur?

You would be surprised in how much this can help you track down the source of the issue. Did it start today, yesterday or last week? Maybe even years ago (yes there are users that will wait years before reporting an issue and expect you to solve it in minutes >_<).

Did this ever work for you/the user?

Apply common sense when asking this question. Some people will get offended but it can be very helpful in finding out if something broke or there is a setting wrong…

What error (code) is returned?

No problem without an error, that much is simple. Something not working, an outlook error code returned when connecting or something showing up in the event log. Each and every one of these will help you out in solving the issue faster and better.

Tools

With all the information you have obtained from the user you should be getting an idea on what is going on and what the impact of the issue is. If you know the solution to it, you can skip this section, on the other hand, if you need more information you can use the following tools to narrow down specific items and get more information on them.

Eventviewer

Maybe the single most useful tool in helping you solve a problem! Exchange errors will be logged in the application log most of the time and rarely one or two in the system log.

Exchange best practice analyser

ExBPA is a neat little tool built in to the Exchange Management Console allowing you to run some reports and get information on configuration errors in Exchange. Note that it can create performance baselines as well as check if the environment is ready for Exchange. If you are running Exchange 2003 you will have to download exBPA (here) as it is only present in 2007 and 2010.

Exchange troubleshooting assistant

Also known as ExTRA and just like the ExBPA it is built in by default in to the EMC. It contains a number of common troubleshooting paths and can be very useful to collect data automatically instead of having to scour through different manual paths. The version for Exchange 2003 is available here.

Telnet

Yes, this little client can be helpful although it is limited in to testing mailflow. Remember that on windows 2008 and up you will have to install the client before you can be able to use it. Don’t worry though. No reboot is required J. Commands to test mail flow:

EHLO toasterlabs.com
mail from: marc.dekeyser@toasterlabs.com
rcpt to: administrator@toasterlabs.com
data

Blablablabla
.
quit

You can get more information on this from the following URL:
http://www.samlogic.net/articles/smtp-commands-reference.htm

Increasing event log levels

Increasing the event log levels is a great way to get more information on what is going on logged in the event viewer (as well as to get your event logs flooded). Slightly different to use in Exchange 2003 and 2007/2010 but the result remains the same.

Exchange 2003: Right click the server object in the Exchange system manager console and go to the “diagnostic logging” tab. Increase the logging to the highest level for the entries related to the issue you are troubleshooting.

Exchange 2007/2010: I prefer the powershell route to increase the logging in these versions of Exchange. You can get the current eventloglevel by using the following command:

Get-eventlogloglevel

From this you can mark and copy the desired item you want to increase logging on by using the following command:

Set-eventloglevel –identity “MSEXCHANGESA\OAL GENERATOR” –Level High

Note that you can also pipe these commands if you want to increase everything in a certain set.

Get-eventloglevel MSEXCHANGSA\* | set-eventloglevel –level high

You can find more information about the commands used and the different levels at the following technet link:
http://technet.microsoft.com/en-us/library/dd335139.aspx

Performance monitor

If you are running in to performance issues you can use the OS built in perfmon to see what is causing your slow down. A detailed description of the performance counters are available here:
http://technet.microsoft.com/en-us/library/dd335215.aspx

Remote Connectivity Analyser

This Microsoft website allows you to test autodiscover, RPC over HTTP and activesync connections. Note that you will need a username, password, domain name and email address to test the connections. No information is stored on the Microsoft servers so in theory you are not required to use a test account, yet I still recommend it.

https://www.testexchangeconnectivity.com/

Microsoft baseline security analyser

More security oriented, the MS BSA allows you to scan for security updates present and missing from Exchange 5.5 servers and later. Download from here.

Public Folder DAV admin

As the name of the tool suggests, this tool would be used to administer and troubleshoot public folders. Download from this location.

ESEUTIL

A great tool for database recoveries! This tool will fix the edb file by either replaying log files in to the database or changing the log file replays required to get out of a dirty shutdown. There are a number of different options to run with this tool but the most important ones would be the following:

· Check for shutdown state (/mh)

· Offline defrag (/D)

· Hard recovery

· Soft recovery

You can get more information on this tool right here.

ISINTEG

This tool should always be used after running an eseutil repair. Whilst eseutil will fix the physical file it is not aware of the table structure used in an edb file. ISINTEG is specifically designed to fix the table structure where possible (and chuck the data if it is FUBAR).

To run isinteg your information store needs to be running so make sure that is happening. Typically you would run it in the following context

Isinteg –s servername –tests alltest –fix

More information is available here.

Some other tools

There are even more tools available from Microsoft that are not directly linked to troubleshooting yet still deserve a place in this document as they might come in handy at one point:

· Exchange 2007 Anti-Spam migration

· Exchange server Jetstress

· Exchange server stress and performance

· Exchange load generator

· Exchange server profile analyser

More information on these tools (and their download locations) can be found here:
http://technet.microsoft.com/en-us/exchange/bb330849

Until next time!

 

Technorati Tags: ,,,,,,,,,,,
,,,,,,,,,,,,,,
,,,,,,,,,,,,,,
,,,,,,,,,,,,
,,,,,,,,,,,
,,,,,,,,,,,,,
,,,,,,,,,,,

Recovery storage groups

As you might, or not, be aware off there is no item level based recovery in Exchange that is natively supported by Microsoft. So to perform recoveries we need the recovery storage group (captain obvious). The purpose of this is to mount the database you want to recover from on the Exchange server and use exmerge to merge the data you are recovering into the active database. An RSG will not be accessible to users and you can only create one at a time.

Exchange 2003:

1. Open Exchange system manager
2. Drill down to the server you want to recover to
3. Right click the server and select New > Recovery storage group
4. Specify the drive you have restored the database to. If possible use the same drive as the active database as this will improve performance quite a bit.
5. Click ok J
6. Right click the RSG and select “Add database to recover”
7. Select the right database you are going to recover.
8. Make sure that “This database can be overwritten by a restore” is checked (by default is should be)
9. Mount the database
10. Select the database in the recovery storage group, open the mailboxes container .
11. Select and right click the user(s) you want to restore.
12. Run Exchange task from the menu
13. Select the “recover mailbox data” task
14. Depending on your situation select either the Merge data or Copy data context
15. Schedule if necessary
16. Watch as your data is getting recovered.

Once this process is complete all data will be where it is supposed to be once more!

Exchange 2007:

1. Open up the Exchange management console
2. Go to the tools subset and open the Database Recovery Management tool
3. Select the storage group you want to link to the RSG
4. Double check the information presented in the next screen and click the Create the recovery storage group.
5. By default the RSG will be linked to the following folder: C:\program files\microsoft\exchange server\mailbox\<storage group>\RSGxxxxxxxxxx
6. Recover files to the RSG folder
7. Once recovered g o to the recovery storage group management tool and slect to mount the database.
8. Once mounted, go back to the task center and select Merge or copy mailbox contents
9. Make sure the proper database is selected and click on the gather merge information.
10. If you are dealing with a dial tone database click the “Swap database configurations” checkmark. If not, just click next
11. Click the Perform Pre-merge task
12. Select the mailboxes you wish to recover and let ExTRA do its thing.
13. Once the process is completed use ExTRA to dismount and remove the recovery storage group. Once that has been done you manually can remove the files in the RSGxxxxxxxx folder.

And that is it!

Exchange 2010:

1.       Open the exchange management shell

2.       Type in the following:

a.       New-mailboxdatabase “name” –server “servername” –recovery:$true –edbfilepath “path to restored edb file”

b.      Mount-database “name of DB you just created”

c.       Get-mailboxstatistics –database “name of restored database”

d.      New-mailboxrestorerequest –sourcedatabase “name of recovery database” –sourcestoremailbox “Username” –targetmailbox “emailaddress of target mailbox”

That will create a new recovery request. You can view the state of the request by using:

Get- MailboxRestoreRequest

Once completed, remove the request with

Get- MailboxRestoreRequest –status completed | remove-MailboxRestoreRequest

And that is it!

EDIT: Added the 2010 section :)

Technorati Tags: ,,,,,,,,,,,,,
,,,,,,,,,,,,,,
,,,,,,,,,,,,,,
,,,,,,

3 Comments Filed Under [ Exchange ]
The information store service is stopped and will not start

Troubleshooting the information store service can be straightforward yet immensely complicated if you don’t know what is going on. For this reason I think it is important to know that there are 3 likely culprits that will cause your information store service to go down and refuse to come up:

· Database problems
· Active directory problems
· Antivirus software

Trying to work out which is the culprit can be hard, elimination is probably the easiest way to work through this… So let us get started!

1. Open Exchange Management Console (or the Exchange System Manager if you're on 2003)
2. Expand until you reach the database
3. Open the properties of the database
4. Check "Do not mount this database on start up"
5. Click ok
6. Open services.msc

Next:

1. Open Start, run
2. Type in services.msc, click "OK"
3. Scroll down until you reach the Microsoft Exchange Information Store Service.
4. Right click the IS service and try to start it.
5. Does it start?

If the IS service mounts at this point you're most likely going to have a corrupt database. Open a command prompt and run the "ESEUTIL /mh <path to priv1.edb>" command. Scroll down until you see the "State" and "Log required" Field:

     

clip_image001

     

If you have the database state on "Dirty Shutdown" you'll need to run the following commands on the database:
1. Eseutil /p <path to priv1.edb>
2. Eseutil /d <path to priv1.edb>
3. ISInteg -s "server name" -test alltest -fix
Follow the on screen instructions for the ISInteg and repeat ISInteg until all errors have been corrected. This is extremely important as ISInteg fixes the database tables and will either fix or get rid of corrupt items.
Depending on how big your database is it might take a while to complete the database recovery. If you need to get your users back online fast you can use the Dial-tone recovery method. This means you'll move all the files in the physical location of the database where you can perform the recovery and mount the database in ESM or EMC. It will tell you that it could not find a database and ask you if it can create a new (blank) database. If you confirm a new database can be mounted and users can access new emails that are received if they are in online mode and access their old mails only if they have the cached mode enabled.
Now, in case the above did not get your service to start up you have reached a pickle. We need to find out if it's an AD or AV issue!
1. Open Start, run
2. Type in services.msc, click "OK"
3. Scroll down until you reach the Microsoft Exchange services.
4. Note what services are down. Is only the IS service not functional or is the transport service down as well?
Note: If you're transport service is down as well the likely hood of it being an Active Directory issue increases!

Try starting the IS Service, it will error out but what is important is that you will now have some events logged in the application log. In most cases these events will be ID 5000 and 1121.

Going into the event log:
1. Open start, run
2. Type in eventvwr, click "OK"
3. expand until you hit the "Application log"
4. Identify the recent events from source "MSExchangeIS"
5. Also have a look at the events from source "ADAcces"
If events 5000 and 1121 are logged they should point you in the right direction for what is wrong with the AD. Usually it's Exchange that cannot contact the GC (so check if the domain controllers are reachable!. In that case there's a quick and dirty workaround. Note that you should only do this to restore functionality for your environment and it is a temporary measure. After you repair the AD issues you are highly advised to let Exchange choose its DC/GC!

For Exchange 2003:

1. Open the Exchange System Manager
2. Expand untill you hit your Exchange server
3. Open the properties of the Exchange server
4. Switch to the "Directory Access" tab
5. Select "Domain Controllers" in the drop down list
6. Select a working DC
7. Deselect "Automatically discover Servers"
Note: If your Exchange server is installed on a Dc it will always contact that DC, no matter what you set in this field.

For Exchange 2007:
1. Open the Exchange management shell (powershell for Exchange)
2. Use the “Set-Exchangeserver -StaticConfigDomainController -StaticDomainController –StaticGlobalCatalog” command.
Note: If your Exchange server is installed on a Dc it will always contact that DC, no matter what you set in this field. For Exchange 2010 you can use the same command as for Exchange 2007.

In case there are no events 5000 & 1121 you'll most likely have events 9565 & 9564 logged. These are caused by the antivirus program being broken. You'll want to disable the antivirus key in the registry:

1.Click Start, and then click Run.
2.In the Open box, type regedit, and then click OK.
3.In Registry Editor, locate the following subkey in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\VirusScan
4.In the right pane, double-click Enabled.
5.Click Decimal, type 0 in the Value data box, and then click OK.
6.On the File menu, click Exit to quit Registry Editor.
7.Start the Information Store.
http://support.microsoft.com/kb/323664
Remove your AV in a service window and reboot the server.

 

Technorati Tags: ,,,,,,,,,,,
,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,
,,,,,,,,,,,,
,,,,,,,
,,,,,,
4 Comments Filed Under [ Exchange ]
Troubleshooting incoming mail flow (or the lack thereof)

Usually you’ll get alerted to this issue with a call saying that users have not gotten any new email for a while. They will still be connected to Exchange in outlook, you can still log on to the OWA and, when looking at your hub servers, you can see that the all services are up and running (Note that it is possible the transport service could be stopped…).

A number of reasons can exist as to why you are not getting any mail flow:

· Your recipient polies are not configured correctly

· The receive connector is configured incorrectly

· The mx record no longer exists

· The mail server is not reachable from the internet

· You ran out of space on your queue database drives

Let us look at each of these possible issues individually…

Testing mail flow

Before we actually go ahead and look at each of the items I would recommend, if possible, to test mail flow by running telnet and using the ehlo commands to connect to the server from both external and internal servers. That way you can narrow down where the issue is located.

Recipient policies

The recipient policies are responsible for “stamping” your users with the correct SMTP (email) address. If your users are not “stamped” with the correct address you will not receive email. Very simple yet oh so annoying… This will most likely be a problem you run in to at the setup of a new domain. Checking if the correct recipient policy is set up is quite simple and resolving it even simpler.

For Exchange 2003:

1. Open up the Exchange system manager

2. Expand down to recipients, recipient policy.

3. Select the recipient policy and check that you have the correct domain(s) listed there

For Exchange 2007/2010:

1. Open up the Exchange management console (EMC)

2. Expand the organization configuration

3. On the Hub Transport item, select the email address policy.

4. Check that the policies have the correct domains listed.

It is important to note that you need to have the correct domain listed in the accepted domains tab under hub transport before a correct email address policy can be created.

Receive connector

Exchange needs a receive connector to allow mail servers to connect to your mail server and actually deliver mail.

For Exchange 2003:

1. Open up the Exchange system manager

2. Expand down administrative groups, first administrative group, routing groups, first routing group and select the connectors container

3. You should see the SMTP connector here, if not you will have to create a new one.

4. Take the properties of this connector and check them for accuracy.

For Exchange 2007/2010:

1. Open up the Exchange management console.

2. Expand down to server configuration, Hub transport

3. Select one server and check it has two receive connectors

4. On the default receive connector, right click and select properties

5. Make sure that on the security groups tab the “anonymous” entry is checked.

6. Check that the network tab is configured correctly.

7. Rinse and repeat for all servers listed in the hub transport tab.

MX records

The mx records are a part of the DNS infrastructure and let other mail servers know what IP to deliver the mail for your domain on. You can do a lookup for these records by using nslookup.

1. Open a new command (DOS) prompt
2. Type in nslookup
3. Set type=mx
4. Enter your domain name, e.g. toasterlabs.com
5. Make sure it returns the correct IP address for your domain.

There are a lot of things you can do with MX records. For more information please check:
http://en.wikipedia.org/wiki/MX_record

The mail server is not reachable from the internet

This could happen if a new firewall is installed but the rules and port forwarding are not configured correctly. If you want to test if the server is reachable from the internet try to use telnet to connect to the public ip address on port 25

telnet> o 132.157.125.23 25

Note that a default Exchange header response to this looks as follows:

220 hostname.domain.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.1600 ready at Thu, 30 Nov 2012 18:09:43 -0600

If it does not look like this you are not connected to an Exchange server!

The mail queue

Exchange uses a number of queues to store the incoming mails before they get either sent on to other Exchange servers or delivers it locally. If the location of these queues are not changed they will be on the C:\ drive. As we all know, the C:\ drive has some strange gravitation field that causes it to fill up (unless you actually maintain that…). If you see it has less than 3GB available and you are not receiving email, you are faced with an automated protection mechanism that stops Exchange form accepting mail.

The mail queue

Exchange uses a number of queues to store the incoming mails before they get either sent on to other Exchange servers or delivers it locally. If the location of these queues are not changed they will be on the C:\ drive. As we all know, the C:\ drive has some strange gravitation field that causes it to fill up (unless you actually maintain that…). If you see it has less than 3GB available and you are not receiving email, you are faced with an automated protection mechanism that stops Exchange form accepting mail. This feature is called backpressure and is only present in the 2007 and 2010 versions of Exchange. Your C drive can, however, still fill up on an Exchange 2003 server Smile. In case backpressure strikes you should see the following events:

Event log entry for critically low available disk space
Event Type: Error
Event Source: MSExchangeTransport
Event Category: Resource Manager
Event ID: 15006
Description: The Microsoft Exchange Transport service is rejecting messages because available disk space is below the configured threshold. Administrative action may be required to free disk space for the service to continue operations.

Event log entry for critically low available memory
Event Type: Error
Event Source: MSExchangeTransport
Event Category: Resource Manager
Event ID: 15007
Description: The Microsoft Exchange Transport service is rejecting message submissions because the service continues to consume more memory than the configured threshold. This may require that this service be restarted to continue normal operation.

You have 2 possible ways to solve this:

1. Clean up your C drive

2. Move the transport queue location.

Personally I believe you should not leave the queues on the C drive as it is often overlooked, but then again, you should not allow the C drive to fill up anyway J.

To move the transport queues you should perform the following actions:

For Exchange 2003:

1. Open up the Exchange system manager

2. Expand administrative groups, first administrative group, servers, expand the server that is supposed to be receiving emails, expand protocols and lastly, expand SMTP.

3. Right click the SMTP virtual server and select stop.

4. Right click it again and select the properties.

5. Click messages and type in the new path for the Badmail directory and for the Queue directory.

6. Right click the SMTP virtual server and select start.

For Exchange 2007/2010:

1. Open up a notepad session as administrator (right click, run as administrator)

2. Open the following file through notepad: C:\Program Files\Microsoft\Exchange Server\Bin\EdgeTransport.exe.config

3. Find the following section <appSettings>

4. Change the <add key=”QueueDatabasePath” value=” “> /> to reflect the new path.

5. Save and close

6. Restart the transport service

7. Verify the new mail.que and trn.chk files have been created at the new path

8. Remove the mail and trn files at the old path.

This should cover most of the issues you can encounter with mail flow. It is important to remember that these are all solutions for “bigger” issues, aka all users have been affect. In case there are only a number of users that are experiencing no mails use the message tracking log in the Tools section of the EMC to find out if they were even sent any mail… They might just be unpopular J.

4 Comments Filed Under [ Exchange ]
New users do not show up in outlook when in cached mode

A fairly common (and annoying) problem which seems to like to popup after migrations, yet not unsolvable. The key issue here is that there are new users added to the directory but they are not showing up in outlook. Now, if you are like most organisations then outlook will be operating in cached mode. So log in to OWA and test if you can see the new users there. I’m giving it a 99% chance that you will (and if you don’t you have a serious problem at hand!)

The reason you are not seeing these new users appear in outlook cached mode, but can see them in OWA, is because for one or another reason the offline address book is not generating properly. The easiest thing to do here is to create a new oab, forge generation, assign it to a mailbox database and force downloading of the oab in an outlook client to verify if that worked. Alternatively you can increate logging on the MSEXCHANGESA\OAL Generator to see if the new address book generated successfully.

For Exchange 2003:

1. Open Exchange system manager

2. Drill down to recipients, offline address lists

3. In the right pane you should see the default offline address list.

4. Right click in the right pane and create a new offline address list.

5. Now drill down to the mailbox database, right click it and set the new OAB to be the default for that database.

6. Open outlook with a mailbox that is residing in that mailbox database

7. In outlook, click on the down arrow next to Send/receive. Selects download address book and click OK. Note that if asked, you should select to download the entire address book and not just the changes.

For Exchange 2007/2010:

1. Open the Exchange management console

2. Drill down the organization configuration, mailbox

3. In the action pane select the New offline address book

4. Give the OAB a name, select a generation server (in case of a CCR this needs to be the active node)

5. Include the default global address list

6. When presented with the distribution points page enable the web base distribution and, in case of outlook 2003 clients, enable the public folder distribution.

7. Once the wizard has completed, right click the new OAB and select to generate the OAB.

8. Now drill down to the mailbox database, right click it and set the new OAB to be the default for that database.

9. Open outlook with a mailbox that is residing in that mailbox database

10. In outlook, click on the down arrow next to Send/receive. Selects download address book and click OK. Note that if asked, you should select to download the entire address book and not just the changes.

This should resolve the issue with users not showing up in Outlook when in cached mode. Feel free to delete the old OAB,

2 Comments Filed Under [ Exchange ]
Allowing internal services to relay through exchange

We all get those requests where there is a certain service that requires to send mails by using your company email server. Whilst an open relay is generally a way to get your domain blacklisted forever, allowing an internal relay is usually a necessity. By default Exchange is setup to deny relaying from any IP address, including your internal network. In this section I will show you how to allow relaying from your internal network.

Exchange 2003:

1. Open the Exchange system manager

2. Expand the organization object, servers, server name and then expand the protocols node

3. Expand the SMTP node and right click the virtual SMTP server on which you want to allow relaying and click properties

4. Click relay

5. In the relay restriction dialog box you will see that the default is the “Only the list below”.

6. Click add and enter the IP address of the service you want to allow to relay

7. Click OK, Apply and OK

Your Exchange server will now allow that IP address to relay.

Exchange 2007/2010:

1. Open the Exchange management console.

2. Expand the server configuration, down to the Hub transport.

3. Select the hub transport you want to configure for relaying.

4. From the actions pane, select “new receive connector”.

5. Name the SMTP connector in the new dialog that pops up (I recommend “Allow Relay” for simplicity sake) and select Custom as the intended use for this receive connector.

6. Choose next.

7. On the local network settings page click the add button and click on the add button.

8. You can specify an IP address of your server here, leave the port on its default.

9. On the remote network settings window click add to add in the IP address of the service you want to grant relaying rights.

10. Click next, New and the connector will be created.

11. Right click the new connector and choose properties.

12. Go to the permissions tab and check the “exchange servers” box.

13. On the authentication tab check the externally secured box.

14. Choose OK.

That is it and you should not be able to relay through the Exchange 2007/2010 server.

Technorati Tags: ,,,,,,,,,,,,,
,,,,,,,,,,,,,
,,,,

Add Comment Filed Under [ Exchange ]
Reseeding the passive node of a DAG/CCR

Running a CCR or DAG is a great way to have a server resilient database. Relying on an asynchronous copy of the log files (Each log file gets copied over only when the store has released it) it copies over the log files from the active node to the passive node so it can be played in to the passive nodes database. But whilst being a great failover solution both solution are also quite high-maintenance, CCR more so than a DAG. Running in to a situation where the CCR or DAG is down because of to many missing log files is annoying at best, but manageable.

When that happens it will be required to reseed the passive node, a time consuming process but fairly easy.

Reseeding the passive Exchange 2007 node:

1. Logon to the passive node
2. Suspend the replication between two nodes by executing Suspend-StorageGroupCopy -identity “<servername>\Generic Storage Group”
3. Delete or move all .log, .chk, .edb files on the passive node (for that storage group: F:\Generic storage group)
4. Copy over the .edb from the active node to the passive node
5. Resume the replication between the nodes by executing Resume-StorageGroupCopy -identity “<servername>\Generic Storage Group”

This should reseed the log files and .chk files to the passive node. Once the reseeding is complete the storage group should show up as healthy in the console (or by using the Get-StorageGroupCopyStatus command.)

Reseeding the passive Exchange 2010 node:

1. Logon to the passive node
2. Suspend the replication between the two nodes by executing suspend-mailboxdatabasecopy –identity Mailboxdatabasename\servername
3. The copy status will change to failed and suspended.
4. Reseed the database by executing Update-MailboxDatabaseCopy -Identity "Mailbox Database \servername" –DeleteExistingFiles (add in –manualresume if you want to prevent the automatic replication resume)

How long either process will take depends on the network speed. It will, however, bring your CCR or DAG back in to a current state. If Exchange is still complaining about to many missing log files (it happens >_<) you can opt to enable circular logging, take a backup (important!) and disable circular logging. Use that as a last resort only!

Technorati Tags: ,,,,,,,,,,,
,,,,,,,,,,
,,,,,,
Add Comment Filed Under [ Exchange ]
Sopa to be revived and put in action in Ireland?
Remember SOPA? The proposition that could have turned law if the internet had not revolted against it? Well, Ireland might be getting it's own version of this law, only this time it won't be discussed in a democratic way, oh no, it will be pushed through to become a law by a "Ministerial Order" issued from no other then Sean Sherlock!

If you believe SOPA should be stopped at all fronts, sign the petition. Tell other people. Remember that even the smallest drop can make an ocean move...

http://blog.blacknight.com/say-no-to-an-irish-sopa-style-law-say-yes-to-democracy.html
http://stopsopaireland.com/


2 Comments Filed Under [ General ]