Wyse WSM 7 Sizing and Planning Guide

Wyse WSM 7 Planning and Sizing Guide
Dell Cloud client-computing

February 2015
A Dell Technical White Paper
Revisions
Date
Description
August 2014
Initial release
September 2014
Revise Client Caching feature naming

Updated Server Sizing example
WSM DB failover now support all site types
October 2014
Application layering post mount feature

IOPS per user at startup
November 2014
Updated for WSM 7.1.0 release
Dezember 2014
Updated for WSM 7.2.0 release

Adjusted download location of AMD Driver for quad-core Cloud Desktops
February 2015
Add RAID mode on server sizing part, updated resource links

New section about freeing up disk space from old Windows updates
Wyse WSM 7 Planning and Sizing Guide | Version 20150212
THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND
TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF
ANY KIND.
2013 Dell Inc. All rights reserved. Reproduction of this material in any manner whatsoever without the express
written permission of Dell Inc. is strictly forbidden. For more information, contact Dell.
PRODUCT WARRANTIES APPLICABLE TO THE DELL PRODUCTS DESCRIBED IN THIS DOCUMENT MAY BE FOUND
AT: http://www.dell.com/learn/us/en/19/terms-of-sale-commercial-and-public-sector Performance of network
reference architectures discussed in this document may vary with differing deployment conditions, network loads, and
the like. Third party products may be included in reference architectures for the convenience of the reader. Inclusion
of such third party products does not necessarily constitute Dells recommendation of those products. Please consult
your Dell representative for additional information.
Trademarks used in this text:
Dell, the Dell logo, Dell Boomi, Dell Precision ,OptiPlex, Latitude, PowerEdge, PowerVault,
PowerConnect, OpenManage, EqualLogic, Compellent, KACE, FlexAddress, Force10 and Vostro are
trademarks of Dell Inc. Other Dell trademarks may be used in this document. Cisco Nexus, Cisco MDS , Cisco NX0S, and other Cisco Catalyst are registered trademarks of Cisco System Inc. EMC VNX, and EMC Unisphere are
registered trademarks of EMC Corporation. Intel , Pentium, Xeon, Core and Celeron are registered trademarks of
Intel Corporation in the U.S. and other countries. AMD is a registered trademark and AMD Opteron, AMD
Phenom and AMD Sempron are trademarks of Advanced Micro Devices, Inc. Microsoft , Windows, Windows
Server, Internet Explorer, MS-DOS, Windows Vista and Active Directory are either trademarks or registered
trademarks of Microsoft Corporation in the United States and/or other countries. Red Hat and Red Hat Enterprise
Linux are registered trademarks of Red Hat, Inc. in the United States and/or other countries. Novell and SUSE are
registered trademarks of Novell Inc. in the United States and other countries. Oracle is a registered trademark of
Oracle Corporation and/or its affiliates. Citrix, Xen, XenServer and XenMotion are either registered trademarks or
trademarks of Citrix Systems, Inc. in the United States and/or other countries. VMware , Virtual SMP, vMotion,
vCenter and vSphere are registered trademarks or trademarks of VMware, Inc. in the United States or other
countries. IBM is a registered trademark of International Business Machines Corporation. Broadcom and
NetXtreme are registered trademarks of Broadcom Corporation. Qlogic is a registered trademark of QLogic
Corporation. Other trademarks and trade names may be used in this document to refer to either the entities claiming
the marks and/or names or their products and are the property of their respective owners. Dell disclaims proprietary
interest in the marks and names of others.
Table of contents
1
New Features in WSM 7.0.0 ..................................................................................................................................................... 8
New Features in WSM 7.1.0 ...................................................................................................................................................... 9
New Features in WSM 7.2.0 ................................................................................................................................................... 10
High Level Overview of the WSM Solution .......................................................................................................................... 11
Network, Infrastructure Services and System Security ..................................................................................................... 16
5.1
Network Topology ........................................................................................................................................................ 16
5.2
Network Infrastructure and Services ......................................................................................................................... 18
5.3
PXE Boot ......................................................................................................................................................................... 20
5.4
Non-PXE Boot ............................................................................................................................................................... 21
5.5
Infrastructure Services.................................................................................................................................................. 22
5.6
System Security Credentials ........................................................................................................................................ 24
Server Roles and Group Concept ......................................................................................................................................... 26

6.1
Server Roles.................................................................................................................................................................... 26
6.2
Server Groups ................................................................................................................................................................ 27
6.3
Device Groups ............................................................................................................................................................... 28
6.4
Adding Devices .............................................................................................................................................................. 28
Site Based Architecture ........................................................................................................................................................... 29

7.1
Overview ......................................................................................................................................................................... 29
7.2
Site Groups ..................................................................................................................................................................... 31
7.3
Site Templates ............................................................................................................................................................... 31
7.4
Secure Communications for Linked Sites ................................................................................................................ 33
7.5
Site Version ..................................................................................................................................................................... 34
OS Image Creation and Patching ......................................................................................................................................... 36

8.1
Write cache Modes ....................................................................................................................................................... 38
8.2
OS Image updates ........................................................................................................................................................ 40
8.3
Reference Device Group ............................................................................................................................................. 41
8.4
OS Image Patch Rollback ............................................................................................................................................ 41
Content Distribution................................................................................................................................................................ 42
9.1
Overview ......................................................................................................................................................................... 42
9.2
Content Distribution for Linked Sites ........................................................................................................................ 42
9.3
Bandwidth Throttling .................................................................................................................................................... 43
9.4
Image compression ......................................................................................................................................................44
9.5
Offline deployment of OS / Application Images .....................................................................................................44
9.6
Automatic cleanup of older images versions...........................................................................................................44
9.7
Fast Patch .......................................................................................................................................................................44
10 High Availability and Disaster Recovery ............................................................................................................................... 45

10.1 Overview ......................................................................................................................................................................... 45
10.2 WSM Database ............................................................................................................................................................... 46
10.3 Built-in database failover support .............................................................................................................................. 46
10.4 WSM Server Software ................................................................................................................................................... 47
10.5 WSM server hardware and storage ............................................................................................................................48
10.6 Network infrastructure ................................................................................................................................................. 49
10.7 Disaster recovery ........................................................................................................................................................... 49
10.8 System Monitoring & Health Check .......................................................................................................................... 50
11 WSM Server Sizing ................................................................................................................................................................... 51
11.1
Overview ......................................................................................................................................................................... 51
11.2 Storage Requirements .................................................................................................................................................. 52

11.3 Shared Storage Support ............................................................................................................................................... 53
11.4 User Data and Settings ................................................................................................................................................. 54
12 Desktop and Server OS Virtualization .................................................................................................................................. 56
12.1 Overview ......................................................................................................................................................................... 56
12.2 Client Caching ............................................................................................................................................................... 56
12.3 Power Management ..................................................................................................................................................... 57
12.4 Microsoft License Enabling for Streamed Clients ................................................................................................... 57
12.5 Microsoft VHD File Format Support........................................................................................................................... 57
13 Application Virtualization ........................................................................................................................................................ 58
13.1 Overview ......................................................................................................................................................................... 58
13.2 OS Support for Application Virtualization ................................................................................................................. 59
14 Mobile Disconnected Mode................................................................................................................................................... 61
14.1 Overview ......................................................................................................................................................................... 61
14.2 Power Management ..................................................................................................................................................... 62
14.3 User data partition preservation ................................................................................................................................. 63
14.4 Mobile Disconnected mode and Linked Sites ......................................................................................................... 64
15 Multi-Platform Support (Golden Image) .............................................................................................................................. 65

15.1 Overview ......................................................................................................................................................................... 65
15.2 The Uniplat tool ............................................................................................................................................................. 65
15.3 Adding platforms support to existing Image ............................................................................................................ 66
16 Performance troubleshooting and OS Image optimization ............................................................................................68
16.1 Overview .........................................................................................................................................................................68
16.2 Measuring boot statistics .............................................................................................................................................68
16.3 Establishing a baseline ................................................................................................................................................. 69
16.4 Image Optimizations .................................................................................................................................................... 70
16.5 Freeing up disk space from old Windows Updates................................................................................................. 72
17 FAQ ............................................................................................................................................................................................. 73
18 Additional Information ............................................................................................................................................................84
Executive summary
This document delivers helpful information for planning a Wyse WSM solution covering the following
topics:
Overview of the WSM solution

Networking Services and System Security
Server Roles and Sizing
Sites and Content Distribution
High Availability and Disaster Recovery
Sizing Guidelines
Desktop and Application Virtualization
Mobile Disconnected Mode for offline devices
Multiple hardware platforms support
Image optimization and performance troubleshooting
Frequently asked questions
Audience
Solution Architects
Consultants
System Engineers
Affected Products
WSM 7.0.0
WSM 7.1.0
WSM 7.2.0
Examples
This document is using real life scenarios to help understanding the key factors for planning a Wyse
WSM solution.
Reference documents and resources
WSM Admin Guide

WSM Product Release Notes
Wyse WSM Reference Architecture and Configuration Guide
Wyse Online Community & Support Forums
New Features in WSM 7.0.0

WSM 7.0.0 is a major release of the WSM software suite.
The key objective of this release is to introduce this new features:
Application layering
Separately provision individual apps or groups of apps by policy/department to any physical or
virtual desktop.
- Layer applications onto individual or groups of physical or virtual endpoints
- Deliver these apps independently of OS images or previous application, delivery to any given
endpoint
Client Caching
Significantly enhances the WSM-delivered virtual desktop and application performance.
- Reduces server-side storage and network bandwidth requirements
- Improves performance
- Improves user experience

WSM 7.1.0 is a maintenance release of the WSM software suite.
New Features:
Application layering on Windows 8.1

Client caching on Windows 8.1
French Windows OS support
Support for both server platform and streamed client OS
Uniplat support for golden image management
Virtual application patching on streamed OS

WSM 7.2.0 is a maintenance release of the WSM software suite.
New Features:
10
WSM now supports Wyse vWorkspace license format in adition to the legacy Wyse format.
High Level Overview of the WSM Solution

WSM is a Desktop Virtualization solution that addresses the requirement for full PC functionality together
with the benefits of a centrally managed Cloud computing solution.
By virtualizing the entire operating system and applications, WSM enables endpoints to operate like a full
features Personal Computer, but without requiring any local storage. Providing the operating system and
applications independent of each other makes it easier for IT to backup, update, manage, maintain, and
support a multitude of desktops with minimal staff.
It is also particularly suited to use in education as it can meet the requirements for very diverse computer
use - which is typical in schools and colleges - while being very cost-effective.
How WSM works
WSM delivers operating system and applications, on-demand, to a Cloud Desktop or diskless PC or virtual
Machine. A Cloud Desktop is very similar to a Thin Client, but has no operating system stored locally.
In contrast to other Virtualization solutions, WSM runs the operating system and applications on the Cloud
Desktop, not the server. This means the software can interact with local display and peripheral hardware in
the same way as a PC does. There is no remote display protocol used.
Versatile operating system & application support
WSM supports Windows operating systems with full functionality. Multiple operating system images can be
maintained on the server enabling desktops to be reconfigured by just restarting them. This simplifies the
support of workplaces with different requirements or hardware specifications.
Application functionality is the same as on a PC. Applications can be installed into the operating system
image or virtualized separately. Application virtualization enables application access to be controlled
independently of the operating system. This is particularly useful when a limited number of application
licenses are available, or if applications should only be available to a specific group of users.
Multimedia support
By running applications locally, WSM is able to run multimedia applications in the same way as a PC. Both
streamed content (for example YouTube) and fast moving local graphics (for example Google Earth) will
be displayed correctly. If significant multimedia use is required, Wyse quad-core Cloud Desktops or Dell
Optiplex diskless desktops are recommended.
Peripheral support
Local support of peripherals is the same as with PCs. USB, serial, parallel or PC card connected devices
can be used.
11
User customization support

WSM can be operated in persistent or volatile modes. In persistent mode, user changes to operating
system and application settings are stored and applied to subsequent sessions by the same user. In
volatile mode these changes are discarded so the user session will always be consistent. In either mode,
the reliability of the session is maintained avoiding disruption to teaching due to miss-configured PCs.
Centralized management
WSM uses a web-based console to provide centralized management of the environment. Integration with
Active Directory enables computer account management and application access to be linked to existing
groups and their users.
Resilient Multi-site Architecture
Cloud Desktops and diskless PCs connect to a WSM server on their local LAN. For multi-site installations,
WSM enables centralized management by replicating operating system images and application packages
across a WAN connection to WSM servers on remote sites. In the event the WAN connection is lost, the
remote site can continue to operate indefinitely using the last operating system images and application
packages that were received. When the WAN connection is restored, any new updates will be transferred
to synchronize the main and remote sites.
High availability
If more than one WSM server is deployed on a site, the servers will provide a highly available system in the
event of one server failing. Users disconnected from the failed server are connected to other available
servers when they are restarted.
Client hardware
Dell offers a wide range of Cloud Desktops designed for use with WSM.
The Wyse D00D uses an AMD G-T48E Dual core processor running at a speed of 1,4GHz and comes with
an AMD Radeon HD 6250 graphics chip. The Quad core version D00Q comes with an AMD G Series
quad-core 1.5GHz SoC with integrated Radeon 8330 graphics processor, delivering high speed and
power. This enables D class units to be used for Windows 7 and 8, rich multimedia content and
Applications like Google Earth.
The Wyse Z-Class delivers the highest performance. The Z00D is powered by a Dual core AMD G-T56N
1.65 GHz Processor and AMD Radeon HD 6320 Graphics card. The Z00Q with its AMD G Series quadcore 2GHz SoC and integrated Radeon 8400 graphics processor delivers ultra-high speed and power,
making it the ideal client for HD Multimedia content, video-editing, CADCAM and graphics editing.
Wyse Xm mobile Cloud Desktops are available with a Solid State Hard Disk, so users can provision their
device with a copy of the WSM Image to work when being disconnected from the corporate network. The
X00M features are wireless a/b/g/n, Bluetooth and a 14 display with WXGA 1366 x 768 resolution, and
available with the same processor, graphics chip and Network adapter like the Z00D or Z00Q.
Dell OptiPlex and other diskless PCs can be used with WSM too, either to re-use existing hardware, or if
specialist, workstation-class functionality and performance is required.
12
Server hardware
WSM can be installed on server-class hardware, including virtual server environments. The installation
requirements are listed in the WSM Admin Guide.
Integration with other Virtualization solutions
WSM provides a centrally managed, highly reliable computing platform. This can be integrated with
server-based solutions, hosted virtual desktops, or Application virtualization by installing the client
software into the operating system image or deliver it as a separate package.
WSM main features include
Integrated Desktop and Application Virtualization from the network
- Supports the latest Microsoft Desktop and Server Operating Systems
- Provisions the complete operating environment
- Fewer images to manage
Runs like a PC
- 100% application, peripheral and multimedia support
- Rich multimedia supports for Flash, QuickTime and Windows Media files
Security
- No local storage
- Cloud Desktops are useless if stolen
- Used by many government agencies globally
Administration
- Click device recovery and clean-up
- Centralized OS, application and computer management
- Web-based administration console
- Active Directory integration
Scalability
- Distributed architecture with multiple server support
- Built-in Server High Availability
- Consumes significantly less server resources compared to other virtualization solutions
13
Setting up a WSM environment is easy!

1.
2.
3.
4.
5.
6.
Figure 1
14
Install the WSM Server software

