What a week!
So Monday comes along and we get a few users complaining that they couldn’t turn off their Out Of Office. So after a bit of head scratching I managed to turn it off by doing the following:
– Downloaded MFCMapi.exe
– In the main window choose;
– Session-> Logon and Display Store Table
– Select the Outlook mail profile to logon to when prompted.
– You’ll now see a list of your configured message stores in your mail profile.
– Select your mailbox by looking at the Display Name column.
– In the pane below, some properties will get loaded.
– Look at the Property Name(s) column and select the entry called;
PR_OOF_STATE
– When you look at the Value column for this property, you’ll see it is now set to True.
– Double click the entry to disable the check box in front of “Boolean”.
– Press OK to close the dialog.
– Log off your session via;
– Session-> Logoff (thanks to MSOutlook.info)
Now this worked but oddly enough, it kept happening for more users.
During the day a few other users complained that when they email a meeting request to a room the room the request doesn’t get processed by the room and the meeting doesn’t get booked.
So after a think, I started to wonder if maybe this was a issues with our Microsoft Exchange Mailbox Assistant and the Active Directory Topology Service on our Mailbox Server..
So that evening I did a quick restart of the services…nothing.
So next I tried a trusty server reboot of both our Hub Transport / Client Access and our Mailbox server…nothing!
At this point I’m mildly panicking! So as a methodical thinker,
– I created a new user and tested OOF – Broken.
– Tried to repair the user with:
New-MailboxRepairRequest -Mailbox Test1.Account@targetgroup.com CorruptionType,SearchFolder,AggregateCounts,ProvisionedFolder,FolderView
– Moved the user to another Mailbox Database – IT WORKS!!!
– Moved the Room to another Mailbox Database – IT also Works!!
So it looks like the Database is knackered! Well I guess I could move all the users to another Database but that would ruin my DAG so I’d rather not! So what’s my other option, repair the database I guess and look for any broken mailboxes!
First things first, back up the Database, thank you Veeam!
Then ran the following via PowerShell:
New-MailboxRepairRequest -Database "MY-DATABASE" -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview
And kept an eye on the event viewer for the following:
10059- A database-level repair request started.
10047- A mailbox-level repair request started.
10048- The mailbox or database repair request completed successfully.
10059- A database-level repair request started.
10062- Corruption was detected. View the repair log details to see what the corruption type was and if it was repaired.
The following is an example of the information you would get if the repair request detected and repaired a mailbox with event ID 10062 – Corruptions detected during online integrity check for request 321c88e0-0ad2-4e15-b93b-197a94efd1bd
Mailbox:C51AB7C3-9EB7-40C9-AAC6-953FD084AF59
Database:MBD01
Corruption Is fixed FID Resolution
Folder BacklinksYes1c7c-BC72D267870102Update
Folder Aggregate CountYes1c7c-BC72D267870102Update
So after I ran this, I found absolutely no faulty mailboxes which made me worry that this repair had done a sum total of nothing!!
But Wham, it all seems to be working!!
Oddly enough the following week another Database on another site started doing the same the thing but again a database repair sorted the issue…again though finding no faulty mailboxes.
Hope this helps someone else.
