Remote Desktop Services in Azure or Azure RemoteApp?

As IT Professionals, we often have a lot of projects on our plates, as do the people we support in our businesses. These days, remote access to work resources isn’t a bonus, it’s a requirement. How do you make sure employees have access to the work resources they need while keeping them secure?

One common solution that’s been used for a while now is Remote Desktop Services. Formerly known as Terminal Services, RDS provides a rich desktop or application experience and has evolved a lot since its debut in NT 4.0. One of the most useful features of RDS in recent years has been RemoteApp. RemoteApp enables you to make programs that are accessed remotely through Remote Desktop Services appear as if they are running on the end user’s local computer. Instead of being presented to the user in the desktop of the Remote Desktop Session Host (RD Session Host) server, the RemoteApp program is integrated with the client’s desktop.

When it comes to implementing Remote Desktop Services within Azure, you have two choices:

Implement a full infrastructure like you would do on-prem, with a Session Host, Web Access and Broker server roles. This gives you full control from the OS up and is a potential option if you are looking to lift-and-shift your existing RDS infrastructure into the cloud.
Customize an image to use with Azure RemoteApp.

For that first option, simply lifting and shifting the RDS servers to Azure can give you some quick benefits. In many cases your RDS users are coming from outside your corporate network, thus moving those servers to Azure would relieve your on-prem network connect of that traffic load. Plus Azure gives you the ability to scale up or scale out with ease – allowing you to adjust to any change in workload without incurring additional CAPEX costs for hardware.

For a great step-by-step guidance on building you own RDS infrastructure in Azure, I encourage you to read Keith Mayer’s comprehensive posts Part I and Part 2 of RDS on Azure.

Now for that second option, customize an image to use with Azure RemoteApp, I suggest considering using a customized image because chances are you use more applications than just the Microsoft Office Suite. (If you happen to use just Office 365, there is an image for that already!) You also have two choices to make within Azure RemoteApp – cloud only or hybrid. With a cloud collection the data and applications are held in Azure, with no connection to your on-prem network. With a hybrid collection the data and applications are still hosted in Azure, but also lets users access data and resources stored on your local network.

With either customized option, you are responsible for the management and maintenance of that image, however that is still less maintenance than managing and maintaining all the servers required for a traditional RDS infrastructure. Plus, Azure Remote app handles all the scaling needs based on the number of subscribers you authorize.

Combine that with the fact that Azure RemoteApp is supported on Windows, Windows RT, as well as on the Remote Desktop apps for Mac, iOS, and Android, and you’ve got a robust way to let users access resources from any device.

To get started with RemoteApp on Azure, you will need an image which isn’t trivial. If you want to do the hybrid collection you will also need to consider how to sync your on-prem directory to Azure AD, this roadmap can help. There is also an easy to implement trial that just includes 30 days of Office 2013 Professional Plus, but that trial can’t be converted to a production RemoteApp installation after the trial ends.

So what is right for your organization? Only you can say. But I have my short list of things I’d move to Azure and RDS would be right up there with SharePoint deployments. Hybrid collections provide the most complete experience since user will be able to access on-premises resources like they can with RDS you provide on-prem now. But cloud collections provide an easy way to isolate your deployment, which could meet at audit requirement or limit access for a specific set of workers.

If you already have a VNET in place with Azure, lifting and shifting RDS might be what you are most comfortable with. At this writing, RemoteApp can’t use an existing VNET, but you can connect the RemoteApp VNET to an existing one if need be. For more information about Azure RemoteApp, I highly recommend starting with the online documentation.

The Imperfect Lab: Letting Additional Administrators Remotely Connect to Servers

An age-old server administration best practice is to make sure that everyone who is administering servers on your network are doing it with their own “admin” credentials.

Up until this point, I’ve done all my remote Azure sessions (PS-Session) with the built-in administrator account. This works fine if you are only person connecting remotely to a server. But what if you want to grant others administrative rights to your machine and they would also like to connect remotely?

Your first step would likely be to add them to the local administrators group. Since you’ve already turned on the “remote management” feature for yourself, you might expect this to work out of the box.

But you probably overlooked this little note in the “Configure Remote Management” box when you enabled remote management – “Local Administrator accounts other than the built-in admin may not have rights to manage this computer remotely, even if remote management is enabled.”

That would be your hint that some other force might be at work here. Turns out that UAC is configured to filter out everyone except the built-in administrator for remote tasks.

A review of this TechNet information gives a little more detail:

“Local administrator accounts other than the built-in Administrator account may not have rights to manage a server remotely, even if remote management is enabled. The Remote User Account Control (UAC) LocalAccountTokenFilterPolicy registry setting must be configured to allow local accounts of the Administrators group other than the built-in administrator account to remotely manage the server.”

To open up UAC to include everyone in your local Admins group for remote access, you’ll need to make some registry changes.

Follow these steps to manually edit the registry:

