Thomas Stensitzki is a leading technology consultant focusing on the Microsoft messaging and collaboration technologies and the owner of Granikos GmbH & Co. KG.
He is an MVP for Office Apps & Services since 2018.
Thomas is an MCT Regional Lead for Germany and delivers Microsoft Learning training courses for Office 365, Microsoft Teams, and Exchange Server.
He holds Master certifications as Microsoft Certified Solutions Master Messaging and as Microsoft Certified Master for Exchange Server 2010. These certifications make him a subject matter expert for any messaging topic related to Microsoft Exchange, Exchange Online, Microsoft 365, and hybrid configurations.
Follow Thomas: LinkedIn, Twitter
His sessions: https://sessionize.com/thomas-stensitzki
MVP Blog: https://blogs.msmvps.com/thomastechtalk Personal blog: http://justcantgetenough.granikos.eu Personal website: http://www.stensitzki.de Thomas' Tech Talk: youtube.com/ThomasStensitzki
Contact Thomas at thomas@mcsmemail.de
When you migrate messages from an alternative email solution (e.g. Lotus Notes) you might migrate sensitive content that must stay private in the new Exchange Server target location.
So how can you mark such messages as private?
The privacy level (Sensitivity) of a mailbox item is controlled by MAPI extended property 0x36.
The command line tool searches for messages containing a given text as a subject substring.
The c# code sets the extended property 0x36 to 2.
A mailbox is accessed using Exchange Web Services. The EWS endpoint is discovered using AutoDiscover for the selected mailbox.
The item modification is handled by the following code segment:
foreach (var extendedProperty in Message.ExtendedProperties) { if (extendedProperty.PropertyDefinition == extendedPropertyDefinition) { if (log.IsInfoEnabled) { log.Info(string.Format("Try to alter the message: {0}", Message.Subject)); } else { Console.WriteLine("Try to alter the message: {0}", Message.Subject); } // Set the value of the extended property (0 is Sensitivity normal, 2 would be private) Message.ExtendedProperties[extendedPropertyindex].Value = 2; // Update the item on the server with the new client-side value of the target extended property Message.Update(ConflictResolutionMode.AlwaysOverwrite); } extendedPropertyindex++; }
SetPrivateFlags.exe -mailbox user@domain.com -subject "[private]"
Search the mailbox for all messages having a subject string containing [private] and ask for changing each item if -logonly is not set to true. If -logonly is set to true only a log will be created.
SetPrivateFlags.exe -mailbox user@domain.com -subject "[private]" -noconfirmation
Search the mailbox for all messages having a subject string containing [private] and change all found messages without confirmation.
It should be noted that this solution is intended for use in migration scenarios.
When providing access to mailbox delegates you can enable access to your private elements as well. But access to shared mailboxes is not configured using the delegation workflow.
The code has been tested using Exchange Server 2013 CU15.
The program utilizes log4net to log detailed information to the file system. The configuration is controlled by the application's config file.
Any issues or feature requests? Use Github.
Like the code? Leave a note.
Sometimes you have the need to download the Offline Addressbook (OAB) for the Outlook email client manually.
When initiating a manual OAB download you might encounter a 0x80200051 error. A common mitigation scenario is to switch between Outlook Online-Mode and Outlook Cached-Mode multiple times. This mitigation scenario does not solve the issue.
When you active Outlook Cached-Mode it is required to perform a full OAB download. The OAB download dialogue provides an option to download OAB changes only. This option ist selected by default. To start a full OAB download you must deselect the checkbox.
Using this download setting you will not encounter the mentioned error and the Offline Addressbook is downloaded by your Outlook email client sucessfully.
Enjoy Outlook!
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
An update to the PowerShell script (Set-ReceiveConnectorIpAddress) to add or remove remote IP address ranges to/from Exchange Server receive connectors is available.
A new parameter to provide a comment on why an IP address is added or removed has been added to the script.
# EXAMPLE .\Set-ReceiveConnectorIpAddress.ps1 -ConnectorName MyConnector -IpAddress 10.10.10.1 -Action Remove -ViewEntireForest $true -Comment 'Personal request of upper management'
Get the most recent version at Github
This script adds or removes IP addresses or IP address ranges to/from existing Receive Connectors.
The input file can contain more than one IP address (range), one entry per line. The IP address parameter can be used to add a single IP address.
The script creates a new sub directory beneath the current location of the script. The script utilizes the directory as a log directory to store the current remote IP address ranges prior modification.
A log is written to the \log subfolder utilitzing the GlobalFunctions Logger object.
# Example 1 # Add all IP addresses stored in D:\Scripts\ip.txt to a receive connector named RelayConnector .\Set-ReceiveConnectorIpAddress.ps1 -ConnectorName RelayConnector -FileName D:\Scripts\ip.txt -Action Add
# Example 2 # Remove IP address 10.10.10.1 from a receive connector nameds MyConnector from all Exchange Servers in the forest .\Set-ReceiveConnectorIpAddress.ps1 -ConnectorName MyConnector -IpAddress 10.10.10.1 -Action Remove -ViewEntireForest $true