Install the OS and the WSM Client software on a Reference Device
Capture an OS Image from the Reference Device
Register the OS Image in the WSM console
Add clients and assign them to a Device Group so they can stream the OS Image
If Application virtualization will be used, package and then register the Application Images in the
WSM console and assign it to (Active Directory) User Groups.
WSM Concept
WSM Licensing
WSM is licensed per client, and all advanced features like Application Virtualization, High Availability and
Site Architecture etc. are built in and available with no additional cost. Because licensing information is
stored in the WSM database, WSM can be installed on just one or dozens of servers without importing
licenses on each server.
The WSM Suite includes a 90 day Evaluation license. During this period, customers can test the
functionality of the product with the exception to configure the system for a multi-site environment. At
any time, it is possible to add a full Evaluation license (provided by Dell) or full production license to the
system to enable the system to support Linked Sites.
The Evaluation version (i.e. WSMSuite7.2.0-Evaluation.exe) cannot be used to upgrade existing Versions of
WSM. However, if a full production license is entered you can continue to use the installation after your
trial period is over so there is no need for reinstalling WSM for moving a PoC to Production. The
Production version of (i.e. WSMSuite7.2.0.exe) is available for customers with active Maintenance from the
Dell Wyse self-service portal.
WSM understands two types of WSM license files: streamed Desktop OS and streamed Server OS. The
WSM system knows what edition of Windows is inside a vDisk and will only stream it to clients (Desktops
or Servers) if a valid license for this OS type is present in the WSM system.
vWorkspace Premier Edition licenses support Desktop and Server OS with a single license and does not
distinguish between Wyse Cloud Desktops and Non-Wyse devices like legacy Wyse WSM licenses do.
This feature requires WSM 7.2.0 or higher.
Microsoft Licensing
WSM on a Cloud Desktop, Thin Client or diskless PC requires the same Microsoft License that is
needed for Desktop Virtualization solutions like VMware Horizon or Citrix XEN Desktop.
Clients that do not qualify for Windows Client Software must have a new license called Windows
Virtual Desktop Access (Windows VDA). Dell offers its Cloud Desktop with a Certificate of
Authenticity (COA), which entitles the device to be put under Software Assurance. Diskless PC
COA is a onetime fee include in the price of a Dell Wyse Cloud Desktop with COA, whereas VDA
is a yearly subscription. This makes the Diskless PC COA the recommended option when
purchasing Dell Wyse Cloud Desktops.
Windows 7 and later requires Volume Licensing (VL) and requires a Microsoft KMS (Key Management
Server) to activate.
15
Network, Infrastructure Services and System Security
5.1
Network Topology
WSM relies on a high-performance network connection between the individual end-user client and the
assigned WSM server. To ensure proper performance when working on a streamed client, the
recommended speed should be 1Gbit/s, but not be below 100 Mbit/s. For the connection between a
single WSM server and the Network Core Switch, a Gigabit Ethernet link is recommended. Because a WSM
server is using a single logical Network Interface for all of its communications, NIC Teaming can be
considered to further improve the throughput of the server/switch connection. CAT 6 cabling can also
give a performance boost of up to 30% over CAT 5.
Since all data is transferred over the network, each network segment must have enough free capacity to
deliver the OS and Applications to the clients. The amount of data that is transferred between a client and
the WSM server it has booted from highly depends on how the individual users are using their system. A
typical task worker, using a set of common business and office productivity applications, will not stress
the network as much as a developer, who typically runs many disk demanding applications at the same
time. The task worker, for example, may access the required bits and bytes to execute a certain application
only once a day (resulting in very little WSM related network traffic afterwards), while a developer maybe
frequently uses an application that creates large temporary files several times a day (resulting in high
network consumption).
WSM 7 can make use of a local disk in a Cloud Desktop for Client Caching, which can greatly help
reducing network traffic and accelerate client boot up time.
An audit of the existing network is recommended to determine its capabilities to support WSM.
Furthermore, a pilot can provide accurate data about the network consumption per User-Profile on a
given work day.
16
Figure 2
WSM Architecture
Example 1
Within a single building, all clients are connected to the LAN with at least 1Gbit/s. The clients are
distributed over five floors. The total number is 450, but only 350 clients are used simultaneously. Of the
total clients, 150 users are used by Application Developers which transfer large amounts of data over the
network. All WSM server are located in a Datacenter within the same building.
In this scenario, Wyse would recommend a Multi-Gigabit connection from each WSM server to the core
switches, and that the floor switches have Gigabit uplink to the core switch. Network Segmentation can be
considered for the 150 developer clients, so they do not saturate the network and leave insufficient
bandwidth for other users on their floor.
Example 2
To continue Example 1, if there is an additional branch office with 15 clients, and the branch is connected
to the organization Headquarters with a 4 Mbit/s line, a WSM Edge server must be placed in the branch
location. These clients will then receive the OS and Application Images from the WSM Edge server in their
local network. As 15 clients will most likely not saturate the network segment, no special configuration is
required.
17
5.2
Network Infrastructure and Services

Network Communication Ports
The communication between WSM servers depends on the configuration of the system. By default the
content distribution between the Core and the Edge servers is TCP/IP based, whereas between sites it can
be either TCP/IP or http(s) based.
The following list of default ports is an excerpt from the WSM Admin Guide:
OS and Application Authentication Service (Default Port: 6910)

OS Streaming Service (Default Port: 6911)
Application Virtualization (Default Port: 6931-6947)
Content Distribution Service (Default Port: 20248)
Multicast Boot Service (Default Port: 10703)
DHCP Proxy Service (Default Port: 67)
Administration Service (Default Port: 8080)
SQL Port (Default Port: 1433)
Content Distribution Service Client Port 20248
NetBIOS Name Service 137
TFTP Service 69
WSM uses 4000 as destination port when sending broadcast message for wake-on-LAN.
Internet Protocol (IP) Support
WSM supports the widely deployed IPv4 version. IPv4 is still the most widely used Internet Layer protocol
and IPv6 deployment is still in its beginnings. Today WSM does not support being addressed as IPV6
(meaning WSM Server installed on a system addressed using IPv6), nor OS and Application Images which
use IPv6 addressing.
Resiliency to Network Issues
With multiple enhancements in communication between client, server and the inter-processes on the
server, WSM is resilient to network glitches, packet losses, and slowness.
End users will automatically experience these enhancements with continued desktop and application
availability during such network issues. For example, their desktop just freezes if the connection to the
WSM server is interrupted, but they are able to continue to work once the server is available again.
18
Figure 3
WSM Network Communication Flow
DHCP
While DHCP is required for clients within a WSM environment, WSM servers should be configured with
static IP addresses.
There are no special options required on the DHCP Server, unless WSM is installed on a DHCP Server
which is not recommended anyway. In such scenario, the WSM DHCP Proxy service must be altered to
listen on port 4011 instead of port 67.
DNS
A functional DNS system is required for proper network communication.
A DNS Record CDServer can be used to auto-discover a WSM Login Server for clients using Non-PXE boot
option.
19
5.3
PXE Boot
Every WSM server runs a DHCP Proxy service, which filters the incoming PXE requests on the network. By
default, only requests from MAC addresses currently present in the WSM database will be answered and
got sent the DHCP Option Tags required for downloading the WSM boot loader. The TFTP service running
on the WSM server will then sent the WSM bootstrap on request, so the client can initiate streaming the
assigned operating system image.
If applicable, the DHCP Proxy can also be set to a so called Device Discovery mode where it accepts all
incoming DHCP requests and adds new clients automatically to the WSM database. This can be either
performed from a clients console at its first startup or being fully automated by inheriting settings from a
Device Template. The later may be an ideal approach for environments with no IT personal, as new clients
can be brought online without any manual configuration required.
Figure 4
20
PXE Boot Process
5.4
Non-PXE Boot
PXE is the preferred method to distribute the WSM bootstrap to clients. However, if the network does not
support PXE, local Non-PXE bootstrap can be used to initiate OS Streaming. The size of the WSM
bootstrap file is less than 1 MB and must be stored locally on the device, for example on a local disk, flash
module, USB key or floppy disk. Furthermore the BIOS must be able to boot from the storage device
where the Non-PXE bootstrap file is installed.
Selected Dell Cloud Desktops* have built-in BIOS support to perform a Non-PXE Boot. The BIOS settings
specific to WSM can be set from the WSM Admin console for the supported models.
Non-PXE is the default for provisioned clients working in Mobile Disconnected Mode, and these will only
use PXE boot to provision the image or patches to the local disk.
PXE Version 2.0 and above is required on the device side, as the WSM Non-PXE bootstrap needs a PXEcapable NIC to use UNDI for driverless NIC configuration.
Figure 5
Non-PXE Boot Process
Dell Wyse Cloud Desktop is a feature that allows supported Dell Cloud Desktops, OptiPlex and Precision
desktop systems to directly boot to a WSM environment from the BIOS without the use of PXE.
21
Multicast
WSM supports multicast to deliver the common portion of an OS Image to clients with the same virtual
disk at startup. This feature reduces network traffic significantly when multiple clients boot up
simultaneously up to the point where the user logs in. After this point, multicast becomes useless as each
user session will access data from the image on demand.
Multicast is an OS Image setting, and it is only available for OS Images that are set to Volatile Cache
(Shared Mode).
All routers/switches/firewalls along the path between WSM server(s) and client(s) must be configured to
allow WSM multicast traffic to be forwarded. Consult the routers/switches/firewalls manual on
configuration specific details.
Jumbo Frame Support
WSM supports jumbo frames to enhance the overall streaming performance of the system. WSM servers
and clients will automatically detect and use jumbo frames once it is enabled on the base operating
system of the WSM server and the virtual desktop image. To obtain the full performance benefit, all
networking equipment in the client-to-server path (routers, switches, and so on) must also support jumbo
frames. See the Wyse Jumbo Frames Knowledge Base article for details on how to setup Jumbo Frames
with WSM.
5.5
Infrastructure Services
Active Directory Integration for OS and Application Virtualization
Active Directory integration is not a requirement for WSM, but it provides a very flexible and convenient
way to centrally manage a large number of clients, users and groups. If Active Directory is not in place,
WSM can be configured to work in a standalone mode where users and groups are created and
maintained within the WSM system rather than being linked from AD.
Active Directory integration also helps streamlining the application assignment for the individual user by
implementing a convenient single-sign-on authentication mechanism. And since Active Directory Groups
are only used for Application virtualization, they do not affect OS virtualization in any way (as this is based
on a per-device level).
Furthermore, Active Directory computer account management will be maintained by WSM too, providing
an additional reduction in administration. When a device is created in the WSM console, WSM creates a
Computer Account with the same name in Active Directory. WSM stores a clients SID and Hostname in its
database and applies it at boot time, ensuring every client behaves like a unique computer (even when
sharing a common OS Image).
If a Linked Site is connected to Headquarters via a slow WAN link or the connection to a Domain
Controller cannot be established, the update of the Computer Account password may slow down or even
stall the boot of clients in the site. In this scenario the system can be configured to not update the
computer account password at boot time, but this procedure will only be successful if there is not a GPO
22
in place that requires machines to change their machine account passwords every X days. If this type of
GPO is in place, please create a new OU for the WSM clients and do not apply that GPO to these clients.
Database
WSM utilizes a Microsoft SQL Server Database to help facilitate:
Store configuration specific data
Device to OS Image assignment
User account and group membership management (in both Active Directory integration and
standalone mode)
Application Image to User Group assignment
The database can be installed on any server, regardless if the server is the WSM Core server or a dedicated
database server already hosting other databases.
In most cases, a SQL Server instance is installed on the same machine as the WSM Core server. WSM
provides a convenient and automatic setup of SQL Server Express which is included in the WSM
installation package.
If there is already a database server running, or for special cases like a large production environment
where high availability is a concern, it is recommended that the WSM database is installed on a server that
is separate from the WSM Core server. This eliminates the Core server being a single point of failure.
All WSM servers configured for the same site will authenticate and communicate directly with the WSM
database on the designated SQL port using the configured security credentials; this communication is not
controlled by the WSM Core server. There needs to be at least a bandwidth of 128kbps from a WSM server
to the SQL Server, as high latencies may cause SQL queries to time out.
If the connection to the WSM database is lost:
Clients that are already up and running will continue to work without interruption.
Other clients cannot be booted, as the WSM system cannot determine the OS Image assigned to
them. This issue will be addressed in a future version of the software.
New OS Images, Application Images, or devices cannot be added to the WSM system.
The SQL server (or the named instance used for the WSM database) must run in mixed mode, and TCP/IP
and Named Pipes protocols must be enabled in the SQL servers network settings.
If a Non US-English Version of SQL Server is used the default language for the WSM SQL account (default
is wsmdb) must be set to English.
WSM is using a XML file to transfer key configuration data and settings from Headquarters to the Linked
Sites. The benefit is a vastly easier installation, configuration, management and maintenance of the
solution. At the same time this approach lowers the cost to implement WSM in a large environment, as it
eliminates the need for a full SQL Server and associated Cals because no full SQL Database Replication is
done.
23
5.6
System Security Credentials

To keep the system secure, WSM is using various credentials:
WSM database: The database requires a username and password for executing SQL queries. Each
WSM server requires this password to access the database. This information is stored encrypted in
the Windows registry after installation. The SQL user is created during the installation of the WSM
Core server.
If WSM is configured for Active Directory integration, its using a domain user account to perform
simple queries to retrieve user and group information. WSM supports Kerberos to secure the
password exchange between the WSM server and the domain controller.
On WS2008R2, the users account properties must be configured for Use DES encryption types to enable
Kerberos password encryption:
Figure 6
24
DES option required for Kerberos Authentication
WSM services: All WSM services are running with local system privileges, but with a few exceptions:
- Unless all Domain Controllers and WSM servers are configured for SSL communication, the
WSM OS Authentication service must run with the credentials of an Active Directory user with
privileges to manage computer accounts (like members of the built in Account Operators
Group). This user must also be a member of the WSM servers local Administrator Group.
Figure 7
WSM Service for AD Computer Account Management
If the WSM repository (StreamingDir) is located on a Network Share, the WSM Administration
Web Service, Monitor and OS Streaming Service must run with the credentials of a user which
has appropriate permissions to access the network share.
- WSM includes a so call Service Credentials feature which allows specifying an AD User in the
WSM Admin Console which will be used to run the WSM Services. The user account can be
specified for the Local Site, Site Groups or globally for all sites. This approach simplifies the
implementation of above mentioned use cases a lot and should be the preferred method as
this ensures all servers will have the same service configuration.
Separate users and roles for Linked Site vs. Headquarters:
- The user SiteAdmin and SiteOperator can login to remote sites only, whereas the (HQ) Admin
can login to any site.
- The users Operator, Dispatcher and SiteOperator can only logon to the WSM Monitor Console
(WSM Web)
- The SiteAdmin, Operator, Dispatcher and SiteOperator passwords can be locked down and
changed from HQ for all sites.
- The above mentioned usernames are hardcoded in the system and cannot be changed.
- Active Directory Integration for WSM Admin & Monitor Console: WSM allows you to assign
WSM built-in roles (Admin, SiteAdmin etc.) to user accounts which have been imported from
Active Directory. With this new feature any AD user account with appropriate role assignment
can be used to login to WSM Admin & Monitor Console.
-
The user roles and their permissions within the WSM Admin and Web console are covered in depth in the
WSM Admin Guide, Chapter WSM Web.
25
Server Roles and Group Concept
6.1
Server Roles
The WSM Server software can be installed on multiple machines to provide redundancy and load
balancing capabilities. A WSM site can have only one Core server, but can have any number of Edge
servers installed.
The first machine where WSM Server is installed automatically assumes the role of the so called Core
server. The Core server is the central point of administration and maintenance, and has a user friendly
Web-based console to provide easy access to the WSM system from any endpoint running a web browser.
Figure 8
26
WSM Server Roles
The Core server

