Continuing the 2013/2016 Public Folder theme… If you see this error in power shell:
Public folder ‘\MyPublicFolder isn’t mail-enabled.
+ CategoryInfo : NotSpecified: (:) [Get-MailPublicFolder], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : [Server=Exchange01,RequestId=73da9220-fa76-4b50-923d-f1d45b2e4470,TimeStamp=1/11/2016 11
:50:40 AM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 9A83BDC,Microsoft.Exchange.Management.MapiTa
+ PSComputerName : yourserver.contoso.com
yet it shows it mail-enabled in EAC, consider that if you are in a multi-domain, it may not show as mail-enabled unless you set the scope to the entire forest (Set-ADServerSettings -ViewEntireForest $true)
Oh, and while I am thinking of it, in a multi-domain forest, the AD objects for legacy mail-enabled PFs were created in the MESO folder of the same domain as the folder creator. In 2013/16 PFs, the AD objects are created in the root domain MESO folder from what I have seen… Just something to keep in mind if you try to find them!
My friend Andrew (what a cool name), has written an article about the latest change in Exchange 2013, starting with CU11 ( and Exchange 2016 CU1). I have to admit I am not a fan of anchoring for Powershell connections, but will withhold final judgment until after I get a chance to play around more with CU11. See:
And maybe CU9. Haven’t tested that, but nonetheless, it didn’t work before CU9. So why install into an existing forest instead of the recommended DMZ or Workgroup? Edge Roles can do more then just “Edge” stuff. They make great open relay servers within your org, let you leverage Powershell and beat the pants off any IIS/SMTP stack you may be running. By installing into an existing forest as a domain member, you can use your domain creds of course, which is a good thing. If you have the licenses, go for it. The Edge role is right in the Exchange admin’s wheelhouse.
Consider the Edge if you need an open SMTP relay in your org. Options are good.