Hello, I am planning to remove a domain COMPLETELY. For which we have migrated all users to our 2007 Exchange environment, moved their PFs, have already removed all connectors in between, and on verge of decommission of their Exchange Sever. However the issue is here that all email enabled public folder got corrupted (its email vanished, all permissions gone away). To research it deeply I found that I've migrated all PF and data, but not the "Microsoft Exchange System Objects" which contains all data for the mail enabled PFs. Due to that our environment has no data of which PF was email enabled and which not. For which we are now mail enabling each of them. But the issue is that all PFs were not mail enabled and we have no such data from where we can find out that which of the PF was email enabled and which were not. Hence I am now seeking any possible option to migrate or move the "Microsoft Exchange System Objects" from their AD to ours, but I am finding no such option searching on Google. Hence I was wondering.. Is there no way to migrate this data? Do we have to manually do all the stuffs? Any suggestion would be appreciable, as I am running through a critical stage.. Thanks !!

The Microsoft Exchange System Objects contain, among other things, mail-enabled objects that link SMTP addresses to public folder objects so that mail routing can determine that mail is to be routed to the public folder store. Honestly, I don't know if that data is portable or not. I recommend that you manually mail-enable one of the public folders and compare the attributes of the associated object in Microsoft Exchange System Objects with the attributes of the corresponding object in the source domain. It's possible you might be able to write a script that does what you need, but I seriously have my doubts. As to folder permissions, their loss doesn't have anything to do with Microsoft Exchange System Objects. Folder permissions are stored in the folders themselves and when you moved them, the security principals didn't get matched to the new users and groups. That's something that expensive migration tools or custom scripts do.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Thanks Ed, I am okay with your advice. But what I am worrying for is that, where there is a procedure of decommissioning of exchange, then isn't there any way of export/ import or moving or whatsoever the "System objects" which contains all vital information about the PFs. What the benifit would be if there are 1000s of PFs and 500 or so PFs are email enabled and we have to note down all those 500PFs so that we can re-mail enable them post moving to another domain.. Isn't there any way round (except any scripting) in exchange 2003.. is this a bug or MS have never though about it?

The "System Objects" actually don't have much information about the public folders at all--take a look at the objects yourself and see. Most of the information is in the public folder hierarchy and in the folders themselves. As I said, some third-party tools, e.g., Quest, move this data between organizations seamlessly. I personally have scripted solutions for such things in the past, so I know it can be done. It's not a bug; it's just that Microsoft has never really been in the migration tools business. From time to time they have tools, but they often don't get maintaned or they become obsolete when new versions of the product appear, as is the case with the Transporter Suite. In some cases tools that work great don't support certain features without extra work, as is the case with ADMT and mail properties. If you want a feature-complete low-effort solution, then you have to pay money to a vendor who's thought of all the scenarios, or write the tools yourself.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

The "System Objects" actually don't have much information about the public folders at all--take a look at the objects yourself and see. Most of the information is in the public folder hierarchy and in the folders themselves. As I said, some third-party tools, e.g., Quest, move this data between organizations seamlessly. I personally have scripted solutions for such things in the past, so I know it can be done. It's not a bug; it's just that Microsoft has never really been in the migration tools business. From time to time they have tools, but they often don't get maintaned or they become obsolete when new versions of the product appear, as is the case with the Transporter Suite. In some cases tools that work great don't support certain features without extra work, as is the case with ADMT and mail properties. If you want a feature-complete low-effort solution, then you have to pay money to a vendor who's thought of all the scenarios, or write the tools yourself.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Okay, so for fulfilling my quest, I have to try third party software. Let me see if with that I can move or import/export "system objects" to other domain, as it is containing as a crucial information within it, which may instantly hamper business of the organization, as it is surely impossible to manually mail enable all 500-600 PFs from 1000 of PFs. Hope your suggestion could work for me. Thanks for your inputs. I'll again make a note after trying the same. Thanks Ed :-)

The way to think of it is tha the tool migrates the public folders, not the system objects. In the migration it preserves the important information that is in the system objects, particularly the SMTP addresses, in the objects it creates in the target domain. It doesn't have to migrate the system objects themselves to do that properly.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Well, the third-party tools are more geared toward doing everything and may be too costly for just public folders. Again, migrating the system objects won't fix your problem because they're only a small part of the data. Migrating them would still require you to link them to the public folder objects. Think of it this way, the tools migrate the data and leave more or less in the same state as in the source system. That doesn't involve migrating the Microsoft Exchange System Objects, it means migrating the data in them that's important.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."