September 8, 2016

Fix AutoKey pasting blank lines in Ubuntu

I have been using AutoKey on my Linux desktop to provide automated text insertion capabilities similar to what I get from AutoHotKey on my Windows systems. I prefer to keep things like my email and ticket signatures stored as hotkeys so that I can more granularly choose when to use them.

The version of AutoKey included in the Ubuntu repositories has an issue where blank lines are inserted rather than the expected text.

Googling yielded the solution from an AskUbuntu post.

To fix the blank line issue, create a file named org.autokey.service at /usr/share/dbus-1/services with the following content:

[D-BUS Service] 
Name=org.autokey.service 
Exec=/usr/bin/autokey

After creating the file with the content above, kill and restart the AutoKey process or just reboot your computer. AutoKey should now properly insert text instead of blank lines!

D-BUS handles all of the communication between different processes running on the Linux system. It appears the D-BUS service for AutoKey is not configured correctly upon installation.

August 31, 2016

Redirecting the root RDS Web Access URL to the login screen

The root RDS Web Access URL (e.g. https://rds.domain.com) does not redirect to the RDS login screen by default in a Windows Server 2012R2 RDS farm setup. Thankfully, there is a simple change in Microsoft IIS to enable this functionality.

In the IIS Manager on each RDS Web Access server in your farm, select “Default Web Site” from the left pane, and select “HTTP Redirect” from the “Default Web Site Home” pane.

RDS Web Access Redirect

Check “Redirect requests to this destination:” and enter https://rds.domain.com/RDWeb. Check “Only redirect requests to content is this directory (not subdirectories)” and set the “Status code” dropdown to Found (302).

RDS Web Access Redirect

The root URL https://rds.domain.com should now redirect to the RDS Web Access login page.

August 30, 2016

Highly-available Microsoft Remote Desktop Services Farm diagram

I stood up my first Microsoft Remote Desktop Services several months ago, with a great deal of help from TheWolfBlog’s great guide.

One thing I didn’t have when I started my work was a good illustration of how the final highly-available infrastructure would look. I’ve included an image of a sample setup below, and I hope it benefits someone.

In the image below, the firewalls represent load balancers.

Highly-Available RDS Farm

August 29, 2016

Dealing with compromised accounts in Exchange Online

We have lately had a rash of compromised email accounts in our Office 365 Exchange Online infrastructure. It appears a well-crafted phishing email caught at least a small percentage of our 100,000-plus mailboxes.

The outbound SPAM protection in Office 365 and Exchange Online is very robust. Suspected SPAM messages are sent through a high-risk pool of IP addresses, and accounts are limited to 10,000 outbound messages per day before being blocked by the anti-SPAM intelligence. A support ticket must be filed with Microsoft to reactivate an account once it is blocked from sending outbound mail.

Normally, the anti-SPAM alerts received when an account hits the outbound message limit are sufficient for administrative notification. The most recent set of spammers, however, have been intelligently working underneath this notification system by sending less than 10,000 messages daily. The spammers instead cover their tracks by setting up email forwarding or an inbox rule to hide any bouncebacks from the slew of outbound junk.

Email forwarders victimized the most recent compromised accounts. These accounts came into the help desk with the same symptom of not receiving email messages. A look at the mailbox through Exchange Online PowerShell reveals the cause:

PowerShell Prompt

The spammer set the mailbox to forward all mail to an external address under their control, thereby hiding the nefarious activities.

To remove the forwarder, run the following in PowerShell:

Set-Mailbox [email protected] -ForwardingSmtpAddress $Null

In some cases, spammers will instead setup an inbox rule to hide their activity. View all inbox rules for a mailbox through PowerShell by running the following:

Get-InboxRule -Mailbox [email protected]

For a clean mailbox, this should return nothing or return valid inbox rules created by the customer.

It never hurts to educate your customers on never giving out login information through an email!

May 5, 2016

Add permission to Public Folder recursively with PowerShell

We had a request to add permissions for a customer throughout a deeply nested structure in our Exchange Online Public Folders.

These commands will not override or change permissions where they are already set.

Connect to Exchange Online PowerShell

$Cred = Get-Credential
Connect-MSOLService -Credential $Cred
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $Cred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Add Permissions and Verify Success

In PowerShell, run:

Get-PublicFolder -Identity "\Folder Name" -Recurse | Add-PublicFolderClientPermission -User jsmith -AccessRights Owner

Verify the change was successful:

Get-PublicFolder -Identity "\Folder Name" -Recurse | Get-PublicFolderClientPermission | Where-Object { $PSItem.User -like "SMITH*" }

Use the customer’s name in the Where-Object cmdlet. All of our accounts are named in a “LASTNAME, FIRSTNAME” format, and the command reflects that. This command will print all of the customer’s rights through the tree.