Click Start, type regedit in the Start Search box, and then click regedit.exe in the Programs list.
Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
On the Edit menu, point to New, and then click DWORD Value.
Type LocalAccountTokenFilterPolicy for the name of the DWORD, and then press ENTER.
Right-click LocalAccountTokenFilterPolicy, and then click Modify.
In the Value data box, type 1, and then click OK.
Exit Registry Editor.

Now you will be able to remotely connect and administer your server using PowerShell with any account you’ve give Admin rights too for that particular server. This would hold true for servers in Azure, as well as servers on your local network.

Special shout out to Bret Stateham for bringing this “remote admin road-bump” to my attention. Sometimes what looks like an “Azure” problem, is really a “Server” feature. 🙂

Terminal Services RemoteApp – Bumps in the Road

This month I’ve been trying to nudge the project of moving to Windows Server 2008 Terminal Services RemoteApp forward at the office. The goal is to get away from using a version of Citrix Presentation Server to access applications over the Internet. The needs of our office have changed and the new features with Terminal Services in Server 2008 make this something we want to adopt instead.

However, nothing is without an occasional bump in the road. Here a couple of ours:

Bump #1 – No way to filter which applications users see on the RemoteApp webpage.

I know this feature was added in Server 2008 R2. Unfortunately, we have to stick with the Server 2008 “classic” due to an important 32-bit application that does not install or run properly under WoW. We debated the importance of filtering the application list and decided it wasn’t a deal breaker. Or we can look at some third-party workarounds.

Bump #2 – Users with passwords set to “enforce change at next logon” can’t get past the TS Gateway.

We have to remember to handle first time password changes for users who only be using RemoteApp by NOT checking the enforcement box and instructing them on how to change there password after they launch an application. (CNTL + ALT + END does the trick from any launched application.)

Bump #3 – No support for Macs with the Mac version of the RDC client.

Ouch. We only have a few employees that use a Mac at home and we’ll have to continue offering GoToMyPC to meet their needs. Not what I’d like to do, but hopefully support for the Mac will come along soon.

Bump #4 – Limitations with multi-monitor support.

Microsoft KB925876 gives some of the details of what type of multi-monitor support is available with Server 2008 Terminal Services and should automatically support spanning if your monitors meeting the configuration requirements. Those rules are: the total resolution on all monitors must be under 4096 x 2048 pixels; the monitors must have the same resolution; the monitors must be aligned side-by-side; and the far left screen has to be the primary one.

This is pretty limiting, especially if you have a laptop connected to an external monitor and want to take advantage of both screens. Or have monitors set up in configuration where one is turned vertically. Or any other number of possible configurations. Windows 2008 R2 improves on this as well, but as noted in #1, we just can’t quite use that yet.

So yes, we’ve got a few bumps, but nothing that would keep us moving forward with the project at this point. Our remote access isn’t supposed to be used by someone as a long-term way to work, nor is used with a frequency that demands extra capital expenditures to overcome a few relatively minor issues.

ImageRight and a Remote Desktop display bug

This week starts our official “pilot” roll out of Server 2008 RemoteApp. This is our planned replacement of Citrix for remote access to several of our regularly used applications. We are only using the Server 2008 (not R2) on the application server because our imaging application, ImageRight (version 4.3), does not support 64-bit. If you are planning on doing something similar, there is a minor display bug when access ImageRight v4 through the Remote Web Applications interface and it’s likely related to how the drop down menus are rendered using ActiveX. The problem is not repeated when one logs onto the server directly.

In the “File Open” menu, there are drop-down menus for choosing the drawer

and file type of the file you are looking for. In this example, the drawer selection defaults to “All Locations,” but depending on your personal settings, it may default to a particular drawer that is used most often.

When a user attempts to drop-down the drawer menu to select another option, the menu appears to snap closed quickly and does not allow a selection, making it impossible to switch drawers. (The File Type selection menu works fine.)

This display bug is not scheduled to be fixed in ImageRight version 4 of the software and it’s not a problem in version 5.0 according to ImageRight support. Meanwhile, the work-around is simple. Right next to the “File Open” tab, is a “Search” tab. The Search tab allows for more specific options to selected – down to page types and document descriptions. However, it all does the same basic features as the “File Open” tab.

In my office this isn’t a commonly used tab, we have another search tool that searches across other records databases at the same time, so I have to make sure to point out the issue to new users and provide the work-around information up front. While I’d like our remote access to ImageRight to be a seamless as working in the office, this display issue isn’t a showstopper.

What’s in a Pop-Up?

Last week, I posted about how some of our strict group policy settings on our Terminal Services RemoteApp deployment were causing some difficulty using some web-based applications, like our time card application. As I continued to use the application through RemoteApp, I found another hiccup in the GPO settings – the lack of the application to be able to pop up additional windows for some special tasks.

I started with looking at all the GPO settings related to the Pop-up Blocker. There are several – Pop-up allow list, Turn off Managing Pop-up Allow list, Turn off pop-up management. After tweaking and disabling those, I still couldn’t get the new task window to appear.

