Azure RemoteApp – Sayonara!

Microsoft Announces Today That They’re Phasing Out Azure RemoteApp, and Transitioning Customers Over to a Citrix Solution Instead

Gabe Knuth first blogged on this possibility August 3rd, and now it has been confirmed.

From the Microsoft Enterprise Mobility Blog:

Today we are announcing the next step in our broad partnership with Citrix in the remote desktop and applications space, which we recently expanded to address new scenarios for our joint customers on the Azure cloud.

Customers have provided us consistent feedback that they want a comprehensive, end-to-end, cloud-based solution for delivering Windows apps. The best way for us to deliver this is with Citrix through XenApp “express”, currently under development. XenApp “express” combines the simplicity of application remoting and the scalability of Azure with the security, management, and performance benefits of XenApp, to deliver Windows applications to any employee on any device. We will have much more to share on this offering through the coming months.

Key takeaways:

  • New purchases of Azure RemoteApp will end October 1st, 2016.
  • End of life date for existing Azure RemoteApp deployments will be August 31st, 2017. Migration of some sort will be required before then.

My thoughts – this is a smart move. As Gabe mentioned, Azure RemoteApp had issues with rapid scaling during logon storms and other load balancing issues. Also, there’s the practical aspect that most organizations, if they move their apps to the Cloud, also need to move the supporting infrastructure (e.g. database servers, CRM/ERP servers, Active Directory, etc). In that sense, it makes better sense to either leverage this new Citrix solution OR simply stand up a full Remote Desktop Services IaaS deployment in Azure. This will only be easier to do with the upcoming release of Microsoft Windows Server 2016.

Why I Created the Resource Site

Let’s Face It, Small Shops Running SBC Solutions Are Not Well Supported

In the Server-Based Computing (SBC) community (e.g. Citrix, Microsoft RDS, VMware Horizon, etc), it’s fairly well-known that the vast majority of SBC implementations consist of 500 users or less. In contrast, the majority of marketing resources from vendors in the space go after chasing companies with 500 users or more. There’s a perception in our industry, rightly or wrongly, that the little shops are simply too expensive when it comes to acquiring their business and supporting them.

My area of expertise in the SBC community is Microsoft Remote Desktop Services, as I design monitoring software for that platform, and am currently a Microsoft MVP in this space. For many smaller shops who need to run SBC environments for teleworking, Microsoft RDS has been the platform of choice, as it only requires a single client access license (the RDS CAL), as opposed to Citrix, which requires not only the Microsoft RDS CAL, but the Citrix Concurrent License that runs on top.

Microsoft Has Recently Made Remote Desktop Services on Windows Server 2012 Harder To Deploy and Manage

Recently, I think that the partitioning of the SBC market that I talked about above (in terms of vendors only wanting to acquire and support medium to larger sized customers) has started to affect product architectural decision making as well. Citrix has continued to move up market, so much so that implementing their products almost always requires outside consulting expertise. In contrast, for the longest time, Microsoft RDS was relatively easier to deploy for even the smallest of shops – you’d turn some of your Windows Servers into Remote Desktop Session Hosts, and if you were a larger farm, you’d consider adding a Connection Broker Server, Remote Desktop Web Server, and Remote Desktop Gateway Server into that mix. Management was done through a handful of tools (TSAdmin, TSConfig, etc) that were fairly straightforward to use.

Enter Microsoft Windows Server 2012. Remote Desktop Services got a radical overhaul in Server 2012, and that overhaul has caused a considerable amount of pain for shops trying to migrate their RDS implementations from Server 2008 to Server 2012. One of the biggest painpoints in the Server 2012 ecosystem has been the restructuring of management tools for RDS. In order to manage user sessions and other configuration aspects, Microsoft moved these features out of those simple tools I mentioned earlier (TSAdmin, TSConfig, etc) into the Remote Desktop Services Manager overlay in the Windows Server Manager utility. Moreover, to even get the RDSM to work at all, the RDS implementation now must have a connection broker installed. And don’t even think about trying to stand up a full Windows Server 2012 RDS implementation in a workgroup – a domain environment is required.

If your implementation of RDS does not have enough roles to activate the RDSM in Server Manager, to date you’ve been forced to manage your session host servers predominantly with PowerShell scripts and command line tools. – a Resource Site For the Neglected Small Shops Running Microsoft Remote Desktop Services

