I'm a big user of both RD Tabs (of course) and ConEmu, a great terminal app for Windows. I am not sure when this issue started, but it was not always present. I think in later Windows 10 builds something may have changed to cause this, but I don't have any evidence and I can't trace the behavior to anything in RD Tabs' source code (certainly the source code has not changed materially in a couple years).

So here's the issue. If you are connected to a remote desktop session where in that session you are running ConEmu, when you switch out of RD Tabs to another Window then back in, you'll see the "@" symbol appear in your ConEmu window one or more times. This happens consistently every time the focus changes back to that window.

Using a keylogger, I was able to see that every time the focus changes on the RDP control, it appears that it resets the keyboard state, sending 50 or more "key up" events for all modifier keys as well as a key-down key-up cycle for keycode 255. I don't have any code like this in RD Tabs. And just to be sure, I disabled all the input focus fix-ups in a debug build and it still happened. I think it's just a change in the underlying RDP control, at least the hosted control that RD Tabs uses. I don't see this behavior in the native app.

In a way it makes sense, there certainly was a problem in older versions of the control where keyboard modifiers could get stuck if you switched out of remote focus to another app then clicked back in. To the remote session, it would, for example, see a SHIFT KEY DOWN event, but not always a SHIFT KEY UP event. By just blanketing the remote session when focused is resumed with KEY UP for all modifiers, it prevents this issue from happening.

So that's all well and good, why does it impact ConEmu? I'm not entirely sure, but I think that keycode 255 may be the culprit since it's the only KEY DOWN event that appears in the input stream. But, again, I'm not sure.

In any case, it manifests as a "@" in the input stream. And there's nothing in RD Tabs I can do to fix this, I can't stop those key codes from going to the remote desktop.

But you can fix this with a little workaround in ConEmu! Basically you just need to assign an empty macro to the keycode it is receiving and it won't output anything anymore.

Go to the Keys & Macro section, select "Macros" in the drop-down. Find an empty macro. I just used Macro 32. Give the "Choose hotkey" field input focus, then click out of RD Tabs to another window and click back in. It will change from to just an empty field. Even though you don't see anything, it's been assigned to that weird rogue keypress. Click save and you are done.

UPDATE November 3, 2021: the double click problem returned this week in the left mouse button.  I took apart the mouse and replaced the button again.  I'm skeptical now that the Japanese Omron switches are any better than the Chinese ones.  It might just be an issue with all Omron switches.

---

There was a Black Friday deal in 2019 for the Logitech G903 mouse.  In theory, it's a great mouse: wired and wireless, high precision, comfortable, tons of button configuration.  But it has one really common issue: the dreaded double click problem.  I was coming from a G502, so it seemed to be a perfect mouse to transition to.  They are really similar, although the 903 doesn't have a wing -- which I'm glad.  I got about six months of use before the problem popped up consistently.

So I decided I'd go the route of replacing the switches.  The problem, supposedly, is more cheaply manufactured Chinese Omron switches as opposed to (again supposedly) higher quality Japanese Omron switches.  There's information all over about this, including how to fix it, but here's a good link I found with pictures: https://blog.thirdechelon.org/2019/10/logitech-g900-g903-double-click-fix-replace-the-switches/

So below is my go at it, in gallery form, for others to look at.

My biggest struggles with this were peeling off the sticker and feet without damaging the plastic chassis or damaging the sticker and removing the battery without breaking it.  As for the sticker, I did okay.  The feet I didn't really care about because I planned to replace them.  They are easy to come by.  And, surprisingly, the new feet are slicker than the stock kind.  The battery was a major pain.  It's very strongly glued and there isn't a good way to slide something in to separate it.  I basically had to pry it with a plastic pry tool (dear god, don't use anything metal) and hope it didn't break.  It didn't.

By default, Exchange Online (like on-premises Exchange before it) allows all users in an organization to view only the free/busy status (blue bars) on other users' calendar appointments.  Some organizations require that the appointment summary or all calendar details be visible by all users.  This is fairly simple for a single user to change on their own, but enforcing it across the organization takes a bit more effort.  PowerShell comes in handy here!  And there are plenty of articles out there on how to do that.  But if you want to continuously enforce this configuration for all new mailboxes, or fix permissions when users change it, we need to schedule a recurring task.  Azure Automation works well for this purpose in the Office 365 / Azure Cloud universe.

Start by creating a "service account" that is an Exchange Organization administrator.  This can just be a standard Azure Active Directory account.  It doesn't need to have an Office 365 license assigned to it.  If you enforce MFA, make sure to generate an application password to use later on.

