Schedule 1: Project plan
This Schedule 1 provides a framework for the different steps in an Awingu roll-out and the corresponding responsibilities. It is applicable to an Awingu small-scale / pilot roll-out in a non- production test environment. A small-scale / pilot roll-out is defined as a setup whereby Awingu is used day-to-day by a limited number of users for a restricted duration of time in a non- production test environment before the customer switches to a full-scale roll-out.
1. Assumption and limitations small-scale / pilot rollout
The small-scale / pilot roll-out plan optimizes the HW cost and implementation cost of the setup, based on a number of assumptions and restrictions:
- Maximum number of users: 20 concurrent users
- Standard connectors only – no customization:
- Standard Application connector with one or multiple application servers (random selection process).
- User connector: labels in Awingu need to exactly match LDAP/AD groups
- Standard File server connector
- Customer provides the infrastructure to run a software appliance (a virtual machine) with 2 cores, 4 GB RAM and 80 GB of disk
- Note that in any deployment (small-scale / pilot or full-scale), SSL certificate management and SSL offloading remains the responsibility of the
- Integration with load balancer/HTTP proxy/SSL offloading is out-of-scope of the small- scale / pilot roll-out.
- This setup does not require additional hardware, but is not redundant, i.e. failure of the VM will make the complete Awingu environment unavailable.
- The default installation by Software Provider includes the possibility of provisioning up to 5 applications onto the platform in the pilot phase. If desired, customers can use the Awingu management interface to provision additional applications during the small- scale/pilot rollout evaluation
- The list of applications may include legacy enterprise applications. All applications need to fulfill basic requirements as listed in the design section, i.e. special implementation schemes for applications that do not meet these requirements are out-of-scope for a small-scale / pilot roll-out
- Web applications can be published on the Awingu platform (part of the 5 applications mentioned above). Single sign-on is not supported for Web applications.
- Language localization is not supported as part of a small-scale / pilot roll-out.
- There is no support for applications that require access to local peripherals such as USB ports, Serial ports, etc.
The Awingu platform can be set-up to become an identity provider (IdP) for a Microsoft’s Office 365 domain or Google’s Apps for Business domain allowing single sign-on (SSO) to these services. Integration of the IdP and the corresponding SSO is not part of a small-scale roll-out. A full-scale roll-out will require the addition of hardware to the setup and potentially some customization of connectors or specific support for legacy applications that do not meet standard requirements.
2. Success criteria of small-scale / pilot roll-out
A small-scale / pilot roll-out allows for evaluation of the major Awingu functionality in a day-to- day working context. Following items can be evaluated during a small-scale / pilot roll-out:
- Ease-of-use of Awingu application
- Test Awingu on multiple types of end-user devices
- Test desktop application delivery methodology
- Test session recovery, session take-over, session sharing
- Test Webapp delivery methodology (if applicable)
- Integration of legacy application (if applicable)
- Test browser based file navigation
- Monitor concurrency and usage level (server load and bandwidth) which will allow to better dimension a full-scale roll-out
- System administrators can test the management back-end of Awingu. The standard duration of a small-scale / pilot roll-out evaluation is 2 months.
3. System overview
An Awingu ecosystem consists of several components:
- Existing IT infrastructure: file servers, LDAP/ Active Directory (domain controller), network infrastructure, load balancers, SSL offloading, proxies,
- Windows application servers
- Awingu servers: In the small-scale / pilot roll-out phase, the complete Software is deployed on one virtual machine.
Awingu professional services consist of the following categories:
- Deployment design
- Configuration & Integration
- End-to-end validation
- Support during evaluation period
4. Deployment design
The goal of the design phase is to:
- verify a number of assumptions on the environment
- agree on the final scope of the small-scale / pilot roll-out
- discuss the current IT environment and scope the integration effort that needs to happen during roll-out
- Verification of network prerequisites: Awingu requires IP connectivity between the end- user browser and the Awingu back-end infrastructure. The browser can be deployed behind a NAT device. Awingu makes use of standard TCP ports for both HTTP(S) traffic and WS(S) traffic and hence requires that these ports are not blocked by any firewall that sits in between the Awingu infrastructure and the end-user browser. If there are (forward/reverse) proxies on the path, these (forward/reverse) proxies also need support for web sockets. A detailed assessment of connectivity needs to done as part of any Awingu implementation project. End-users can connect to Awingu over a VPN infrastructure as long as the above requirements are met. A test report is required, that shows that requirements are met.
- Customer validates whether the required applications are running on:
- At least a windows 2008 server
- The application should be able to run in remote desktop sessions (allowing multiple concurrent sessions)
- Application does not conflict with other applications installed on the same application server
Discuss the virtualization infrastructure to run the Awingu software appliance.
- An appliance capable of running 20 concurrent sessions requires a 2-cores, 4 GB RAM, 80 GB of disk space
- Awingu provides templates for the following hypervisors:
- Microsoft HyperV 2008 R2 & Microsoft HyperV 2012 R2: The appliance is distributed as a zip of a VHD images
- VMware ESXi 5.0 & VMware ESXi 5.5: The appliance is distributed as a OVA container (both VM-8 and VM-9 version are available)
- KVM: The appliance is distributed as QCOW image files (both QCOW2 and QCOW3 images are provided).
Discuss the connectivity requirements during installation
|NTP: UDP Port 123||The Awingu-VM||On- or off-site NTP Service. A common use case is to use the NTP service of the AD server(s)|
|HTTPS: TCP Port 443
(connection to repository server)
|The Awingu-VM||Awingu’s repository servers*: https://repo-pub.awingu.com|
|DNS: UDP port 53||The Awingu-VM||DNS server which resolves the NTP (when provided via FQDN)|
|HTTP: TCP port 8080||The browser of the operator||The Awingu-VM|
|HTTP: TCP port 80||The browser of the operator||The Awingu-VM|
*If required, it is possible to connect to the repository server(s) via a forward proxy Discuss the connectivity requirement during operations.
|HTTP: TCP port 80 (using long living web sockets)||The (test)clients||The Awingu-VM|
|LDAP(s): TCP port 389 (or TCP port 636 for SSL encryption)||The Awingu-VM||To Active Directory Server(s) or LDAP based backend|
|CIFS: UDP port 137,138, TCP port 137,139||The Awingu-VM||To Fileserver(s) backend|
|CIFS: TCP port 445 (if SMB over Direct- TCP is enabled)||The Awingu-VM||To Fileserver(s) backend|
|WebDAV (if needed): TCP port 80 (depending on WebDAV config)||The Awingu-VM||To Fileserver(s) backend|
|RDP: TCP port 3389 (RDP/RemoteApp)||The Awingu -VM||To Application Server(s)|
|Radius: UDP port 1812||The Awingu-VM The Radius Server||The Radius Server The Awingu-VM|
|DNS: UDP port 53||The Awingu -VM||DNS which knows the FQDN of windows backend|
|NTP: UDP port 123||The Awingu -VM||On- or off-site NTP service|
|HTTPS: TCP port 443||The Awingu-VM||Awingu’s repository servers: https://repo-pub.awingu.com Only needed during Configuration|
- For CIFS, the usage port 445 (SMB over Direct-TCP) is not required but allows for better speeds
- The Radius communication is only required when radius based One-Time-Password are part of the small scale
Agree on the configuration information to be provided by the Customer:
- initial configuration of labels:
- labels are associated with users and applications. A user has access to all applications that have a label that is also assigned to that
- a label can e.g. be the equivalent of a
- customer to provide the list of labels that will be
- In a small-scale / pilot roll-out, labels must correspond to LDAP groups (AD security groups)
- initial configuration of applications:
- Discuss the scope of integration: Customer needs to provide a list of application metadata, including:
Discuss the scope of integration:
- application name as it will appear in Awingu end-user UI
- application icon to be used (icons to be provided by customer: 32×32 / 72dpi, preferably in .PNG format)
- MIME-type extension to be associated with the application
- Label(s) to be associated with the applications
- Discuss how to integrate the Awingu profiles into the existing Active Directory Domain Controller structure. This should a.o. the following questions:
- Awingu is capable of authenticating to a single domain. There is no write access necessary on the domain controller during installation and
- Awingu can authenticate to the active directory via the ldap or ldaps protocol. In case, of ldap, the required certificates should be present on the domain controllers.
- Awingu makes use security groups for authorization rules. By default the following groups are assumed to exist:
- A security group of users which will have Administrator rights to configure the Awingu platform after installation. This group is referred to as the “Awingu_Administrators” group
- A security group of users for which the application streams need to be recorded (if required).
- Discuss the file shares which should be accessible through Awingu:
- The file shares should be reachable from the Awingu server via either the WebDAV or CIFS (SMB) protocol. The access to the file-server should be governed by the domain
- Discuss whether session recording should be activated
- In case session recording will be used, a CIFS or WebDAV share should be made available to which Awingu can push all recorded sessions. The credentials on how to access this share should be
- Discuss the application servers:
- Sizing: The load on the application servers are of course highly dependent on the type of application which will be run on then. For office type of application the recommendation is to use for 20 concurrent users a 4-VCPU, 32 Gig RAM
- Some GPOs (on RDP connectivity) are required on the application servers (see below for more details).
- Printing: Printing of documents in streamed RDP and RemoteApp session is possible when only the HP Universal Printer is installed
Roles and responsibilities: This information should be provided prior to installation.
- HW and OS installation have been installed for the Windows application servers 2008/2012 (and joined into the domain) by the
- Applications have been installed on Windows application servers and have been verified to work properly (conflict resolution) by the
- RDP access to those applications is
- Network setup has been done and confirmed to meet Awingu specifications, see above for more
- The infrastructure is ready to deploy the Awingu software appliance
- During installation, access to the console of the Awingu software appliance is required if static networking needs to be set-up
- During installation, access to internet (HTTP/HTTPS) should be available to perform the installation
- During installation, it is best to create one or two user accounts. The recommendation is to make a test-user that is part of the “Awingu Administrator” security group as well as a test-user with equal profile a regular
- If used, the share of recorded application sessions is enabled. And the credentials that Awingu should use to access the drive are known
Tasks: Awingu software installation is performed Roles and responsibilities:
- The prerequisites on network infrastructure needs to be fulfilled by the Customer
- The HW and OS installation is performed by the Customer
- The installation of the Awingu SW modules will be performed by Software Provider
6. Configuration and Integration
Prerequisites configuration: Application/Labels/MIME types/Icons have been described in the design document (see design section for more info).
Tasks: Software Provider configures above parameters onto the platform. Prerequisites integration
- Integration points and method described in the design
- All users of the Awingu platform are defined in the LDAP (AD server)
- A system administrator of the customer is available during configuration for technical assistance.
- In order to deliver correct operation, Software Provider requires the following GPOs to be set on the application servers:
- Computer Configuration / Policies / Administrative Templates / Windows Components / Remote Desktop Session Host / Connections /
- Restrict Remote Desktop Services users to a single Remote Desktop Services sessions:
- Computer Configuration / Policies / Administrative Templates / Windows Components / Remote Desktop Services / Remote Desktop Sessions Host/Session Time Limits:
- Set time limit for disconnected sessions: End a disconnected session in 1 minutes
- Set time limit for log off of RemoteApp sessions: RemoteApp session log off delay Immediately
- In order to allow printing within streamed RDP or RemoteApp applications, a correct printer driver needs to be installed on the application server. This can be done by installing the HP Universal Printers (postscript driver, dynamic mode) on all application servers.
- Computer Configuration / Policies / Administrative Templates / Windows Components / Remote Desktop Session Host / Connections /
- Software Provider and Customer set up, configure and validate the connector between the Awingu servers and the existing Domain Controller or LDAP authentication server
- Software Provider and Customer set up, configure and validate the connector between the Awingu servers and the file servers of the existing IT infrastructure
Roles and responsibilities: Configuration will be performed by Software Provider
Outcome: Platform configured and integration completed. Platform ready for end-to-end validation.
7. End-to-end validation
End-to-end validation of the setup, including:
- Connecting as an end-user to the platform with pre-determined browser (brand + version) and pre-determined device(s)
- Launch all applications one by one
- Access files on the drives (My Drive are accessible for Read/Write operations) Roles and responsibilities: Validation will be performed by the customer
Outcome: Platform ready for usage.
Prerequisites: System has been installed and is operational
- Hands-on Training for system administrator by Software Provider (1hr session)
- Up to a Maximum of 10 attendees per training session
Roles and responsibilities: Software Provider will provide the system administrator training Outcome: Customer’s system administrator is ready for pilot operation and evaluation.
9. Support during evaluation period
A small-scale / pilot roll-out includes system administrator telephone support during business hours during the agreed evaluation period.
10. Concluding remarks
At the time of writing, the HP universal printer driver can be downloaded at http://h20566.www2.hp.com/portal/site/hpsc/public/psi/swdHome/?sp4ts.oid=503550
Based on experience, the overall lead time of a project is largely determined by the design phase, e.g. verifying network prerequisites and application compatibility. Therefore it is important that these steps are scheduled as early as possible in the process.