de-DEen-GB
 
rss

Just can't get enough of IT

This blog is about mostly anything in IT. But the primary focuses are Microsoft Technologies like Exchange, Office 365, Azure and Cloud Security.
On July 25, 2015
0 Comment
3030 Views

Problem

When you mail enable an Exchange legacy public folder, a system object is created in Active Directory which is stored in the so called MESO object container

  • CN=Microsoft Exchange System Objects, DC=MCSMEMAIL, DC=DE

The object created contains all required attributes for Exchange address lists and other Exchange attributes.

When you mail disable a public folder Exchange Server is supposed to delete the MESO object as well. For some reason that might not happen. In this case the public folder will show in Public Folder Management Console as mail disabled, is still capable of receiving emails sent to its email address.

From an Exchange perspective, the email address can still be resolved, because a system object containing the email address still exists.

At first it looked like a permission issue on the MESO object container, but it wasn’t.

Solution

A Microsoft KB article described the issue for a single forest, multi-domain environment and a similar issue with Exchange Server 2010.

Configure the following registry on each Exchange Server hosting a public folder database and restart the MSExchangeIS service.

  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MsExchangeIS\ParametersSystem
  • DWORD (32 bit)
  • EnableDeletePFProxyAndStorePropTogether
  • Value = 1

In addition you should name the public folder and domain controller in the Exchange cmdlet

Enable-MailPublicFolder “\Public Folder Name” –Server PUBLICFOLDERSERVER –DomainController DC01

When you mail enable an exisiting public folder which looks like being mail disabled, but still having an (old) MESO object, a new MESO object will be created. The situation will be as follows:

  • Old MESO object attributes
    • displayName=Public Folder Name
    • CN=Public Folder Name
    • mail=PublicFolderName@mcsmemail.de
  • New MESO object attributes
    • displayName=Public Folder Name
    • CN=Public Folder Name 38513598
    • mail=PublicFolderName2@mcsmemail.de

The result is not necessarily as expected, as the old MESO object is orphaned an never reconfigured again.

Orphaned objects need to be cleaned up manually and beeing recreated again, if necessary. In an Exchange environement that has been migrated from ancient versions to 2010, you might already have a lot of MESO objects having digits added to their common names.

You can cleanup the MESO obejcts as follows:

  1. Delete orphaned object in MESO container
  2. Mail enable public folder

This results in a correctly named and configured MESO object. You can use Bill Long’s PowerShell script to identify orphaned public folder objects in the MESO container.

Note

This information is related to legacy Exchange public folders being hosted on Exchange Server 2007 and/or Exchange Server 2010.

The solution has been validated for Exchange Server 2007 as well, even though the KB article has been published for Exchange Server 2010 only.

Links

 


This post had originally been posted at my former blog SF-Tools.

You need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid? You are interested what Exchange Server 2016 has to offer for your environment?

Contact me at thomas@mcsmemail.de
Follow at https://twitter.com/stensitzki

Read More »

Graphic Whitepaper: Improve Your Exchange Deployment by Learning from a Massive ScaleGiven Microsoft’s success in building Exchange Online running on its Office 365 cloud platform, it has undoubtedly learned a few valuable lessons that can be applied to on-premises deployments.

In this whitepaper, ENow board member and Microsoft Exchange MVP Tony Redmond reveals how standardization, automation and monitoring played into Microsoft’s success with scaling its platform.

Download the Whitepaper here: http://enowsoftware.com/whitepaper/Improve-Your-Exchange-Deployment-by-Learning-from-Massive-Scale.pdf

 

 

 

 

 


Are you unsure, if you should migrate to Office 365? You want to know more about security of cloud applications and services? Your Exchange Server infrastructure requires an upgrade? Contact me via email: thomas@mcsmemail.de

Read More »

A new community PowerShell script to simplify Exchange Server mailbox migrations has been published to TechNet Gallery and Github.

Features

  • Validate CSV file for required column EmailAddress prior to creating migration batch in Exchange
  • Automatic batch naming based on CSV file name
  • Common notification email address settings
  • Variable AutoComplete of batches
  • Common logging of script activities

See script help for examples.

Links

 


Checkout the professional services provided by Granikos for planning and migration your exisiting Exchange Server infrastructure to the cloud. Protect your cloud services using the CloudSOC™ technology provided by Elastica.

Read More »
On July 4, 2015
1 Comment
1543 Views
Last Updated: 2017-08-19

Exchange Server 2013Exchange Server 2016Description

PowerShell module providing centralizied logging and other helpful functions.

Examples

Import-Module GlobalFunctions 
$ScriptDir = Split-Path $script:MyInvocation.MyCommand.Path 
$ScriptName = $MyInvocation.MyCommand.Name 