Go to the Exchange Administrator from the Office 365 admin panel.  Then select Permissions and then Admin Roles.

Edit the Organization Management role and add the user you created in Azure AD.

In the Azure admin portal, create an Azure Automation Account (or user an existing one).

Go to the Credentials section of the automation and add the username and password of the Azure AD credentials you created.  Note: if you have MFA enabled, the password must be the application password.

Go to the Runbooks section.  Create a new runbook.  Edit the runbook.

Exchange Online PowerShell cmdlets are available as a remote session.  You use the stored credentials to establish the session, then import it into the running session.  The number of cmdlets are large.  You should filter which cmdlets you want to import.  This saves a lot of time and prevents the odd crashes (the automation runspaces have a pretty limited amount of resources to work with).

$cred = Get-AutomationPSCredential -Name 'ExchangeOnlineAutomation'
$session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $cred -Authentication Basic -AllowRedirection -ThrottleLimit 1 
$commands = @("Get-MailboxFolderPermission","Set-MailboxFolderPermission","Get-Mailbox") 
$null = Import-PSSession -Session $session -DisableNameChecking:$true -CommandName $commands -AllowClobber:$true

Note: Azure Automation doesn't support piping to Out-Null, so the $null= is a trick to eat the output of a command you don't want to show up in the final script output.

From here, the rest is pretty simple, we just loop through every mailbox, look at the calendar's default ACE, and adjust it if necessary.  

$mailboxes = Get-Mailbox -ResultSize Unlimited
$mailboxes | % {
    $mb = $_
    $calendarDefaultACE = Get-MailboxFolderPermission "$($mb.PrimarySmtpAddress):\Calendar" -User Default
    if ($calendarDefaultACE -and $calendarDefaultACE.AccessRights -inotcontains "reviewer") {
        Set-MailboxFolderPermission "$($mb.PrimarySmtpAddress):\Calendar" -User Default -AccessRights Reviewer
    }
}

The above is assigning the ability of all users to see full calendar appointment details.  If you just want to assign the ability to see the appointment summary, use LimitedDetails instead of Reviewer.

We don't want to leave any sessions dangling as you only get three to work with for Exchange Online PowerShell.  So we should wrap all the above code in try..catch..finally and close the session at the end.  Add some logging and we have the following.

$cred = Get-AutomationPSCredential -Name 'ExchangeOnlineAutomation'
try {
    # Import an Exchange Online session
    Write-Output "Connecting to Exchange Online."
    $session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $cred -Authentication Basic -AllowRedirection -ThrottleLimit 1
    $commands = @("Get-MailboxFolderPermission","Set-MailboxFolderPermission","Get-Mailbox")
    $null = Import-PSSession -Session $session -DisableNameChecking:$true -CommandName $commands -AllowClobber:$true

    $mailboxes = Get-Mailbox -ResultSize Unlimited
    Write-Output "Found $(@($mailboxes.count)) mailboxes."

    Write-Output "`r`nAssigning default permissions for calendar to REVIEWER."
    $mailboxes | % {
        $mb = $_
        try {
            $calendarDefaultACE = Get-MailboxFolderPermission "$($mb.PrimarySmtpAddress):\Calendar" -User Default
            if ($calendarDefaultACE -and $calendarDefaultACE.AccessRights -inotcontains "reviewer") {
                Set-MailboxFolderPermission "$($mb.PrimarySmtpAddress):\Calendar" -User Default -AccessRights Reviewer
                Write-Output "$($mb.PrimarySmtpAddress): Setting permissions."
            }
        } catch {
            Write-Output "$($mb.PrimarySmtpAddress): ERROR - $($_.Message)"
        }
    }
} finally {
    # Close all open Exchange sessions
    Get-PSSession | Remove-PSSession
    Write-Output "`r`nExchange Online session closed."
}

You can test your runbook now.  If it works as expected, publish it.

Now exit out of the editor and set a schedule.  Every run costs a few cents, but really you probably only need to run this once per day so the cost should be extremely small.

I was setting up Azure File Sync tonight and ran into a weird issue that I found absolutely nothing online about.  Whenever I tried to add this one server as a server endpoint, I kept getting an error stating the provisioning was canceled and in the progress area it said "Provisioning failed" with the Enabling Sync step saying "Server job with command name NewServerEndpointWithDatePolicy and id <some guid> failed with -2134347507."

