Just can't get enough of IT

Last Updated: 2018-07-06

Description

This scripts creates a new room mailbox and security two groups for full mailbox access and and for send-as delegation. The security groups are created using a configurable 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:

1. Create a new room mailbox
2. Create a new mail enabled security group for full access delegation
3. Assign full access security group for full access to the room mailbox
4. Create a new mail enabled security group for send-as delegation
5. Assign send-as permissions to send-as security group
6. Create a new mail enabled security group for allowed user to book the new room mailbox
7. Set calendar processing to AutoAccept, if required
8. Set resource capacity, if rewuired

Examples

Xml settings file

Note

The calendar booking security group feature is currently not available. But will be available in an upcoming release.

The following example creates a room mailbox for an Conference Room with empty security groups.

.\New-RoomMailbox.ps1 
  -RoomMailboxName "MB - Conference Room" 
  -RoomMailboxDisplayName "Board Conference Room" 
  -RoomMailboxAlias "MB-ConferenceRoom" 
  -RoomMailboxSmtpAddress "ConferenceRoom@mcsmemail.de" 
  -DepartmentPrefix "C"

You can simplify the use of the script by using a paramterized helper script named Run-NewRoomMailbox.ps1.

The following Run-NewRoomMailbox.ps1 script simplifies the process of creating a team mailbox even more.

$roomMailboxName = 'MB-Conference Room'
$roomMailboxDisplayName = 'Board Conference Room'
$roomMailboxAlias = 'MB-ConferenceRoom'
$roomMailboxSmtpAddress = 'ConferenceRoom@mcsmemail.de'
$departmentPrefix = 'C'
$groupFullAccessMembers = @('JohnDoe','JaneDoe')  # Empty = @()
$groupSendAsMembers = @()
$groupCalendarBookingMembers = @()
$RoomCapacity = 0
$RoomList = 'AllRoomsHQ'
$Language = 'en-GB'


.\New-RoomMailbox.ps1 
  -RoomMailboxName $roomMailboxName 
  -RoomMailboxDisplayName $roomMailboxDisplayName 
  -RoomMailboxAlias $roomMailboxAlias 
  -RoomMailboxSmtpAddress $roomMailboxSmtpAddress 
  -DepartmentPrefix $departmentPrefix 
  -GroupFullAccessMembers $groupFullAccessMembers 
  -GroupSendAsMembers $groupSendAsMembers
  -RoomCapacity $RoomCapacity 
  -AutoAccept 
  -RoomList $RoomList
  -Language $Language

Version History

• 1.0, Initial community release
• 1.1, Some PowerShell hygiene, issue #2 closed
• 1.2, CalenderBooking, Language added

Links

• Download and follow at Github: https://github.com/Apoc70/New-RoomMailbox​
• Download and like at TechNet Gallery: https://gallery.technet.microsoft.com/Create-a-new-Room-Mailbox-99a4e477

Follow

• Twitter @stensitzki
• LinkedIn
• Xing

There are quite a lot of good step-by-step manuals available describing how to enable Kerberos authentication for Exchange Server 2013/2016.

The following issue has been seen in an Exchange 2013 infrastructure (8 server DAG) where Outlook clients use OutlookAnyhwere to connect to Exchange Server. MAPI over Http is disabled on an organizational level due to a compatibility issue with another client software.

Problem

Even if you follow the detailed descriptions you might end up in a situation where your Outlook clients still won't connect to Exchange Server using Kerberos. The Outlook connection status overview (Ctrl + Right Click on the Outlook icon in System Tray) still shows Ntlm as the used authentication provider:

Reason

You are supposed to use the following PowerShell cmdlets to configure OutlookAnywhere to use Kerberos:

Get-OutlookAnywhere -Server CASSERVER | Set-OutlookAnywhere -InternalClientAuthenticationMethod  Negotiate

All eight Exchange 2013 servers where still not offering Nego as an authentication provider even after some period of time. Verifying the OutlookAnywhere configurations using PowerShell showed the correct configuration values. So what to do?

A quick check at the IIS authentication settings of the \Rpc virtual directory of the Front End web site (Default Web Site) showed that this virtual directory was still configured to use Ntlm only.

Solution

Use the IIS management consolte to add the Negotiate authentication provider to the list of available providers and reorder the list to use Nego first.

Now Outlook clients will pick up the configuration change an will connect to OutlookAnywhere using Kerberos.

Note

You should not use the IIS management console to change any settings of the Exchange Server virtual directories during normal operations. Using the IIS management console should only be used for troubleshooting fancy situations that you encounter in your Exchange Server infrastructure. 

The preferred method to change Exchange Server vDir settings is PowerShell.

Links

• Configuring Kerberos authentication for load-balanced Client Access services (Exchange 2016), https://technet.microsoft.com/en-us/library/ff808312(v=exchg.160).aspx
• Configuring Kerberos authentication for load-balanced Client Access servers (Exchange 2013), https://technet.microsoft.com/en-us/library/ff808312(v=exchg.150).aspx

Enjoy Exchange Server

This blog post focusses on an issue where your Exchange Online users are not able to send emails to other Exchange Online recipients outside of your organization when using a 3rd Party Centralized Email Flow Setup. The term 3rd Party Centralized Email Flow Setup describes a solution where you not follow the preferred hybrid architecture proposed by the Exchange product group, but use a 3rd party software as a centralized email gateway.

