Event ID 514 warnings – transaction logs numeric limit near

[Exile_Ken]

One of our Exchange 2003 servers is getting Event ID 514 messages (source
ESE) which shows that the transaction logs for our First Storage Group are
nearing their sequential numeric limit of FFFF0. Based on my calculation I
have about 8 weeks before I get to the critical stage. I have read a few KB
articles ( KB830408 ) and also 2 very good posts on the “You Had me at EHLO”
exchange team blog (http://msexchangeteam.com/archive/2008/08/04/449457.aspx)
, so I understand what needs to be done ( shut down mail stores, check for
clean shutdowns, move all transaction logs to another location, startup the
mail stores which will restart the numeric sequence at 00001).

My question is can I use the Exchange Troubleshooting Assistant v1.1 to do
this on Exchange 2003 SP2? This tool was released with Exchange 2007, and
the blog mentions that it is the preferred method of dealing with the issue,
but it is not clear if the tool can be used with Exchange 2003. So can I use
the tool, or should this be done using the manual steps in KB830408?

Also, has anyone experienced and issues after running this procedure.

Thank you in advance for any information you can provide.

E_K

[Susan]

I've not tried running the 2007 tool to do this...but I just recently had to
shut down the affected stores, move all the transaction logs, and remount
the stores for one storage group that ran into this problem...it was not any
issue. I made certain to do a good full backup before I did this (thus
minimizing the number of transaction logs I had to move), then another one
immediately after...

--
Susan Conkey [MVP]

"Exile_Ken" <exil...@news.postalias> wrote in message
news:26C24695-8FE9-4F1A...@microsoft.com...

[Mark Arnold [MVP]]

There shouldn't be any problems with the manual method as per KB. It's
not particularly compex so the manual tasks should be fine.

[Exile_Ken]

Thank you for the prompt replies. I will go with the Manual method.

E_K

[Exile_Ken]

Back again.

This weekend I will be applying the latest batch of Security patches to our
e-mail server, so I plan on also resetting the transaction log numbers as I
will have the system in a maintenance window. I have a few things I want to
clarify before proceeding, and hope that you attentive folks who helped me
out last month will be kind enough to do so again.

In reading KB830408 (which upon closer examination is pretty ambiguous ), it
talks about going into the properties for each of the mail stores in the
storage group that needs to have its log numbers reset, and
to select the “Don't mount this store at start-up” option. The next part is
not really clear, but it seems to suggest stopping the ME Information Store
service using the “Kill command “Kill the store to dismount the database that
could not be dismounted”. Step 3 then states “Restart the store so that
other storage groups can be mounted.” Why is this necessary? It seems to me
I should be able to just dismount the mail stores in the storage group that
needs to be reset without affecting the other (in my case two) storage groups
on the server, and the mail stores that reside in them. Is this step
assuming that the limit of the logfiles has already been reached, that the
mail stores are “hung”, and these steps need to be taken in order to get the
mail stores in the affected SG dismounted? Unless I am missing something, it
seems I should just be able to dismount the mail stores in the affected SG,
ensure they have been shutdown clean, move the log files to another location,
and mount the mail stores. In another, non MS forum, I found the following
procedures from a user by the name of Oliver. These look pretty
straightforward, and I should think that this procedure will work just fine:

1. Backup the Storage Group .
2. Dismount all stores in the SG .
3. Perform an eseutil /mh against all stores in the SG, confirming they are
in a 'clean shutdown' state .
4. RENAME (note not delete) the Transaction Log folder for the SG .
5. Bring the stores back online .
6. Verify all are online successfully, perform a test login to mailboxes if
necessary .
7. Confirm new Transaction Log folder has been created .
8. Backup the Storage Group .
9 Delete the renamed folder from Step 4. .

If there is any reason that you experts can think of that I would need to
kill the IS service, and do all the other things mentioned in the KB, please
speak up.

One last item I am not sure about, we make extensive use of Public folders.
Of course, the Public Folders store is in the Storage Group that needs the
log numbers reset. Do I need to take any extra precautions, or do anything
different because of the presence of the Public Folder store (I don’t think
so , but thought I would ask just to be sure)?
Once again, thank you in advance for sharing your expertise.

E_K

[Susan]

I didn't need to kill the store process...only thing I see that might be a
problem here is renaming the folder that contains the transaction log
files...you would also need to create a new folder with the old
name...personally, I would just move the transaction log files to another
location...after you do a backup, there shouldn't be very many of them at
all...everything else looks OK, I believe...it's really pretty
painless...and I wouldn't delete the old transaction log files for a couple
of days...

--
Susan Conkey [MVP]

"Exile_Ken" <exil...@news.postalias> wrote in message

news:1CA6E0CA-7C7F-4CA1...@microsoft.com...

[Rich Matheisen [MVP]]

On Fri, 17 Oct 2008 10:28:00 -0700, Exile_Ken
<exil...@news.postalias> wrote:

>Back again.
>
>This weekend I will be applying the latest batch of Security patches to our
>e-mail server, so I plan on also resetting the transaction log numbers as I
>will have the system in a maintenance window. I have a few things I want to
>clarify before proceeding, and hope that you attentive folks who helped me
>out last month will be kind enough to do so again.
>
>In reading KB830408 (which upon closer examination is pretty ambiguous ), it
>talks about going into the properties for each of the mail stores in the
>storage group that needs to have its log numbers reset, and
>to select the “Don't mount this store at start-up” option. The next part is
>not really clear, but it seems to suggest stopping the ME Information Store
>service using the “Kill command “Kill the store to dismount the database that
>could not be dismounted”.

Since you haven't exceeded the maximimum number of log files, the
process doesn't really apply to your situation.

[ snip ]

>Unless I am missing something, it
>seems I should just be able to dismount the mail stores in the affected SG,
>ensure they have been shutdown clean, move the log files to another location,
>and mount the mail stores.

Yep. But I'd also move the *.chk file along with the log files.

>In another, non MS forum, I found the following
>procedures from a user by the name of Oliver. These look pretty
>straightforward, and I should think that this procedure will work just fine:
>
>1. Backup the Storage Group .
>2. Dismount all stores in the SG .
>3. Perform an eseutil /mh against all stores in the SG, confirming they are
>in a 'clean shutdown' state .
>4. RENAME (note not delete) the Transaction Log folder for the SG .
>5. Bring the stores back online .

Oops! Now the databases won't mount!

If you rename the directory you'll have to create a replacement for it
(named identically and on the same drive).

>6. Verify all are online successfully, perform a test login to mailboxes if
>necessary .
>7. Confirm new Transaction Log folder has been created .

You should be doing that at step 5A.

>8. Backup the Storage Group .
>9 Delete the renamed folder from Step 4. .

Since it's not taking up a lot of space, why not keep it around for a
couple of days . . . just in case.

>If there is any reason that you experts can think of that I would need to
>kill the IS service, and do all the other things mentioned in the KB, please
>speak up.

Don't kill the service, just dismount all the databases in the storage
group.

>One last item I am not sure about, we make extensive use of Public folders.
>Of course, the Public Folders store is in the Storage Group that needs the
>log numbers reset. Do I need to take any extra precautions, or do anything
>different because of the presence of the Public Folder store (I don’t think
>so , but thought I would ask just to be sure)?

Nope. The ESE and its log files don't care what's in the file. That's
the job of store.exe.
---
Rich Matheisen
MCSE+I, Exchange MVP