These steps can improve Windows performance a whole lot. It works because a vast array of different applications and services in Windows utilize VSS on their backends. All of the below, except for one server-only step sometimes needed, is encapsulated in PowerShell script (3.0 and up) OVSS.ps1 , part of the windows-tools project.
To do the VSS optimization interactively, start an administrative CMD, and then…
Step 1:
vssadmin Delete Shadows /All
If there are orphan shadows, you will be asked whether you want to delete them. If there are and you delete them, you will see immediate performance benefit. Reportedly, Windows autodeletes them only after there are 64 per volume. We prefer to see zero! These build up as a result of bad shutdowns, drive and drive controller issues, and insufficient RAID resources to serve demands.
Step 2:
We now improve any existing preassociation of disk space for VSS. On some machines, this will increase performance very impressively, immediately. In general it keeps them smooth and stable and prevents hesitations. This does not reserve or take up the space, it just “associates” it, makes it ready for use, so that whenever Windows wants to do any of the bajillions of things it does with VSS, things ranging from tiny to enormous, it can skip that step.
It is worthwhile to know that C: on all workstation installs and many server installs, has a minimal preassociation already set up. And we should check to see if it has been done. So the first step is to check it. Do the below:
vssadmin list shadowstorage
If it gives you something like this:
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.
Shadow Copy Storage association
For volume: (\\?\Volume{84214e3c-0000-0000-0000-100000000000}\)\\?\Volume{84214e3c-0000-0000-0000-100000000000}\
Shadow Copy Storage volume: (\\?\Volume{84214e3c-0000-0000-0000-100000000000}\)\\?\Volume{84214e3c-0000-0000-0000-100000000000}\
Used Shadow Copy Storage space: 0 bytes (0%)
Allocated Shadow Copy Storage space: 0 bytes (0%)
Maximum Shadow Copy Storage space: 100 MB (20%)
Shadow Copy Storage association
For volume: (C:)\\?\Volume{84214e3c-0000-0000-0000-501f00000000}\
Shadow Copy Storage volume: (C:)\\?\Volume{84214e3c-0000-0000-0000-501f00000000}\
Used Shadow Copy Storage space: 0 bytes (0%)
Allocated Shadow Copy Storage space: 0 bytes (0%)
Maximum Shadow Copy Storage space: 373 GB (20%)
where “Maximum Shadow Copy Storage space: “ for each volume is set to 20%, the rest has been done, you are fully optimized. Otherwise, if this is a desktop OS, we resize the existing association for each volume. For volumes without letters, and to pull a list of all VSS-ready volumes, see the note towards the end of this document.
So for the C drive, do the below in administrative CMD:
vssadmin Resize ShadowStorage /For=C: /On=C: /MaxSize=20%
Do repeat for any other active hard drive partitions, D:, E:, et cetera. Don’t worry if you get an error, the next step covers it.
Step 3:
It may well throw an error, saying there is no such association. If this is a workstation OS, vssadmin lacks two commands which we need for any further steps, so in that case we are done. But on any Windows Server OS from 2008R2, if the error was thrown, we do an Add:
vssadmin Add ShadowStorage /For=E: /On=E: /MaxSize=20%
Step 4:
And finally (server only), one more thing which can help if, for instance, C: is almost full but E: has plenty of space:
vssadmin Delete ShadowStorage /For=C: /On=C:
vssadmin Add ShadowStorage /For=C: /On=E: /MaxSize=20%
This maximizes overall performance, and also prevents possible backup failures and other issues due to insufficient disk space on C:.
Note:
On some machines, the volumes do not have letters. For these you will need to use the volume GUID path. In vssadmin list shadowstorage
, they look like this:
Shadow Copy Storage association
For volume: (\\?\Volume{99ac05c7-c06b-11e0-b883-806e6f6e6963}\)\\?\Volume{99a
c05c7-c06b-11e0-b883-806e6f6e6963}\
Shadow Copy Storage volume: (\\?\Volume{99ac05c7-c06b-11e0-b883-806e6f6e6963}
\)\\?\Volume{99ac05c7-c06b-11e0-b883-806e6f6e6963}\
Used Shadow Copy Storage space: 0 B (0%)
Allocated Shadow Copy Storage space: 0 B (0%)
Maximum Shadow Copy Storage space: 32 MB (32%)
For such a situation, substitute \\?\Volume{99ac05c8-c06b-11e0-b883-806e6f6e6963}
(the whole long string) for C:
in the above command lines.
PowerShell will give GUI paths for all volumes thusly:
GWMI -namespace root\cimv2 -class win32_volume
References are here:
https://technet.microsoft.com/en-us/library/cc788050.aspx
https://www.storagecraft.com/support/kb/article/289
http://backupchain.com/i/how-to-delete-all-vss-shadows-and-orphaned-shadows
http://www.tech-no.org/?p=898
Remote Web Workplace. Certificates are verified AOK, and yet at the point of RDP, you receive a popup reading “Your computer can’t connect to the remote computer because no certificate was configured to use at the Remote Desktop Gateway server. Contact your network administrator for assistance.”
To fix this, you’ll need the Remote Desktop Gateway Manager. If you have it, it’s in Start, Administrative Tools, Remote Desktop Services. If you don’t have it, install it:
dism /online /Enable-Feature:Gateway-UI
Then:
- Open the RDGM.
- Right-click the server object, open properties.
- Open the SSL Certificate tab.
- Click Import Certificate.
- Choose the correct certificate — it’s the Exchange list, if this is SBS — and click OK.
FSUTIL is a general-purpose NTFS tweak tool. Here is a set of changes which appears to be helpful in general towards performance:
fsutil 8dot3name set 1
fsutil behavior set memoryusage 2
fsutil behavior set disablelastaccess 1
fsutil resource setavailable C:\
fsutil resource setlog shrink 10 C:\
In order:
- Turns off 8dot3name creation. Does not invalidate existing 8dot3names.
- Increases RAM cache devoted to NTFS.
- Turns off “last access” timestamp storage for files. Disindicated for some older backup systems.
- Makes the filesystem more focussed on “availability” and less on “consistency”.
And here are some which increase reliability:
fsutil repair set C: 0x01
fsutil resource setautoreset true C:\
fsutil resource setconsistent C:\
In order again:
- Turns autorepair on for C: drive.
- Cleans transactional metadata on next mount
- Makes the filesystem more focussed on “consistency” and less on “availability”.
Do be aware that “resource setavailable” and “resource setconsistent” are opposites, both do not get set at the same time :-) Also neither of them appear to be valid on system volumes, errors are thrown.
Here is one set which seems to balance reliability and performance boost:
fsutil 8dot3name set 1
fsutil behavior set memoryusage 2
fsutil behavior set disablelastaccess 1
fsutil repair set C: 0x01
fsutil resource setautoreset true C:\
fsutil resource setconsistent C:\
fsutil resource setlog shrink 10 C:\
Definitions and items:
- VPN stands for Virtual Private Network. A true VPN connects two different networks, using an encrypted “tunnel” through Internet or other non-private connectivity.
- SSL VPN as defined by OpenVPN (and its wrappers like Watchguard SSL VPN), is not a true VPN. It is an SSL-encryption agreement between devices, building either a TCP tunnel or a UDP dataflow, over which tightly controlled network redirection traffic is distributed.
- This means that the source and destination subnets, though not IPs, can be the same.
So let’s say that we need to give a PC which is sitting on someone else’s 192.168.1.0/24 network, an encryption-protected connection for RDP and file sharing, to the office Windows machine at 192.168.1.20. If SSL VPN were true VPN, this would require a subnet change at either the remote side or the home LAN, no further option. But it’s not, so we can do this:
- Restrict the SSL VPN capability on the office side, to just the domain controller (e.g., 192.168.1.250) and the RDP destination (192.168.1.20).
- Make sure that the IP of the device on the remote side, is not a duplicate of either the domain controller or the RDP destination on the office side. So it can’t be either 192.168.1.250 or 192.168.1.20.
- We can do this by setting a static IP on the remote device; alternatively, we can change the DHCP subnet of the remote site. Either of these are vastly easier than changing subnets!
- The only loose end left, may be network printing on the remote side. Just make sure that the printer’s IP is not any of the vitals at the office, and is IPv4, and it will work just fine. Some printers (generally consumer-grade) are defaulting to semi-proprietary IPv6 modes in their Windows configurations, and at least some SSL VPN configurations will not play ball; in this scenario you’ll want to convert the PC setup(s) to use v4.
This one courtesy of the amazing Mike Hunsinger.
- Run the web site SSL test here, specifying the URL to study:
https://www.ssllabs.com/ssltest/
- A rating of A through F, or T, will be reported. T means a fundamental problem with the certificate install itself.
An A rating means the server is set to only accept protocols such as TLS1.2, that are currently recognized as secure. Anything below an A rating means the server responded on SSL or other protocols considered insecure.
Scroll down on the SSL Labs rating page to see the technical details on what protocols were detected and which are failing security checks.
If this is a Windows web server, remote in and:
- Download the portable app, IISCrypto from here:
https://www.nartac.com/Products/IISCrypto/Download
Run this program on the server which hosts the website.
You’ll get a window showing all protocols that are on this server and whether they’re enabled or not. To achieve an A rating, use the details view from SSL Labs as a guide. Disable any protocols in IIS Crypto that SSL Labs flags as a security risk. Only do these after verifying that the web site / web application will certainly work with the newest protocols and does not depend on the older ones.
The protocols that a Windows webserver will accept are specified via Regedit entries. IIS Crypto reads and modifies these Regedit entries automatically.
- Reboot the webserver. Then retest with SSL Labs. Make further changes as dictated by the scoring detail.
- If you have control over workstations, use Group Policy to deploy the certificate to all of them, and to disable insecure protocols, and to enable the secured protocols.
If you see this while trying to share a calendar to another Exchange or Exchange Online user, thus far this has been seen to be caused by (a) duplicate Permissions user entries in the calendar, and (b) user entries in the calendar belonging to deleted, disabled, or otherwise invalid user accounts. Remove the duplicates or invalids, and it goes away!