All the above said, there are tons of organizations, with 500 users or less, who need quality resources for both their conventional (e.g. all RDS roles deployed) and unconventional (e.g. some RDS roles deployed, workgroup environments) RDS deployments. Thus, I decided to create Over time, it will become a rich repository of PowerShell management scripts, free tools, and other tips/tricks for smaller RDS deployments. The RDS community, while small compared to Citrix, continues to grow and deserves more resources. I hope will help further fill that niche. Please check it out now and take advantage of all it can offer you!

New MUST HAVE Remote Desktop Services Hotfixes for Windows Server 2012 R2

Greetings again, folks.

Since the time of our last RDS Hotfix/Update post, the Remote Desktop Services team at Microsoft has released additional new hotfixes for Windows Server 2012 R2 RDS deployments. All of these are considered “must have” updates to make sure that your RDS deployment on Windows Server 2012 is nice and healthy. Read on and you’ll see why.

Redirected Drives, Printers, and Ports Get Really Slow in RDS Session

When connecting with Remote Desktop Services (RDS), working on any redirected resources (drives, printers, and ports) becomes very slow.
Are users complaining about sluggish redirected drive or printer access? Apply this update.

Yikes! Blue Screen of Death “Stop Error” on Windows Server 2012 R2 Acting as Remote Desktop Session Host

On a computer that’s running Windows Server 2012 R2 and Remote Desktop Services (RDS), you may experience a Stop error with message that resembles the following:
Stop: 0x000000C2 (0000000000000007, parameter2, parameter3, parameter4)
Stop: 0x0000003B (c0000005, parameter2, parameter3, parameter4)

Obviously, if your RDSH servers are blue-screening, apply this update post haste.

Connection Broker Issues and Delays On Your Busy RDS Farm?

If there’s a significant high number of remote desktop connections that are made to a High-Availability RD Connection Broker in a short duration of time, you may encounter the following issues: 1.) The connections experience long delays, or users are never connected to the system. 2.) High CPU usage on SQL Server that’s used with High Availability-based Connection Broker.

This is a must apply update for the RDS Connection Broker on Windows Server 2012 if you’ve been running into scalability issues.

Windows Server 2012 R2 Running the Remote Desktop Gateway Role Crashes

The RD Gateway server crashes because of a conflicting operation where the user disconnects the connection at the same time when the server also ends the connection.

Apparently if a user tries to disconnect at the same time a server is trying to disconnect them on their own, the RD Gateway server goes Tango Uniform. Better apply this update.

That’s all for now.

— Your humble Microsoft RDS MVP

Do you need complete RDS/XenDesktop monitoring & reporting for only $9 per server per month? Review our sample reports and watch demonstration videos here.

Most RDS/Citrix Monitoring Tools Licensing Models are Bull$h!+

Ready for another epic Andy rant on the Citrix/RDS monitoring industry? Strap into your seats, folks! Today we’re going to take on how most RDS and Citrix monitoring tool vendors adopt licensing models designed to soak their customers and bleed them dry.

RDS Licensing

RDS Licensing Gotcha 1: When They Charge You For Data Retention, and/or Tier Their Licensing Based on Citrix/RDS Data Retention

This seriously chaps my hide. Back when I ran Dorian Software, our licensing model was simple. You paid us for each Windows system you monitored / archived Windows event log data from. We didn’t care if you had your auditing turned on full bore or at a trickle, nor how many gigabytes of log data you generated each day. We simply gathered up the incoming entries and stashed them into a database. Then, we put YOU in control of your own data retention / grooming policies. Provided you had the database server beefy enough to handle a year or more’s worth of log data, you could hold on to data that long or longer.

We use this same licensing model at RDPSoft for our Remote Desktop Commander Suite. We put you in charge of the Citrix and RDS data retention, as you can see below from one of our configuration dialogs. And just like in the Dorian days, our licensing model is based on the total number of RDS servers and workstations/virtual desktops you’re collecting data from, not the number of concurrent users connecting to sessions/remote apps, nor the retention days or the volume of data collected. There’s a word for this licensing model: Fair.

rds licensing retention
We put you in complete control of your RDS and Citrix data retention.

