The community script Update-CASMailbox simplifies the process for enabling or disabling protocols for Exchange mailbox access. Active Directory security groups are used to enable or disable a protocol for the group members.
Your Active Directory contains a security group named Exchange_POP_enabled which contains all mailbox users requiring POP3 access to be enabled.
You can use the following command to have POP3 enabled for all members of the given security group.
.\Update-CAS-Mailbox.ps1 -POP -FeatureEnabled $true -GroupName Exchange_POP_enabled
The script does not disable the POP3 for all non-members, as this might not be required as all new mailboxes have POP3 disabled anyway. If there is such a requirement, just let me know.
The following protocols are currently supported:
You need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid with Office 365? You are interested in what Exchange Server 2016 has to offer for your environment?
You are not able to list public folders in a co-existence scenario with Exchange Server 2007 and Exchange Server 2010/2013 using the Exchange 2007 EMS or EMC.
When you try to execute Get-PublicFolder you receive the following error:
Get-PublicFolder " There is no existing PublicFolder that matches the following Identity: '\'. Please make sure that you specified the correct PublicFolder Identity and that you have the necessary permissions to view PublicFolder.
This might happen after you have removed the first Exchange 2007 mailbox server, but not the last Exchange 2007 mailbox server.
Exchange Server 2007 uses the Exchange System Attendant to access the public folder store and fails, if the System Attendant discovery in Active Directory does not provide a proper configuration.
KB 2621350 describes the discovery process:
There two annoying things about these steps
The magic System Attendant mailbox has been removed from Exchange 2010. But the System Attendent configuration node does still exist in the Active Directory Configuration Partition for compatibility reasons. The configured attributes of the System Attendent entry vary depending on the version of the installed Exchange Server.
In regards of public folder issue, we need to focus on the following:
To fix the public folder access issue for Exchange Server 2007, set the homeMDB and homeMTA attributes. Set the Exchange System Attendant attributes to appropriate values for your Exchange servers.
Repeat steps 4 to 8 for each Exchange 2013 server in your environment.
Repeat steps 4 to 13 for each Exchange 2010 server in your environment.
Wait for Active Directory replication and retry to access the public folders using Get-PublicFolder in an Exchange Server 2007 Management Shell.
It might be required to restart the Exchange 2007 Information Store and System Attendant service of the Exchange 2007 server in question
Use an administrative PowerShell
Restart-Service MSExchangeIS Restart-Service MSExchangeSA
I haven’t noticed any issues in production environments so far. If you encounter any issues in your environment, feel free to leave a comment.
You need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid? You are interested in what Exchange Server 2016 has to offer for your environment?
Contact me at thomas@mcsmemail.de Follow at https://twitter.com/stensitzki
This script sets the mailbox ExternalOofOptions to 'External' for members of a given security group.
ExternalOofOptions for users that are NOT a member of the security group will be set to 'InternalOnly'. If required the script will set the ExternalAudience to None and will delete an existing OOF message.
Controlling the ExternalOofOptions and ExternalAudience settings has been implemented to follow dedicated company compliance rules.
This is the second of two scripts for the complete solution. Find the first script here.
# EXAMPLE # Run script with default settings .\Set-ExternalOOF.ps1
The script can be used to assign an application account (e.g. CRM, ERP) send-as permission to user mailboxes to send emails AS the user and not as the application.
This script loops through a membership list of an Active Directory security group. A single mailbox (CRM/ERP service account mailbox) is added to each mailbox (CRM/ERP user mailbox) of the security group members to provide send-as permission.
The script has been developed as a solution to enable proper functionality with Dynamics NAV 2016.
# Assign Send-As permission to crmapplication@varunagroup.de for all members # of 'CRM-FrontLine' security group. The mailboxes as hosted On-Premises! .\Set-SendAsPermission.ps1 -SendAsGroup 'CRM-FrontLine' -SendAsUserUpn 'crmapplication@varunagroup.de'
# Assign Send-As permission to ax@granikoslabs.eu for all members of 'AX-Sales' # security group. All mailboxes are hosted in Exchange Online! .\Set-SendAsPermission.ps1 -SendAsGroup 'AX-Sales' -SendAsUserUpn 'ax@granikoslabs.eu' -ExchangeOnline
The Exchange Server product used the Extensible Storage Engine (ESE, aka JET Blue) to store data for decades. The story of the JET Blue (in contrast to JET Red which is used for Access database) can be read here (https://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine). In the acient days of data storage the ESE database was the best choice for storing mostly unstructured data with many dynamic properties.
The Messaging API (MAPI) had been developed in the 1990s to provide programmers with a set of unified interface for easier message exchange. The MAPI documentation at TechNet has been replaced by the current Outlook 2013 MAPI Reference. In todays world it is not easy to find reliable ressource about the original MAPI implementation. The only printed resource is Inside Mapi (Microsoft Programming Series) , ISBN 978-1572313125 , which has been published in 1996.
At Ignite 2015 Ross Smith VI joked about moving the Exchange storage engine to SQL. Back in the day with Exchange 2013 in production and Exchange 2016 coming, this was true. But Ross laid the tracks for the evolution of Exchange.
But it seems that the Exchange Product Team realized that in today's world with heavily standardized communication and less dynamic requirements than in the 1990s the days of JET blue are over. At the same time SQL Server evolved to mature database solution, capable of handling big data. The question was, if it can store SharePoint data, why not Exchange data. After twenty years of Exchange Server using the good ole ESE engine it was time to move on.
The SQL scripts that are used by Exchange to configure SQL are loacted in $exbin\SQL
CREATE TABLE [dbo].[MAPI_PROPERTIES]( [MAPI_PROPERTTY_ID] [int] IDENTITY(1,1) NOT NULL, [MAPI_PROPERTY_NAME] [nchar](127) NOT NULL, [IsWellKnownProperty] [bit] NOT NULL, [MAPI_TYPE_ID] [int] NOT NULL, CONSTRAINT [PK_MAPI_PROPERTIES] PRIMARY KEY CLUSTERED ( [MAPI_PROPERTTY_ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO ALTER TABLE [dbo].[MAPI_PROPERTIES] WITH CHECK ADD CONSTRAINT [FK_MAPI_PROPERTIES_MAPI_TYPES] FOREIGN KEY([MAPI_TYPE_ID]) REFERENCES [dbo].[MAPI_TYPES] ([MAPI_TYPE_ID]) GO ALTER TABLE [dbo].[MAPI_PROPERTIES] CHECK CONSTRAINT [FK_MAPI_PROPERTIES_MAPI_TYPES] GO
The current Exchange 2016 CU2 Preview supports an undocumented registry key to activate SQL Server support for Exchange. Personally I do not know, if this was supposed to be officially included in a public realease. So maybe the SQL support was made available by error and is already removed from the most current build again.
The famous SqueakyLobster registry key in has been used in Exchange 5.5 to troubleshoot performance issues. The new "Lobster" key is used to activate hidden code in Exchange Server product. The name of the key is LobsterMapiDB.
This key activates support for Exchange modern storage. Without this key you won't be able to move mailboxes from ESE legacy storage to SQL modern storage.
It is assumed that a SQL Server 2014 instance is available. A SQL Server 2014 Express edition is sufficient for testing purposes.
Note: Any changes to configurations or the registry should be validated in a test environment first. Never try this in production right away.
The high level steps required to activate SQL support for Exchange 2016 are:
The detailed steps are:
<?xml version="1.0" encoding="utf-8" ?> <!-- Exchange SQL Configuration - preliminary support --> <!-- %MAILBOXDATABASENAME% will be replaced by Exchange --> <!-- More information https://goo.gl/QiTtDo --> <configuration> <sectionGroup name="SqlMapiProviderGroup" type="Microsoft.Exchange.Data.SQL.SqlMapiProviderGroup, Microsoft.Exchange.Data.Common, Version=15.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> <section name="SqlMapiProviderSection" type="Microsoft.Exchange.Data.SQL.SqlMapiProviderGroup, Microsoft.Exchange.Data.Common, Version=15.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> </sectionGroup> <runtime> <gcServer enabled="True" /> <generatePublisherEvidence="False" /> </runtime> <appSettings> <add key="MigrateMailboxesAutomatically" value="false" /> <!-- Not yet supported --> <add key="AllowJETBlueCoexistence" value="true" /> <!-- Allows for SQL/ESE Coexistence in DAG --> <add key="PerDatabaseMaxSize" value="1GB" /> <add key="VerboseLoggingEnabled" value="False" /> </appSettings> <SqlMapiProviderSection> <SqlMapiProvider> <add name="LobsterMapiDB" providerName="System.Data.SqlClient" connectionString="Data Source=SERVERNAME\INSTANCE;Initial Catalog=%MAILBOXDATABASENAME%;Integrated Security=True;MultipleActiveResultSets=True" /> </SqlMapiProvider> </SqlMapiProviderSection> </configuration>
CREATE LOGIN [DOMAIN\Exchange Trusted Subsystem] FROM WINDOWS
More can be found here:
Enjoy Exchange for the next 20 years...
An Exchange Receive Connector requires a configuration for who can submit messages to the connector. The original TechNet description of the Set-ReceiveConnector cmdlet and the PermissionGroups attribute is as follows:
"The PermissionGroups parameter specifies the groups or roles that can submit messages to the Receive connector and the permissions assigned to those groups. A permission group is a predefined set of permissions granted to well-known security principals. The valid values for this parameter are as follows: None, AnonymousUsers, Custom, ExchangeUsers, ExchangeServers, ExchangeLegacyServers, and Partners. The default permission groups assigned to a Receive connector depend on the connector usage type specified by the Usage parameter when the Receive connector was created. "
The description implies that it is possible to set the PermissionGroups attribute to Custom.
When you try to set the permission group to Custom, you will notice that this results in an error. You will encounter this error especially when you try to copy a receive connector from one Exchange Server to another Exchange Server.
The attribute itself is being set to Custom by Exchange itself when add AD permission explicitly.
The example shows the configuration of a FerrariFax receive connector that needs to be configured across all Exchange 2013 DAG member servers.
Receice connector set to None
Add a dedicated Permission
Get-ReceiveConnector "SERVER\Connector for UMS (SERVER-FAX)" | Add-ADPermission -User DOMAIN\FaxUser -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-Bypass-Anti-Spam,ms-Exch-SMTP-Accept-Any-Recipient
Receive connector set to Custom by Exchange
You can copy a receive connector across a number of Exchange servers using the PowerShell script Copy-ReceiveConnector.ps1 hat has been published at TechNet Gallery.
The script has not been modified to handle this situation, yet. The source code repository is available at Github
This scripts creates a new shared mailbox (aka team mailbox) and security groups for full access and and send-as delegation. The security groups are created using a naming convention. If required by your Active Directory team, you can add group prefixes or department abbreviations as well.
The script uses a Xml configuration file to simplify changes for variables unique for your environment.
High level steps executes by the script:
<?xml version="1.0"?> <Settings> <GroupSettings> <Prefix>pre_</Prefix> <SendAsSuffix>_SA</SendAsSuffix> <FullAccessSuffix>_FA</FullAccessSuffix> <CalendarBookingSuffix>_CB</CalendarBookingSuffix> <TargetOU>mcsmemail.de/IT/Groups/Mail</TargetOU> <Domain>mcsmemail.de</Domain> <Seperator>-</Seperator> </GroupSettings> <AccountSettings> <TargetOU>mcsmemail.de/IT/SharedMailboxes</TargetOU> </AccountSettings> <GeneralSettings> <Sleep>10</Sleep> </GeneralSettings> </Settings>
The following example creates an empty shared mailbox for an internal Exchange Admin team with empty security groups.
.\New-TeamMailbox.ps1 -TeamMailboxName "TM-Exchange Admins" ` -TeamMailboxDisplayName "Exchange Admins" ` -TeamMailboxAlias "TM-ExchangeAdmins" ` -TeamMailboxSmtpAddress "ExchangeAdmins@mcsmemail.de" ` -DepartmentPrefix "IT"
The following Create-TeamMailbox.ps1 script simplifies the process of creating a team mailbox even more.
$teamMailboxName = 'TM-Exchange Admin' $teamMailboxDisplayName = 'Exchange Admins' $teamMailboxAlias = 'TM-ExchangeAdmin' $teamMailboxSmtpAddress = 'ExchangeAdmins@mcsmemails.de' $departmentPrefix = 'IT' $groupFullAccessMembers = @('exAdmin1','exAdmin2') $groupSendAsMember = @('exAdmin1','exAdmin2') .\New-TeamMailbox.ps1 -TeamMailboxName $teamMailboxName ` -TeamMailboxDisplayName $teamMailboxDisplayName ` -TeamMailboxAlias $teamMailboxAlias ` -TeamMailboxSmtpAddress $teamMailboxSmtpAddress ` -DepartmentPrefix $departmentPrefix ` -GroupFullAccessMembers $groupFullAccessMembers ` -GroupSendAsMember $groupSendAsMember -Verbose