is the central repository for OS and Application Images
Runs the Content Distribution Service to process and initiate distribution of images to other WSM
servers on assignment, based on administrator specified schedules.
Like every other WSM server runs the
- WSM Administration Web service
- WSM Monitor console
- TFTP and DHCP Proxy services
- OS and Application Authentication services
- OS and Application Virtualization services
- Services to interact with Active Directory
Additional Edge server can be installed to
Provide dynamic load balancing within a user created Server Group
Ensure continuous deliver images to clients in case of a Core server failure
Support a distributed network with geographical dispersed sites
Every Edge server holds a copy of the OS Image and any Application Images available on the WSM Core
server. When a client boots from a WSM server, it will by default automatically write back data to a write
cache file on the server it has booted from. There is a 1:1 relationship between a client and its OS Image
write cache.
6.2
Server Groups
WSM Server Groups are used to group servers into logical entities to streamline management of servers
with the same configuration settings. This feature allows the assignment of OS Images, Application Images
and Device Groups to all servers in a group instead of individually assign these to each WSM server. In
addition, all servers in a group automatically function in a load balanced mode, providing high availability
and scalability.
The Default Server Group is automatically created during WSM server installation. All WSM server that
have not been specifically assigned to other user-created groups are automatically placed in the Default
Server Group. Every WSM server within the Default Group automatically shares the same OS Image and
Application Image assignments.
A WSM administrator can move servers between the Default Group and other user-created Server Groups
as the situation requires by simply assigning a server to a different group. When a server is added to a usercreated group, it adopts the OS Image and Application Image assignments of the user-created Server
Group to which it was assigned to. Servers in a user-created Server Group will automatically work in a load
balanced mode.
27
6.3
Device Groups
Device Groups allow easy grouping and management of devices with similar attributes. WSM provides two
types of Device Groups: Default and user-created.
The Default Device Group is created automatically during WSM Server installation and stores devices until,
if necessary, they are assigned to a user-created Device Group. Each client within the Default Group can
have individual settings and up to four OS Images assigned to it. On a per device basis, the administrator
can set the Boot Selection Mode to First Disk, First Available (if the same OS Image is available on multiple
servers), or User Select (to allow the user to decide at boot time which OS Image to load).
User-created Device Groups share Connection Type, Device Class, Server Group, and OS Image
properties and are always assigned to a single Server Group. The default boot mode should be set to Load
Balanced, because in this mode the system decides which server in a Server Group is least loaded and
assigns the client to work from this server for this session. Other selectable modes are again First Disk, First
Available or User Select if there is more than one OS Image assigned to the Device Group.
Recurring Schedule for device commands
WSM provides the ability to schedule recurring device commands such as Reboot, Shutdown or Wake on
LAN. The commands can be scheduled hourly, daily, weekly or at monthly intervals and are available for
Device Groups at the local site level.
WSM includes a so called WSM Monitor Service feature to enable administrators at Headquarters Site to
send commands such as shutdown, restart or Wake-on-LAN to devices on Linked Sites even if this is
behind NAT.
6.4
Adding Devices
There are different ways to add clients to the WSM system:
Adding them manually from the WSM Admin console*
Import clients from a text file and assigning them to a Device Template
Configure the WSM DHCP Proxy to enable "Enable Device Discovery" and add new clients
automatically based on Device Templates
Configure the WSM DHCP Proxy to enable "Enable Device Discovery" but add new clients manually
from their console at the first boot. (there must be no Device Template present in the system to get
the add client screen)
* If you have WSM configured for Active Directory, the default OU is specified on the Active Directory
Domain Details page to let WSM know where to create computer accounts for clients added to the
system
28
Site Based Architecture
7.1
Overview
WSM Sites are based on a concept whereby geographically dispersed locations can run WSM
independently, each with its own database instance, yet managed from a central location. In such setup,
each WSM Site is a fully-capable WSM installation, including a Core and optional Edge servers using a local
WSM database. This feature allows remote offices or sites to continue normal operations even if network
connectivity to Headquarters is interrupted. Although each site is a full WSM installation, all management
and administration is typically performed from a central point - Headquarters.
Some definitions:
Site: A local group of a Core and optional Edge servers that share a local database and works
independently from other sites. The Edge servers in a site only know about their Core server and
database, and their setup and management is the same regardless what type the site is configured
for.
There are three types of sites:
Standalone Site: a site which is not linked to or managed by any other site. For example, a WSM
installation with a single database and Core/Edge servers would be considered a Standalone Site in
WSM terms, even if the servers were physically located at geographically dispersed locations.
Headquarters Site: A special site which is the focal point of Administration to control and manage
Linked Sites. All administration activities, including OS and Application image assignment and
deployment and Server and Device management are performed from this location.
Linked Site: A site that is linked to or managed by the Headquarters site. Administration activities
for servers, clients and Images at these sites are performed from the WSM Core server at the
Headquarters site. Basically, a Linked Site is like a Standalone Site, but the Linked Site Core server
has a local database and periodically reads configuration data from the Headquarters Core server
and sends asset and device status reports back to it. If the connection to HQ is down for a longer
period of time, configuration and image patch management can also be applied using XML files.
A WSM Site is not directly related to a physical location nor bounded by physical boundaries (such as a city
or district). Administrators have complete flexibility in choosing how to organize their sites. For example, a
WSM Site can set up for each city, for each building in a campus, or, for a single floor in a building or even
set up multiple sites in a single room.
29
Figure 9
Linked Site Concept
The WSM Site Architecture requires a SQL database installed at each Linked Site in addition to the
Headquarters Site. The supported database versions are listed in the Product Release Notes and WSM
Admin Guide.
30
7.2
Site Groups
Grouping sites into Site Groups allows easier organization when managing a large WSM deployment.
Furthermore, in a Linked Site scenario the Administrator can schedule the content distribution from
Headquarters to the Linked Site based on the Site Group level.
The Headquarters Site will always remain in the Default Site Group, and cannot be assigned to a nondefault group.
7.3
Site Templates
A Linked Site gets key configuration and image version information by polling the WSM services at
Headquarters at periodic intervals. The database at Headquarters is not directly accessed by the Linked Site
servers, nor is it fully replicated.
The configuration information for Linked Sites is defined via Site Templates. New sites inherit their
configuration information from a template when being set up, and update their configuration whenever
the template is updated. This enables a cookie-cutter approach to creating, configuring and managing
large numbers of remote sites. Further, the installation, configuration, management and maintenance
processes (especially at the HQ site) are vastly simplified, as a result of eliminating database replication.
With this enhanced site based architecture, WSM can balance between central deployment/management
and resiliency of local execution. Instead of configuring every single site individually, the administrator just
manages the Site Template and the configuration changes are synchronized automatically when the Core
server in the Linked Site contacts the HQ Core server at the next scheduled interval.
Each Site Template must have one or more Server Group, Device Group and OS Image assigned and
requires a unique Device Template. These items must be created at Headquarters level and will act as
placeholders but will never show any entries or real time statistics from a Linked Site. Within a Linked Site,
the system will create these items based on the Site Template placeholders.
When a new Linked Site is to be installed, this is set up as a Standalone Site first and gets converted to a
Linked Site by tying it to a Site Template. The license information is copied from Headquarters to a Linked
Site during the first sync up after linking and gets updated every time a new license is entered at
Headquarters (this does not require publishing the Site Template at the HQ level).
SSL certificates are not copied from Headquarters. Thus if SSL is used for communications with
Headquarters, the certificate must be imported to each site. Changes can be made to the Linked Site, but
entries that do not exist in the Site Template will be deleted from the site.
The system setting Allow Template Change can be used to protect Linked Sites from accidental template
changes. If that checkbox is checked, the template changes are propagated to the site. If that box is
unchecked, the changes to a template are not applied at a site.
A Site Template will be available to a Linked Site only after it is published at Headquarters. Previous
versions of WSM generated the Site Template XML every time it was requested by a Linked Site. This could
31
let to a performance issues, but was also susceptible to damage caused by user errors. Several versions of
the Site Template may exist at HQ, but only the latest one published is used by the sites. The administrator
can easily revert back to the last version used if required, providing control and resilience to user error.
WSM provides flexibility to the level of control that can be imposed at HQ versus the local site. During
deployment planning, Administrator can determine the level of control within a Linked Site. These settings
are global and will apply to all existing and any new sites for this WSM installation.
Template based: Complete control from HQ, no flexibility at a remote site. This option requires a
fully configured Site Template at the HQ Level.
Allow multiple Server/Device Groups per Site Template: Allows the WSM administrator to assign
multiple Server and Device Groups to a Site Template, and the remote site administrator can
manage the assignment of individual servers and devices to the appropriate groups as needed. This
information is preserved across template syncs. Any new groups that are created locally will be
deleted during the next template sync. This option requires a fully configured Site Template at the
HQ Level.
Preserve Linked Site Local Data: Allows a Linked Site administrator to make changes at the Linked
Site level that will not be deleted upon Site Template synchronization. This option allows the Linked
Site to get its configuration from the Site Template but still have individual settings not determined
by the Site Template, for example additional Device Templates or Device Groups that should only
exist in this site. This option requires a fully configured Site Template at the HQ Level.
Locally managed sites: Allows full flexibility at remote site. Administrator can also create OS and
Application patches at remote sites, as if it were a Standalone Site. These patches can also be
distributed from the HQ Core server to other sites if the HQ Administrator wants to rollout such
patch to other Linked Sites too. If this option is selected, then the option Preserve Linked Site Local
Data is automatically selected too. A Site Template is required for this option, but it can be empty.
If the Site Template is not empty, then its configuration is applied to the Locally Managed site.
Each Linked Site must have a site code with a maximum of five letters. This code is prefixed to the Device
Template name before a client is created at a site when utilizing the PXE Auto Device Discovery
mechanism. This way it is ensured that every client is getting a unique name across the enterprise. For
example, a new client discovered in a Linked Site with a Site Code of RO and an assigned Site Template
named LS will get the name RO-LS_1. The name of a client is also becoming its computer name, but you
can rename any existing client later. Another option is to add clients in advance: either manually or by
importing them from a text file so a proper hostname is in place prior to the first startup.
WSM provides an enhanced Overview/Dashboard page that shows
the site currently being logged on to
at the Headquarters site, the aggregated number of devices/servers and license count/remaining
number of licenses for the entire WSM installation
Consolidated views of all remote servers, services, devices and image/patch deployment status are
available on the WSM HQ Core server Admin and Web Console.
32
Here is a brief list of actions a global administration can take from the Headquarter:
Adding a new OS to some / all the sites from the central location
Patching an existing OS in some / all the sites from the central location
Adding a new application to some / all the sites from the central location
Patching an existing application in some / all of the sites from the central location
Creating / editing user and Device Groups
Assigning OS / applications to device / user groups
When a site is converted from Standalone to a Linked Site:

All servers will be automatically placed in the named Server Group. If there are multiple Server
Groups specified for the Site Template, the local site administrator must assign the server to the
groups manually.
All clients are moved to the named Device Group, unless there are multiple Device Groups
specified for the Site Template. Then again the local site administrator must assign the devices
accordingly.
Clients get the OS image(s) and settings assigned to that Device Group
Pre-existing Server and Device Groups are deleted (unless they have the same name as whats in
the template)
Changes can be made to the Linked Site, but entries that do not exist in the Site Template will be
deleted from the site (if the HQ Administrator does not allow such via the global site configuration).
If new Device Groups or Server Groups are manually added at remote site, they are automatically
deleted on the next sync up with the Site Template (if the HQ Administrator does not allow this via
the global site configuration).
7.4
Secure Communications for Linked Sites

Sites can be configured to access Headquarters using HTTPS. The Headquarters Core server can be
configured with a certificate from a well-known CA, or a self-signed certificate. As with any application, in
the case of self-signed certificates, the CA certificate must be imported at remote Sites.
Communication from Linked Sites to Headquarters also requires authentication. The password must be
configured at Headquarters and also specified at each Linked Site when linking it to Headquarters.
The steps to configure WSM for HTTPs will be explained in a future release of the WSM Admin Guide.
33
7.5
Site Version
If all Linked Sites and Headquarters have been upgraded to WSM 7, it is recommended that the OS Image
Version is set to version 7 to get all the benefits of the latest version. Benefits include faster patch and
distribution of OS Image. If some Linked Sites still have an older version of WSM installed, a version must
be selected that is compatible with the oldest version WSM Installed. Older version of WSM will not be able
to stream/patch/distribute OS Image with newer header version.
Site Version High/Low info allows OSMVDiskImage.exe to determine what vDisk version it should create by
default. If at least one server is running an older version of WSM (Version 4.1 for example),
OSMVDiskImage.exe will create a vDisk of version 4 so that the resulting image can be distributed among
all servers. Otherwise it will create a vDisk of version 7 by default. The admin can also manually select
another version but needs to confirm a warning message before proceeding.
WSM Admin Service keeps track of the Site Version of all servers in the registry. OSMVDiskImage.exe
queries this info from the WSM Core server talking to and displays it on screen. If it displays N/A, it likely
means the Server is < 5.x and does not respond to clients version query. In this case OSMVDiskImage.exe
assumes it is talking to an old server and create version 4 vDisk by default.
Once all WSM server in all sites have been to WSM, you may update the vDisk version from by running
VDiskImageCreation.exe tool while the vDisk is not being streamed. On WSM 5 and higher, you can no
longer set an image to private mode once it is registered. In this case, VDiskImageCreation.exe will make a
copy of the original image, and then change the version of the vDisk copy. This new vDisk (the copy) can
be registered in the WSM Admin Console afterwards. Once a vDisk is upgraded to version 5 or above (via
VDiskImageCreation.exe) it can no longer be distributed or patched from a WSM 4.x server.
Please note that a vDisk version is different than the WSM Client version installed on that image. A vDisk
of version 6 can have an old WSM Client (e.g. 5.1.0) installed. Likewise, a version 4 vDisk can have a new
WSM Client 6.2.0 installed. The vDisk version merely describes whats in the vDisk header, not whats
contained (e.g. what OS, which WSM Client version) within the image. When you boot a version 4 vDisk
which contains WSM client 4.0.1 to a device and then run WSMClient.exe to upgrade the WSM client to
5.0.1, the vDisk version stays at 4. Hence it is still streamable/patchable and distributable to all server
versions.
34
Example 1
Typically, 500 clients in a single location would require a minimum of four WSM server, assuming that
every server can handle up to 150 clients simultaneously. It is recommended having at least one extra
server for high availability situations, resulting in a total of five servers for this example.
The first server installed will assume the role of the WSM Core server, while other servers installed would
be configured as Edge server. All servers could be grouped into a single Server Group, or multiple Server
Groups could be created if required. Note that the total number of servers needed depends on the load of
the servers and the network topology. But as WSM is licensed per device and not per server, additional
servers can be added without additional licensing cost.
Example 2
For a branch office with 15 clients, a small server or powerful workstation can be used to run WSM Server.
However, to ensure continuous operation if this machine is down, a second one should be considered to
avoid a SPOF. If there are two servers in the same location, it is common practice to assign them to the
same Server Group to provide automatic load balancing and failover. To simplify the administration, clients
within the office should be grouped into a user-created Device Group which is assigned to the Server
Group for this branch office.
Example 3
In a multi-branch scenario, where remote offices are connected over the WAN or dial-up lines, the aim is
to design an architecture that is resilient against connectivity outages. The WSM site concept can be used
to achieve this goal.
In each branch, WSM would be set up as a Linked Site, consisting of a Core server with a local database
and optional Edge servers. If the WAN is down, operation in the remote office is ensured because the
servers always use their local database. Once connectivity to Headquarters is re-established, the site
configuration will be updated by syncing with the Site Template hosted on the HQ Core server.
35
OS Image Creation and Patching

