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
You want to know about the right on-premises Exchange Server architecture? A blog post about this topic has been published on the ESE blog yesterday.
Read the full blog post at ENow's ESE blog.
Enjoy reading.
This is a map of the current datacenter footprint of Exchange Online, as presented during Microsoft Igite 2017 in Orlando.
There is a difference between Exchange Online datacenters hosting mailboxes and front door endpoint datacenters. Front door endpoints are public peering locations providing client connections with higher reliability and lower latency.