# Create a new logger object, keeping the last 14 days of log files
$logger = New-Logger -ScriptRoot $ScriptDir -ScriptName $ScriptName -LogFileRetention 14 

# Write a new informational message to the log file  
$logger.Write('My Log Message')

# Write an error message to the log file
$logger.Write('My custom error message')

# Write a warning message to the log file
$logger.Write('My custom warning')

# Send a log file by email at the end of your script
$logger.SendLogFile('sender@mcsmemail.de', 'recipient@mcsmemail.de', 'smtpserver.mcsmemail.de')

How to install a PowerShell Module

You can "install" a PowerShell module by copying the module to a sub folder of the same name as the module in either of the two following locations:

  • Default PowerShell module path define by PSModulePath variable ($env:PSModulePath)
  • Custom PowerShell module path, which requires the full path to be added to the PSModulePath system variable

Default PowerShell Module Path

  1. Open a new PowerShell window and query the content of PSModulePath variable
    PS C:\> $env:PSModulePath
    C:\Users\admin\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\sys
    tem32\WindowsPowerShell\v1.0\Modules

     

  2. Create a new folder named GlobalFunctions in C:\Program Files\WindowsPowerShell\Modules

  3. Copy the GlobalFunctions.psm1 file to C:\Program Files\WindowsPowerShell\Modules\GlobalFunctions

That's it.

Custom PowerShell Module Path

These steps assume that you use a dedicated PowerShell scripts folder, e.g. D:\MyScripts

  1. Create a new folder named MyModules in D:\MyScripts
    -> D:\MyScripts\MyModules
  2. Create a new folder named GlobalFunctions in D:\MyScripts\MyModules
    -> D:\MyScripts\MyMOdules\GlobalFunctions
  3. Copy the GlobalFunctions.psm1 file to D:\MyScripts\MyModules\GlobalFunctions
  4. Add the full file path D:\MyScripts\MyModules to the system variable PSModulePath
    You can use Set-PersistentPSModulePath.ps1 script, provided here. Just copy the script to D:\MyScripts\MyModules 
    .\Set-PersistentPSModulePath.ps1 -Add

Close the current PowerShell window and open a new PowerShell window. That's it.

PowerShell 5

When using PowerShell 5, you can simply use the following PowerShell command from within an administrative PowerShell window.

Install-Module GlobalFunctions

When a new version of the GlobalFunctions module has been released, use the following PowerShell command to update the module.

Update-Module GlobalFunctions

That's it.

Version History

  • 1.0 Initial release
  • 1.1 Write to Event log added, send log file added
  • 1.2 CopyFile added
  • 1.3 Updated for PowerShellGallery
  • 2.0 Converted to UNICODE, Functions added: Replace-SpecialCharactersUpperCase, New-RandomPassword
  • 2.1 WriteToConsole switch added to Logger.Write method

Links

Follow

 

 

Read More »

Description

This script copies a single receive connector from a source Exchange Server to a single target Exchange server or to all other Exchange servers.

The primary purposes of this script are:

  • Simplify migration of legacy Exchange receive connectors (Exchange 2007 or Exchange2010) to a modern Exchange server (Exchange 2013 or Exchange 2016)
  • Simplify receive connector distribution across multiple Exchange servers (Exchange 2013 or Exchange 2016)

Examples

Copy Exchange 2013/2016 receive connector nikos-one-RC2 from server MBX01 to server MBX2

.\Copy-ReceiveConnector.ps1 -SourceServer MBX01 -ConnectorName nikos-one-RC2 `
-TargetServer MBX2 -DomainController MYDC1.mcsmemail.de

Copy Exchange 2013/2016 receive connector nikos-one-RC2 from server MBX01 to all other Exchange 2013 servers

.\Copy-ReceiveConnector.ps1 -SourceServer MBX01 -ConnectorName nikos-one-RC1 `
-CopyToAllOther -DomainController MYDC1.mcsmemail.de

Copy Exchange 2013/2016 receive connector nikos-two relay from Exchange 2007 server MBX2007 to Exchange 2013 server MBX01 and reset network bindings

.\Copy-ReceiveConnector.ps1 -SourceServer MBX2007 -ConnectorName "nikos-two relay" `
-TargetServer MBX01 -MoveToFrontend -ResetBindings `
-DomainController MYDC1.mcsmemail.de

Version History

  • 1.0, Initial community release
  • 1.1 Domain Controller parameter added, permissions group copy added
  • 1.2 Move to FrontendTransport added, optional permission copy added, reset bindings added
  • 1.3 Update receive connector, if receive connector exists
  • 1.4 Fix to handle connector updates properly
  • 1.41 Minor fixes and update for Exchange 2016

Links

Script last updated: 2016-07-26

Additional Credits

Additional credits go to Jeffery Land, https://jefferyland.wordpress.com

Follow

Read More »