However, more and more Citrix and RDS monitoring vendors tie their licensing models to data retention. This includes the Citrix Director plus Edgesight monitoring platform. If you want, in effect, unlimited data retention, you get to pay through the nose. We’ve seen licensing schemes whereby pricing is tiered based on retention, such as one day, one month, or one year. Guess what – the one month and one year data retention options are considerably more costly.

To those vendors adopting those models, we at RDPSoft say: STOP HOLDING YOUR CUSTOMERS’ DATA HOSTAGE.

RDS Licensing Gotcha 2: When They Charge You For Concurrent Users, But Also Count The Built-In Services and Console Sessions Towards the Total

Seriously? You’re so greedy that you’re going to run up the concurrent user count by adding the built-in services and console sessions on every Windows system? Yes, there are vendors in the marketplace that do this. If you’re evaluating other Citrix / RDS monitoring tools, you MUST read their licensing fine print. In this market, more than many others, the licensing scams models are apples and oranges.

Unfair Licensing Schemes Are the Product Of Desperation, Not Innovation

I’ve been around the software industry long enough to tell you how these convoluted and unfair licensing models come into being. It’s no different in the RDS/Citrix tools market.

Picture a bunch of sales weasels professionals gathered around a conference table. They’re sweating bullets because they have major quotas to meet for the year. More than likely there are now ambitious revenue targets set by management in place. “Eureka,” one of them exclaims, “let’s change our licensing model / rules to create more billable units/devices/interfaces/users per customer. That’s the ticket!”

Rather than innovating and raising prices to match an expanded feature set, they simply change the rules of the game midstream. If the subsequent cost increases are mild enough for most customers, those customers don’t complain too much. The old anecdote about boiling a frog slowly comes to mind.

At RDPSoft, Our Licensing Model For RDS and Citrix Monitoring Is Fair, and Maximizes Value

We’re probably old fashioned, but at RDPSoft, we believe in the golden rule. When we buy software or services, we ourselves want to be treated fairly, and we want to support vendors that provide a lot of value for our money. We treat our customers no differently. To summarize, here’s how we do that:

  • Our licensing is based on the number of servers, workstations, or virtual desktops you want to monitor, not the number of named users or concurrent users.
  • We don’t charge you / upsell you based on how much monitoring and reporting data you want to store over time.
  • We don’t pad our margins by forcing you to pay for extra licenses to monitor the built-in console or services sessions.
  • We offer an extremely affordable, pay as you go monthly subscription option for only $9 per RDS/Citrix server monitored, and $1 per Workstation/VDI monitored.
  • We offer free support and a money-back guarantee during the first 30 days after purchase / subscription start. If our software does not perform in your environment for any reason, we will refund your purchase price. Your satisfaction is our number one concern.

Are you ready to save money by dumping your existing RDS/Citrix monitoring vendor? Would you like to start monitoring your RDS farm without breaking the bank on licensing costs? View all the features of our Remote Desktop Commander Suite here, and start your monthly subscription for only $9 per server per month.

Only the Shadow Knows

Alright folks … time for a post on the fun, twisted history of shadowing RDP users in Microsoft Remote Desktop Services. Not a month goes by that I don’t field a call from an administrator confused about the shadowing changes implemented in Windows Server 2012. Plus, I want to tell you all about what we’ve done in Version 3.6 of Remote Desktop Commander to make these RDP shadowing variations as seamless as possible among the different Microsoft OS versions.

First Rule of Shadow Club: You CANNOT Shadow RDP Users on Windows Server 2012, ONLY Windows Server 2012 R2

This keeps biting RDS admins in the butt. There is ZERO support for shadowing in Windows Server 2012. I’ve written at length about many of the radical changes between RDS on Windows Server 2008 and Windows Server 2012. Microsoft literally roto-rootered the whole RDS stack in Windows Server 2012, tearing out old plumbing and integrating new plumbing related to RemoteFX and RDP enhancements. It took them until the Windows Server 2012 R2 release to put Humpty Dumpty mostly back together again. So unless you REALLY like pain, don’t upgrade to Windows Server 2012 – bypass it and upgrade to Windows Server 2012 R2 or Windows 2016.

Review: Legacy Shadow Techniques for RDP Users on Windows Server 2003 and Windows Server 2008

