how to delete an item from schedule+ free/busy that says it is already deleted, but is halting publishing of free/busy

I have a user who's free/busy information isn't available, so I tried simple things, like making sure at least 2 months are published, /cleanfreebusy, made sure replication is woking across servers, turned up replication error logging, anything I could think of.

Inside of the schedule+ free/busy folder while viewing from ESM, there is a replication message for this user, but when I double-click on it, or try to view the contents of the message I receive a "404 Page can not be displayed" error.  When I try to delete it I recieve "some items can't be deleted.  They were either moved, already deleted, or access was denied."

I have also tried to remove this item using MBDVU32, but when I delete it from there nothing changes, and this message is still there.

Any ideas how I can get rid of this message so I can start republishing his information?
LVL 3
bribri007Asked:
Who is Participating?
 
SembeeConnect With a Mentor Commented:
I have nothing else to suggest at this time except a call to Microsoft. It isn't an issue that I have seen before, so I have no first hand experience.

Simon.
0
 
SembeeCommented:
You are not supposed to manually modify items in the free/busy folder - Exchange looks after that itself.

Any reason you are still on Exchange 2003 SP1? I would suggest an upgrade to Exchange 2003 SP2 before you go any further because at the moment it cannot be clear if that is not the cause of your problems.

Simon.
0
 
bribri007Author Commented:
DARN!  I have to correct that we are on SP2.  We are on windows 2003 SP1.  My first post and I already got something wrong...

I do recognize manually deleting something from the free/busy, but I have just inherited this exchange org, and this is one of the problems that came with it.

Thanks for looking at this!
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
bribri007Author Commented:
As opposed to trying any further to delete this item, what would be the potential ramifications of changing this users legacyExchangeDn using ADSIEdit?

What else does this field map to/do aside from the free/busy info?
0
 
bribri007Author Commented:
nevermind... I just read some of Sembee's older posts about why not to change the legacyDn
0
 
bribri007Author Commented:
I'm thinking if I move the user to a different server, that would change this users public folders home server, and possibly that would reset their schedule+ message, and it could replicate out and erase the corrupted one on the old server.  Any ideas about that?
0
 
SembeeCommented:
That may work. Although free/busy information is usually replicated to all servers anyway - at least that is what I do.

Simon.
0
 
bribri007Author Commented:
Ok... so I moved the user to another server, and that created a new replication message in the system folder, and in addition it shows the original one as being a valid message.  And I can see the free/busy info in oulook.

This unfortunately creates 2 for the user on this server.  The other servers in the cluster only see 1 message, the new one.  Upon attempting to delete the "old" one, everything reverts back to the way it was.
0
 
bribri007Author Commented:
This is now in the hands of Microsoft.  I have an ISinteg scheduled for next saturday.

Thanks for your time Simon!
0
 
bribri007Author Commented:
If anyone else stumbles on this thread,

the utilities

MFCMapi and 7171

were also unable to delete these items.  I will try to post the results of the ISinteg when it is done.

Thanks again!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.