Problem

You have followed the recommendation to secure the Exchange Online inbound connector for your on-premises email servers by using a certificate name or the remote IP address of your on-premises email gateway.

Assumption

The on-premises email security gateway utilizes a self-signed certificate to secure TLS connections. The gateway is configured to use two different send connector setups:

• Internet Connector
  Use receipients domain MX records
  Use self-signed certificate
  Target address space: *
   
• Office 365 Connector
  Use tenant.mail.protection.outlook.com to route internal email messages
  Use self-signed certificate
  Target address space: tenant.mail.onmicrosoft.com

In this case Exchange Online Protection (EOP) will not be able to differentiate between tenant internal inbound mail flow and mail flow targeted to other tenants. Therefore, email messages sent from your Exchange Online users to recipients located in other Exchange Online tenants will be discarded.

Interestingly enough, this will happen silently. Your gateway solution will log a successful delivery to Exchange Online Protection. The tenant administrator of the recipient domain will not find an any information in the Exchange Online message tracking logs.

The following diagram illustrates the setup.

Solution

The solution for this problem is pretty simple. Just use dedicated certificates for each connector targetting Exchange Online.

Change the Internet Connector to fully trusted 3rd party certificate. In this case you are not required to modify the existing Exchange Online inbound connector setup.

The new connector configurations are:

• Internet Connector
  Use receipients domain MX records
  Use 3rd party certificate
  Target address space: *
   
• Office 365 Connector
  Use tenant.mail.protection.outlook.com to route internal email messages
  Use self-signed certificate
  Target address space: tenant.mail.onmicrosoft.com

The following diagram illustrates the new setup:

Links

• Important notice for Office 365 email customers who have configured connectors, https://blogs.technet.microsoft.com/exchange/2016/03/29/important-notice-for-office-365-email-customers-who-have-configured-connectors/
• Mail flow best practices for Exchange Online and Office 365 (overview), https://technet.microsoft.com/en-us/library/jj937232(v=exchg.150).aspx

Enjoy!

Problem

Out-of-Office (OOF) messages have to follow the compliance rules as regular email communication. This is not necessarily a known fact to end users.

If a company does have a strict compliance policy regarding external OOF messages you can use the following solution to establish a strict and simple to use OOF configuration. 

Only specific employees are supposed to send OOF messages to external recipients. All other employees are supposed to send internal OOF messages only.

Solution

The solution consists of two PowerShell scripts.

The first script is used to remove any exisiting OOF rules created by a user using the Outlook OOF Rule Wizard. This is required to avoid any strange behaviours in regards to OOF messages being sent even if OOF is deactivated. The most common reasons for such a behaviour are migrated OOF rules created by previous Exchange Server versions.

1. Remove-OOFRule.ps1
   
   This script finds and removes all OOF rules for all users using Exchange Web Services (EWS).
   This script is supposed to be executed in preparation for the next script.  
    
2. Set-ExternalOOF.ps1
   
   This script sets the ExternalOofOptions attribute of a user mailbox depending on an Active Directory group membership. After cleaning up all OOF rules in step one, you will be able to control the OOF settings by group membership. 

You can read more about scripts here:

• Script 1: Remove Out-Of-Office rules from user mailbox
• Script 2: Set external OOF settings based on AD group membership

You can use the follow command line example, if you want to automate the execution of script 2 using a scheduled task.

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 3.0 -command ". 'D:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; "D:\Scripts\Set-ExternalOOF\Set-ExternalOOF.ps1 -RemoveRights"

Follow

• Twitter @stensitzki
• LinkedIn
• Xing

Description

This script searches for OOF rules created by users using the Outlook rule-tab in the OOF assistant and deletes exisiting OOF rules.

In preparation to configure compliant Out-Of-Office (OFF) settings for users, any existing OOF rule needs to be deleted. The script will use either an exisiting Exchange Server EWS library or the Managed EWS library installed using the default file path.

This is the first of two scripts for the complete solution. Find the second script here.

The script access the mailbox rules using Exchange Web Services. Therefore the account executing the script either needs to have ApplicationImpersonation rights or full access to the user mailbox.

Requirements

• Exchange Management Shell (EMS) 2013+
• GlobalFunctions library as described here: http://scripts.granikos.eu
• Locally installed Exchange Web Services (EWS) Library, https://www.microsoft.com/en-us/download/details.aspx?id=42951

Examples

# EXAMPLE 1
# Find any existing OOF rule and write results to log file
Remove-OOFRule 

# EXAMPLE 2
# Find and delete any existing OOF rules in all user mailboxes and write delete actions to log file
Remove-OOFRule -Delete

# EXAMPLE 3
# Find and delete any existing OOF rules for user SomeUser@varunagroup.de and write delete actions to log file
Remove-OOFRule -Mailbox SomeUser@varunagroup.de -Delete

Version History

• 1.0, Initial community release

Links

• Download and follow at Github: https://github.com/Apoc70/Manage-OOF-Settings
• Download and like at TechNet Gallery: https://gallery.technet.microsoft.com/Remove-Out-Of-Office-rules-3f740964

Additional Credits

Rhoderick Milne (https://blogs.technet.microsoft.com/rmilne)

Follow

• Twitter @stensitzki
• LinkedIn
• Xing