Removing Exchange 2007 Mailbox Role Prompts for Public Folder Database Deletion

I am attempting to remove the Exchange 2007 Mailbox role from a server which formerly served as a target for SCR replication.  This server also hosted a replica of critical public folder calendar data, the OAB, and SCHEDULE+ FREE BUSY data.

I have removed the public folder calendars, OAB, and SCHEDULE+ FREE BUSY items from replication to the public folder database on this server, and confirmed via the following command that these replicas have been removed from the database.

However, the uninstall process still fails to remove the Mailbox role due to the public folder database on the server still containing data.

I presume this is a reference to the four public folder names shown below.

Is it safe to remove these folders from the database?  If so, how is this best done?

Any assistance in this matter is greatly appreciated.

[PS] C:\Windows\system32>Get-PublicFolderStatistics -Server EXCHANGESERVER2

Name                                     ItemCount               LastAccessTime
----                                     ---------               --------------
globalevents                             0                9/21/2013 12:09:11 PM
internal                                 0                9/21/2013 12:09:11 PM
OWAScratchPad{579ABDB1-7A85-4B7C-83A7-BB 0                9/21/2013 12:09:11 PM
StoreEvents{579ABDB1-7A85-4B7C-83A7-BB58 0                9/21/2013 12:09:11 PM

Open in new window

Who is Participating?
V16ProConnect With a Mentor Author Commented:
LectricX --

Well, that's encouraging...  ;-)

I appear to have answered my own question.

I used the 'Get-PublicFolderStatistics' command to retrieve the public folder details from another server in the Exchange environment (one which had been migrated to from another server previously), and I noticed two each of 'globalevents', 'internal', 'OWAScratchPad', and 'StoreEvents' -- each with different hashes following the name, with the exception of 'globalevents' and 'internal', which were each listed twice and were not followed by hashcodes.

This article from MS was my second clue -- it clearly says not to muck with them.

Since none of the hashcodes on the server I queried matched the hashes from the server I want to decommission, I presumed that the duplicate copies on the one server were from where 'MoveAllReplicas.ps1' had been used to move folders off of another server in the past prior to decommissioning.  Thus, I concluded that 'MoveAllReplicas.ps1' was the best bet for this decommission as well.

I fired off the following command, and after about 15 minutes, 'Get-PublicFolderStatistics' revealed a clean public folders database on the server I'm decommissioning, and showed a third copy of the four system folders on the destination server.  Problem solved.

[PS] C:\Windows\system32>MoveAllReplicas.ps1 -Server EXCHANGESERVER2 -NewServer
[PS] C:\Windows\system32>Get-PublicFolderStatistics -Server EXCHANGESERVER2
[PS] C:\Windows\system32>

Open in new window

Thanks for helping me get oriented in the right direction!
Nathan PConnect With a Mentor Systems ArchitectCommented:
That's a really tough question actually.  Only people crazy enough to still have Public Folders on 2010 are going to try and answer it, and you've only decided to give out 375 points for an answer?  I find it curious that you've done that.

Anyways.. Since I likely won't get it right anyways, I'll give it a stab.

If the public folders were a replica, can you see these folders on any of the other servers?  Do they also have 0 items?

Next, is this the original server you set it up on?  If so, the system might be reading these every time no matter what.

I'd be looking into those two thoughts before you tried deleting the folders.  Out of curiosity, if you shut down the information store service on that server, does anyone have any trouble using Exchange?
Adam BrownSr Solutions ArchitectCommented:
"Only people crazy enough to still have Public Folders on 2010 are going to try and answer it"

So you know, Public folders are fully supported in Exchange 2010, are perfectly acceptable to use, and have even been greatly improved in Exchange 2013. So people using Public folders on 2010 are most assuredly not crazy.
Nathan PSystems ArchitectCommented:
Prior to Exchange 2007's release, Microsoft advised that Public Folders would no longer be necessary or supported.  There was considerable reaction to this in the community, and some backtracking and "Microsoft-ese" speak turned that into 'de-emphasized'.

The 2007 suite of Exchange/Outlook removed the intrinsic need for them, and the sheer pressure to keep them as something Exchange can do from businesses who used them kept them alive.

The public folder has continued to be supported, but you have to ask yourself why you'd use a subsection of a technology that Microsoft has tried to kill off multiple times, and is the ONLY vendor that writes code for it?

One day, they'll be successful.  IMHO, Best to move away from the carcass before the vultures turn up.
V16ProAuthor Commented:
While Expert's suggestion did not itself solve the problem, it provided the important information necessary to get me pointed in the right direction.  I appreciate LectricX's assistance!
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.