App-V: On Targeting Azure RemoteApp Images with the App-V Management & Publishing Server

February 10, 2016 1 comment

There are two types of Collections with Azure RemoteApp: A Cloud Collection and a Hybrid Collection. App-V requires that the client must exist on domain-joined machines in order to be supported. Azure RemoteApp Custom Images can be part of a Hybrid RemoteApp collection where the images are joined to the local domain. This now entails App-V and Azure RemoteApp the possibility of integration with the App-V Management & Publishing Server using a cloud-based or on-premises App-V Infrastructure scenario:

Cloud-based App-V Infrastructure: This is where the App-V Management, Publishing, and Content Sources are based in Azure IaaS (with the content being also available with extended Azure PaaS services as well.) In this scenario the Hybrid Collection must be associated with an existing VNET that also contains the App-V back-end resources. This scenario also requires that the Azure RemoteApp clients and the App-V infrastructure are joined to the same local domain either hosted in Azure IaaS or via the forthcoming Azure AD Domain Services (In preview – https://azure.microsoft.com/en-us/services/active-directory-ds/) The Azure RemoteApp images are pre-configured for the Publishing Server or controlled via GPO (group policy.)

The Cloud-based App-V Infrastructure can easily service both cloud-based resources (RDSH in Azure IaaS, Azure RemoteApp) as well as traditional on-premises clients (via the web, through Site-to-Site VPN’s, or ExpressRoute.)

On-Premises App-V Infrastructure: This is where the App-V Management and Publishing Servers are based in an on-premises network servicing primarily on-premises clients. In this scenario the Hybrid Collection must be associated with a VNET attached and routed to the on-premises App-V infrastructure through a site-to-site VPN or ExpressRoute. The Azure RemoteApp images are joined to the local domain and pointed to the Publishing Servers via pre-configuration or GPO. In this scenario, it is recommended to still leverage Azure-based content sources for content even though streaming over the on-premises connection would be possible – but not recommended.

Walking Through the Process:

For the sake of this conversation, we will assume that an existing App-V 5.1 infrastructure has already been provisioned, be it cloud-based or on-premises. Obviously, before you would start the process of setting up a custom image, you will want to make sure you have this in place.

1.)    Create a custom operating system image that has the App-V RDS 5.1 Client installed –  then import image into Azure RemoteApp. This is an oversimplification of a process that is further outlined in a previous blog post on configuring and preparing an image for use with App-V and Azure RemoteApp: http://blogs.technet.com/b/gladiatormsft/archive/2015/04/29/app-v-on-app-v-applications-hosted-in-azure-remoteapp.aspx.) You can pre-configure the client and even pre-publish some applications prior to upload. I would advise skipping the client pre-configuration and instead, leverage AD GPO’s to configure the client.

2.)    Create an Azure RemoteApp domain-joined (hybrid) collection and leverage the OS image as the template image for the collection. When you go to join the domain, you will want to join the domain to a specific OU (organizational unit) within your local domain. It will be much easier to administer and control the configuration of your ARA images if they are contained within a specific OU. NOTE: This step is massively simplified here in the explanation. More specific ARA information on joining Hybrid Collections can also be found here (https://azure.microsoft.com/en-us/documentation/articles/remoteapp-create-hybrid-deployment/)
 

3.)    The image upload may take a while to provision. Once the image has been provisioned, the status will show as ready.

     

4.)    Once the images have been provisioned, you will start to see computer objects appearing in the OU you specified for the domain join.

      

5.)    At this point you can begin to configure a Group Policy Object and link it to the OU for the ARA images.

      

Within the GPO, you can leverage the ADMX templates for App-V via the MDOP ADMX template download package (available here: https://www.microsoft.com/en-us/download/details.aspx?id=41183) to control the App-V 5 client settings including App-V Publishing server targets, shared content store mode, scripting configuration, etc.

6.)    Now the interesting part begins: The App-V management console allows you to target packages to user AD (Active Directory) groups or machine AD groups.  When it comes to targeting groups, GPO’s only allow you to control local group membership. As a result, the targeting options available for machine groups that affect ARA machines is pretty much the Domain Computers Group. However, if you wanted to target the ARA images for machine groups (global publishing) you can effectively use the Domain Computers group coupled with the OU configuration for the specialized publishing server. User Targeting is a more flexible option as there are no restrictions with regards to the non-persistent provisioning of the ARA images.

   

In this example, I have targeted both the Domain Computers machine group as well as a custom user group within the App-V Management Console.

   

