FREQUENTLY ASKED QUESTIONS

• • Windows applications & desktops (via RDP/Terminal Server): Awingu can connect to RDP and make the published application, desktop, RemoteApp, Remote Desktop or VDI available in HTML5. Note: this typically requires a Microsoft RDS license. Read our blog post for more background.
  • Linux applications or desktops: these are also transposed to HTML5 via the Awingu technology (using xRDP in the backend)
  • (Internal) web applications: these are made available via the Awingu Reverse Proxy, with Single Sign-On capabilities (Basic Authentication)
  • SaaS applications like Office365 and Google Apps: these are made available via Single Sign-On. The applications will open and run in a separate tab.
  • Azure Windows 10 Enterprise Multi-session (Windows Virtual Desktop, WVD): similar to classic RDP based environments.

Every desktop or VDI that can be connected via RDP, can be made available in HTML5 via Awingu – as shown in our Demo Environment Rundown (watch it here).

No, Awingu’s platform will connect to application servers, SaaS, Web apps and files. Awingu does not host/run or impact your (legacy) applications on it’s software platform. These keep running on application servers (with Terminal Server/RDS). At Awingu, we want to be as little disruptive as possible to your existing IT architecture.

Most certainly not! Awingu makes your legacy applications and files available in any browser via HTML5. No rewriting of the application is required. Awingu wants to be as little disruptive as possible to your existing application landscape. That enables us to get you up-and-running in no time.

Yes, Awingu also uses an encrypted connection and supports multi factor authentication which makes it a secure solution. As such, you will still be using SSL, but in a user-friendly fashion. However, you won’t have hassle-full VPN setups and login procedures to work remotely.

Awingu has very light and non-disruptive requirements. The requirements are described below:

There are 3 options to connect your SaaS services with Awingu. This implies end-users will have to log in only once into their online Awingu workspace. From there, they will automatically be signed in into their SaaS services. (Note: all 3 options can be mixed)

1. Leverage Awingu as Identity provider: Awingu acts as an Identity provider. Since Awingu 3.2 it has connectors to a number of popular SaaS services. These include Microsoft Office 365, Google Apps for Work and Salesforce. It is possible to build custom connectors on demand. The usage of these SaaS services will also be covered in the usage insights reports. Usage of our SaaS connectors is described in detail in the admin guide.

2. Leverage integration with Microsoft’s Azure AD: If you are using Microsoft Azure AD to setup Single-Sign-On with SaaS services, you will also have the SSO when opening the SaaS service via Awingu.

3. Leverage integration with Okta: If you are using Okta to setup Single-Sign-On with SaaS services, you will also have the SSO when opening the SaaS service via Awingu.

On August 12th, 2016, Microsoft announced stopping it’s Azure RemoteApp service. The service discontinued in August 2017. Read more about the options Microsoft suggested for migrating out of RemoteApp at https://docs.microsoft.com/en-us/azure/remoteapp/remoteapp-migrationoptions. While the communication mentions a partnership with Citrix for a replacing service, Awingu can offer a perfect alternative already today.

Try Awingu with two free concurrent users on Azure Marketplace (here) or, request a free trial account here.

On top of being available right now, Awingu also offers a richer solution compared to Azure RemoteApp. The table below gives a good summary view:

Very often we get the question “what is my total cost for running Awingu?” The answer, as you’d expect is: “it depends”.

Are you deploying in a public cloud? On-premise? Do you want a fully redundant platform or not? What software are you running? Where are your operations based? How many users will run on Awingu? It’s impossible to map out all of the possible scenarios. However, at a higher level, we can bring the cost of Awingu down to the following building blocks. The costs are purely indicative and will depend on your specific context. They should only be used as a high-level guideline.

* named user licenses vs. concurrent user licenses? https://www.awingu.com/what-is-the-pricing-per-concurrent-user/

Awingu provides multiple ways to securely authenticate with multi-factor authentication (MFA). The table below gives a summary of the different options. As of Awingu 4.2, “Time Based Password” 2FA is also supported as a built-in service.

Currently, we support

• VMWare ESX
• Hyper-V
• KVM
• Microsoft Azure
• Amazon AWS
• Google Compute

• Awingu provides access to classic file shares via WebDAV or CIFS. In addition, a direct connection is possible with the Office 365 OneDrive environment of the end user.
• From the Awingu workplace, users can also immediately share documents with third parties, in a safe and controlled manner

