Wyse WSM 7 Sizing and Planning Guide

A Dell Technical White Paper

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

2 Wyse WSM 7 Planning and Sizing Guide | Version 20150212

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


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 NX-

0S, 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

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

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

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

5 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

6 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

7 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

8 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

9 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


1 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


2 New Features in WSM 7.1.0 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


3 New Features in WSM 7.2.0 WSM 7.2.0 is a maintenance release of the WSM software suite.

New Features:

WSM now supports Wyse vWorkspace license format in adition to the legacy Wyse format.


4 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.


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 quad-

core 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.


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


Setting up a WSM environment is easy!

1. Install the WSM Server software 2. Install the OS and the WSM Client software on a Reference Device 3. Capture an OS Image from the Reference Device 4. Register the OS Image in the WSM console 5. Add clients and assign them to a Device Group so they can stream the OS Image 6. 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.

Figure 1 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.


5 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.


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.


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.


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.


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 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 PXE-

capable 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.


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


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.


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 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.


6 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 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 user-

created 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.


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


7 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.


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.


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 non-

default 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


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.


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.


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.


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.


8 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.


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


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.


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.


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.


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.


9 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.


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(

Documents

Wyse WSM 7 Sizing and Planning Guide