7.)    Publish App-V apps in ARA (using path option or pre-published discovery.) Within ARA, you can publish applications by querying the Start Menu of the image or by using Path Publishing. App-V applications will not show up via a Start Menu query unless they have been pre-published globally in the image. For this reason, it is better recommended to Path Publish the App-V applications. This requires juuuuuuust a bit of a workaround. If you plan on publishing an App-V application by path, you will need to be able to know the actual integration path to the executable in advance.

For machine-targeted (globally published) packages, they will begin with:

%SYSTEMDRIVE%ProgramDataMicrosoftApp-VClientIntegration<Package_GUID>Root

For user targeted (user published) packages, they will begin with:

%LOCALAPPDATA%MicrosoftApp-VClientIntegration<Package_GUID>Root

If you do not know the package GUID from sequencing, you can easily retrieve it from the package details within the App-V management console.

Any additional path information beyond the root folder must also be obtained in order to complete the path. Since the APPV format is a ZIP format, you can easily view this information within the APPV package file itself.


8.)    Once you have this information, you can proceed to publish the App-V applications n the Azure RemoteApp publishing console.

  

9.)    Upon logon using the ARA RDP client, you should then see your App-V applications appearing just like any other normal application.

      

Advertisements

App-V: More on App-V with Azure RemoteApp

February 9, 2016 Leave a comment