• No local data; everything runs safely in the browser
• Multi-factor authentication; you can use the built-in ‘One time Password’ tool or a range of commercial solutions in the market (such as Azure MFA or Radius based solutions)
• Granular control: determine per user (group) whether they can print, download, share documents, …)
• Audit; full use is made available in real-time audit logs (e.g. who has deleted documents, from which location is a particular user logged in, …)

• There are no limits on the type of printers.
• Awingu’s virtual printer: the ‘Virtual Printer’ generates a document to be printed in the browser and will launch the print job from the browser to the known printers on the user’s PC. There is no need to manage printer drivers. This is very useful for remote / BYOD usage.
• Network printers: Inside the office, Awingu admins can define network printers in the back-end. As such creating a known default for the end-user.
•  

The Awingu interface is available in over 20 languages, amongst which Dutch, French, English, Chinese, Spanish, Portuguese, Swedish, Danish, Norse, Finnish, Italian, Russian, Polish, Romanian, Latvian, Lithuanian, Czech, Slovenian, Ukranian, …

• • Smartcard: these are supported for “in app” usage (not for authentication) via the Awingu ‘Remote Application Helper’. This small agent must be installed on the device of the end)users and is available for Windows, Mac and Linux.
  • Scanners: most scanners will behave similar to keyboards and will as such function within Awingu. As exceptions exist, please contact Awingu support to find out more.
  • Printers: see printer FAQ topic
  • USB storage drives: Awingu does not have a direct link with your local storage, as well as USB disks. Data can be down- or  uploaded from / into Awingu in a 2-step approach assuming the end-users has the right to down/upload data.

• • Awingu security layers such as:
    • Built-in Multi-Factor Authentication
    • Easy Session Recording
    • Full usage auditing
    • Using Awingu as a point of entry where you manage the network and have the ability to add security checks (vs. a shared WVD broker)
  • Awingu aggregation. Probably not all of your users will require hosted desktops on Azure. Some of your users might need to connect only to a selection of applications, some might not require a full Windows experience (e.g. Chromebook users), etc. With Awingu you create one unified experience in the front-end which makes life easier for the users, and those managing the users.
  • Simplicity in user management. Today, adding a user in WVD still requires scripting in PowerShell. With Awingu “on top” the process of adding users and groups is very straightforward.
  • Awingu session sharing. Easily share your hosted desktop with other users for collaboration purposes while having a full and easy audit trail of everything that happens within those sessions.

At Awingu, we believe in easy-of-use and simplicity. End-users visit a URL in their browser – all recent browsers are tested by our teams – enter their login & password and get access to their workspace. The experience is consistent and optimized for usage across devices (e.g. laptop or tablet).

Have a look at this video to get an idea how simple it is. Or even better, take one of our trial accounts for a spin!

Migrating away from an existing Citrix infrastructure to Awingu is one of our most frequent use cases. It’s actually a really easy and fast four-step process. We’re describing it below in full detail.

Note: There are a number of reasons why migrating from Citrix to Awingu is a good idea. We elaborate on this in more detail here.

Below is a picture of a typical Citrix XenApp Deployment:

Installing Awingu next to this setup can be achieved by deploying 1 (or more for load distribution or High Availability) in the Access Layer following this procedure which can be executed in less than 1 hour.

1)     Download and setup Awingu according the regular installation guide.

Download the admin guide here

2)     Add non admin users to direct access user group

When ‘Citrix Virtual Delivery Agent’ is installed on a machine, non-administrators can no longer RDP to the machine. A new local group called Direct Access Users is created on each Virtual Delivery Agent. Add your non-administrator RDP users to this local group so they can RDP directly to the machine.

– Enable non-admin RDP users to get direct RDP access –

Add here the security group for the users which should have access.

– Add security group for users with access –

3)     Enable RDP policy in Citrix studio

3.a. To be able to initiate a remote session a policy needs to be added to Citrix. Open the Citrix director and browse to the policy section. On the right top choose ‘Create Policy’

– Create new policy –

3.b. In the search field search for: ‘Launching of non-published programs during client connection’ and select it.

– Launching of non-published programs during client connection –

3.c. Enable this policy for all objects in this site