Not very descriptive!  And searching yielded no results, so it's apparently not a common error.

Well thankfully the Azure File Sync agent has very good logging.  In the Event Viewer, you look under Applications and Services Logs, Microsoft, FileSync, Management, Operational for these types of errors.

The very last entry was the error, event ID 5103.

This is basically the same text that showed up in the portal, but with one vital extra clue: Sync is not supported on a volume using compression.

Oh, well that explains it!  Except... The only problem is that this volume isn't compressed.  I double checked this.

Yup, not compressed.  But maybe some deep subfolder is compressed.  So I reset compression by recursively disabling compression on the entire volume again.  So now I knew none of the files were compressed. 

Trying again led to the same error.  This is where I hit a brick wall and decided to take a break.

I found later that the entire volume had been compressed at some point in the past.  But this was years ago, and as shown above, compression is now disabled.

So it appears that disabling compression isn't enough for the validation step of Azure File Sync.  Something from the past is still lurking around in the system.  What could the agent possibly be looking at that made it think the volume was still compressed?

At this point, I put on my programmer's hat and tried to think how they developed the detection logic.  Since nobody else I could find is having this issue, it must be something pretty unique or rare happening here.  I checked WMI properties on the volume (there's a flag for compressed volume), but that also showed that the volume was not compressed.  I dug a bit in the registry, but I couldn't find anything interesting.  I looked up the Win32 API call to obtain volume properties and executed that, but it also the volume was uncompressed.  So what is the agent looking at?

Then it dawned on me.  NTFS metadata is stored in the system hidden "System Volume Information" folder that is at the root of every drive.  Maybe there is a clue there.  I went into the folder properties of File Explorer and disabled "Hide protected operating system files (recommended)."

Then I went back to the root and it all became very clear.

Compressed folders show up in blue because I have "Show encrypted or compressed NTFS files in color" enabled (this is disabled in Server 2016+ by default).  But if you look at the properties of the folder, you can also clearly see that the System Volume Information folder itself is compressed.

So all I needed to do was uncheck that, apply recursively, and be on my way, right?  Nope.  System Volume Information is highly protected by the operating system due to the critical nature of the data stored in there.  So to remove compression, we have to go through a lot of hoops first.

The easiest way to do this is to run a few commands from an elevated command prompt.  The GUI just gets in the way.

First I took ownership of System Volume Information.  (If you are going to repeat these steps, obviously change the commands to your admin username and file path where applicable.)

TAKEOWN /F "D:\System Volume Information" /R

A bunch of errors flashed by, but this is okay.  This will get us far enough.  Now I ran the following two commands.

ICACLS "D:\System Volume Information" /GRANT Administrator:F

ICACLS "D:\System Volume Information" /GRANT Administrator:F /T /C

More errors flashed by, also okay.

Now back in the GUI, I went to the properties and unchecked the compression option.  I chose apply recursively and watched it go.  It ran into a lot of errors (of course) and I just had to keep clicking through them until it finished.  Curiously, when I was done, all the subfolders were no longer comrpessed, but the System Volume Information root folder still showed up as compressed.  I repeated the steps but chose "this folder only" this time and that took care of that.  Weird, but okay.

At this point, I rebooted the server.  On startup, Windows will reset the permissions to System Volume Information, so we don't have to worry about undoing the permissions we added above.

Back in Azure, before I could try to add the server endpoint again, I had to delete the previous attempt.  It's not intuitive (no surprise for Azure) but in this case, you right click and select delete.

Now I attempted to add the server endpoint back and waited a few minutes for provisioning to start.

Success!

From this we can deduce that the developers looked at the compression attribute on System Volume Information for the detection logic instead of the drive root or via the volume properties API call.  That's different from the other ways I saw how to do it when I googled, but maybe it's the correct way for whatever reason compression has to be disabled for Azure File Sync?  I really don't know.  It may also be a bug.

In any case, the error message needs to be written a lot more clearly, this issue was not obvious at all!

It's pretty neat how much Cloudflare gives you for free.  I just added some firewall rules for the Avian Waves website.  Now when you attempt to register an account, it will do a really quick scan to make sure you are not a malicious bot or spammer.  In addition, I am using Cloudflare's threat score system to do the same check for IP addresses that are in blocks of known spammers or other malicious actors.  If it isn't sure, it might ask you to solve a CAPTCHA.  Sorry, I know it's annoying, but hopefully it cuts down on forum and blog spam as well as fake user accounts.  And it should only bug you with a CAPTCHA one time.