In order to leave no stone unturned, I proceeded to look closely at every IE setting that was configured and came across “Disable Open in New Window menu option”, under User Config – Policies – Admin Templates – Windows Components – Internet Explorer – Browser Menus. The provided explanation leads one to believe that it only hides the option from the shortcut menu to prevent users from manually launching a new window from that browser session. However, it also prevents an application from launching the window as well.

Since the Pop-Up Blocker itself wasn’t the problem, I was curious about what the Pop-up Blocker actually blocks. MSDN has some in-depth explanations about how the Pop-up Blocker works, but it comes down to this: Pop-up blocking prevents new browser windows being opened automatically using a script. Pop-up Blocker doesn’t affect browser activities when they are initiated by a user action (such as clicking a button or hyperlink), when opened in the Trusted sites and Local intranet zones, or when opened by other applications running on the local computer.

It does block script methods that call the following:

window.open
window.showHelp
window.showModalDialog
window.showModelessDialog
window.external
window.NavigateAndFind

An interesting note was that pop-ups created with “window.createPopup” are unaffected by the Pop-up Blocker. That doesn’t make sense to me, but I’m not a developer and I’m sure there is something I’m missing.

In my case, changing the Pop-up settings were moot, because the specific policy blocking the “window.open” command trumped any attempt to open a new windows, specifically those initiated by users.

Enabling Terminal Services ActiveX on IE7

As great as Windows 7 is turning out to be, many companies with Server 2008 Terminal Services Web Access (or plans to move to Remote Desktop Services in the near future) will likely have users connecting from home with Windows XP and Internet Explorer 7 for foreseeable future. However the Terminal Services ActiveX control required by TSWA is disabled by default in XPSP3 as a security measure. This control in needs to be explicitly enabled in IE7 in order to use the web access features of Server 2008.

Usually you can enable or disable an ActiveX control in IE using the “Manage Add-Ons” tool, but it’s likely that you willl be unable to see the TS specific control in IE7 on XP SP3 in that tool. The workaround is to delete the two following keys from the registry:

HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{7390f3d8-0439-4c05-91e3-cf5cb290c3d0}
HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{4eb89ff4-7f78-4a0f-8b8d-2bf02e94e4b2}

Once you delete these keys, the required ActiveX control should be enabled in IE7.

64-bit ImageRight support? – The "drivers" are in control.

The disaster recovery testing is touching more areas then I even though possible related to what options we can consider in our production and emergency environments. It’s bringing to light how interconnected software has become, and how those connections can sneak up on you, even when one is dealing with them everyday.

A basic premise of our recovery plan is to provide access to our recovered systems remotely, until we can make office space and desktop systems accessible to everyone. In order to keep things “simple” and provide the quickest possible up time, the plan calls for using Windows Terminal Services (aka “Remote Desktop Services” in 2008 R2) technology.

Due to the improvements in the offerings available directly by Microsoft related to remote access and the relatively small number of applications we need to make available, we determined that bringing terminal services up initially would be faster than recreating our Citrix environment during an emergency.

In conjunction with this (and the fact that we have only a small amount of remote use in production) we are currently planning to reduce licensing costs by only providing access using Microsoft products. Windows Server 2008 (and now R2) has many of the features we were looking to Citrix for in the past. While it’s possible for us to meet most of our needs with Server 2008, we’d much prefer to use 2008 R2.

While I was at the Vertafore Conference, one of my goals was to find out their schedule for 64-bit support. As one of our main enterprise applications, its important that it’s available on our remote access solution. Since I was unable to run the software on my 64-bit Windows 7 computer, I wanted know how far they were from addressing that.

Turns out, it all comes down to third-party drivers for peripherals. ImageRight works with several popular hardware vendors when it comes to scanners, including Kodak, Canon and Fujitsu. This allows customers to take advantage of more of the built-in scanner features that come with the hardware, instead of writing a generic scanner driver that could reduce the functionality native to the device. They also use the drivers to provide desktop features that allow end users to import documents directly from their PC.

Because of this, 64-bit support for the ImageRight software is directly related to how quickly scanner vendors make 64-bit drivers available. ImageRight claims that the makers of these key peripheral devices are complaining that Microsoft didn’t give them enough warning between Windows Server 2008 and the release of Server 2008 R2 regarding the official “death” of the 32-bit version of the OS to provide 64-bit drivers for all their devices.

ImageRight is planning to have support for 64-bit operating systems by the end of this year. We aren’t planning on a widespread upgrading of desktop hardware to 64-bit any time soon and will be able to wait without too much suffering. However, it does alter our plans for our remote access changes in the next 3-6 months. A disappointment for sure.

Also, the delay doesn’t help existing ImageRight clients or upcoming new ones that hope to run (or at least begin to test) an important software product on the most current hardware and operating systems available. An interesting domino effect that ends in needing to reconsider what I’ll be using for remote access during my recovery testing this month.