– Enable for all objects –

3.d. Give it a meaningful name and enable the policy

– Give a name and enable policy –

3.e. Set the policy priority higher

– Set policy priority –

3.f. If you want to speed the policy up you can always update them manually

– option: manually update policies –

4)     Optional: De-Install Citrix software from app servers

The result would be like in following picture:

Please note that the Netscaler can be optionally used to loadbalance to the different Awingu appliances but any loadbalancer will do.

There is no need any more of the Citrix Control layer. The Awingu appliances have all knowledge needed to do the brokerage to the different RDS servers.

Have any questions or remarks? Please don’t hesitate and reach out to us.

Introduction

The Awingu All-In-One App in the Microsoft Azure marketplace allows you not only to deploy an Awingu appliance, but also to deploy a complete Windows backend infrastructure and configure Awingu to use this backend.  The result of an Awingu All-In-One Azure marketplace solution is a pre-configured, ready-to-use Awingu environment hosted in the cloud.

This is very useful in following scenarios:

1. Greenfield projects where no existing Windows environment is available

2. Migration to the cloud

3. Testing purposes, e.g. to evaluate Awingu

Deployment

Deploying an Awingu All-In-One Azure marketplace solution is done through the Azure Portal using a wizard in 3 easy steps.

To start the wizard, search for ‘Awingu All-In-One’ on the Azure marketplace and click the ‘Create’ button.

The wizard will present you some options and questions in easy 3 steps.

Please note that Awingu All-In-One is not available in Azure Classic.

Basics

The first step ‘Basics‘ covers Azure settings and determines where your Awingu All-In-One environment will be deployed.

This is based on the Azure subscription and datacenter selected.  All virtual machines will be deployed in a single, newly created Resource Group.

Currently it is only possible to deploy in a new Resource Group.

Awingu Configuration

The second step ‘Awingu Configuration’ will present you with all options and questions required to deploy and configure the Awingu appliance.

Windows Backend Configuration

The third step ‘Windows Backend Configuration’ will present you with all options and questions required to deploy and configure the Windows backend servers.

This backend will consist of 1 Active Directory server and a selectable amount of Windows application servers.  The Awingu appliance will be configured automatically to connect to these servers.

Summary

This step gives you a summary of earlier provided information for review.

If all information is correct, press OK to start deploying your Awingu All-In-One environment.

Next Steps

Congratulations! You have your Awingu All-In-One environment up-and-running!

Now you can navigate to http://{prefix}.{location}.cloudapp.azure.com and sign-in using the admin username and password provided in step 2 of the wizard.

No, Awingu is a software vendor. We do however sell our software to different types of Service Providers so they can build an offering around Awingu. Awingu is an ideal solution for Service Providers:

1. Fully multi-tenant with tenant personalization

2. Open API’s

3. Runs on any infrastructure (e.g. Azure Stack, vCloud)

4. Multi-node deployments, support for RDS farms,…

Typical Service Provider value propositions are:

1. Awingu-as-a-Service: where the SP hosts Awingu’s platform and resells to end-customers or channel partners at a price per month per user. The customer is responsible for his own applications;

2. Workplace-as-a-Service: Where the SP hosts and manages both the Awingu platform as well as other applications.

Also, we are part of cloud marketplaces such as the Microsoft Azure Marketplace.

Interested to build an offering based on Awingu’s platform? Contact us here

Have a look at our pricing page!

Awingu sells license keys based on the number of ‘concurrent’ users. A minimum of 20 concurrent users needs to be purchased. Concurrent users can be compared to ‘bandwidth’; e.g. 20 concurrent users means that at any time 20 users can simultaneously log in into Awingu.

How many ‘named’ users does a concurrent user cover? It depends. The ratio can be as low as 1/5 when for example your company works in multiple shifts per day and employees don’t use their PC full-time. But equally, it be a 1/1 ratio when your employees are power-users and don’t work in shifts. A single employee (or user) can generate more than one concurrent user when he/she logs into Awingu from different devices at the same time, or when he/she logs into Awingu from different browsers at the same time. The number of concurrent users is not impact by the number of applications somebody opens.

Note: For Service Providers, a different pricing model is available. This is based on named users. Want more info? contact us here.

No. You can link as many applications or files with Awingu as you wish. Our pricing is only based on the number of concurrent users.