Thursday, April 30, 2015

Azure RemoteApp: First look at pinning Azure RemoteApp shortcuts to the Start Screen!

Feels like Déjà vu saying this, but again another big improvement in the continuous development cycle of Azure RemoteApp has been announced!

As RDS MVP we were notified earlier that this was on the roadmap, but we were able to see it live in action yesterday. The Microsoft RDS team has demonstrated an updated Azure RemoteApp client that allows pinning a RemoteApp to your local Start Screen! To me, this is a huge improvement in regards to the adoption Azure RemoteApp. This means that you no longer need to constantly switch to the Azure RemoteApp client to a launch a RemoteApp. In fact, after the initial sign in, you can even close the client and still launch a RemoteApp directly from the Start Screen.

I’ve been asking the RDS Product team for this feature since day1, and I was not the only one. The feature is the number one voted request on the Azure RemoteApp User Voice Page :)

The new client is currently still in development and not available for public preview yet. But I am able to share some screenshots. Below is a screenshot of the updated client. It looks very similar to the previous client, but notice where is says “Find all your apps in the Start Menu All apps list.”

image

This means that as soon as you have logged in on the Azure RemoteApp client, the RemoteApps that have been assigned to you are now also available in the All Apps section of the Start Screen as shown below. And from here you’re able to pin these items to your Start Screen as desired.

image

In the new update of the Client, the Connection Center (shown in the first screenshot) will be decoupled from Azure RemoteApp Client itself. This means that after you sign in on the Azure RemoteApp Client and have retrieved the Remote Apps, you could close the Connection Center and continue to use already running Remote Apps and even launch new  RemoteApps from the Start Screen or All Apps section without having to re-open the Connection Center.

Since the RemoteApps are published to the AllApps Section of the Start Screen, you also have the option of simply typing the name of the application and launch the RemoteApp directly from there, similar to any local installed application and also similar to running RemoteApp in a on premises or hosted scenario.

 image

The new client capabilities were demonstrated on Windows 8.1, but should also work on for example Windows 7 SP1, and basically any version of Windows that is currently supported for Azure RemoteApp.

UPDATE:
Watch the full video here: https://event.on24.com/eventRegistration/EventLobbyServlet?target=launchConsole.jsp&eventid=981683&sessionid=1&key=E6CC10F6C89FB61DDD42C27608871B7A

Friday, April 24, 2015

Online Course: Azure RemoteApp, from introduction to advanced now available!

I have authored a new course for opsgility.com about Azure RemoteApp. It’s called “Azure RemoteApp, from introduction to advanced” and it’s available today!

The course contains 7 modules exploring everything you need to know about Azure RemoteApp including various hands on labs.

Course overview
The Azure RemoteApp, from introduction to advanced course will help students to get acquainted with the Azure RemoteApp. The course will start with explaining Remote Desktop Services to lay a foundation for the rest of the course. After that we will dive into Azure RemoteApp by explaining the basic concept and perform an actual cloud based deployment. Next, we will cover the more advanced Hybrid Deployment including setting up connectivity to on-premises and creating custom templates. We will end the course with an discussing pricing, licensing and SLA and discuss some Tips, Tricks & Caveats.

image

”…Opsgility is an innovative training company founded by Michael Washam that focuses on teaching technology through hands-on practice. Our instructors are some of the brightest and most knowledgeable in the industry, and are made up of Microsoft Most Valuable Professionals (MVPs) and Microsoft Certified Trainers (MCTs) in over 10 countries. ..”

Deploy Azure RemoteApp collection to your Azure Virtual Network (with support for ExpressRoute) now publically available!

Another big milestone in the continuous development of Azure RemoteApp (ARA)! It is now supported to deploy a Azure RemoteApp collection to an (existing) Azure Virtual Network (VNET) including support for Express Route!

As RDS MVP’s we have been able to test drive this new feature in beta. With the ability to use (existing) Azure Virtual Networks the setup of a Azure RemoteApp Hybrid Collection makes so much more sense. No more need to create a separate Azure RemoteApp VNET, you can now just use leverage the generic Azure VNET which also allows you to start using Express route.

After you have created the Azure RemoteApp Hybrid Collection, you now have the option to Link a virtual network

image

And simply point a Azure VNET

image

And since this is now a generic Azure VNET you can also manage it the same way.

image

Check out the RDS Team blog for more details: Deploy Azure RemoteApp collection to your Azure Virtual Network (with support for ExpressRoute)

Monday, April 20, 2015

Azure RemoteApp issues on iOS 8.3

Microsoft has reported errors when using Azure RemoteApp in iOS version 8.3

TIME
4/17/2015 9:53:50 PM

TITLE
Important Information Regarding Azure RemoteApp on iOS8.3 [West US]

DESCRIPTION
“…Azure RemoteApp users who attempt to sign-in on an iOS 8.3 device will experience an error message. If users desire to use Azure RemoteApp, they should not upgrade to iOS 8.3, an update to the Remote Desktop client will soon be published to the AppStore…”

Monday, April 13, 2015

Manage users in Azure RemoteApp based on Active Directory groups, with PowerShell!

Prior to December 11/12/2014 Azure RemoteApp supported functionality to authorize users to an Azure RemoteApp Collection based on Azure Active Directory group membership.

image

However, this feature was deprecated starting from 11/12/2014. Also see: As of 11/12/2014 ‘Active Directory group’ support for Azure RemoteApp will be deprecated.

The statement that Microsoft made related to this change:

