Steps to set up a SFTP/SSH server using OpenSSH on Windows Server 2012 R2

1. Download the latest OpenSSH for Windows binaries. Choose the OpenSSH-Win64.zip package.

2. Extract the package and save them to C:\Program Files\OpenSSH folder.

3. Open an elevated PowerShell console, and run the following commands to install SSHD and ssh-agent services.

cd "\Program Files\OpenSSH"
.\install-sshd.ps1

If failed due to the Policy that prevents it from executing, run this instead:

powershell -ExecutionPolicy Bypass -File .\install-sshd.ps1

4. In the same PowerShell console, run the following commands to generate server keys and restrict an access to them.

.\ssh-keygen.exe -A
PowerShell -ExecutionPolicy Bypass -File .\FixHostFilePermissions.ps1 -Confirm:$false

5. Open an incoming port in Windows Firewall for the SSH server. You can either run the following PowerShell cmdlet to open it or do it through Windows Firewall set up from Control Panel.

New-NetFirewallRule -Protocol TCP -LocalPort 22 -Direction Inbound -Action Allow -DisplayName SSH

6. Open services window, locate the sshd service and click Start to start the service. If succeed, you are all set. And you need to change the Startup Type to Automatical so the service can be launched automatically.

Testing the connection to the server

You can use any tools that support SSH to connect to the SSH server you just set up, such as FileZilla, WinSCP, PuTTY to name a few. Take WinSCP for example, use the server’s name as Host name, leave the Port number at 22, and type in your Windows user account info as the username and password. If it’s part of the Windows domain, use the format of domain_name\username or username@domain instead.

In some cases where you need to verify the fingerprint of the server, this is how you can find out:

.\ssh-keygen.exe -l -f ssh_host_ed25519_key -E md5

then, when you connect to the SSH server the first time, you can compare the info you just collected with the one popping on the screen.

Alternative options

I had to try a few times to make OpenSSH work for me. But if it doesn’t work out for you, there are a few other options you can try to use as well.

• CoreFTP
• BitVise SSH Server
• freeSSHd and freeFTPd

Resources

Installation Guide on WinSCP

How to enable BitLocker encryption on Windows Server 2012

The reason I don’t see the Unlock Drive option is that the BitLocker feature is not enabled by default on a newly installed Windows Server 2012.

To enable the feature, open Server Manager and launch Add Roles and Features wizard.

Select BitLocker Drive Encryption option in Features stage and click Install.

It takes a few moment to get it installed. You will need to restart the server to have the change taken in place.

Once installed and restarted, you will see the Unlock Drive option appeared in the context menu.

And you will be able to unlock the drive by providing the password. If you need to access the same encrypted drive repeatedly, you can check “Automatically unlock on this PC” option.

The other way around this is to use the PowerShell cmdlet if you don’t want to enable BitLocker feature on the server.

The syntax of the cmdlet Unlock-BitLocker is something like this.

Unlock-BitLocker [-MountPoint] <String[]> -Password <SecureString> [-WhatIf] [-Confirm] [<CommonParameters>]

On Windows desktop systems, both folders are easy to clean up with the built in tool Disk Cleanup Utility. But, it’s not the case in Windows Server, especially the more recent versions like 2012 R2. You probably could enable Desktop Experience feature to bring back the Disk Cleanup Utility but it won’t guarantee to clean up these two giant folders managed by the system upgrades and updates. If you are facing the same challenge as I do, here are the options you can take away.

Clean up WinSxS folders on Windows Server 2012 R2

WinSxS, aka Windows component store, contains all the files required for a Windows installation as well as any updates to those files within the component store. Therefore, the folder could become quite big over time. Because it’s associated with system installation it’s not a good idea just simply deleting the folder. Rather, utilizing a command-line tool called DISM, Deployment Image Servicing Management, is way more appropriate. It has a parameter /cleanup-imagethat provides a few more advanced options to reduce the size of the WinSxS folder.

First of all, you can run the following to analyze the component store to see what’s included in there.

dism /online /cleanup-image /AnalyzeComponentStore

Then, run the following to remove superseded and unused system files from the system and reset the base so all existing updates cannot be removed after the command is completed.

dism /online /cleanup-image /StartComponentCleanup /ResetBase

It didn’t clean up a whole lot in my case, only claimed back a little over 1 GB space.

Note: If you are somehow still using Windows Server 2008 R2, installing KB2852386 after enabling Desktop Experience feature makes things a lot easy to clean up right with the Disk Cleanup Utility tool.

How to clean up WinSxS folder on Windows 2008 R2

How to clean up Windows.old on Windows Server 2012 R2

With Disk Cleanup out of the equation, manual cleanup seems to be the option left. Thanks to this Q&A at ServerFault, here is what I did to bring back over 50 GB of storage space.

First of all, run Sysinternals junction.exe utility to get a list of all junctions in a text file, junc.txt on my desktop.

junction.exe -s -q c:\windows.old > %UserProfile%\desktop\junc.txt

Then, run the following script in PowerShell to remove all junction points and single symbolic links on the system.

foreach ($line in [System.IO.File]::ReadLines("$env:userprofile\desktop\junc.txt"))
 {
     if ($line -match "^\\\\")
     {
         $file = $line -replace "(: JUNCTION)|(: SYMBOLIC LINK)",""
         & $env:userprofile\desktop\pstools\junction.exe -d "$file"
     }
 }

Replace with the correct path for junction.exe utility and the junc.txt files, if needed.

Once that’s done, run the following to take over ownership of the windows.old folder.

takeown /f c:\windows.old /r /d y

And reassign the full control rights to everyone.

cacls c:\windows.old /t /g everyone:F

Then, finally to remove the whole folder.

rmdir /s /q c:\windows.old

It may take a little while for the command to complete but once it’s done you will be so delighted to see how much space you just brought it back to life. Enjoy.

If you have a lot of users using RDS with UPD enabled, there will be a lot of individual UDP files stored on the file share, named with the unique GUID of the AD user, like below:

So, how to identify which UPD disk belongs to which user account?

You can use the following PowerShell cmdlet to find out the user based on the GUID.

Get-ADUser -fileter {SID - like "GUID"}

Or, find out the GUID based on the user account ID.

Get-ADUser -filter {SamAccountName -like "UserID"}

Or, even better, use this little portable standalone tool called Sidder to help you to quickly identify which UDP belongs to which AD user. You will need .Net 4.5 Framework to use this tool.

The ones in orange are the ones that are in use at the moment. The tool also allows you to delete UPD as well. Deleting UPD will result in a fresh start for that user next time when they log in.

Turns out, what’s caused this problem is that the server was configured to use WSUS instead of Microsoft Windows Update server. Because Windows needs to download the 3.5 installation files from Windows Update service, it couldn’t if it’s configured to use WSUS.

The fix is also pretty straightforward, just one Group Policy setting that needs to be changed. And you can do so through Local Group Policy so it doesn’t affect the Group Policies you have in place on a domain level.

Open Group Policy Editor, navigate to the following location:

Computer Configuration > Administrative Templates > System

Open “Specify settings for optional component installation and component repair” setting, select Enable and choose the “Contact Windows update directly to download repair content instead of Windows Server Update Service (WSUS)” checkbox.

Click OK.

.Net 3.5 feature got installed successfully after I tried again.