The Environment:
Exchange Enterprise 2K3 SP1 in Native Mode on W2K3 Enterprise SP1
and
Exchange Enterprise 2K3 SP2 in Native Mode on W2K3 Enterprise SP1
Was migrated from a Exchange 5.5 environment.
All remnants of 5.5 and NT4.0 are long gone.
The problem:
We would like to mail disable many public folders because we need to do a
dump via LDAP or WMI of all the SMTP addresses to give to our external mail
forwarder/scanner [FrontBridge].
Here is the problem:
If I am in ESM and right click on a folder and them pick all tasks I am
prompted for "mail enable" the public folder. This is what I expect. The
folder has not been mail enabled. I do not execute the "mail enable".
If I then right click on the folder and choose properties to look at the
folder properties the Public Folder get's "Mail Enabled" though no effort of
mine.
When I then exit the properties window and go to "All Tasks" I am then
prompted with the ability to "Mail Disable" the folder because it has been
"Mail Enabled"
There is now no way to "Mail Disable" the folder either though WMI or ESM.
If
you execute the "Mail Disable" nothing happens.
So the question is how do I stop this from happening? I want to
programmatically "Mail disable" hundreds of folders.
I have seen the post about deleting the object in "AD" but I want to
understand why we are doing this? It seems that we are creating a future
problem to make this one go away. Aren't you orphaning the public folder
entries then? What are the repercussions of this? If you want to Mail
Enable this folder in the future will "Mail Enable" repopulate the AD?
Thanks in advance!
Fred Lobmeyer
"Fred Lobmeyer" <Lobm...@myalias.postalias> wrote in message
news:53A12A2D-C3AA-462B...@microsoft.com...
The problem is that I want to create a list of valid email addresses to stop
directory harvesting attacks on my site. The SPAMmers try every combination
of x...@blah.com. So I end up having to get these delivered to my host and
then reject them. If I can upload the valid LDAP list then they will reject
them and they will not try and relay these invalid addresses to my Exchange
Server.
Thanks anyway though. I am trying to get resolution for the problem with
ESM and WMI not correcting the Public Folder to email Disabled.
Sincerely,
Fred
"Fred Lobmeyer" <Lobm...@myalias.postalias> wrote in message
news:1D6D31FD-7F42-41A7...@microsoft.com...
Thanks for your notes.
Sincerely,
Fred Lobmeyer
Right-click the folder | properties. This did not re-mail-enable the folder.
Exchange tabs are gone. The corresponding AD object does not get
recreated/reappear under MS Exchange System Objects.
Exchange 2003 SP1 - Native mode.
--
Bharat Suneja
MCSE, MCT
www.zenprise.com
blog: www.suneja.com/blog
-----------------------------------------
"Fred Lobmeyer" <Lobm...@myalias.postalias> wrote in message
news:53A12A2D-C3AA-462B...@microsoft.com...
I am running Exchange 2003 in Native Mode.
Again the problem is with the folders that were replicated from the 5.5
environment.
Sincerely,
Fred Lobmeyer
had a problem with this once when the remote registry service was not
running.
"Fred Lobmeyer" <Lobm...@myalias.postalias> wrote
news:53A12A2D-C3AA-462B...@microsoft.com...
Thanks though,
Fred Lobmeyer
All public folders migrated from Exchange 5.5 to Exchange 2k3 are
mail-enabled by default. The issue where you are seeing the folder as not
being then being mail enable is most likely a glitch in the ESM.
This is very simple to fix in a programmatic way. Simply delete all public
folder object from the MESO (Microsoft Exchange System Objects) Container
that you do not want to receive email. Removing the objects from AD will
not have any affect on the public folder store objects. The objects in AD
exist solely to allow public folder mailflow.
All permissions, replica, data, and other information for public folders are
stored within the Information store. The only thing we store in AD is the
SMTP address of the public folder.
Naturally I recommend testing this with a subset of folders before deleting
all of the ones that you don't want to keep (it is always best to test no
matter who is giving the advice).
Hope this Helps,
--
Matthew Byrd
Microsoft PSS
Run Microsoft Exchange Server Best Practices Analyzer Today
http://www.microsoft.com/exchange/exbpa
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Fred Lobmeyer" <Lobm...@myalias.postalias> wrote in message
news:53A12A2D-C3AA-462B...@microsoft.com...
Thanks for the answer. The "Glitch" is muli-fold and I actually think it is
bigger in that there is a problem in the API that does this function.
1) It doesn't show the folder as "Mail Enabled"
2) If you look at properties of the folder so that ESM displays the correct
status of the folder you can not "Mail Disable" a 5.5 Created Public Folder.
3) WMI does not allow you to "Mail Disable" the public folder either. This
is why I think it is a "bug" in the API.
Can this please be reported to Engineering? This is extremely frustrating
and is not my favorite thing to do to delete records out of AD. I have had
problems with other records in the past and don't want to create a bunch of
orphaned information in AD because the API, WMI, and GUI don't work as
advertised.
Sincerely,
Fred Lobmeyer
My best guess in that case is that there is something wrong with the active
directory objects themselves. I have seen minor glitching in this arena
where the incorrect information as displayed for a short time period but I
have not seen anything on the order that your are describing. I would
recommend that you use LDP to access the properties of a 5.5 public folder
and a E2k3 created public folder and look for something that is
significantly different about then (other than msexchangeadcglobalnames) and
modify that attribute to bring it in line with the E2k3 created object.
That will hopefully correct your issue. It may take some playing in order
to figure that out. But deleting the objects thru the API and deleting them
thru ADUC is doing the exact same thing. Either way it is deleted, and that
deletion must replicate thru AD using normal AD replication means. If you
are having issues with you AD replication this can cause orphaned objects
but otherwise this is no different than deleting a user object from AD.
If deleting the objects thru ADUC is not acceptable and you are unable to
determine what maybe broken with the 5.5 created AD objects then I would
recommend opening a Case with Microsoft Support. I do not believe that we
will be able to help you any further here in the forum as the complexity of
the issue exceeds what can be done in their environment.
Hope this Helps,
--
Matthew Byrd
Microsoft PSS
Run Microsoft Exchange Server Best Practices Analyzer Today
http://www.microsoft.com/exchange/exbpa
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Fred Lobmeyer" <Lobm...@myalias.postalias> wrote in message
news:67234CF2-4439-4556...@microsoft.com...
I now have the problem described in http://support.microsoft.com/?id=328740
as opposed to what I had before. So THERE IS A BUG HERE!
THERE ARE REPORTS ALL OVER THE WEB ABOUT NOT BEING ABLE TO MAIL DISABLE A
PUBLIC FOLDER.
Resolutions 1 & 2 do not work because I can't mail disable the folder and
remove the SMTP addressess. Now I am in the worst situation. A screwed up
AD and a screwed up out of Sync information store.
So how do you fix this now that you put me in this situation? Again as the
article states we did have ADC running as part of the migration. What the
article misses is that all Public Folders in 5.5 are mail enabled by default.
There was not a mechanism to have Exchange not create the SMTP address for
the public folder.
So since this is happening enough that there is an article written how do we
fix this? It was with PSS's suggestion that I deleted all the AD objects
related to the Public Folders. Now I am in a much worse place.
I think there should be a utility to resync this. Correct PR_PF_PROXY in
the Information Store and then if someone wants to mail enable public folders
that have been orphaned by PSS, ESM should just do what it was intended to do.
As I reported two notes back. I think that this is a bug in ESM. If you
pick Mail Disable, FIX the entries or not. Just don't report that nothing
happened because the user will think that what they requested to be done has
been accomplished. In the current case ESM does not report any errors it
just decides not to do anything even though there is clearly something to be
done.