Deleting Data on Deduped Volume Doesn't Clear Up Space

I have recently cleared up some data on a drive volume which was deduped via Server 2012 R2.  The dedupe functionality was working extremely well, and I was getting 80% dedupe on a 3.5TB volume, so no complaints there, however when it came time to archive off some data and then delete it, I noticed that the data wasn't actually freeing up. 

This little issue will only occur when you've got Dedupe enabled via the Server OS.  Luckily, there's an easy way to get around this, with a quick PowerShell command.

The solution is to enable something called Garbage Collection.  This is actually a scheduled job that is designed to reclaiming any unused chunks of data that are no longer being referenced by files that have been recently modified or deleted.  WHilst it may run on a scheduled basis, we need to force it to run here, to speed up that process.

Open up PowerShell and type in the following command:

Start-DedupJob D: -Type GarbageCollection -Verbose

The drive letter in bold is whatever your volume is which you'd like to run this on.  Once you've done this, the server will kick into action and will start cleaning up the volume.  You can monitor it's progress by using the following command:

Get-DedupJob

Reset SA Password - SQL Server

I recently needed to get into an SQL database, which only had the SA account as a 'sysadmin'.  The unfortunate thing was the client didn't have the SA password documented anywhere.  So we needed to reset that password somehow, or risk having to completely reinstall SQL!

Luckily, there's a relatively easy way to be able to get into a locked out SQL database, by resetting the SA password.  The only caveat, is that you are a local administrator of the SQL server itself.  Most of the time it's going to be on the domain, so as long as you have a Domain Admin account, you're going to be able to get in rather easily.

Fisrtly, you will need to download PsExec.  It's from the Microsoft website.  Extract the contents to your desktop of the server or somewhere you can easily access the .exes within it.

Through CMD, navigate to the location of the EXEs.

psexec -s -i "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

This will fire up SQL Management Studio, running as the system account.  Once you've done that, go into the security section of SQL and reset the password for the SA account!

It's that simple!  Shouldn't take you more than 5 minutes to get in and reset the password, provided you come across this blog ;-)

Poor SMB performance on new File Server (2012 R2)

Recently upon setting up a new server environment for a client, I noticed that workstations had rather poor performance when accessing data from an SMB on the File and Print server.  Transferring of data to the file server was rather slow, and opening up .exes from the network took ~50 seconds  before I was prompted to run the application (not acceptable).  All servers were Server 2012 R2, and it was running on a Dell T440 with Hyper-V.  All the NICs are Broadcom, and the drivers were fully up to date.

After looking into this issue, I discovered that some settings on the Network Adapters needed to be changed.  When checking the properties of the network adapter (in this case I had two NICs in a team, so I had to do it on both of them), go to Advanced, and set the following items to Disabled:

• Large Send Offload V2 (IPv4)
• Large Send Offload V2 (IPv6)
• TCP/UDP Checksum Offload (IPv4)
• TCP/UDP Checksum Offload (IPv6)
• Virtual Machine Queues

Keep in mind that when doing this,  it will drop off the network adapter for about 10 seconds.  If you're doing this on a live Virtual Host, make sure you only  do it to one adapter, and wait for the adapter to come  back up online, and ensure the NIC Team is fully active again before performing this on the second NIC.  This will ensure you don't lose network connectivity to the host, and subsequently to the Virtual Machines.

After doing this for both NICs, I tested netowrk connectivity, and it was considerably faster.  Even just loading the file structure on a network drive was immediate, rather than a 1-2 second wait.  Testing it out on the same .exe that I had issues with before, it's gone from opening in ~50 seconds, to opening in ~1-2 seconds.