If you are having trouble with anything due to this, please contact me at the link above.  Include your IP address.

Several minor bugs were discovered after the general release of RD Tabs 3.0.11.  The update is available now right here.  More information is available in the forums.

Several minor bugs were discovered after the general release of RD Tabs 3.0.10.  The update is available now right here.  More information is available in the forums.

Through various error reports and some direct contact, I was made aware that, at least for a time, Kaspersky antivirus products were incorrectly flagging a component of RD Tabs as malware through their heuristics engine.  Heuristics engines are notorious for flagging false positives since it bases what it judges as malware simply on the profile of the application and not that it has ever been verified to be malicious.

The file in question is "Launch Remote Desktop Services Manager.exe" which is a very small (about 30 lines of code) app whose only purpose is to search for the Remote Desktop Services Manager MMC and launch it if available.  RD Tabs will crash without it because there is some detection logic exported so RD Tabs knows whether to add the Remote Desktop Services Manager to the Tools menu.

It appears Kaspersky may have fixed this detection flaw already (I'm not sure, I don't use Kaspersky) as I am no longer seeing error reports coming in and the online scanner showed the file is safe.

If Kaspersky deleted or quarantined that file, you will need to restore it to use RD Tabs, or reinstall RD Tabs.  Your settings will not be lost if you have to reinstall, so I suggest doing that just to make sure all the components are unaltered.

For RD Tabs 3.1, I'm going to eliminate the hard dependency on the component to the main RD Tabs application so RD Tabs will not crash if this file ever gets quarantined again.

I was doing some housecleaning on one of my Microsoft Hyper-V clusters and noticed that five VMs had checkpoints from various times in the past.  Typically you want to keep checkpoints (formerly known as "snapshots") around for only a short while since merging can cause performance degradation and sometimes it just flat-out doesn't work.  I was pretty sad to see these were years old.  Sigh.

Well, these VMs were on a high performance SAN and they were all non-critical, so I shut them down.  I then took a SAN snapshot of the volumes so I could revert in case they failed.  Enough layers of snapshots yet?  Anyway.  I deleted the checkpoints on the first VM.  Nothing seemed to be moving.  I checked Resource Monitor to see if there was any disk activity on those volumes.  Nothing.  I gave it an hour and it was just stuck at 0%, showing "Merge in Progress" but it was pretty clear no merge was in progress.  This was what I was afraid of.

So next, I nuked the volume, reverted to the SAN snapshot and tried using the PowerShell Merge-VHD command.  It also got stuck at 0%.  I gave it 15 minutes, saw no activity, and nuked that one too.  So, thinking maybe it was the host, I duplicated the SAN snapshot to another host and tried again with Merge-VHD.  Nothing.  Clearly it's the VHDX/AVHDX files that are the problem.

What can we do?

Well, it's actually possible to merge another way.  If you export a checkpoint, it will flatten (merge) the VHD files down to the exported location.  Could this possibly work where other methods failed?  Shockingly, it did.  Not only did it merge, it merged really fast.  It went basically as fast as my SAN would go, which was a nice change.

So how do you do this?  First you need a pristine copy of the Hyper-V VM.  That means all the undisturbed VHDX files, VM configuration files, and everything else.  You can take advantage of snapshots from your storage system like I did or restore from backup.

Once you get the files, you need to import the VM (if you restored from backup, this may not be necessary).  Go through the wizard, when it asks which VM you want to import, you will see several dates.  Choose the oldest one.  It's kind of not intuitive, because it seems like you should specify the date of the most recent checkpoint, but what's happening is it's actually asking you for which disk in the chain is the first one.  Complete the wizard.

Now for another non-intuitive step.  We need to take a fresh checkpoint here, even though the other checkpoints are giving us fits.  The reason is because we are going to be exporting this checkpoint and we want the state of the VM to be completely up-to-date.  So, that means we need to create a new checkpoint.

After it finishes creating, right click on the new checkpoint and select Export.  Go through the wizard and select a location with plenty of free disk space to store the merged VHDX.

After a little time, you will have a fully exported VM with one flat VHDX file (or more if you have more disks).  From here you can either import it from the temporary location, or simply replace all the VHDX and AVHDX files with the merged one and edit the Hyper-V configuration to point to the new VHDX file.

From here, checkpoints should be working again.  You should be able to create and delete them without issue.  Until the next bug.

Several minor bugs were discovered after the general release of RD Tabs 3.0.9.  The update is available now right here.  More information is available in the forums.