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"
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
This script reconfigures the IIS log folder to use a different folder instead of the default C:\inetpub\logs folder.
Additionally, the log settings can be adjusted as well. The script changes the default log file location and settings on a server level.
By default, the settings are inherited by websites. If manual changes have been made on a website level, not all settings will be inherited.
Change the IIS log file location to D:\IISLogs
.\Set-Webserver.ps1 -LogFolderPath D:\IISLogs
Change the IIS log period to an hourly period
.\Set-Webserver.ps1 -LogFilePeriod Hourly
Use the local time for filenames and log file rollover
.\Set-Webserver.ps1 -LocalTimeRollover $true
Additional credits go to Michel de Rooij, https://eightwone.com
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?
This script removes orphaned mobile device partnerships from Exchange Server 2013+ user mailboxes. Run the script as a scheduled task to maintain your Exchange Server environment properly.
This script utilizes a settings.xml file to configure
Settings.xml (default)
<?xml version="1.0"?> <Settings> <EmailSettings> <SMTPServer>smtp.mcsmemail.de</SMTPServer> <SMTPPort>25</SMTPPort> <MailFrom>postmaster@mcsmemail.de</MailFrom> <MailTo>postmaster@mcsmemail.de</MailTo> </EmailSettings> <OtherSettings> <!-- MobileDeviceLimit defines the overall threshold of mobile devices for a single user to synchronize. Default is 5. --> <MobileDeviceLimit>5</MobileDeviceLimit> <!-- AgedDeviceLimit defines the threshold of allowed aged devices for a single user to be removed. Default is 1. --> <AgedDeviceLimit>1</AgedDeviceLimit> <!-- Time threshold in days to identify old mobile devices, Be default devices not synchronized for 150 days will be removed --> <LastSyncDays>150</LastSyncDays> </OtherSettings> </Settings>
Steps being executed by the script:
# Example 1 # Remove old mobile device partnerships without sending a report email .\Remove-MobileDevicePartnership.ps1 # Example 2 # Remove old mobile device partnerships and send a report email .\Remove-MobileDevicePartnership.ps1 -SendMail # Example 3 # Search for old mobile device partnerships and write results as CSV to disk .\Remove-MobileDevicePartnership.ps1 -ReportOnly # Example 4 # Remove old mobile device partnerships for a single mailbox and send a report email .\Remove-MobileDevicePartnership.ps1 -MailboxFilter USERALIAS -SendMail
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
Recently I was facing an issue where Windows Server 2012 R2 reported remaining 22% of free disk space of one of the Exchange Server data volumes. The Exchange Server data volumes are connected using mount points.
Before trying to identify any issues in regards to hidden system files or streams, I checked the volume shadow copy configuration using the Disk Management MMC.
Windows Disk Management showed that volume C: was using a mounted volume as shadow copy target.
Examining the available disk space using the Get-Diskspace.ps1 PowerShell script, it showed that WMI was reporting the FreeSpace the same way as the Disk Management.
[PS] D:\SCRIPTS\Get-Diskspace>.\Get-Diskspace.ps1 -ComputerName EX01 Fetching Volume Data from EX01 Name Capacity (GB) FreeSpace (GB) BootVolume SystemVolume FileSystem ---- ------------- -------------- ---------- ------------ ---------- E:\ExchangeDatabases\DatabaseSet1\ 2048 1083 False False NTFS E:\ExchangeDatabases\DatabaseSet2\ 2048 445 False False NTFS E:\ExchangeDatabases\DatabaseSet3\ 2048 1219 False False NTFS E:\ExchangeDatabases\DatabaseSet4\ 2048 1091 False False NTFS
The only viable solution to reclaim the wasted disk space was to remove the shadow copy of volume C.
First I checked the current list of shadow copies using the vssadmin command line tool.
D:\>vssadmin list shadows vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool (C) Copyright 2001-2013 Microsoft Corp. Contents of shadow copy set ID: {eb09ce08-f8a6-47ea-b48d-2d6da7591d4e} Contained 1 shadow copies at creation time: 23.06.2017 16:05:56 Shadow Copy ID: {3684b224-bca2-42c4-a0b3-43b7d0db2d96} Original Volume: (C:)\\?\Volume{df40ac48-f610-11e3-80ce-806e6f6e6963}\ Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1 Originating Machine: ex01.granikossolutions.eu Service Machine: ex01.granikossolutions.eu Provider: 'Microsoft Software Shadow Copy provider 1.0' Type: ApplicationRollback Attributes: Persistent, No auto release, Differential
The vssadmin tool does not clearly state the path to the shadow copy volume. Therefore, it is much more convenient to identify the shadow copy target using Disk Management. But the output shows that the shadow copy is nearly six months old. So it's safe to delete this orphaned shadow copy.
You can easily delete all shadow copies of a selected volume using the following command
vssadmin delete shadows /for=c: /all
But it turned out that the shadow copy could not be deleted, even with administrative credentials in use.
D:\>vssadmin delete shadows /for=c: /all vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool (C) Copyright 2001-2013 Microsoft Corp. Error: Snapshots were found, but they were outside of your allowed context. Try removing them with the backup application which created them.
Needless to say, that a well-known third party solution is in use to backup the servers. The shadow copy remainers are copies created by the backup solution and were not properly removed after backup due to a system failure during backup.
But how can you remove the current shadow copy without tempering the exisiting permissions for your account?
Simply use the Disk Management MMC to modifx the current shadow copy configuration and the shadow copy is removed.
Switch to the command line and check for existing shadow copies.
D:\>vssadmin list shadows vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool (C) Copyright 2001-2013 Microsoft Corp. No items found that satisfy the query.
The oprhaned shadow copy is gone.
Now open the Settings windows for the source volume again and change the Located on this volume to be the same as the source volume anfd change the Use Limit to the same value for the volume that is configured on other servers.
Enjoy Volume Shadow Copies