The PowerShell script to set Client Access mailbox settings based on AD group membership has been updated.
The issue fixed had been registered as issue #1.
The new release version is v1.1.
When you migrate messages from alternative email solution (e.g. Lotus Notes) you might migrate sentitive 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 modificatiuon 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 to 0 (which 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 mailbnox 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