Yes, I included Windows Server 2003 because I know some of you deviants still have some Windows 2003 systems running in your enterprise, long after extended support and updates have expired. That’s fine you slackers – blame legacy apps and management. :)

Back in the good ole days of simpler operating systems, to shadow you would either:

1.) Fire up a copy of TSAdmin (Remote Desktop Services Manager), highlight the user session in question, then right mouse click to shadow them, OR:
2.) Command line it with the shadow command, passing it the user’s session ID and the server their session was located on.

Legacy Shadow User RDP
Ahh, the good ole days of RDP user shadowing…

Both of these approaches required you to run the app or the command from within a Remote Desktop session; you could not issue these commands directly from the console session of a server or workstation.

New Shadow Techniques for RDP Users in Windows Server 2012 R2 (and Windows 8.1 and Windows 10)

Alright, let’s engage in some fantasy now shall we? Let’s say that all of your servers are Windows 2012 R2, and all of your workstations are Windows 8.1 or Windows 10. Ha ha! See how funny I can be? In this case, you can use the new command line arguments built into the Remote Desktop Connection Client (mstsc.exe) to get the party started.

NOTE 1: Unlike Windows Server 2008, Windows Server 2003, and Windows 7, you DO NOT already have to be running in a remote desktop session to start shadowing another user session. You can be logged into the console session of your own desktop, laptop, etc and jump right into shadowing a remote user’s session, IF:

1.) Your Windows system is running Windows 8.1, Windows 10, Windows Server 2012 or later.
2.) Their Windows system is running Windows 8.1, Windows 10, Windows Server 2012 or later.

If either one of the systems is at a lower OS level, this new approach won’t work.

NOTE 2: In Windows Server 2012 R2, by default you need to be a local administrator on the machine hosting the sessions you wish to shadow. This is a major shift from Windows Server 2008 and earlier operating systems. There is a way around this however with a gnarly command you can run inside Powershell.

Again, provided you live in this magical world of fairy tales, unicorns, and homogeneous operating systems, you simply launch mstsc.exe with the appropriate combination of command line switches, such as:

1.) Switch /v, which is the remote computer with the session you want to shadow (e.g. /v:MY2012SERVER)
2.) Switch /shadow, which accepts the session id of the user session that will be shadowed (e.g. /shadow:1)
3.) Switches /control and /noConsentPrompt, which determine whether you can control or only view the session, and whether or not the user is notified that you are shadowing their activity, respectively.

Putting it together: mstsc /v:TARGETSERVER /shadow:1 /noConsentPrompt lets you monitor (but not control) session 1 on TARGETSERVER without notifying the user.

The RDP Shadow Reality: You Run a Heterogeneous Network Full of Systems That Are At Different OS Levels.

I gave a talk on RDP 8 at TechMentor two weeks ago, and asked for a show of hands to find out who had deployed Windows Server 2012 in their environment. The vast majority of attendees were still running Windows Server 2008, and those who had started deploying Windows Server 2012 still had a lot of Server 2008 systems in place. So the reality is, you’ll be dealing with two different approaches to shadowing RDP users for a while.

Given this challenge, we’ve recently built a bit of magic into our latest version of Remote Desktop Commander when it comes to shadowing users. We automatically detect whether or not you want to shadow a user on the local system or a remote system, and we also look at the OS level of both the local machine and the remote machine. If both systems are running Windows 8.1, 2012 R2, Windows 10 or later, we shell out immediately to MSTSC with the new options. If there is an OS level mismatch, we’ll first establish a client RDP session on the remote system, and then auto launch a helper utility on the remote system that will invoke the appropriate shadowing technique to start shadowing the desired session.

Intelligent RDP User Shadowing
Remote Desktop Commander makes this much easier…

Shadow User RDP Settings

In addition, as you can see in the above screenshot, we give you even more options before starting the RDP user shadow attempt. For instance, you can temporarily override the GPO that controls whether or not users are notified that their session will be shadowed. You can also start your client session in Admin mode, so that the connection broker doesn’t block you from connecting to the desired server in the collection.

The best part? These shadowing features come in both versions of Remote Desktop Commander – the Lite edition, which handles basic session management and user shadowing, and the Remote Desktop Commander Suite, which handles all of the above plus does extensive monitoring, reporting, session recording, performance tracking, all for only $9 per server per month.