When creating a new OS Image from the so called Reference Device, the entire content of the system
partition is copied to an image file hosted on the (HQ) Core server.
The term Reference Device is used in WSM for
Any device that has an Operating system plus the WSM Client software installed on its local disk to
capture an OS Image from.
Any device flagged in the WSM console as Reference Device used for the Patch process. This role
can be assigned on purpose by assigning a device to the Reference Device Group, and is not tied to
the device the OS Image has initially been created from.
Creating an OS image is done using the Virtual Disk Image Creation tool (OSMVDISK.EXE), which executes
the following tasks:
Create a virtual disk file (vDisk) on the (HQ) Core server

Map the vDisk file so it is accessible from the Reference Device
Partition and format the vDisk like the system partition on the Reference Device
Copy the registry and all files from the system partition to the vDisk
Adjust the boot.ini file of the vDisk if necessary
Un-map the vDisk
After creating an OS Image, it must be registered at the WSM Admin console of the (HQ) Core server. To
stream it back to clients, it must be assigned to one or more Server Groups and Device Groups.
36
Image Creation Process

During OS Image creation, the Reference Device is automatically added to Reference Device Group on the
Core server and becomes the designated Reference Device for this new OS Image. To verify the OS Image
has been captured successfully it will be streamed to the Reference Device as part of the OS Image
creation process. Only if this step has been finished without problems the new OS Image should be
registered in the WSM console.
The image capture process provides error messages and information through all of the capture process
procedures (from checking for Microsoft pre-requisite hotfixes to hand holding the user throughout the
process).
Figure 10 OS Image creation
37
Multiple Partition Support

WSM supports multiple partitions within a single vDisk. Each partition will have its own cache mode and
associated write cache file.
The following features are available:
Extending the size of an existing virtual disk.
Preserving user settings and data while patching the OS Image by redirecting the user profile
directory to a separate partition.
Moving the windows paging file from the system partition to a separate partition. This will result in
smaller OS Image patch file, as writes to the paging file will not be considered as part of the
patching process, which is described later in this document.
The steps to create a new, multi-partition OS Image are described in the WSM Admin Guide.
Older Single-Partition OS Images can be upgraded to be Multi-Partition capable. Furthermore the size of
a vDisk can be extended if the initial size of the OS Image becomes too small. The system partition of a
multi-partition disk cannot be extended.
8.1
Write cache Modes

To share an OS Image between multiple clients at runtime, write accesses must be redirected as otherwise
this would lead to disk file corruption and unexpected behavior. Thus, WSM allows writing to the OS Image
only when it is accessed from a single client during OS Image capturing process, and the system will block
other requests to write to the OS Image while being altered.
For normal operation, the OS Image must be set to either Volatile or Persistent Cache (Shared Mode). In
Volatile mode all changes from a session are discarded at the next reboot which keeps the system clean,
slim and uniform. Persistent cache mimics a full PC and preserves the changes made across reboots,
which us beneficial if a true PC experience is needed.
While working with the shared image, every client requires a designated write cache file to store all data
that is created, modified, added or deleted from the OS Image file currently used. This write cache file has
a 1:1 relation to the OS Image and the MAC address it has been accessed from. All writes that would
normally go to the local hard disk on a PC will be redirected to the related write cache file on the WSM
server the client has booted from. Theoretically, the maximum size of a Write Cache file is equivalent to
the OS Image size being streamed, but typically the Write Cache files are less than one Gigabyte. Write
cache will never shrink, as WSM will reuse sectors in the write cache file that are no longer in use by the
original contents. For example, if a 30MB file is copied to the streamed client's desktop and then deleted,
WSM will reuse that 30MB chunk of the write cache file before growing it.
38
Figure 11 Write Cache of OS Image

In Volatile Cache mode the write cache file is automatically reset to zero bytes each time the client starts
or shuts down if later has been configured by the Administrator.
In Persistent Cache mode, the Write Cache files are stored permanently and thus it is advisable to avoid i.e.
massive swapping (without any limits set) and large writes to the virtual disk because this would grow the
write cache file unhindered.
To avoid excessive growth of the Write Cache files it is recommended to optimize the OS Image as
covered in paragraph Performance troubleshooting and OS Image optimization.
If a write cache file gets corrupted or the Administrator wants to reset the state for a client using an OS
Image in persistent cache mode, the Reset Device State command is available for Device Groups and
individual clients.
If Client Caching option is used to keep the write cache locally on the endpoint, there is still a 32MB write
cache file created on the WSM server for the first phase of booting and in case client side cache media
cannot be initialized and the client can fall back to server side write cache.
39
8.2
OS Image updates
A simple three step patching workflow allows users to patch the image(s) directly or through the creation
and distribution of delta files. WSM will automatically copy images, ensure the integrity of the images, and
patch images without any user intervention. It also provides the ability to roll back to a previous version if
needed.
There are different options to update an OS Image:
1.
Patch OS Directly (introduced in WSM 5) is replacing former Private Mode and is recommended if
only one WSM server exists and the Administrator can take all clients offline to finalize the patch.
Using the Patch OS Directly procedure, the designated Reference Device is working with the OS
Image in shared mode and after all updates have been applied from it, the related write cache file
is merged into the shared OS Image. With this change, users can continue to work with streamed
desktops while the administrator patches the OS in parallel. Only during the patch finalization
process will the streamed clients need to be shut down for a brief period of time. At the next boot,
all clients will work from the updated OS Image automatically.
2. If not all clients can be shut down at the same time, the administrator may create a copy of the
initial OS image and register it with a different name in the WSM console. This copy will be treated
like a new image and can be updated using the Patch OS Directly option from the assigned
Reference Device. After the patch has finalized, the updated OS Image must be assigned to all
relevant clients or Device Groups. During the whole process all clients can remain up and running
and use the initial OS Image until they reboot. If required, a reboot of the clients can be scheduled
from the WSM Admin Console. Otherwise, the clients will use the updated OS Image at their next
startup. Drawback of using a full copy is the additional disk space used and that a full copy of the
OS Image is sent across the network if multiple servers are installed.
3. If the OS Image is present on multiple servers or is distributed to Linked Sites, it may not be
effective, or even possible, to distribute an updated copy of an OS Image across the network to all
servers. In such a scenario, a built in patch process using delta files helps to identify the binary
difference between the base OS Image and its updated copy. Only this delta is deployed to other
WSM server streaming the base image. One the remote servers a new OS Image is crafted from
the base image and the delta and once this is active, it is assigned automatically to all clients and
Device Groups so they can use it at their next boot. This patch process is designed so it does not
interfere with the current setup. WSM continues to stream the active OS Image unless the so
called patch is ready to be used. This is the recommended procedure for every Core/Edge server
installation, regardless of the network topology or Site Architecture in place. It ensures operation
of all clients up and running plus provides a convenient Rollback mechanism in case the updated
OS Images does not work as expected.
Updating OS Images using the Patch OS Image with Delta process allows an easy rollback to a previous
version of the OS Image.
40
8.3
Reference Device Group

With WSM 5 a simplified OS Image and Patching procedure was introduced, where a designated Reference
Device is used to apply changes to the image either during OS Image capture, Patch OS Directly or
Patching with Delta Files procedure.
A Reference Device must be assigned to the built-in Reference Device Group in order to use it for a patch
process.
Reference Devices will always boot the OS Image from the Core server, regardless if the OS Image is
assigned to a user-created Server Group with multiple servers and load balancing in place.
8.4
OS Image Patch Rollback

If an OS Image was updated by using the Patch with Delta files process described above, WSM allows
rolling back to a previous version. This will just revert back the OS Image assignment to the image used
before. As during the OS patching, this will become active at the next reboot of a client and will not affect
the current operation.
41
Content Distribution
9.1
Overview
WSM provides a built in Content Distribution mechanism to transfer OS and Application Images and
patches from the (HQ) Core server to other WSM servers. Images are assigned to Sites and Server Groups,
whereas patches only replace existing image assignments and hence do not have to be assigned manually.
Content distribution between the HQ and Linked Sites can be done via TCP/IP or http(s). Between the
Core server and Edge servers within a site, the protocol used is always TCP/IP.
After enabling the distribution of an OS, the pre-processing and copy operation must be scheduled by the
Administrator at the (HQ) Core server first. Application Images are copied automatically to all servers in a
Server Group and do not need to be scheduled.
The Content Distribution Client is responsible for pulling updates from the Core to the Edge servers, and
the interval to check for scheduled or pending operations can be set on the System Settings / CDS page of
the WSM console.
9.2
Content Distribution for Linked Sites

WSM Content Distribution features a starburst process between sites and within individual site servers. A
Linked Site Core server will copy the OS image from the HQ Core server, and any Edge server within the
Linked Site will copy the image only from the (site) local Core server.
In a Linked Site environment, the HQ Admin is able to control the deployment globally and on a Site
Group level. Customers with large numbers of sites can organize sites into groups, and deploy images and
patches to a group at a given time. In addition, the administrator can limit the number of simultaneous
image downloads from HQ to Linked Sites. This enables throttling of the number of remote sites that
might be attempting downloads of images from Headquarters.
The start time is expected to be specified as military time; so 10:25pm should be entered as 22:25. If the
administrator enters 22:25 for "Image Deployment Start Time" and 8 for Deployment time range, sites will
be able to schedule images for deployment in between 10:25 PM at night and 6:25 AM in morning every
day. If the servers are in different time zones, the time zone of the HQ Core server is used. If the value for
Image Deployment is set to "0" for a particular site group, sites will be able schedule image deployment at
any time they check in. The HQ Administrator wont be able to set a Time Range for the Default Site group.
Sites that belong to Default Site group will be able schedule image deployment at any time they check in.
42
Before an image can be deployed to other servers and sites, it must be enabled for distribution. Until the
Administrator activates the distribution feature of the OS Image, it will not be prepared and copied to other
streaming servers or remote sites.
Once you have clicked the Distribute button, the OS Image is effectively locked down and no
configuration changes can be made to the OS Image from that point onward. In particular, the OS Image
cannot be updated using the Direct OS Patching procedure. Changes to the content of the OS Image
can be done only through Patching with Delta Files.
Deploy a new version of the OS Image to Site Groups
The system always deploys the latest version of the OS Image to the Default Site Group, and sites that
belong to the Default Site Group automatically get this version (aka patch) assigned. Only for those Sites
which belonging to a non-default site group, the WSM Admin has to assign the patch manually.
The Administrator may have good reasons why he wants to choose a different version and deploy for any
Non-Default Site Group(s). As an example, for site group America, the Administrator may choose to assign
"patch version 2", but for site group Europe administrator may assign "patch version 3". In this case all sites
that belong America will patch/rollback up to "patch version 2" but for sites that belong to Europe will
patch/rollback up to "patch version 3".
Unless the Administrator is using the Update OS Version feature from the OS Image / Site Groups page,
the copy of the patch to the Linked Site Core server(s) will not start.
9.3
Bandwidth Throttling
This feature allows the administrator to control the transfers of images and patches that are downloaded
from the Core server. The Administrator can set bandwidth limits globally for all Linked Sites, based on
non-default site group membership and also within each site.
WSM provides the ability to control bandwidth usage by
limiting the number of simultaneous downloads from HQ to Linked Sites,
Monitor active, waiting and disconnected connections to view information such as last heartbeat,
current bandwidth and average bandwidth.
Abort connections that havent checked-in within certain threshold.
Monitor image download activity via the WSM Monitor Console (WSM Web)
43
9.4
Image compression
WSM by default compresses OS and Application Images and patches to reduce the amount of data for
initial image deployment or the transfers of large delta files. The images/patches are uncompressed after
they have been copied to the destination.
In a Standalone Site environment, where all servers are connected via LAN, compression can be turned off
to save disk space and avoid the additional time for compressing / uncompressing content.
9.5
Offline deployment of OS / Application Images

If a WSM server needs to be set up in a location where it is not possible to transfer full images over the
WAN, images can be either copied to the WSM server when it is connected to the corporate LAN or from a
removable storage device.
When the WSM server connects to the (HQ) Core server to initiate a (scheduled) image copy operation, it
will recognize that there already is an image with the same name present on its local disk. Next, a CRC
check between the local image and the image on the server is performed, and if this is successful, the
copy operation is skipped. If the CRC does not match, the local image will be deleted and a full copy
operation will start.
9.6
Automatic cleanup of older images versions

When a number of patches are deployed, the server can run out of disk space because WSM retains a full
copy of all prior images. This feature allows user to control Images he would like to keep on system. A
background task, depending on configuration settings, will delete Images from Streaming Directory of
each WSM server. Note that the background task will delete Images from all servers other than the server
where the Image was registered.
The OS Image Cleanup Feature will not delete any images or patches from the HQ Core server.
9.7
Fast Patch
WSM Fast Patch feature provides a mechanism to speed up the rate at which a Linked site is updated to
the latest version of an image. It is designed to speed up the process of bringing up or rebuilding Linked
Sites that have long patch histories. This option will always create the current version of the OS image as
well as the one previous on the Linked Site, but does not create all the intermediary OS image files. The
process skips intermediate copy operations and/or checksum validations, and only the final image is
validated.
This feature can be useful in cases where a new Site is added to the WSM system after several patches
have been deployed to other Sites that have been in the system for a significant amount of time. Note that
WSM still preserves the ability to roll back to the prior image version (a dull image of the last-but-one
version is preserved to enable a rollback to the prior version).
44
10
High Availability and Disaster Recovery
10.1
Overview
In a Client - Server computing model various components are working together to build a solution.
Depending on the customers need for business continuity, the implemented architecture is key for
designing a fault tolerant environment.
Paradoxically, adding more components to an overall system design can undermine efforts to achieve
high availability. That is because complex systems inherently have more potential failure points and are
more difficult to implement correctly.
WSM delivers a set of high availability features and provides mechanisms to easily recover from a system
failure or outage:
Site based architecture

Automatic load balancing and failover within Server Groups
Assign Core server role to another WSM server
Automatic recovery of WSM server IP-Address or hostname change
Automatic or manual database failover to a WSM backup server within a site
Wizard assisted re-configuration of the WSM database connection
Shared StreamingDir to host images and server side write cache files on a common directory
To help identifying the critical components and to plan and architect a high available WSM Architecture,
this section highlights the most important subsystems:
45
Database
WSM server software
Server hardware and storage
Network infrastructure
10.2
WSM Database
The WSM database is the heart of a WSM system and if the deployment consists of multiple servers, it must
be available all the time to support continuous operation.
In a multi-server scenario it is best practice to run the WSM database on a system that is configured for
high availability, for example by using Microsoft Clustering or other similar working products.
These are the steps to move the WSM database to another SQL server or instance:
1. Backup the WSM database (StreamingDB) on the source server
2. Restore the StreamingDB on the new server.
3. Create an SQL user called wsmdb and make it the owner of the StreamingDB. This user must also
have sysadmin privileges.
4. Open WSM console on the Core server and stop all Services on all WSM server and change the
required values on the Database configuration page.
5. Take the old database offline or detach it.
6. Stop and restart all WSM services up to three times on the Core/Edge servers so all WSM services
can adjust to the updated settings.
10.3
Built-in database failover support

