Schannel Event 36870 – A fatal error occurred – RDP

Came in one morning to reports that nobody can access a particular Windows Server 2012R2 RDS server.  To keep from being too wordy, I took some time and narrowed it down to just an issue with that one particular server, not RDS itself.  As I kept digging I came across numerous instances of the following Schannel Event 36870 error on the effected RDS host, which I could then reproduce by attempting to make an RDP connection to the server experiencing the issue.

Now this led me down quite a number of SSL certificate rabbit holes, but the winner came from this stackoverflow article, which referenced this Microsoft blog post, in which scenario 2 was my solution.  I restored default permissions to C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, restarted the box, and wha-lah!  RDP was functional again!

QuickBooks Periodically Asking for Windows Admin on RDS Server

I come across this issue from time to time with new QuickBooks installations on RDS (terminal) servers.  The fix is really quite simple, though for some reason I always seem to forget about it when deploying.  Anywho, the symptom is every once in a while the QuickBooks application will require a Windows administrator to logon and launch the application.  Users will see the below prompt:

To fix this:

1. Logon to the server that is hosting the QuickBooks database service

2. Launch services.msc and navigate to the QuickBooksDBxy service (xy changes depending on version)

3. Open the properties of the service and select the “Log On” tab

4.  Change the “Log on as:” to “Local System account” with the “Allow service to interact with desktop” option checked

5. Click OK and restart the service



Enabling Password Change for RDS 2012R2/2016

The ability for a user to change their password when it has expired via the Remote Desktop Services webpage is disabled by default.  Enabling the feature is quite simple, but with anything take a moment to consider the security implications and make sure that your organization is okay with the risk.

Connect to the server that hosts the RD Web Access role and launch IIS.  Navigate to Sites\Default Web Site\RDWeb\Pages and select Application Settings.

Locate the “PasswordChangeEnabled” setting, open it up and change the Value to “true”.

Click OK and you’re off to the races.

HAProxy Configuration for Remote Desktop Services

Remote Desktop Services can be a touchy subject for some, but I find the solution to work well.  When the need to provide external access arises I will typically use HAProxy to, you never would have guessed it, proxy the traffic to the appropriate places.  It has proven to be rock solid in its performance, and offers decent logging when issues arise.  Please note that there should be additional security measures taken to secure this, so don’t just drop it in and think you’re done.

A lot of the configuration options are simply taken from the HAProxy documentation.  I do suggest taking some time and reading through a lot of the common options to help fine tune your config.  Before I drop the my “template” config, let’s do a quick overview of what it contains (though I will have comments in the config).  First things first, I set up the built in stats page.  This is very useful and I don’t see much reason not to set it up.  I then redirect port 80 traffic (http) to port 443 (https/SSL).  Next up is to proxy any https/SSL traffic in to the RDS server.  Finally, we proxy the RDP traffic through and we’re good to go!


Sage 50 “Failed to switch Terminal Server to INSTALL mode…”

I think that anyone would agree that dealing with financial software is always a pain.  Today is no different!  All joking aside, the issues (yes with an “s”) began from the beginning of my journey to upgrade Sage 50 2017.2 to Sage 50 2018.1.

To be honest Sage has really tried to make this a painless process.  Should be as simple as downloading the update via the application GUI, closing the application to prompt the upgrade, and you’re off to the races.  If that worked as designed it really would be simple, not that the issues are that bad just frustrating.  Anywho, upon closing the application to upgrade I was presented with the following “error” message:

Rather bothersome considering I (obviously) was an administrator, but okay let’s just find the actual upgrade executable and run it as administrator.  I navigated to %InstallDirectory%\Sage\Peachtree\<CompanyName>\Updates and ran Sage50_2018.1.0.Upgrade.exe found there.  Simple enough right?  Of course not my young padawan learner, this is financial software after all.  I was then presented with the following error:

For starters, I love the typo “To swith” in the error message.  Spoilers, the switch doesn’t work.  This brought me to old faithful…Google.  I stumbled upon a Sage support article (found here) which provided multiple options for resolving this issue.  I chose the second option which had me do the following:

  1. Open up %TEMP%\RarSFX0\peachw\install
  2. Run _setup.exe as administrator
  3. Follow prompts to install

That did the trick for me, as such that brings this little post to a close.


P.S. If you have activation issues after the upgrade, bounce the box and try again.

Client Machine Cannot Launch RDS Apps. Event 4625 Status 0xC000035B.

My help desk gave me a shout today saying that a particular user could not launch an RDS app from their computer.  Naturally I checked all the basics with test account and all was operating as expected so I knew it had to be something with the client machine.

I did a bunch of more basic troubleshooting (I didn’t have a lot of faith in this particular technician) and then started digging through the logs on the RDS Gateway box until I found the following little bugger (Event 4625):

Naturally this doesn’t tell me anything, but with a little Google-Fu I came up with this source.  I changed the LmCompatibilityLevel value to 3 or higher as directed, gave the machine a reboot, and wha-lah it worked.  The value can be found at HKLM\SYSTEM\CurrentControlSet\Control\Lsa.

Installing Office 2016 on RDS Server with Shared Computer Licensing

When installing Office on an RDS Server accessed by multiple users, you need to configure the installation for shared computer licensing.  To do this, you begin by downloading the Office Deployment Tool.  Once you have that downloaded, run the executable.  This will provide you with two files; configuration.xml and setup.exe.  Edit the configuration.xml file and you should see something similar to what is below:

This is missing a few key configuration options, such as the “SharedComputerLicensing” which is the primary reason for this post.  Also, I’m personally not all that interested in adding Visio to most of my RDS environments, but I am interested in deploying the 64-bit version of Office.  See this Office Support page to see all of the configuration options.  It should look more like what is below:

Once you have that done, save the configuration.xml file.  Shift + right-click somewhere in the file explorer window and select the “Open command window here” option to make your life a little easier.  Then run the following two commands:

The second command will take a while as it is actually installing.  Once it is done, you are done!

Windows Server 2012R2 Pending Reboot Status Won’t Clear

Recently I was setting up a new RDS deployment and when I went to install one of the roles (in this case the RD Gateway) it would not let me do so saying that the server was still pending reboot.  This isn’t uncommon with new deployments as I’m doing many things at once so I gave it the good ol’ reboot, but the issue still persisted.  Confuzzled I consulted Uncle Google for some advice and found the answer in a pesky reg key.  Once I deleted the “PendingFileRenameOperations” reg key from the location below and gave the box a good reboot everything worked as normal.

Path to reg key: HKLM\System\CurrentControlSet\Control\Session Manager

Google credit found here.