“…Continuous changes to user groups' membership, especially when that group owner is different from RDS admin, make billing and usage less predictable. Because of this, we are deprecating user group support in Azure RemoteApp…”

As a result, the only way to add users in bulk is using the .CSV bulk import option. You can find more info on that here: Introducing CSV based user import

To allow for easier management I wrote a PowerShell Script that synchronizes users to a Azure RemoteApp Collection based on Active Directory Group Membership.

The script will do the following, based on a specified Active Directory group & Azure RemoteApp Collection;

- Add users to an Azure RemoteApp collection who are a member of the AD group
- Remove users from an Azure RemoteApp collection who are not a member of the AD group anymore

This will result in only allowing access to, and being billed for, users that are added to an Active Directory group.

Below is a sample output in a scenario where 4 new users were added to the group and 4 other users were removed. When finished the scripts outputs the users currently allowed access to the Collection.

image

If needed you could create a Scheduled Task, or maybe even better in Azure Automation and have this run periodically and include the action to add users to the AD group in your current Identify Management solution.

The Azure Portal below reflects the changes instantly.

image

I uploaded the PowerShell script to TechNet Gallery, get the link here:

https://gallery.technet.microsoft.com/Manage-users-in-Azure-f793aea7

The PowerShell script obviously requires the modules of both Active Directory and Azure and a Azure Publish Settings file to be able to connect to Azure for Remote Management.

2 notes of caution:

- Any user that is not a member of group specific in the script will be removed from the Azure RemoteApp Collection, without a warning. So make sure the group contains all users that need access to the collection

- You will be billed by Azure based on the number of users that have been allowed access. So make sure that the group specific in the script only contains members that actually need access.

Tuesday, April 7, 2015

March update to Azure RemoteApp

imageThe Remote Desktop (Azure RemoteApp) team released a blog post containing an overview of the new features and capabilities for Azure RemoteApp! Talk about continuous development !

 

“…

  • Ability to create a custom image from an Azure VM, read full blog post.
  • PowerShell modules and SDK for Azure RemoteApp Management, read full blog post.
  • Australia region now available, read full blog post.
  • Office O365 platform image was updated with March Windows Server 2012 R2 software updates.
  • iOS client was updated to version 8.1.7 resolving third party keyboard issues and adding additional languages (8.1.8 was released today and changes some telemetry behavior).
  • Android BETA client was updated to version 8.1.7 resolving issues with Android 4.0 and a few bugs.
  • Windows Phone client was updated to version 8.1.9 resolving issues with some RD Gateways.
  • Mac client was updated to version 8.0.15 resolving issues with <ALT> key and international keyboards.
  • Fixed issue using non-US locales that would cause collection creation failures, read more.
  • Two Azure RemoteApp site updates to accommodate all the changes on March 5th and 25th.

Following documentation was released and updated:

Source: http://blogs.msdn.com/b/rds/archive/2015/04/07/march-update-to-azure-remoteapp.aspx

Wednesday, April 1, 2015

Office 365 activation issue on RDS running Office 365 Click2run (C2R) with Shared Activation (0x80004005)

Consider the following scenario

  • An RDS environment that hosts one or more RDSH servers with Office 2013 Click 2 Run installed.
  • Shared activation has been enabled
  • Federation is not in place so activation relies on a user activating manually once by entering his O365 credentials
  • Registry value NoDomainUser is configured to 1 (Advised by Microsoft in case of the scenario above) also see  https://support.microsoft.com/en-us/kb/2913639

A new user who doesn’t have a profile yet, logs on for the first time and launches an Office application for the first time and gets prompted with the Office 365 activation screen. This is expected behavior in environments where federation is not in place.

The user finishes the activation and is seems to have been successful when checking the account tab in Word at that time.

image

However, when the user closes Office (in the case Word) and opens another Office application, he’s now suddenly being prompted with the error “Sorry, we cannot verify the license currently installed for this productError code 0x80004005

This is because at this point no Credential has been created in the Credential store.

image

And the user has to perform activation again (even within the same RDS session).

Why is this? The fix by adding the NoDomainUser registry value does not completely fix the issue. This is because the first time an Office application is launched, it completely removes the Identity Registry Key (including the NoDomainUser registry value).

Process Monitor confirms this:

image

What Process Monitor also reveals is that prior to deleting the Identity key, the value or Version is queried, and it cannot be found, because no identity has been configured yet.

image

Apparently Office first checks if an identity version is in place and only if there isn’t, it removes the Identity key.

So how to make the fix complete? Besides adding the NoDomainUser based on the KB article, we also add a fake version registry value using a GPO Preference, and set that to apply Once.

image

This results in the following in the HKCU at first logon

image

This causes Office to think there is an identity in place and thus it does not remove the key, which allows the NoDomainUser key to do it’s work, which results in a successful activation at first logon!

I’ve Been in contact with the Office Team, and they have confirmed that an official fix is on track to go live in April update release!

When in doubt, use Process Monitor! Winking smile

RDP Client for Microsoft Band!

Great news! Yet another RDP client is available. After Windows, iOS, MacOS and Android, Microsoft now made a RDP client available for the Microsoft Band!

image

The client is a based RDP 8.1 and is supporting features like RD Gateway and multi touch.

It’s also fully compatible with Azure RemoteApp, allowing you to run your native Win32 applications at any time from your wrist hosted in the Azure Cloud!

You need to update your Microsoft band to version 10.2.2712.0 09 R to be able to pin the RDP tile on you Band.

* 02-04-15 Update *
This was obviously a April fools joke :)