WSM also provides built-in capabilities for automatic database failover within a Standalone, HQ or Linked
Site. This allows enterprises to ensure continues operation of the WSM solution without the need to
cluster the SQL database in every branch office.
The capabilities include:
Automatic or manual failover to the backup database after a certain amount of time
Automatic or manual resume using the primary database server when it comes back online
To enable WSM database failover, a second install of SQL on the backup server within the same site is
required. Only one server can be configured as the backup server. However, the site can contain any
number of Edge servers, and all of them will use the backup database the same way.
To set up database failover:
1. The Core server must be up and running.
2. Create a shared folder with read/write access for both SQL servers services. Its recommended to
create the folder on the backup server, so the copy of the StreamingDB is still available in case the
Core server fails.
3. On the server supposed to run the backup database, WSM must be first installed as Core server of
a Standalone Site in order to configure the registry and local database on this server. The license
import and Active Directory integration can be skipped, as the server will later become an Edge
server of the existing WSM installation in the next step.
4. Modify the BackupServer.properties file on the backup server so it matches your setup.
46
5.
Execute the ConfigureBackupServer script on the backup server. This will make the server become
an Edge server of the exiting installation and configure the DB failover settings on the WSM Core
server.
While the system is running from the backup SQL database:

Additions or deletions of clients on a site are not supported
Content Distribution of OS Images/Application Images and their patches are not supported.
Administrators will not be able to send real-time commands such as shutdown or reboot to
clients.
If the primary server is down, a Linked Site will not be able to contact Headquarters for
aggregation and synchronization of the Site Template or the OS and Application Images.
10.4
WSM Server Software

Every WSM server runs multiple services to communicate with the clients it serves, the WSM database,
other WSM servers as applicable and Active Directory if configured.
In a simple scenario there might be only one WSM server. The easiest way avoid system outage in case this
server fails is to setup another server as Edge server and make both servers member of the same WSM
Server Group and have the SQL database running on a different server than the WSM Core server. In case
the Core server would not be available, the Edge server is still able to deliver images to clients without reconfiguration.
From the WSM Admin Console it is also possible to assign any Edge server the role of the Core server if
required, and once the former Core server starts up it will automatically be degraded to work as an Edge
server. This way it is possible to configure the WSM system even when the outage of the Core server is
longer than expected. After the Core server is fully operational again, the assignment can be reverted to
the initial state.
As WSM is licensed by device and not per server, there is no additional cost for installing any number of
Edge servers. With the outlined built-in failover mechanism theres no need to cluster WSM Server, which
helps lowering the cost and reduces the complexity and the need for 3rd party tools to build a high
available solution.
47
Figure 12 High Availability within Sites
10.5
WSM server hardware and storage

To eliminate server hardware as potential source for a system outage, you should consider redundancy for
the critical hardware components like Network Cards, storage, power supplies etc. Based on the hardware
vendor there are various options available to make a server resilient to a failure of a critical component.
Virtualizing a WSM server and using the hypervisor vendors methods for high availability is also a viable
option to decouple the Server OS and WSM software running on the underlying hardware.
48
10.6
Network infrastructure
If the network connection between a Cloud Desktop and the WSM server is down, there is nothing else to
do than restoring the connection to continue working on the client.
Dell has designed the system in a way that a live-streamed client will not blue-screen or crash if the
network is down; instead the OS will wait and pick up the work after connectivity has being restored.
Hence the system is very fault tolerant to network outages.
In a network with multiple locations, the LAN within a branch is often not a customers main concern. As
the lines between sites and Headquarters are often not owned by the customer himself, he will look for
solutions that are able to cope with an outage of the WAN for any amount of time. Some customers use
redundant WAN lines, with automatic failover, to avoid network connectivity failures. However, many do
not have such configuration due to the expense. WSM Site Architecture was developed with exactly this in
mind: making a branch work independently from the Headquarters Core server and the WSM database! By
configuring a Core server in a branch as Linked Site it will update its local database periodically with the
settings of the Site Template at Headquarters. When the connection to Headquarters is down for a long
time, the configuration and Image patches can also be imported while being offline. This way, the branch
can work even when the network connection to Headquarters is lost for forever!
10.7
Disaster recovery
Backing up the WSM database and the files on the WSM server is obligatory and normally theres no
discussion on whether or not to back up a server system anyway.
The more important question is: How do I get system XYZ up and running again?
If a WSM Core server must be replaced or rebuilt from scratch for some reason, the recovery procedure
depends on whether or not a full backup of the earlier server is available. If the server can be restored from
a full backup (including registry entries, system files, and machine name and IP address), then no additional
steps are required and the server will connect to the database and resume normal operations.
If no backup is available for the Core server, the sequence to restore the WSM system would be:
1.
Designate one of the remaining Edge server as the new Core server. Remember this would only
work if the database was on a different server and not the Core that failed.
2. If there are no Edge server and/or a new Core server should be set up to use the existing database
a. On the new server, set the Hostname and IP Address to be the same as the old server being
replaced.
b. Copy over all the OS and App images that were configured for the old server, using the same
StreamingDir location as the old server.
c. Install WSM software on the new server, and configure it as a new standalone Core server.
d. From the WSM UI, skip the import of the server license file, and instead navigate to the
Systems Settings page.
e. Select Database Configuration, and change the database server information to point to the
database for the original WSM installation.
49
f.
Save settings and restart all WSM services. The new server effectively inherits all the
configuration information of the original server from the database.
3. Make sure the Edge server demoted from the temporary Core server role if applicable
If the contents of the StreamingDir on the restored server are out-of-date, those files must be manually
copied over from another server. Since the database already contains the assignment information for
these files, no further assignment operations are needed.
10.8
System Monitoring & Health Check

