We were taught early on that when you heat water to 212 F (100 C,) it starts to boil. Oh, those memorable science experiments we did in high school. We put a thermometer in a water-filled flask and light up a burner to heat the water in the flask. We watch as the thermometer records the temperature of the heated water. We see it. We believe it. And we called it science. Until a friend told me otherwise. He lived in the mountains and explained that my statement about the boiling point of water is partially – not completely – true. Because the boiling point of water – or any liquid, for that matter – is not just dependent on the temperature but also the atmospheric pressure. I wished they taught Phase Diagrams in high school.

There are a lot of documentation, blog posts, tutorials, etc. about how you can configure database instant file initialization. I even wrote one back in 2008. It’s one of those performance hacks that you can implement on your SQL Server database to skip past zeroing out the data files when performing file operations. If you’ve been working with SQL Server for a while, you know that this is a recommended best practice – grant the Perform Volume Maintenance Task permission to the SQL Server service account.

Did the Atmospheric Pressure Change?

SQL Server database files have always been stored on storage subsystems that have direct relationships with the host operating system – direct attached storage (DAS,) storage area networks (SAN,) volume mount points, shared storage for failover clusters, etc. So, when we refer to file system permissions, we look at the host operating system as a point of reference. Granting the SQL Server service account the Perform Volume Maintenance Task permission? Open the “Local” Security Policy management console (emphasis mine.)

SQL Server 2012 introduced the option to store database files on a Server Message Block (SMB) file share. This means that you can create databases on a file share – be it a standalone instance or a failover clustered instance. In the past, we probably wouldn’t even consider storing database files on SMB file shares due to the latency. But the improvements in the SMB protocol as of Windows Server 2012 have made it possible to run low latency workloads like SQL Server.

But this also means that what we used to do to enable database instant file initialization may no longer apply because the file system is no longer considered local to the host operating system. In fact, the installation process will give you an idea about file system permissions when you decide to configure SQL Server to store database files on SMB file shares.

To create the database files on the SMB file share, we need to grant the full control share permissions on the remote file system or the database creation process will fail.

Let’s Change the Temperature

You can grant the Perform Volume Maintenance Task permission to the SQL Server service account all you want on the machine running SQL Server and you won’t see any difference. That’s because the permissions that you need to get database instant file initialization going need to apply on the host running the storage subsystem. For example, if you are installing SQL Server on a machine named SQL01 and the database files will be stored on a file share with host named HA-FileShare, here are several things that you need.

1. The machine hosting the file share should to be joined to an Active Directory domain. From a security perspective, it’s easier to manage computers and user accounts when they are joined to an Active Directory domain. The machine hosting the file share will have to be joined to an Active Directory domain if you will be installing a SQL Server failover clustered instance.
2. The SQL Server service account should be granted the Full Control NTFS and share permissions on the file share. Remember, it will be the SQL Server service account performing the file system operations. So, it needs the appropriate permissions on the file share.
3. The SQL Server service account should be granted the Perform Volume Maintenance Tasks permission on the remote machine. That’s right. When you run the Local Security Policy management console to grant the Perform Volume Maintenance Task permission on the SQL Server service account, you have to do it on the remote machine running the file share. In this example, it should be done on the host HA-FileShare not on the host SQL01. That’s because the file system is local to HA-FileShare. 
4. Either restart the SQL Server service or reboot the remote machine. This is to make sure that the permissions are properly applied. We usually restart the SQL Server service for this to take effect. But since the permissions are applied on a remote machine, you could also reboot the remote machine hosting the file share. I wouldn’t recommend that approach especially if the file share is hosting other mission-critical applications.

New features introduced in SQL Server can force us to learn new things. But understanding how the features work and the fundamentals behind them can help make implementation a lot easier. It’s one of the reasons I like going back to the basics.