EVent ID 1022 MsExchangeIS warnings

[purepest]

Hi

One of our exchange servers has a lot of event id 1022's in it.

The messsage says Logon failure to database and the error is -1069.

I have checked the internet and it mentions people trying to login while their mailboxes are being moved. This isn't the case.

I cannot find any information on 1069.

I have checked the permissions on the user accounts mentioned in the logs (but to be honest its most of the users on the information store) and they have the SELF permissions assigned ok.

The System mailbos for the store is fine as well. I have compared it to working system mailboxes.

When the users try to use outlook they get operation failed.

HELP
SOS

 

[58sniper]

1069 can be reported for a couple of things. Can you cut&paste the text from one of the errors?

Pat Richard, MCSE(2) MCSA:Messaging, CNA(2)

 

[xmsre]

Event ID 1022 is a logon failure and should be a bit more specific in the text of the event. -1069 is Jet_errVersionStoreOutOfMemory. It would be interesting to know how you managed to get that, but you should probably give MS a call.

 

[purepest]

In the end we just restarted the information store service and it came back online.

We did mention a call to MS which always ends in my boss having a heart attack because of the cost involved

Its an interesting combination of events that lead upto it. The exchange box is on a neverfail pair and we had performed a practice fail over that morning. Although this was done approx 2.5 hour before the failure.

The was also a new symantec def rolled out that morning which could have caused the problem.

Really dont know

When I get back to work I will se if the event is still there and copy it into this ticket

thanks for the help

 

[xmsre]

It's some kind of issue with an internal table called the version store running out of space. I've seen orphaned b-tree splits, backgroud theads starved for proccessor time during high CPU utilization, some long running transaction is left open, and such cause this in earlier versions of exchange, I was just curious what could have caused it here.

I'm not very familiar with the Neverfail product, and all I seem to be able to google is marketing fluff.

I assume there's a replication piece and some sort of failover piece. Depending on how the replication was implemented (sync, semisync, or async) that could result in something like this during a cut over. The theory would be that a transaction was left open and 2.5 hours later the version store filled to capacity.

I'm glad to hear that a restart cleared things up.