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 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?
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
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
Simplify your daily work as an IT Administrator by using the Azure based Group Policy Search website. This site helps you to find the GPO settings you are looking for.
The following screenshot shows an example when search for "Outlook PST"
Enjoy GPO Search.
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
This script helps to create ceritifcate requests (CSR) based on hostnames used for internal and external Urls of Exchange Server virtual directories.
The script queries Exchange Server 2013+ virtual directory hostnames to create a certificate request.
The request is created using an inf file template. You can prepare multiple template files to choose from. Template files are supposed to be stored in the same folder as the PowerShell script.
The resulting inf file used to create the certificate request is stored on the same directory as the PowerShell script. The script queries for the certificate's common name (CN).
If created, the certificate request is stored in the same directory as the PowerShell script. The content of the certificate request file is the CSR to be submitted to a Certificate Authority.
Copy the following content to a text file, name it Default-Template.inf and save it to the same directory as the Create-CertificateRequest.ps1 file. Aternatively, download the template as a zipped archive file.
[Version] Signature="$Windows NT$" [NewRequest] Subject = "CN=##COMMONNAME##" Exportable = TRUE ; TRUE = Private key is exportable KeyLength = 2048 ; Valid key sizes: 1024, 2048, 4096, 8192, 16384 KeySpec = 1 ; Key Exchange – Required for encryption KeyUsage = 0xA0 ; Digital Signature, Key Encipherment MachineKeySet = True ProviderName = "Microsoft RSA SChannel Cryptographic Provider" RequestType = PKCS10 ; or CMC. HashAlgorithm = sha256 SMIME = FALSE [Strings] szOID_SUBJECT_ALT_NAME2 = "2.5.29.17" szOID_ENHANCED_KEY_USAGE = "2.5.29.37" szOID_PKIX_KP_SERVER_AUTH = "1.3.6.1.5.5.7.3.1" szOID_PKIX_KP_CLIENT_AUTH = "1.3.6.1.5.5.7.3.2" [Extensions] %szOID_SUBJECT_ALT_NAME2% = "{text}##DNSSAN##" %szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_PKIX_KP_SERVER_AUTH%,%szOID_PKIX_KP_CLIENT_AUTH%"
# EXAMPLE 1 # Create a new certificate request inf file used dedicated organizational information. The common name will be determined seperately. .\Create-CertificateRequest.ps1 -ModernExchangeOnly -Country DE -State NW -City Hueckelhoven -Organisation Varuna -Department IT # EXAMPLE 2 # Create a new certificate request for Exchange 2013+ using the common name only. The common name will be determined seperately. .\Create-CertificateRequest.ps1 -ModernExchangeOnly -CreateRequest
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.
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.
You can read more about scripts here:
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"