Native Windows File Checksum Tool: certutil -hashfile

Just a quick note in the interests of software trust and security: there’s a great builtin tool in Windows 10 that we can use to check files we download to make sure they haven’t been tampered with or otherwise adulterated. We don’t need to worry about using untrusted bits to check our untrusted bits any more, and we can toss the legacy FCIV.exe in the recycling bin. This built-in checker included in the Windows 10 distro will calculate all of the most common hashes used these days, such as MD5, SHA1, SHA256, and SHA512.

For example, at Command Prompt, just run

certutil -hashfile "C:\VeraCrypt Portable 1.23.exe" sha256

to check your portable Veracrypt file. The “certutil” tool is very powerful and has a myriad of other uses, but the full help info for “certutil -hashfile” is pretty straightforward:

Microsoft Windows [Version 10.0.17134.345]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>certutil -hashfile -?
  CertUtil [Options] -hashfile InFile [HashAlgorithm]
  Generate and display cryptographic hash over a file

  -Unicode          -- Write redirected output in Unicode
  -gmt              -- Display times as GMT
  -seconds          -- Display times with seconds and milliseconds
  -v                -- Verbose operation
  -privatekey       -- Display password and private key data
  -pin PIN                  -- Smart Card PIN
  -sid WELL_KNOWN_SID_TYPE  -- Numeric SID
            22 -- Local System
            23 -- Local Service
            24 -- Network Service

Hash algorithms: MD2 MD4 MD5 SHA1 SHA256 SHA384 SHA512

CertUtil -?              -- Display a verb list (command list)
CertUtil -hashfile -?    -- Display help text for the "hashfile" verb
CertUtil -v -?           -- Display all help text for all verbs


For purposes of checksum verification (i.e., the “-hashfile” option), it seems to be portable (you can find certutil.exe in C:\Windows\System32), meaning we should be able to build it into WinPE images, discretely carry it in the event anyone should try to coerce us into installing untrustworthy software, etc.

Availability Group Endpoint URL Firewall Gotcha

A few days ago I was working on changing the Endpoint URL and Port for a 2016 SQL Server Availability Group to use a private network interface. We wanted this so we could have the Synchronizing (or Mirroring) traffic have its own dedicated network, which would keep it away from the network traffic of client connections to the database server. This would help increase the throughput of data to and from the databases in the Availability Databases list.

Our setup is a straight forward Windows Cluster with two Nodes. We have two stand alone SQL Server Instances running on these Nodes. Each Instance has an Availability Group defined with one Node the Primary Replica and the other Node the Secondary Replica. We run the Replicas in Synchronous Commit Availability Mode with Automatic Failover. All connections are allowed to the Primary Role and the Readable Secondary is set to no.


SQL Server 2016 Configuration Manager missing, SSMS 17.2 “Cannot connect to WMI provider”

On an internal SQL Server 2016 instance that we run on a Windows 10 host/OSE, we had SQL Server Management Studio 17.1 installed, and it recently informed us that a new version (17.2) was available. Someone performed that upgrade (I plead the fifth!)– perhaps uninstalling 17.1, and doing the full install of 17.2 SSMS. A few days later (while logging traffic through the network generated by using “runas” to authenticate SSMS to another domain) I found that the local copy of SQL Server Configuration Manager (under Start > Microsoft SQL Server 2016 > Configuration Tools) had disappeared, and we instead had SQL Server 2017 RC1 Configuration Manager (Under Start > Microsoft SQL Server 2017 RC1).

And that would have been fine– but launching it generated an error:

“Cannot connect to WMI provider. You do not have permission or the server is unreachable. Note that you can only manage SQL Server 2005 and later servers with SQL Server Configuration Manager.
Invalid namespace [0x8004100e]” Keep reading…

The feature “Scale out deployment” is not available in this edition of Reporting Services

When you migrate your SSRS installation to a new host or instance, additional records can get added to [dbo].keys in the ReportingServices database. This is the source of the error. Assuming you do not intend to use scale-out RS– in which case, you need to check the Edition you are installing– the solution is to delete all but the newest record. Keep reading…