WSM displays the status of clients, servers, Content Distribution etc. on various places like the WSM
Administrator Console, the WSM Monitor Console or the WSM Client Statistic and Network Test tools.
This is a brief overview where information about the system is available:
WSM Admin Console
- Global system configuration settings, Sites and templates, Server and Device Groups, Active
Directory integration, OS and Application Image assignments, Licensing
- Active Directory connection status and configuration
- Alerts and Audit Login trail
- Device and application usage reports
WSM Monitor Console (WSM Web dashboard)
- User interface to monitor Server health status, Image and Patch deployment, provides detailed
client statistics
- View the assignment of an OS Image to Site Groups
- HQ Deployment view allows content connection monitoring and to schedule the deployment
of an OS Image to one or more site groups
WSM Client Statistic Tool
- A detailed graphical interpretation of the client log files stored on the WSM server
- Shows boot time statistics, network consumption, up time etc.
WSM Network Test Tool
- Runs in Client / Server mode
- Checks network communication to test ports and bandwidth
50
11
WSM Server Sizing
11.1
Overview
Since WSM Server feeds clients with data from its storage, it can literally be sized like a file server. More
RAM, a fast storage and good network connectivity are more important than the number of CPU Cores. In
the Windows Server OS, the maximum throughput should be set for file sharing, and not for network
applications.
The Windows Network provider order should be set to:
Microsoft Windows Network
Microsoft Terminal Server / Remote Desktop Session Host
Web Client Network
While every user uses their system differently, it is difficult to estimate how much workload is generated on
a WSM server. In addition, it does not help to just add more RAM or more CPUs to get a better
performance.
WSM is a true 64-bit application and can address the full memory space of the host machine. The 32-bit
version, which is used to upgrade existing WSM instances, is still limited to address a maximum of 2 GB
virtual Memory for any of its processes.
For each GB of vDisk size, the OS Streaming Service will use approximately 1MB of RAM. For example, a
20GB image streamed to 100 clients at the same time would cause the OS Streaming service to approach,
if not exceed, the 2GB memory limit when running on a 32bit system.
Application virtualization does not impact the system that way, but keep in mind that other services like
SQL Server also require memory.
For each 50 clients streamed from a server, the recomendation is 4 cores, 16GB of RAM, 2Gbe throughput
and 15K SAS-drives in RAID 0 or RAID 10 configuration. Consequently, for 300 Users (6 x 50 Users) a
system with 24 Cores, 96GB RAM, 12Gbe and a Shared storage with enough IOPS is required.
The Wyse WSM Reference Architecture and Configuration Guide available includes an example for a
server supporting up to 50 clients and provides test results and guidelines to achieve optimal boot
performance. Replace the hard disks with SSDs for best user experience.
51
This formula can be used to estimate the memory usage the WSM OS Streaming service:
<WSM OS Streaming Service in MB> = (#of clients x (OS Image 1 in MB / 1000))
Example: 50 clients x 25MB = 1250MB
This formula can be used to calculate the theoretical maximum number of clients a single WSM server can
serve when executed on a 32bit Server OS:
Number of theoretical maximum clients = 70-75 %( 2000/OS Image in GB)
Example: 75% (2000/25GB) = 60 clients
11.2
Storage Requirements
Each WSM server should have a separate partition or storage for storing the OS and Application Images as
well as all the Write Cache files. The storage used to store WSM images and write caches must deliver
superior performance as all clients will access this disk.
WSM stores three different types of data files:
OS Images and OS Image patches
Application Images and patches
Write Cache files
The WSM Core server is the central repository for all OS and Application images and therefore requires
enough storage to store this data. These images are then copied from the Core server to the Edge servers
as required.
If the Content Distribution service is configured to use compression (enabled by default), additional disk
space to compress/de-compress any images and patches must be calculated.
Calculating the required IOPS for the storage is a challenge as each user group may have their own access
patterns and the overall requirements to the system will vary a lot between customers. The real problem is
that often there is no data available on the current average and peak IOPS for the customers physical
computers, but without this baseline, you cannot make a reasonable calculation what is needed when
they go virtual with WSM. With server side caching, the average IOPS per user is typically around 11-15
during boot (after that its often negligible), but using rules of thump for estimating the IOPs per user is
dangerous as they do not take into account the read/write mix and may not be applicable for the
customers use case.
The best way to gather empirical data on disk IO needs is an assessment while doing a Proof of Concept.
The average IOPS observed over time divided by the number of clients provides a good foundation for a
proper planning of the storage configuration.
Client caching offloads peak IO from the WSM server as it keeps the most often read data locally and can
also store the write cache file on the local disk rather writing back to the WSM server over the network.
52
While disk reads can be accelerated using array based or host based caching etc., optimizing the storage
for disk writes is trickier. The best performance can be expected from RAID-0 and RAID-10 configuration,
whereas RAID-5 and RAID-6 will add high IO penalty on disk writes and is hence not the ideal for storing
the WSM StreamingDir.
11.3
Shared Storage Support

Storage resources are optimized via Shared Storage support as servers no longer require their own
dedicated storage. This feature adds support for a common Streaming Directory for multiple WSM servers
(allowing the sharing of common OS and application images) resulting in significant reduction in storage
requirements across a cluster of WSM servers.
Storage needs to be accessible as a Drive letter or \\. For example, the path to a shared StreamingDir
would have to be entered as \\FS01\WSM\StreaminDir on all WSM servers configured to use Shared
Storage feature.
Its not recommended placing the StreamingDir on CIFS storage, as there will be performance penalties
compared to a SAN or iSCSI just because of the protocol.
Using Service Credentials is a prerequisite for using the Shared Storage feature to ensure all WSM services
on any WSM server accessing files on the remote storage are able to authenticate with the appropriate
credentials.
Separating the network traffic for Shared Storage from the connection used for streamed clients is highly
recommended to avoid saturation of either network segment.
A common Streaming Directory placed on Shared Storage must deliver superior performance to not
become a bottleneck for each of the servers accessing it. As this network share is also a single point of
failure, technologies like DFS or clustering could be considered in order to prevent any outage of the
service. Its also recommended to use a dedicated NIC in every WSM server just for this connection and a
separate NIC for serving the client network.
53
11.4
User Data and Settings

The WSM solution does not require a designated file server; however, it is best practice to store user data
files and profiles for example on a file server instead on the virtual disk of the individual client. This would
ensure that users are able to access their personal files and settings, regardless which write cache mode is
used and from which server their client has booted. Technologies like Roaming Profiles require a File
Server anyway and are recommended to preserve user data and settings.
As mentioned before, the Write Cache file for a client is always created on the same server the client
streams the OS Image from. In a scenario where a) Persistent Cache is set for the OS Image and b)
multiple WSM servers are used in a load-balanced setup, it may be required to use a common Streaming
Directory located on a Shared Storage. This allows any client to access files and settings present in its
Write Cache file anytime, regardless from which WSM server it receives the streamed OS Image.
Example 1
There are three different OS Images used, each of them is 25 GB in Size and set to volatile cache mode.
For this example, calculate the data partition of the WSM Core server as follows:
1. OS Images: 25 GB x 3 = 75 GB plus enough disk space for OS patching (i.e. three times) 300GB
2. Temporary write cache files: ~500 MB x 100 clients per Server 50 GB
This sample calculation results in a minimum size of 350 GB for the drive hosting the Streaming Directory.
The WSM Core Server at Headquarters site will always have a copy of all images and patches, whereas
Edge and Linked site servers can use Image Cleanup feature so obsolete images are automatically purged
from their Streaming Directory to avoid running out of disk space.
Example 2
The 15 clients in the branch office would all have the same OS Image assigned. Therefore, the WSM server
in the branch office requires less storage than the WSM server at Headquarters:
1. OS Image: 25 GB plus the same size for OS Patching 50 GB
2. Temporary Write Cache file: ~500 MB x 15 clients per Server = 7,5 GB
This sample calculation results in a minimum size of 58 GB for the drive hosting the Streaming Directory.
To calculate the RAM required for this type of server use the formula from page 42:
(#of clients x (OS Image 1 in MB / 1000)) = <WSM OS Streaming Service in MB>
(15 x (25000MB/1000)) = 375MB
54
Example 3
Total number of Clients, Type
50 x Wyse R00L, 2GB RAM
Number of WSM servers, Type
2, virtualized on VMware vSphere
Server OS
Windows Server 2003, 32bit
Server Specs
1vCPU, 4 GB RAM, 1 x vNIC, SAN
Network Connectivity / Speed
Network CAT 6, Switches CAT 5
OS Image Version / Write cache

mode
Windows 7, Volatile Cache Mode
Boot time of clients to logon screen
2 Minutes (if WOLed before business hours)
Example 4
75 x Wyse C00L, 2 GB RAM
2 physical servers
Server OS
Windows Server 2008R2, 64bit
Server Specs
1 x Xeon 5520, 6GB RAM, 1GB NIC,

2x146GB SAS 6G Raid 1 for IS, 4 x 300GB
SAS 6G Raid 0+1 for WSM, Raid Card with
512MB cache
Network CAT 5, 1GB Core Switches with
100MB to the clients

OS Image Version / Write cache mode
Windows XP, Volatile Cache Mode (no

Multicast)
Boot time of the clients
2-3 Minutes
Example 5
240 x Wyse V00L, 1 GB RAM
8, virtualized on Microsoft HyperV
Server OS
Windows Server 2003, 32bit
Server Specs
2 x XEON E5520, 36GB RAM, 10GB NIC, 2 x

146GB 10K RAID 1 for OS & PF, 6 x 146GB 10K
for WSM
Network CAT 5, 1GB Core Switches with

100MB to the clients
55
OS Image Version / Write cache mode
Windows XP, Volatile Cache Mode for

Students / Windows XP, Persistent Cache
Mode for Teachers
Boot time of the clients
45 Seconds (100 Clients at the same time)
12
Desktop and Server OS Virtualization
12.1
Overview
While there is no change to Desktop OS Virtualization in WSM 7 other than support for the latest Desktop
Operating Systems, delivering Server Operating Systems opens a whole lot of use cases.
Wyse WSM enables rapid and efficient server image delivery to physical or virtual machines. This new
feature allows for more agile deployment, configuration and management of virtual servers than existing
methods processes that previously took hours are reduced to minutes. This helps organizations harness
the benefits of virtualization and cloud computing, while simplifying management and deployment
processes and helping to reduce costs. By adding on-demand delivery of server OS images to Dells
reliable and secure end-user computing portfolio, Wyse WSM offers another powerful computing
alternative that helps organizations quickly stand up new servers where and when needed, and gives
employees and students secured access to content regardless of location.
12.2
Client Caching
By default, the write cache for live-streamed clients resides on a WSM servers disk.
WSM 7 introduces Client Caching, which allows the system to take advantage of storage available on the
client to do read and write OR write caching.
This provides superb performance gains over its already best in virtualization class performance. It turbo
charges desktop (OS and application) performance and improves boot performance by thirty to fifty
percent. At the same time, server side storage requirements and the network traffic between client and
server are reduced.
This feature can be used with both persistent and non-persistent desktops, and all settings are
configurable from WSM Administrator Console.
Cache Handling Methods
- Good (Write only) - All writes are cached on the client
- Best (Read and Write) - Reads and writes are cached on the client. Provides the best
performance while using more storage space
Storage locations
- First volume - Uses the first local disk volume (a.k.a. partition) which has the minimum
specified free space.
- First disk - Uses the first physical disk drive that has the minimum specified total space
56
If a Device Group is configured for Client Caching, but the client does either not have a disk or it cannot
be initialized, the system will automatically fall back to Server Side Caching for this client only.
To initialize a local cache volume or disk, the client has to boot at least one time with Server Side Caching
feature enabled. At the next boot, the client will switch to Client Caching.
The configured cache mode and status are displayed in the WSM Admin Console and on the client in the
WSM Status utility.
Client Caching with an OS image in persistent desktop mode in a load balanced (multiple WSM servers)
environment requires shared storage across the WSM servers. This limitation is only with persistent
desktop mode and not applicable to Non-Persistent mode (also known as Volatile mode).
If Client Caching option is used to keep the write cache locally on the endpoint, there is still a 32MB write
cache file created on the WSM server for the first phase of booting.
12.3
Power Management
WSM automatically configures the Microsoft power setting based on the mode being used on the
streamed Client or Server:
Live Streamed Mode - Sleep and Hibernate buttons are disabled, and the High performance power
setting is selected automatically.
Mobile Disconnected Mode - Sleep option enabled, Hibernate disabled, balanced power plan is
selected, and laptop lid closed option is automatically set to shut down.
12.4
Microsoft License Enabling for Streamed Clients

WSM allows administrators to check and enable Microsoft licensing using a UI as part of the image capture
process and as part of the patching process. Thus reducing errors and making it easier to enable licensing
via Microsoft KMS (Key management server). This is applicable only to Windows 7/8
Professional/Enterprise and Windows Server Volume license editions.
12.5
Microsoft VHD File Format Support

This feature introduces the ability to use a VHD image to stream to clients. For details on how to use VHD
in a WSM system, see WSM Admin Guide (documentation is available at: http://www.wyse.com/manuals
or by clicking Help in the top-right corner of the WSM Administrator Console).
57
13
Application Virtualization
13.1
Overview
In addition to the commonly used approach to include applications in the base OS image, WSM provides a
layered Application Virtualization technology to deliver applications on top of it. This allows IT personnel
to maintain a smaller number of OS Images, while having the ability to quickly roll out additional
applications based on the user group membership.
Introduced with WSM 7, the new Departmental Installed Application (DIA) Layering is replacing the snapshot based packing process of previous versions. Application Layering provides native application
performance, with instant ON/OFF and without the time consuming subscription process used before.
Application can be easily virtualized and patched from the Reference Device or a client in live-streamed
mode. The installation of the application(s) is captured into a separate vDisk, which is staggered on top of
the OS image when the user logs in.
Figure 13 Application Virtualization
58
WSM Application Virtualization driver manages file and registry layering process which mounts the
application(s) seamlessly at user login. It supports demanding applications with drivers like iTunes, Rosetta
Stone etc.
DIA Layering is also available stand-alone, with no underlying OS image to virtualize Applications for
legacy PCs and virtual Machines. In this release, this devices must be present in the WSM Admin Console
even when they boot from their local disk and do not use live-streaming.
Applications can now follow the user across any deployment (desktops, streamed desktop or VM). A user
can have only one copy of the Application Layer mounted at the same time, which means that hat if he is
logged in at multiple clients, the application layer can only be mounted at one of them.
The decision whether an application is included in the base OS Image or if it should be virtualized should
be made according to the end users requirements and how the environment is going to be managed and
maintained.
Application Layers are assigned to Sites and Server Groups like OS Images, but their deployment will
happen automatically and does not have to be scheduled.
Unlike an OS Image, the Application image supports only the volatile cache mode. This means once
registered, any updates to the application do not persist across reboots. If you want to update a
registered application image, you may use the patch process as described in Updating the Application
Image in the WSM Admin Guide.
At mount time, additional, layer specific registry settings can be merged so settings for HKCU etc. are only
applied
while
the
layer
is
mounted.
During
vDisk
creation/patching,
the
file
C:\WSM\UserScripts\postmount.reg may be modified as needed, for example to disable Microsoft Office
first time user experience screen.
13.2
OS Support for Application Virtualization

With the release of WSM 7.1.0, Application Layering is now supported on Windows 7, 8 and 8.1 32-bit and
64-bit Desktop Operating systems. Windows 8 and Server OSs will be supported in future releases.
The WSM 7.0.0 and 7.1.0 Product Release Notes list some generic known issues with DIA Layering.
Example 1
The marketing department has purchased only ten Adobe Creative licenses. The administrator wants to
enforce compliance based on the purchased license count, but all users must share a single OS Image to
simplify patch and deployment management.
The easiest way to achieve all goals is to create a single base OS Image for all clients in the marketing and
creative department and use Application Layering for the Adobe application.
The administrator first has to create and Application Image for Adobe. After registering it in the WSM
Admin console, he must assign the Application only to the Marketing User Group.
59
Example 2
Recently there was a new version of Adobe Creative released, and now the administrator wants to roll it
out to the creative team to see if it meets their requirements.
In this scenario, the administrator would create a new Application Layer.
To automate and enforce the use of the new version for the creative team, the admin will have to
Remove the creative team user group from the exiting application. This will automatically remove
the Application Layer at next login.
Add the new Application Layer to the WSM console and assign the Marketing User Group to it.
60
14
Mobile Disconnected Mode
14.1
Overview
Mobile Disconnected Mode allows the User to work with an offline copy of an OS Image while his client is
disconnected from the corporate network. Mobile Disconnected Mode is a per-device or Device Group
setting and when enabled, WSM provisions a copy of the assigned OS Image to a clients local disk. WSM
supports single partition and multi-partition OS Images, as well as preserving a user created data partition.
Application Virtualization is not supported on Mobile Disconnected clients.
To support offline mode, devices need to meet the minimum WSM hardware requirements and must have
enough local disk storage to store the OS Image that is used when working offline.
The minimum disk size can be calculated with the following formula:
(OS Image Size x 2) + 110MB
Example 1:
On the Reference Device, the Windows OS with all preinstalled Applications (e.g. MS Office) has 14,5GB. As
spare space for future expansion we reserve 3,5GB.
In this scenario, the formula to calculate the OS Image size looks like this:
14,500MB + 3500MB = 18000MB
Now lets calculate the size of the free disk space required on the provisioned client:
(18000MB x 2) + 110MB = 36110MB
This is an example how Mobile Disconnected mode works. It is assumed that the OS Image is set to
Persistent Cache mode, Force provisioning is disabled, and the Device or its Group is set to "Mobile
Disconnected" mode in the WSM console.
1. The client will do a PXE boot and the OS Image gets streamed from the server
2. From within the streamed OS, provisioning is initiated by right clicking the WSM Disk Status utility
and selecting Provision Disk. The process will wipe the disk and create three partitions: one for
the WSM boot loader, one for the OS Image and a third one for the write cache. A full copy of the
OS Image hosted on the WSM server is then copied to the clients hard disk.
3. On all subsequent boots, the client will contact the WSM Authentication server to compare the
Image ID of the local copy with the OS Image hosted on the server. If they are the same or the
client is working offline, it will perform a local boot. If the Authentication Server cannot be
contacted, the client will boot from its provisioned disk anyway.
4. If the OS Image has been patched on the WSM server, the WSM boot loader will recognize this and
ask the user if wants to re-provisioning now or later.
61
5.
If the user selects "Yes" to upgrade to the new version, the client will stream the OS Image from
the network first and then provision the local disk with the patched Image version.
6. If he selects "No" to first sync or save his data, the WSM bootstrap will ask again on the next and
subsequent boots until he selects "Yes" to re-provision the disk.
If a client got provisioned but the Network card is still the preferred boot option set in BIOS, the client will
still retrieve the WSM PXE-bootstrap from the WSM server but will load the OS Image from the hard disk. If
PXE-boot fails the control is passed to the next boot media (for provisioned clients the Non-PXE bootstrap
programmed into HDD) and this will go through its own Authentication Server discovery process.
The Non-PXE bootstrap will contact the WSM OS Authentication service on the Authentication Server (the
WSM server it got provisioned from) and updates the list of servers from this or any other server on this list
each time it boots.
If the g key on the keyboard is pressed while the Non-PXE bootstrap is loading, the user is presented with
the options to
1. delete the local cached Authentication Server information
2. Discard the entire OS Image present on the hard disk
3. Delete the write cache to go back to a pristine copy of the provisioned OS Image.
The provisioning status of a client is displayed in the WSM Admin console on the Device Details page:
Status:
Online: client is booted to provisioned disk and is connected to the WSM server
Offline: client is not connected to the WSM server
No Response: client is disconnected or powered off
Provision Status:
14.2
N/A: client is not provisioned

Provisioning In Progress (Round 1 of 2): Files are copied to local disk
Provisioning In Progress (Round 2 of 2): Finishing up provisioning
No Error: default message if no errors occur or other status to display
Power Management
In Mobile Disconnected Mode
62
Sleep option is enabled

Hibernate is disabled (not supported in Network mode either)
Balanced power plan is selected
Laptop lid closed option is set to shut down
14.3
User data partition preservation

Mobile Disconnected mode also supports preservation of a single data partition across OS Image patches.
In earlier releases, the entire disk would be rebuilt when the OS image is updated and any partitions on a
clients disk would have been lost.
Mobile Disconnected mode supports preserving a single, existing data partition and its contents when a
client is provisioned. Writes will go directly to this partition (no write cache mode), and Force Provisioning
must be disabled to allow the user to select which partition to save during the provisioning of his client.
These are the steps to create a data partition that is preserved across OS Image updates:
1. PXE-boot from the virtual disk
2. Using windows disk manager, create two partitions:
3. The first partition is just a placeholder for the provisioned OS Image. The size is approximately
equal to: (vDisk total size * 2) + 110MB
4. the second partition is for the data partition
5. Delete the first partition
6. Start provisioning the local disk
7. Select the partition to be preserved:
Figure 14 Select Partition To Save dialog box

8. At subsequent provisioning events, step 1 -3 are not necessary as the data partition already exists.
If there is an existing data partition on the to-be-provisioned client and enough free space in front of it to
store the WSM Partitions, the user can select to keep it. Otherwise, WSM will create a new data partition
on the remaining disk space. If the image is patched and re-provisioned, the 4th partition may be
automatically deleted if the space requirements have changed and there is no longer enough available
space to save it. If deleted, it will be recreated to a new size of the remaining space.
63
14.4
Mobile Disconnected mode and Linked Sites

There are several options to enable and control the provisioning of clients in Linked Sites:
Modify the global Site Configuration settings and enable Allow Multiple Server/Device Groups for
Site Template. Next, add an additional Device Group with Mobile Disconnected mode enabled to
the exiting Site Template. The advantage of this approach is that individual options can be set per
Device Template and Device Group and the admin has still control what groups will exist in any
Linked Site.
2. The second option is to create a separate Site Template with two Device Groups: one for network
and another one for laptops. The advantage of this approach is that existing sites will not be
affected and you can control in which sites Mobile Disconnected mode is available or not.
3. Another option is to modify the global Site Configuration and enable Preserve Linked Site Local
Data to allow the existence of local groups within individual sites. This allows the Administrator of
each site to create Device Groups as needed. While this enables maximum flexibility for
SiteAdmins, the drawback is maybe a lack of control which sites do have local groups or not.
4. Any combination of the above options is possible too.
1.
After modifying global Configuration Settings on the HQ Core server, the Site Template(s) have to be
published so changes are applied to the Linked Sites.
Move provisioned devices between sites
The IP-Addresses of the Authentication Servers are stored on the clients local disk. If a user with a
provisioned laptop is roaming between sites but Image updates and patches should only be applied in his
home site then there is no need to do anything. If the Site Administrator does not add the client to the
local database the WSM server will not send the PXE-bootstrap and the client will boot from provisioned
disk.
If a provisioned client should be permanently assigned to a different site, it must first be created in this site
and added to a Device Group with Mobile Disconnected mode enabled. When the client boots for the first
time in the new site, the list of Authentication Servers must be updated so the NON-PXE bootstrap knows
which WSM server to contact for Authentication.
Using the g-key on the keyboard, it is possible to discard the list of Authentication Servers stored on the
clients disk and either use a DNS record CDServer.abc.xyz (where abc.xyz is the DNS domain) or enter up
to four WSM servers manually.
The client will have to be provisioned in his new home-site one time so it is ensured the OS Image patch
level on the client is the same as used by all other clients in this site.
64
15
Multi-Platform Support (Golden Image)
15.1
Overview
WSM OS streaming relies on the network card driver within the OS Image to support the NIC in the client
where the OS Image is streamed to. If the driver is not present in the OS Image or does not match the
hardware being used, the start of Windows will get stuck half way through as the combination of physical
NIC and driver will not work. Another important detail is the Hardware Abstraction Layer (HAL) and
computer type (ACPI etc.), as these must match too so Windows can boot all platforms from the same
image. If platforms are different, they must all be set to the lowest common feature set (i.e. to Uniprocessor, non-ACPI if this is the lowest platform).
A Golden Image can be created by moving a disk with a Windows installation between the Reference
Devices until Windows has discovered and installed all hardware. One each platform, the Wyse WSM
SelectNic tool must be executed so the NIC driver is flagged and recorded. On the last platform, the WSM
Client is installed and the OS Image is created from this device.
An easier approach to create a common, golden OS image is using the Wyse WSM Uniplat tool, which is
covered in depth in the in the WSM Admin Guide.
WSM v7.0.0 release does not support Golden Image creation using WSM Universal Platform tool
(UNIPLAT). To create a Golden Image in this release, you have to move the disk between the Reference
Devices. This has been fixed in WSM 7.1.0.
15.2
The Uniplat tool

The Wyse Universal Platform (Uniplat) is part of the WSM Client Utilities package and it allows backup and
restoring of a system on different platforms.
The process to create a universal image for use with various platforms using UniPlat is:
1. Install UniPlat on device #1 with all drivers installed.
2. Backup the System partition to a USB disk or network share.
3. Restore the UniPlat backup file to an empty partition on device #2 and select the Keep critical
drivers from current Windows session.
4. Reboot device #2, so it starts from the restored Windows installation and can install the drivers for
the new hardware found.
5. Repeat steps 2 to 4 for every other device type you want to support with this image
6. install the WSM Client software and create the OS Image
65
15.3
Adding platforms support to existing Image

When a new hardware platform is released, one of the common questions is: will it work with the existing
OS Images in my WSM installation?
Windows is quite flexible to boot from hardware which is different from the one it was initially installed on
if the main characteristics like HAL are the same. For example a, single OS Image fits fine to stream to Dell
Wyse D00D, Z00D and X00M Cloud Desktops with single and dual core processor installed.
The latest generation of the Dell Wyse quad core Cloud Desktops is using a new, cutting-edge Systemon-Chip architecture, which is very different from its dual core brothers. Hence an existing OS Image for
dual core clients will fail to boot on this new platform, which means the customer cannot us the existing
OS Image for the new clients.
Creating a separate OS Image for a new platform leads to two drawbacks:
customer would have to maintain two images in parallel
patching a new OS Image up to the level of the existing one is often a time consuming and
complicate process, if not all changes which have been applied over the lifecycle of the image are
well documented.
The good news is that WSM includes all the tools to address the customers concern and needs for this use
case:
A procedure called Reverse Image Capture can be used to restore an existing OS Image back to
the disk of the Reference Device. This way the current state of the OS Image is transformed into a
living Windows Installation which can be used as the source of a new image
With the WSM UniPlat Tool it is possible to create a Windows installation that includes the drivers
for both hardware platforms
So even when the existing OS Image does not work for the new clients because of their different
architecture, the customer can create a new, combined image for all clients from the OS Image currently
used with little efforts.
To create a new, Golden Image from an existing OS Image:
Start on the existing Reference Device and
1.
use the Reverse Image Capture Process (see page 78) to restore the current OS Image to the disk
of the Reference Device
2. uninstall the WSM Client
3. update drivers and applications, apply Windows updates etc.
4. create a UniPlat Backup File from the current Windows installation
66
On the new Reference Device

5.
6.
7.
8.
9.
10.
Install the same Windows Version as running on the Z00D Reference Device
Restore the UniPlat Backup File to an empty, primary partition
Restart the device and boot it from the WSMRestore partition
Install all missing drivers, i.e. the AMD Driver package for the Quad Core platform
Install the WSM Client
Create a new OS Image from the combined Windows installation
Do not use the option Keep critical drivers from Windows session if restoring from D00D/Z00D/X00m
to D00Q/Z00Q.
67
16
Performance troubleshooting and OS Image optimization
16.1
Overview
If the experience on a WSM provisioned client is not as expected and you need to find out the root cause,
you first have to understand which parts of the system do have an impact on the end user experience.
Always remember that a WSM provisioned client is executing applications locally but all data is accessed
from a virtual hard disk that is connected over the network and hence it is inadequate to compare it 1:1
with a physical PC.
16.2
Measuring boot statistics

Often the boot time of a client is used for performance comparison, but what in fact is the boot time?
Lets have a look what happens when a client is starting up:
1.
2.
3.
4.
5.
6.
7.
8.
Power Button is pressed, followed by BIOS self-test

PXE-Boot: client receives network information from DHCP and WSM DHCP Proxy
Client loads and executes WSM Bootstrap from WSM server
Login to WSM Authentication Server, OS streaming starts
Windows Boot loader gets executed, WSM drivers are loaded
Windows Logon
User Login: User profile gets loaded, WSM Client starts, Windows Desktop gets prepared
Client is ready to work.
Figure 15 Boot process from vDisk and measurements
68
There are typically four measurements that are used to gauge the boot time of a client:
Visual / User monitoring - this is the end user measurement that measures how long it takes to get
to a usable desktop from the time the power button is pushed. Of course there is no way to
programmatically measure and record this and it is subjective.
Boot time in the OSM Tray - this measure is started when the OSM Network driver (OSMI Stack) is
loaded and counts to the time the WSM service is started. The WSM service can be and usually is
started before the user logs on, so this time will not reflect the loading of a user's profile.
Boot time in OSStrmSvr.log file - this measure starts when the OS Streaming service sends its first
I/O to the client and ends when the WSM service is started.
Boot time in LSLog.txt - this measure starts when the OS Authentication service grants permission
to the client to boot to OS and ends when the WSM service is started.
The Ios<mac>.log file of the individual client tracks the information the moment that the OS
Streaming service starts streaming to a client and does not stop, it is continuous. The amount of
data is the total disk I/O (reads and writes). Looking at the size of the write cache file it is easy to
find out how many data is read from and how many is written to the vDisk.
16.3
Establishing a baseline
A lack of performance could be caused by the WSM server itself (Storage, RAM, CPU), the network
connection between the client and the server, the client itself (CPU, RAM, Video) - but also the OS Image
itself (Software & Drivers loaded etc.)
To establish a baseline for performance troubleshooting, record and analyze the following parameters:
Network Connectivity
- On the WSM server, use the Task manager/Performance Monitor to check the utilization of its
NIC
- Measure Bytes total / sec (Set scale factor to 0.0000010, for Gbit/s NIC)
- What other traffic is on the network segment; is it already saturated?
- if a high number of clients are powered on a the same time and they network is the
bottleneck, consider multicasting if Volatile Cache mode is used for ALL partitions of the
relevant vDisk
WSM server disk subsystem
- Use Performance Monitor to check physical disk counters
- Average Disk Queue Length (should be less than 2)
- Physical Disk % Read Time
- Physical Disk % Write Time
69
Memory
- On the WSM server, is there enough RAM for OS streaming and system caching? On the client,
is there enough RAM to execute applications and cache disk access at the same time?
- Monitor
o Pages/sec
o Available Mbytes (Scale: 0.001)
o Cache bytes (Scale: 0.0000001) & Cache Copy Read Hits %
o Committed bytes (Scale: 0.0000001)
16.4
Image Optimizations
WSM automatically optimizes certain settings while capturing the OS from the Reference Device:
Figure 16 Advanced vDisk Optimizations
70
But there are a number of things that can be done to optimize the OS image furthermore. First of all,
understand what are the services, drivers and other startup code that have to be streamed over the
network before the system is fully up and ready for the user.
Windows Operating Systems enable several convenient features by default presuming a large and fast hard
disk. While many of these features can also be useful on a diskless system where the disk is actually on the
network, their use decreases cache effectiveness and also increases resource utilization. The resources
considered here are the network bandwidth and the storage space needed for the WSM repository.
Disable ALL automatic Update Features
- Windows Updates
- Adobe Reader
- Flash Player
- Google Earth
- Browser and Add-On updates
- Anti-Virus engine updates
Disable unwanted features and background services
- Windows Error Reporting
- Windows Search
- Media Player Network Sharing
- Indexing feature
- Windows XP logical prefetch
- Scheduled/Automatic anti-virus engine updates and scans of the virtual disk
- Deactivating SuperFetch service
- On Windows 8 consider disabling:
o Automatically update my Apps
o Share Information with MS and other Services
o Disable Getting things ready message
To avoid excessive growth of the Write Cache files
- Set the paging file to a fixed size
- Limiting the size of Recycle Bin and the Windows Event Logs
- Disable Offline Folders, System Restore points and Hibernation (not supported anyway)
- Keep the Default User profile as small as possible
- Use Client Caching if there is a local disk in the Cloud Desktop
71
16.5
Freeing up disk space from old Windows Updates

Over time, the size of the Windows installation on the Reference Device or within the patched OS image
will grow as Windows Updates are applied to the system.
1.
Patches and updates are downloaded to the C:\Windows\SoftwareDistribution\Download folder

and remain there even after patch installation. To free up disk space, the content of the folder can
be deleted after all updates have been installed successfully.
2. Old versions of system components and files for uninstalled, disabled Windows components are
stored in C:\Windows\WinSxS folder. This folder is the Windows component store and includes all
operating system files and thus can grow very large as udated are installed. You should not try to
delte files in this folder manually, but rather use these options to reduce the size of WinSxS folder
in a safe an controlled manner:
a. On Windows 7 SP1, install the Update from Microsoft KB Article 2852386. This will add an
option to the Disk Cleanup wizard called Windows Update Cleanup which can help reduce
the size of the WinSxS folder.
b. On Windows 8.1, the command line tool dism.exe can be used to clean up the sytem.
Run this command from a elevated command prompt:
dism.exe /Cleanup-Image /online /StartComponentCleanup /Resetbase

This Microsoft Technet Article explains what dism.exe and the paramters used do in detail:
https://technet.microsoft.com/en-us/library/dn251565.aspx
Warning: While we have seen no negative impact by using the above methods you should use them
carefully and understand that they are performed on your own risk. Make sure you always have a backup
in place before start makinging any changes to the Windows installation!
72
17
FAQ
Question:
What are the supported operating systems for WSM Version 7.2.0?
Answer:
WSM server components:
Windows 2012/2012 R2 (English, Simplified Chinese, Chinese - Taiwan, French)
Windows 2008 R2 SP1 (English, Simplified Chinese, Chinese-Taiwan, French)
Streamed Server:
Windows 2012 R2 (English, Simplified Chinese, Chinese Taiwan, French)

Windows 2012 (English, Simplified Chinese, Chinese - Taiwan, French)
Windows 2012 - Multipoint server (English)
Windows 2008 R2 SP2 (English, Simplified Chinese, Chinese - Taiwan, French)
Microsoft Windows 2008 R2 SP1 (English, Simplified Chinese, Chinese-Taiwan, French)
Streamed Desktop:
Windows 8.1 Pro/Enterprise x86 and x64 (English, Simplified Chinese, Chinese-Taiwan, French)
Windows 7 Pro/Enterprise x86 and x64 (English, Simplified Chinese, Chinese-Taiwan, French)
IMPORTANT: Windows 7 and later requires Volume Licensing (VL) and requires a Microsoft KMS (Key
Management Server) to activate.
WSM includes a client side Windows KMS Licensing Tool which is an easy to use UI for slmg.vbs and can
be used during OS Image capture operation or any time later while patching the OS. Applications still need
to be done manually and separately (for example for Microsoft Office).
More information about Windows product activation through KMS in a WSM environment is available in
Wyse Knowledgebase Solution 22106: Wyse WSM - Windows 7 Licensing Best Practices.
73
Question:
What client hardware is supported?
Answer:
WSM officially supports:
Dell Wyse D00D, D00Q, Z00D, Z00Q, X00m
Selected Dell OptiPlex Cloud Desktops (refer to Release Notes and www.dell.com/clouddesktop for
more Information)
PCs, other hardware platforms and virtual machines that satisfy the minimum requirements for a
WSM client (see Administrators Guide: Wyse WSMTM).
When using Windows 7 on Dell Cloud Desktops class or any other hardware using a PCI-E NIC, a
Microsoft hotfix is required to stream the OS to other clients. The hotfix needs must be installed before
creating the OS Image.
For Windows 7:
http://support.microsoft.com/kb/2344941
For Windows 7 SP1:
http://support.microsoft.com/kb/2550978
Question:
What databases are supported by WSM?
Answer:
Microsoft SQL Server 2008 R2 Express (included with the WSM softwareselect the
Embedded Database option during installation)
Microsoft SQL Server 2012 R2 Express (when used as external database)
Microsoft SQL Server 2012 R2 Server (when used as external database)
Question:
How many SQL Server licenses do we need when we use a full SQL Server Product (not the Express
Edition)?
Answer:
As only the WSM servers will talk to the SQL Server and not the clients, one license per WSM server or a
licensing per CPU is required. Check with your Microsoft licensing expert on the latest policies for SQL
licensing to ensure compliance to the Microsoft licensing models.
Question:
In a HQ / Linked Site scenario, what Database versions are required?
Answer:
All databases can be run on SQL Express Edition.
74
Question:
Where do I find the latest drivers for the Dell Wyse Cloud Desktops?
Answer:
You can download driver packages from http://www.wyse.com/downloads > Product Downloads > Active
> Cloud Desktops
If you prefer to always use the latest drivers, you can directly download them from the ICs manufacturer
website:
Dell Wyse D00Q, Z00Q
Display
AMD Catalyst Display

Driver for AMD GSeries SOC with
Radeon HD8330
(D00Q) and HD8400
(Z00Q)
http://support.amd.com/us/gpudownload > Embedded

Graphics > Radeon Embedded > G-Series SOC 1st Gen
formely codenamed eKabini > select your OS
HD Audio
Realtek High Definition

Audio Codecs
http://www.realtek.com.tw/downloads > High Definition

Audio Codecs (Software)
LAN
Realtek RTL8168
http://www.realtek.com.tw/downloads > Communication

Network ICs > Network Interface Controllers >
10/100/1000M Gigabit Ethernet > PCI Express > Software
SM Bus
USB 3
Dell Wyse D00D, Z00D, X00M

Display
AMD Catalyst Display

Driver for Radeon
HD6250 (D00D) and
HD6310/6320 (Z00D)
http://support.amd.com/us/gpudownload > Desktop

Graphics > Radeon HD Series > Radeon HD 6xxx Series
PCIe > select your OS
HD Audio
Realtek High Definition

Audio Codecs
http://www.realtek.com.tw/downloads > High Definition

Audio Codecs (Software)
LAN
Realtek RTL8168
http://www.realtek.com.tw/downloads > Communication

Network ICs > Network Interface Controllers >
10/100/1000M Gigabit Ethernet > PCI Express > Software
SM Bus
Controller
AMD G-Series
ftp://supportemea.wyse.com/public/WSM/Drivers/AMD_GSeries_SM_BUS_Controller_WinXP.zip
Important: only required on Windows XP
75
USB 3.0
Renesas Electronics
USB 3.0
http://downloadcenter.intel.com > search for USB 3.0

driver
WLAN
Sparklan WPEA-121N
http://www.sparklan.com > Support > Driver Download >

PCIE > WPEA-121N > Driver
Question:
Does the WSM server software support 64 bit Software?
Answer:
Yes, WSM works fine on 64bit Windows Server family
If WSM server is installed on 64 bit versions of Windows Server 2008 or 2003/2003R2, its advisable to
download and implement Microsoft Windows Dynamic Cache Service to avoid running out of system
cache. This software is available from the Microsoft Download Center. In Windows Server 2008 R2, the
Memory Manager was redesigned to address this issue, we but received feedback from customers that
even on 2008 R2 the system can run out of free memory and starts swapping.
WSM server on startup will automatically register the set cache command on Windows Server 2008 R2 &
2012 and 2012 R2, allowing for more free memory to be available in the system and preventing excessive
swapping. The size of the file system cache can be set via Registry if the defaults are not suitable for the
system. The registry key is HKLM\SOFTWARE\Wow6432Node\Wyse\WSM\MaxSystemCacheMBytes for
WS2008R2 and HKLM\SOFTWARE\Wyse\WSM\MaxSystemCacheMBytes for WS2012 and 2012 R2.
Accepted values are:
1-99
limit the maximum size of the System File Cache to this percentage of
currently available RAM
> 200*
limit the maximum size of the System File Cache to x Mbytes
0 (default)
Depends on physical ram size:
Physical Ram Size
Maximum System File Cache Size
<= 2GB
Physical ram size * 50%
> 2GB & < 8GB
>= 8GB
* The maximum system cache file size must be >= 200MB AND <= physical ram size minus 300MB
To apply these new settings a reboot of the WSM server is recommend freeing up the memory currently in
use. SetCache64.exe output SetCache.log file under <WSM server install folder>\log folder. This log file
records the exact value system cache file size was set to.
Since every WSM environment and server work load is different, the default setting that Wyse provides is
by no mean suitable for all environments. Hence it is strongly recommend to the customer to monitor
the memory usage of their WSM server and adjust the MaxSystemCacheMBytes setting accordingly.
76
Question:
If the Edge servers (of an Standalone Site) or a Linked Site Core server (Multi site) cannot communicate
with the HQ database, will the clients still function, and if so is there a time limit on how long the Linked
Site Core server database will continue to respond to clients requests?
Answer:
The terms Core-Server and Edge-Server refer to servers that are part of the same site. All servers at a
single site use the same database. An Edge-Server will continue to function as long as it has access to the
database, regardless of the health or presence of the Core-Server. If an Edge server loses connectivity to
the database, clients will not be able to boot from that server, and that takes effect immediately, not after
two hours or days or weeks.
In a multi-site scenario, if a remote site is disconnected from the HQ site, the clients will continue to boot
at that site - forever, no time limit. Clients at that remote site will continue to operate with whatever data is
in the database. Even if the admin does not re-establish the connection to Headquarters for a year, that's
fine, the site will be fully functional on its own.
It is also possible to apply configuration settings and deploy OS Image/patch in a disconnected site by
importing the relevant XML from the HQ site.
Question:
Is it possible to have two NICs in the WSM server? I want to use one for the internal network
communications with Active Directory and the SQL Server, and the other for the Client Network.
Answer:
Having two independent NICs in the server should not be a problem in most cases.
Question:
In the WSM server, is it possible to use two or more NICs with separate IP Addresses for
serving multiple client networks?
Answer:
WSM will only use one of those NICs for WSM work. If you are concerned about high availability of your
Network card, you should consider NIC-teaming to bind multiple physical Network Cards to one logical
NIC.
NIC-teaming should be configured before the server is added to the domain; otherwise DNS issues can
occur that may lead to issues during the WSM server installation.
77
Question:
There is already another PXE-Server installed on my network. How can I make both solutions coexist?
Answer:
If Altiris or ZEN is already installed on your network, an exclusion list can be created on those Systems to
not answer PXE-Requests from WSM clients. Wyse clients have a MAC Address starting with 00-80-64.
Within WSM, the built-in DCHP Proxy Service prevents streaming to unknown devices by default.
Unknown means that their MAC is not included in the WSM database. Only after adding a device to WSM
it will receive the WSM bootstrap, and with that, the ability to load the assigned OS Image. The optional
Device Discovery feature allows overriding this mechanism and adds devices automatically via Device
Templates or manually from devices while loading the WSM bootstrap for the first time.
Question:
How does the Load Balancing feature works in WSM?
Answer:
Load balancing works by making use of user-created server and Device Groups (no default groups). When
a client boots up, WSM will select a server from the assigned Server Group based on an internal load
balancing algorithm. Load balancing is built-in automation; therefore, there is nothing to configure to take
advantage of this feature.
WSM uses this process to select which server in the Server Group to boot from:
1.
2.
3.
4.
Finds out the load (number of clients booted from a server) for each server from the Server Group.
Selects a few of the least loaded servers from all servers in the Server Group.
Sends a request to the servers.
Selects the server that responds first.
Question:
Can we automate the setup of new WSM servers?
Answer:
Yes, the installer supports scripted installation, upgrade and removal of the WSM server software. The
script files and documentation can be obtained from a WSM server in the <WSM server installation
directory>scripts folder.
Question:
If a client loads the OS Image from an Edge server, where do the Application Images for come from?
Answer:
Application Images are always streamed from the same server that streams the OS Image. This is because
the write filter file for a client is always located on the same server it has booted from, and allows users to
write personal application settings to this file for later use.
Therefore, Wyse recommends deploying all Application Images on all Edge servers, so that a user always
has access to their applications.
78
Question:
I want to deploy a large OS Image on my Edge server and/or Linked Site Core server. Is there a way to
avoid the initial copy process over the network?
Answer:
To foist (pass off as genuine or fake) the OS Image:
1.
2.
3.
4.
Add the OS Image to the HQ Core server console

Finish the image configuration and set the appropriate write cache mode etc.
Assign the OS image to the relevant Site Groups, Sites and Server Groups
Copy the OS Image (not the compressed file if DS is configured for compression) from the (HQ)
Core servers StreamingDir to an external storage device.
5. On the Edge server/Linked Site Core server, copy the image from the storage device to the servers
StreamingDir.
6. Schedule the OS Image copy on the (HQ) Core server.
7. At the scheduled time, the deployment process on the will start but will skip the copy if the
destination and source file are the same.
Question:
Does WSM support Fiber optic Network cards on the client side?
Answer:
Yes, if an external converter like the Allied Telesis AT-MC 102XL is used, it should work fine. A PCMCIA
card will not work with WSM since it is not available on the BIOS level. Non-PXE will not work because
Non-PXE needs the UNDI support from a PXE capable NIC in order to send/receive packets to the
network.
Question:
Does WSM support wireless networks for WSM Client/ Server communication?
Answer:
As PXE communication is not supported by most wireless cards, and the NON-PXE WSM Boot Agent does
not support wireless either, there is no way of directly booting a WSM provisioned client using a wireless
LAN.
However, in theory, a wireless bridge that is connected at one end to the client via LAN cable will work, if
the wireless network is a) configured before the initial connection and b) provides sufficient bandwidth for
streaming. Even the fastest available WLAN Adapters that support 802.11n, which provides a theoretical
speed of 300Mbit/s, provide fewer throughputs than a 100Mbit/s LAN connection, and hence are not
recommended for being used with WSM.
Question:
What is the maximum size for the virtual disk?
Answer:
Per default the maximum size is 100GB. There is a registry setting to increase this value.
79
Question:
Is it possible to increase the OS Image after it has been created?
Answer:
Yes, you can extent the virtual disk without creating the OS Image again from a client having the WSM
Client software installed (i.e. the Reference Device. Virtual Disk Edit Utility allows you to expand the size of
an existing partition or add another partition to the vDisk.
Question:
How do I update the NIC driver and install VPN client software AFTER the OS Image has already been
captured and is no longer installed on the Reference Device.
Answer:
Updating network divers or boot critical drivers or installing software like a VPN client often lead to an
interruption of the network communication which will render the streamed client unable to apply these
changes to the patch. Reverse Image Capture allows an administrator to image a hard-disk of a referencedevice with the contents of a virtual disk that resides on the server (this is effectively a virtual-to-physical
operation, instead of the normal physical-to-virtual image capture, and therefore is referred to as a
reverse image capture).
Stream the image to a client with HDD/SSD
Format the boot partition on the physical disk with the same file system
Run OSImage.exe from the Wyse\WSM\OS folder and use the HDD as the target folder.
This process may require a reboot to complete and if your streamed image is in volatile mode this will
cause an issue (and a message stating this popped up). In this situation simply shutdown the client and
appended _TMPUSE to the write cache file for the client used so it is kept across reboots.
Customers may want to simply make sure that they stream an image that is in persistent mode. In this case
the actual state of the device (image + write cache) will be restored to the target partition.
After the process is complete, boot from the physical disk and apply your changes
Capture a new OS Image and register it at the WSM server
80
Question:
What is actually being stored in the Write Cache files?
Answer:
Anything that would normally be written to the hard drive in a traditional PC is written to Write
Cache. This includes temporary files, internet cookies, page file information and user profiles information
(and files, if a user is not using roaming profiles).
Question:
Will personal settings and applications follow a user if they move from one client to the next?
Answer:
Remember that personal settings are stored in the Write Cache files (along with other information). As the
Write Cache is based on each client, any personal settings will not follow a user.
If roaming profiles are set up on the network, then personal settings would follow a user. This situation is
similar to profiles in a PC environment, where a new profile would be created if you log in to a separate
machine, unless roaming profiles are set up.
Applications on the other hand, are distributed based on user credentials. That is, they will follow the user
no matter what thin client they log in to.
Question:
If the OS Image is set to Volatile Cache, how can the users personal data survive a reboot?
Answer:
In previous versions of WSM, if the base OS image was updated, all user information was lost because the
write cache had to be discarded unless Roaming Profiles where utilized to decouple the Users personal
settings and data.
WSM supports separating the user data from the system information by placing user profiles folder on a
different partition. This enhancement allows user settings and data to persist even when the system
partition is set to volatile cache mode.
To use this new feature simply check the Move User Profiles to separate partition option when creating a
new vDisk file using Virtual Disk Image Creation tool (OSMvDiskImage.exe).
81
Question:
How do I move the computer accounts in Active Directory for my WSM clients? Can I specify an OU
where new Computer Accounts are being created in Active directory?
Answer:
By default, WSM is using the default Computers container in AD to create new the computer accounts for
the devices added to the WSM Admin Console
On the Active Directory Details Page you can add additional Device OUs, which point to the relevant OU in
AD. These can then be used to
move exiting clients to a different OU (from their Device Details page)
specify a target OU when creating clients rather using the Default Computer container
be the default OU for new clients if no other OU is specified
A mass movement of devices from one OU to another can be done directly in AD.
1.
Go to AD and create a new OU from Active Directory Users and Computers. Select all devices
and move to the newly created OU.
2. Wait for Synchronization Polling Frequency and go to WSM Admin UI Device OU section under
AD settings page. The newly created OU will automatically appear in Admin UI.
3. On the device details page of each device moved, the Active Directory Organizational Unit field
will be updated with the new OU path
Question:
How do I enable Database failover within a site?
Answer:
This is a multi-step process that involves reconfiguration of the SQL server services and the setup of an
additional backup server. The procedure is described in this document, the WSM How-To series and will
be included in a future release of the WSM Admin Guide.
82
Question:
Can I delete the patch; the patched OS Image and any compressed files from ally my servers after the
rollback was successful? I want to save disk space and do not want to roll out this patch again.
Answer:
WSM provides an OS Image Cleanup feature to delete revised OS Images, patches and rolled back images.
The number of images to keep etc. is set on the WSM server > Settings > OS Image Cleanup configuration
page.
Question:
I have multiple patches deployed for and OS image, how can I rollback to a specific one? And how do I roll
out a patch again which I have rolled back before?
Answer:
This depends which way you roll back the patch.
1.
Rollback from OS Image / Patches page:

-
Use this link if you would like to roll back the latest version of registered OS image from all servers,
sites and site groups that have deployed it.
You may rollback only one version of OS Image at any given time when using this feature and
cannot select a specific one.
If you would like to deploy the same Image again, you will have to re-register the patched OS
Image and must provide different name for OS Image while re-registering.
2. Update OS Version from the OS Image / Site Groups page:

- Use this link if you would like to patch or rollback an OS Image version for all sites that belong to
particular "non-default" site group. Sites will eventually "converge" to a version of the patch that is
deployed to a site group by either rollback or patch.
- As an example consider following scenario:
Assume three sites (California, New York and Washington) that belong to the Site Group
America.
Assume following OS Image hierarchy registered at HQ: Base Image, Patch 1, Patch 2, and
Patch 3.
Assume at given point of time California has Patch 1 deployed, New York has Patch 2 deployed
and Washington has Patch 3 deployed.
Assuming the administrator at this time deploys/rolls back to Patch 2 for the America Site Group.
As an end state, all sites in America will converge to Patch 2. California will be "patched" to Patch
2, Washington will be rolled back from Patch 3 to Patch 2 and New York will remain as is.
83
18
Additional Information
More information about Wyse WSM can be found at: http://www.dell.com/us/business/p/wyse-wsm/pd
The Wyse WSM Reference Architecture and Configuration Guide for WSM 4 is available here:
http://i.dell.com/sites/doccontent/business/solutions/engineering-docs/en/Documents/wyse-wsmreference-architecture.pdf
Service and support information is available at: http://www.wyse.com/serviceandsupport/
Wyse Online Community: http://community.wyse.com/forum/forumdisplay.php?16-Wyse-WSM
If you have a technical question please check the online Knowledge Base at
http://www.wyse.com/serviceandsupport/support/askwyse.asp, raise a case the Self-Service Portal or
engage with your local Dell CCC Sales Team.
84

Wyse WSM 7 Sizing and Planning Guide

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Wyse WSM 7 Sizing and Planning Guide

Enviado por

Direitos autorais:

Formatos disponíveis

Wyse WSM 7 Planning and Sizing Guide

Dell Cloud client-computing

A Dell Technical White Paper

Revise Client Caching feature naming

Application layering post mount feature

Updated for WSM 7.1.0 release

Updated for WSM 7.2.0 release

Add RAID mode on server sizing part, updated resource links

Wyse WSM 7 Planning and Sizing Guide | Version 20150212

Wyse WSM 7 Planning and Sizing Guide | Version 20150212

New Features in WSM 7.0.0 ..................................................................................................................................................... 8

New Features in WSM 7.1.0 ...................................................................................................................................................... 9

New Features in WSM 7.2.0 ................................................................................................................................................... 10

High Level Overview of the WSM Solution .......................................................................................................................... 11

Network, Infrastructure Services and System Security ..................................................................................................... 16

Network Topology ........................................................................................................................................................ 16

Network Infrastructure and Services ......................................................................................................................... 18

PXE Boot ......................................................................................................................................................................... 20

Non-PXE Boot ............................................................................................................................................................... 21

System Security Credentials ........................................................................................................................................ 24

Server Roles and Group Concept ......................................................................................................................................... 26

Server Groups ................................................................................................................................................................ 27

Device Groups ............................................................................................................................................................... 28

Adding Devices .............................................................................................................................................................. 28

Site Based Architecture ........................................................................................................................................................... 29

Site Groups ..................................................................................................................................................................... 31

Site Templates ............................................................................................................................................................... 31

Secure Communications for Linked Sites ................................................................................................................ 33

Site Version ..................................................................................................................................................................... 34

OS Image Creation and Patching ......................................................................................................................................... 36

Write cache Modes ....................................................................................................................................................... 38

OS Image updates ........................................................................................................................................................ 40

Reference Device Group ............................................................................................................................................. 41

OS Image Patch Rollback ............................................................................................................................................ 41

Content Distribution for Linked Sites ........................................................................................................................ 42

Bandwidth Throttling .................................................................................................................................................... 43

Wyse WSM 7 Planning and Sizing Guide | Version 20150212

Image compression ......................................................................................................................................................44

Offline deployment of OS / Application Images .....................................................................................................44

Automatic cleanup of older images versions...........................................................................................................44

Fast Patch .......................................................................................................................................................................44

10 High Availability and Disaster Recovery ............................................................................................................................... 45

11.2 Storage Requirements .................................................................................................................................................. 52

Wyse WSM 7 Planning and Sizing Guide | Version 20150212

15 Multi-Platform Support (Golden Image) .............................................................................................................................. 65

Wyse WSM 7 Planning and Sizing Guide | Version 20150212

Overview of the WSM solution

WSM Admin Guide

Wyse WSM 7 Planning and Sizing Guide | Version 20150212

New Features in WSM 7.0.0

Wyse WSM 7 Planning and Sizing Guide | Version 20150212

New Features in WSM 7.1.0

Application layering on Windows 8.1

Wyse WSM 7 Planning and Sizing Guide | Version 20150212

New Features in WSM 7.2.0

Wyse WSM 7 Planning and Sizing Guide | Version 20150212

High Level Overview of the WSM Solution

Wyse WSM 7 Planning and Sizing Guide | Version 20150212

User customization support

Wyse WSM 7 Planning and Sizing Guide | Version 20150212

Wyse WSM 7 Planning and Sizing Guide | Version 20150212

Setting up a WSM environment is easy!

Install the WSM Server software

Wyse WSM 7 Planning and Sizing Guide | Version 20150212