Last April, we gave a little bit of information on the limited use of App-V applications with Azure RemoteApp (http://blogs.technet.com/b/gladiatormsft/archive/2015/04/29/app-v-on-app-v-applications-hosted-in-azure-remoteapp.aspx.) This piqued the curiosity of many and over the past several months, we have been validating several scenarios involving the integration of App-V with Azure RemoteApp images within hybrid collections. 

As you might have heard, Eric Orman – the Program Manager for Azure RemoteApp, announced at Ignite Australia that App-V *IS* supported with Azure RemoteApp within specific scopes. (https://channel9.msdn.com/Events/Ignite/Australia-2015/WIN336.)   This is a significant development for companies that want more options for bringing their desktop applications to Azure as well as the birth of another chapter in the story of App-V in Azure. In the three months since that announcement, one of the most common question I have been getting is “Why? How is this significant?”

Why App-V for Azure RemoteApp?

I would say the three most important aspects about being able to use App-V with Azure RemoteApp are the following:

Keeps Custom Images Thin: Custom Images with Azure Remote App have to remain beneath the 127GB maximum for VHDs. In addition, the more applications pre-installed to ARA images translates to a longer upload time. Customers embracing App-V will have the ability to quickly bake an image for upload with minimal pre-publishing (or NO pre-publishing if leveraging path publishing the with the App-V Publishing Server or Configuration Manager.) In addition, App-V clients baked into Azure RemoteApp images can have those applications stream to memory using the App-V Shared Content Store rather than to disk also preserving permanent storage consumption on the ARA images. It is important to note that Premium Plus subscriptions coupled with a high-end storage back end (Azure Files) would be recommended for Shared Content Store use in ARA.

Allows for Streamed Application Updates: When a company decides they would like to move a LOB application to the Azure cloud using ARA, it involves an image upload. Periodically, the application may require maintenance and patching. Without a demand technology such as App-V, this would require re-uploading and re-provisioning of ARA images. With App-V, applications that have been sequenced for streaming can be dynamically updated to the ARA images without the need to re-upload any new custom images.

On-Premises, Azure IaaS, and Azure RemoteApp resources can share application Content Sources: If your organization is currently leveraging App-V and streaming content from content stores – be it on-premises or in Azure IaaS, these same resources can also be leveraged by your ARA-provisioned images as well.

Scenarios for App-V with Azure Remote App

When designing a strategy for delivering App-V applications with Azure RemoteApp, you will pretty much follow along the same lines as you would when you are designing App-V for any other target. The exceptions in the world of App-V involve the current existing gaps between the App-V IaaS (Infrastructure as a Service) and the Azure RemoteApp PaaS (Platform as a Service.)

The following table outlines the pros and cons of the different options for App-V delivery, application storage, and publishing and targeting with Azure Remote App:

 

Configuration options

Pros

Cons

Delivery method

Streaming (on demand from content server)

Application is always the latest and fresh

Possible first time latency upon initial application launch

Mounted (Pre-cached into the ARA image.)

Fastest 1st launch – all of the application assets are already present on the ARA virtual machine.

Potential Image Bloat – applications take up additional image space (remember the 127gb limit)

Primary Application location storage

Shared Content (Stream-to-memory)

App runs in memory of Azure RemoteApp instance

Eats memory and requires good connection to streaming (file) server where the app resides. Affects baseline.

Disk (Cached)

  • Fast execution
  • App not dependent on availability of Content Source

Bloat – takes up image space (127gb limit)

Targeting

User*

*Requires full standalone App-V infrastructure or Configuration Manager 2012 R2 or later

Global (machine)

Pre-publish or target using Publishing server

  • Need to update your Azure image if you want to update the app.  (huge)
  • Takes up some space on image

* In addition, User targeting also requires that the App-V application be pre-published via a path Publishing rule for the Azure RemoteApp collection.

 

More to come . . . 🙂

Anatomy of an Outlier Bug: The Issue of the Failed App-V Report Upload

January 24, 2016 2 comments

When software malfunctions, product support teams attempt to narrow the issue down to user error, configuration, or code. If the software attempts to perform a function where a specific result is expected and the actual results are different, we classify that as a bug. Of course, there is great debate on what is perceived as a bug, or is simply “by design” meaning the software was doing exactly what it was programmed to do – it just may be completely different from what the end user expected.

Let’s assume we are not having the “by design” vs. “bug” debate. When a bug confirmed, the next common item that is measured is the impact of that bug – impact within the specific customer’s environment, the frequency and likelihood of the bug occurrence. Bugs that have only occurred one or two times where the impact is minimal is usually referred to as an “outlier bug.”

Outlier bugs can be tricky – especially if there is not a known workaround. Software vendors have to weigh the risk and cost of implementing bug fixes via current version patches (as opposed to correcting the code for the next release.)

A while back I encountered one of those outlier bugs in which this bug only affected one customer (at the time) and it only revolved around one specific App-V package. It involved the App-V Client Reporting Agent failing to upload reporting XML data. The following issue was occurring.

Client machines were failing to upload reporting data. Upon a manual test using the Send-AppVClientReport cmdlet, it would yield the following error:

 

PS C:Windowssystem32> Send-AppvClientReport

Send-AppvClientReport : No reporting data has been sent to the specified URL. Verify the URL and try again.

Operation attempted: Send reporting data to reporting server.

AppV Error Code: 1300000013.

Please consult AppV Client Event Log for more details.

At line:1 char:1

+ Send-AppvClientReport

+ ~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidResult: (:) [Send-AppvClientReport], ClientException

    + FullyQualifiedErrorId : SendReportError,Microsoft.AppV.AppvClientPowerShell.SendAppvClientReport

==============

This issue was NOT occurring on all of the clients, so the first major step was to find the common denominator. Eventually we found the common denominator was a specific package. In addition, we actually got quite lucky. In many cases, the machines getting this issue only had one specific package deployed to them.

So we grabbed the XML file (C:ProgramDataMicrosoftAppVClientReportingdd6c24e-be93-48f7-b531-4eaa007128ec.xml) to view the Reporting cache and eventually narrowed it down to only occurring when the specific application was published.

What makes this issue an outlier is that the element that was causing the issue involved a package where the primary application had a version field that was greater than 16 characters. On a lark, we started modifying the XML data manually and found that if the reporting XML file was manually edited, and enough digits were removed from the version field, the upload worked. For some reason, only 16 characters were allowed in the version field. All of the fields were supposed to allow for 32.

Once root cause was narrowed down, the time came to assess the impact of the bug. It was definitely viewed as an outlier bug due to the fact there was only one known occurrence (again – at the time.) The assessment of how likely this would reoccur soon became a moot point as the good news here as the issue was within the database itself. The App-V 5 reporting service is stateless and writes directly to the temporary tables in the AppVReporting database. So we were able to fix the issue for the customer without cracking open binaries for patching.

If you are interested in the database script, it was published out on the TechNet Gallery here:

https://gallery.technet.microsoft.com/App-V-5-Fix-for-App-V-f8c1ac29

This fix was included in the App-V 5.1 release.

 

 

 

 

 

Less Than 1 Week Until the End of Support for Legacy versions of Internet Explorer (except Windows Vista and Server 2008)


Here we are! It is almost time. Over 16 months ago, Microsoft announced that support for legacy versions of Internet Explorer would be ending on January 12th, 2016 (http://blogs.msdn.com/b/ie/archive/2014/08/07/stay-up-to-date-with-internet-explorer.aspx.) The hour is almost upon us. In addition to the announcement, technologies including Enterprise Mode, Compatibility View, and persistent emulation modes were addedenhanced to assist customers in bringing older sites and web applications over to remove deployment blockers to IE11 and ultimately, Windows 10. Most of our customers in the enterprise have already leveraged (or are currently in the process of leveraging) these technologies.

If you are still running on older versions, you will soon notice that there is a warning message that will start appearing. In December, Microsoft published an article (https://support.microsoft.com/en-us/kb/3123303) that lays out the details of a new "End of Life" upgrade notification for Internet Explorer, which will be shipped as an update next week on January 12th.

The update will apply to Windows 7 SP1 and Windows Server 2008 R2 for users who have not upgraded to Internet Explorer 11 (i.e. IE8, IE9, and IE10 users). The update includes a new “end of support” notification feature when the browser is launched. This will automatically open a new tab with the appropriate download page (http://windows.microsoft.com/en-us/internet-explorer/download-ie) for your particular operating system.

For those enterprise customers that are still in the process of deploying and migration to Internet Explorer 11 (or have arranged for a custom support agreement) the KB article mentioned above also lays out instructions for disabling the notifications.

For those customers that are still on Windows Vista and Windows 2008 (which are in extended support and do not support IE11) – those operating systems will not be affected by the update. IE9 is still the latest version of Internet Explorer supported by these operating systems. Windows 8 and Windows 8.1 are also unaffected (support for Windows 8 will end on January 12th and Windows 8.1 comes with IE11).

The notification tab will not appear on every launch of the browser. After the tab is closed it will be 72 hours before it is shown again and only when launching IE (i.e. not during a browsing session).

For more information about the end of support for old versions of Internet Explorer see the following links: https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support and https://support.microsoft.com/en-us/lifecycle#gp/Microsoft-Internet-Explorer page. For technical information about how to upgrade to Internet Explorer 11 and Microsoft Edge see the Browser TechCenter pages on TechNet (https://technet.microsoft.com/en-us/browser.)

For my Friends and Family: You have no excuse not to secure your Microsoft Accounts with Multi-Factor Authentication

November 27, 2015 Leave a comment

I am always begging my close friends and family, many who are not all that technical, to follow basic tenants for securing their digital worlds. From changing their passwords on a regular basis (even having them schedule it to coincide with Daylight Savings Time/Standard Time conversions a la “smoke detector battery changes) to keeping their operating systems and anti-virus software up to date, I warn them that risks are not just for enterprises and governments. In fact, in the past six months, the following has happened to me:

  • A good friend of my mother (a female) begins sending me Webcam spam from her Skype account.
  • An old high school friend (another female) begin sending out large organ pics (male) to everyone on their Facebook friends list.
  • My sister got hit with some serious ransomware. All of her pictures are encrypted with a $500 dollar ransom. She’s still running Windows XP.

Given that my primary accounts for personal use involve Microsoft services and accounts – and I work for Microsoft, I feel compelled to evangelize the fact that all of your Microsoft online accounts (Hotmail, Live, Outlook.com, Office365) can be protected via multi-factor authentication.

 

What is Multifactor Authentication? It is simply a method of authentication that involves at least two disparate factors for authentication. In most cases, single factor authentication involves a simple password for verification of identity. This is the oldest and one of the most archaic and insecure methods of verifying identity. When you enable multifactor authentication, even after submitting a correct password, additional steps are taken to verify you are who you say you are. You may have to do this when you sign on to a web site from an unknown or previous unknown location. In some cases, you may have to answer additional security questions (not the best additional factor but indeed and additional factor) or enter a text code sent to your mobile phone (much more secure secondary factor.)

 

In the case of Microsoft account, the following FAQ answers your questions about the options available

http://windows.microsoft.com/en-us/windows/two-step-verification-faq

If you want to enable multifactor authentication, you can do so under your account profile here:

https://account.live.com/proofs/Manage

If you are accessing Hotmail, Live, Outlook.com from Outlook 2010, 2013, 2016, you will need to set up app passwords (app-specific passwords) after you enable two-step/multifactor authentication

http://windows.microsoft.com/en-us/windows/app-passwords-two-step-verification

An excellent post on Channel 9 along the same lines:

https://channel9.msdn.com/posts/Multi-Factor-Account-Setup

The Authenticator App for Windows Phone gives you codes to use: 

https://www.microsoft.com/en-US/store/apps/Authenticator/9WZDNCRFJ3RJ

This blog post walks you through the process: 

http://blogs.technet.com/b/mspfe/archive/2013/10/02/how-to-use-the-microsoft-authenticator-app-for-windows-phone-to-enable-two-factor-authentication-on-facebook.aspx

https://support.office.com/en-us/article/Set-up-multi-factor-authentication-for-Office-365-8f0454b2-f51a-4d9c-bcde-2c48e41621c6

If you are using an Android phone, the Microsoft Account app will also allow for verification through a one-touch app.

https://play.google.com/store/apps/details?id=com.microsoft.msa.authenticator 

FAQ on additional identity apps verification

http://windows.microsoft.com/en-US/Windows/identity-verification-apps-faq

 

Categories: Uncategorized

Farewell to Zune

November 14, 2015 3 comments

As I write this, within a few hours, the Zune Service is expected to end per earlier announcements. What exactly will happen with the functionality of the Zune 4.8 software, will be only that limited functionality will remain.

I am sad. I loved the Zune player – especially the ZuneHD. I still use the ZuneHD rather than the phone because of the storage space, and the fact that battery consumption is way better on the ZuneHD player than any phone I have used or seen.

zune

It is likely that download subscription content will start to fail at some point once media usage rights need to be re-queried. All other DRM-free MP3/WMA media should still play as expected. I imagine that the device sync will still work as well. I had the pleasure of keeping the 10-song-a-month feature thanks to the grandfather policy. Since this will be ending, I made sure to use my song credits this last time. The songs I chose were:

  • Lou Reed – What’s Good
  • Roxy Music – Avalon
  • Wendy Bagwell – Here Come the Rattlesnakes
  • Warren Zevon – Boom-Boom Mancini
  • The Cramps – I was a Teenage Werewolf
  • Blondie – X-Offender
  • Tom Petty – Straight Into Darkness
  • Deep Purple – Hush
  • Deep Purple – Smoke on the Water
  • Deep Purple – Highway Star

(Yes, I have an eclectic variety of tastes)

So What Happens Next?

Per the following KB article: https://support.microsoft.com/en-us/kb/3096659

Existing Zune Services will be converted to Groove Music (formerly XBOX Music) – not to be confused with that other software Microsoft acquired over a decade ago. I’ll be trying to use my ZuneHD with this service.

zunes

I used every Zune device that was released and still have them – including the original Zune30 from 2006. I am somewhat sad.

Categories: Uncategorized

App-V 5.x Client Publishing Server Address

October 22, 2015 1 comment

Hi all,

I've had the pleasure of working with the Gladiator for the past 5 years and now I have the opportunity to provide some great information about App-V 5.x to the world.

What we have been seeing out in the field is that there seems to be some confusion on how to view the App-V 5.x Publishing Server XML correctly, so this should walk you through how to view the metadata from a users perspective.

Firstly if you query the Publishing Server using “Get-AppvPublishingServer” the following will be returned.

You can then take the URL and paste it in a browser to see which packages and connection groups are entitled to you.

The misconception here is that your meant to see the connection group as your in the AD Group but it can’t be seen?

The App-V 5.x client is actually passing parameters to the string so that it can see the correct data, you can review what is passed here: https://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_pub_metadata_clientversion.

Reviewing the article there are two parameters ClientVersion and ClientOS which will show a true representation of user entitlement which is what you should be using to query the publishing server.

Note: The ClientOS is used so that we can show or hide the OS restrictions set within the App-V Package.

Hopefully to make your life easier run the following Powershell script on the App-V Client which will build the Client URL for you.

Import-module AppvClient

write-host

$AppVPS = Get-AppvPublishingServer | select URL
$url = $AppVPS.URL

$AppV_Version = (Get-ItemProperty HKLM:SoftwareMicrosoftAppVClient -Name Version).Version

$Ver = (Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindows NTCurrentVersion' -Name CurrentVersion).CurrentVersion

$Model_Check = (Get-WmiObject -class Win32_OperatingSystem).Caption

if($Model_Check.Contains("Server")){ $Model = "Server" } else { $Model = "Client" }

if ((Get-WmiObject -Class Win32_OperatingSystem).OSArchitecture -eq '64-bit'){ $architecture = "x64"} else { $architecture = "x86" }

$ClientURL = $url + "?ClientVersion=" + $AppV_Version + "&ClientOS=Windows" + $Model + "_" + $Ver + "_" + $architecture

$ClientURL

 Then copy the $ClientURL returned value and paste it into your browser, you should see a different result including the connection group which you couldn’t see before.

Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

Hope this helps in understanding what a user is actually entitled to.

David Falkus | Premier Field Engineer | Application Virtualization