Technology.Life.Insight.

Omega Calibre 9605

I was fortunate enough to invest in a new Omega Seamaster Aqua Terra 150M Co-Axial Chronograph GMT recently and found that there was very little online information not only on this stunning timepiece, but the fantastic Omega in-house created movement, the Calibre 9605, living within. This post intends to shed a little more light on the capabilities of this movement and the Seamaster 231 reference models. 23110435202001

(Image courtesy of Omega)

A Brief History of Time (Keeping)

Omega is one of the most renown luxury watch makers in the world with a deep and storied history beginning in the 1840s. The famed Co-Axial movement, present in all Omega automatic watches, was brought to market in 1999 when Omega worked with genius watch-maker George Daniels who created the first new mechanical escapement the world had seen in 250 years. Many mechanical watches up to that point, and still to this day (Rolex), use the traditional lever escapement which make use of a lever with two ruby pallet stones pushed by the escape wheel. The escapement in a mechanical watch is what allows the power of the mainspring to be consumed in controlled manner while keeping near perfect time.

 

In a very simplified example, a tooth of the escape wheel is locked against a pallet stone that has a precise angle cut at the top, slowing the watch's gear train, until pushed to an unlocked position. This action of unlocking an escape wheel tooth sends an energy impulse back to the balance wheel causing it to swing back and forth with its own balance spring. The balance assembly in these movements are referred to as the "regulating organ" and are akin to a swinging pendulum in a pendulum clock. This motion causes the lever to pivot and lock the escape wheel using the opposite stone until pushed open by the next tooth of the escape wheel. This pushing of the balance wheel back and forth results in the frequency of the watch and determines its accuracy, typically 18,000 beats per hour, and is what produces the watch's ticking sound. The traditional lever escapement method requires lubrication of the pallet stones as friction is created when the escape wheel pushes against the angled pallet stones, 18,000 times per hour.

 

Daniels' design was different in that he used a modified lever fork with three pallet jewels driven by a modified double escape wheel fixed to the same axis (hence "co-axial") that separates the locking and impulse activities (rubies on fork: 1 impulse, 2 locking). This design also uses a modified balance with two additional impulse jewels, one for each direction of rotation. Most of the operation is handled by the larger lower wheel with the upper wheel receiving motion from the torque wheel but also sending a balance impulse during the anti-clockwise balance rotation. As the balance rotates clockwise, the entry pallet (on the far left of the fork) moves to an unlocked position and a tooth on the bottom wheel pushes the impulse jewel attached directly to the balance. When the balance completes its clockwise rotation, it swings anti-clockwise and the exit pallet (on the far right of the fork) moves to an unlocked position and a tooth from the top wheel pushes the jewel in the center of the fork. This pushes the lower impulse jewel attached directly to the balance by the end of the fork causing the balance to complete its anti-clockwise motion. The impulses to the balance wheel regulate the frequency of the watch and occur from both the upper and lower wheels depending on the rotational direction of the balance.

 

The expected result of the co-axial movement is an effective elimination of the sliding friction of the pallet stones over the escape wheel with what should ultimately result in less wear and lengthened service intervals. There is also a reduced need for pallet stone lubrication. Neat design but definitely a good deal more complex than the traditional lever escapement with several additional parts. Time will tell if the co-axial escapement is truly that much better but for now the experts agree that Omega has created something special and innovatively differentiated. Here's a great video from Omega detailing exactly how their Co-Axial movement functions: https://www.youtube.com/watch?v=2ID9bGj_gtY

 

image

(base image courtesy of Omega -  I added labels)

 

Calibre 9605 Movement

Omega's Co-Axial calibre has evolved from what began as the 2500 to a fully in-house developed premium movement with several models and complications. The 9300 was Omega's first fully in-house made movement that would change the brand forever. Proving you can do it all under one roof is a big deal for a watch maker and as a consumer looking to invest in a premium timepiece. Omega boasts a few additional innovations which separate their watches from the competition. Omega features a free sprung balance that uses silicon for the balance wheel and balance spring which as a material is incredibly durable and resistant to magnetism. Magnets are the enemy of a mechanical watch and Omega has taken steps to reduce their effects, even more so with the new Master Co-Axial designation via the Swiss METAS certification. The 9605 is a COSC certified chronometer which is a label given to less than 3% of Swiss watches designating that a timepiece is made of the highest quality components and rigorously precision tested. Below is an image of the silicon balance wheel (Si14), balance spring and co-axial escapement.

image

This movement uses a twin barrel mainspring with a slipping clutch in the second barrel to prevent over-winding and is able to provide a 60 hour power reserve drawing from both barrels. This design aspect is also intended to prevent loss of accuracy over time due to any decreased torque when the watch is operating on its power reserves. The 9605 is also outfitted with a traditional column wheel for chronographic functions (start, stop, reset). The weighted rotor on the outermost portion of the movement drives the automatic winding mechanism and can wind the mainspring turning in either direction. The image below is the back of my Seamaster AT showing the balance bridge, 2nd barrel, column wheel and weighted rotor of the 9605 movement, stunningly finished in rhodium plating styled with "Geneva waves in arabesque." Fantastic doesn't begin to describe this remarkable piece.

 

 

Calibre 9605 Functions

The 9605 movement has a fancier twin called the 9615. The movements are identical in function but the 9615 uses gold for some pieces of the movement visible through the transparent case back. The 9605 features four complications in addition to the basic time function: chronograph, date, GMT, 12 hour and 60 minute recorders. This is an incredible tool for traveling! The GMT hand lives with the small seconds hand at 9:00. This small seconds hand is the primary seconds hand for the watch and will always be spinning when the watch is wound. For small seconds the 24 marker of the dial = 60 and the 12 marker = 30. The The sweep seconds hand on the main dial is controlled by the upper chronograph pusher and can run all the time if desired or function as a stopwatch.

 

The 12 hour and 60 minutes recorder hands at the 3:00 subdial is also controlled by the chronograph function via the upper chronograph pusher. This 12-hour subdial at 3:00 can be used to track a specific number of hours or minutes but it can also be used when travelling to another time zone. Simply start the chronograph function when the local time is noon or midnight. The local time will now be tracked via this subdial with the main dial representing the time back home. This is the easiest way to track two time zones while travelling. Alternatively the time on the main dial can be adjusted to reflect the local time. The lower pusher is used to reset the sweep seconds and 3:00 subdial only once the chronograph function has been stopped via the upper pusher.

 

Another useful feature when considering different time zones is the GMT hand in the subdial at 9:00. This hand should always point to GMT/ UTC and is used to calculate the time in another time zone. Simply add or subtract hours based on the offset of the other time zone in question (example, GMT-6). The date is fairly self explanatory but should be noted that Omega uses a gradual change mechanism that will slowly shift the date displayed between the hours of 9pm and 2am each day. Make sure to never manually adjust the date during these hours as damage could occur.

 

The crown has three positions once unscrewed, pulled directly outward.

  • The first position is to manually wind the mainspring for extra power. If the mainspring completely unwinds due to lack of use, you will use this position to restart the watch, ~30 turns of the crown. You can also manually wind if you haven't worn the watch for a few days and want to tighten the mainspring. Never wind the watch while on your wrist!
  • The second position is used to adjust the hour hand on the main dial. When this hand crosses midnight it will change the date.
  • The third position is used to adjust the minute hand on the main dial. Turning this position will also adjust the GMT hand in the 9:00 subdial. Make sure you are on the 'correct' side of midnight when adjusting the GMT hand.

 

image

 

Resources

Omega Operating Instructions

Omega Co-Axial in action

History of Omega

Native RDS in Server2016 - Part 4 - Scaling & HA

Part 1: The Basics
Part 2: RDVH
Part 3: RDSH
Part 4: Scaling and HA (you are here)

Most environments that I've run across using native RDS for VDI (RDVH) tend to be fairly small, <500 seats but I have seen some larger footprints built around RDSH. The single largest problem for the native RDS solution is management of the environment. This tends to get pretty unwieldy from a management perspective around the 500 user mark using native tools. PowerShell can and should be used in larger environments. The RD Connection Broker (RDCB) itself is capable of 10K concurrent connections so clearly supports scale in and of itself, but it's really unfortunate that the surrounding native management tool stack isn't up to the task and there really isn't much to enable it either. Unidesk can be leveraged to extend the native RDS story (currently Server 2012 R2) providing much better manageability by integrating directly with the RDCB to create desktops and collections. Unidesk provides a good solution that fundamentally alters the deployed architecture using a highly scalable and robust layering model.
The other big consideration with scaling the native RDS stack is MAC address management in Hyper-V. This one is important, especially with compute host densities ever climbing as the semiconductors pump out increasingly core-dense CPUs. By default, Hyper-V supports 256 unique MACs per host. Every Hyper-V host in the world has a 3-octet prefix of 00-15-5D, the next two octets are unique to each host and derived from the IP address assignment, the last octet is auto-generated between 00-FF. The last octet alone is an 8-bit value so represents 256 possible MAC address. You can modify the 4th or 5th octets to increase the pool on a per host basis but be very careful that you don't accidentally assign an overlapping value. In other words, don't mess with this unless you really know what you're doing. Another scenario to avoid is MAC address pool conflicts,  which would potentially happen if you deploy a Hyper-V host with a dynamic IP that could be leased to another new Hyper-V server at some point. Very important lesson here is to use static IPs for your Hyper-V hosts.



What about SCVMM?

This question usually comes up in relation to RDS, do you need System Center Virtual Machine Manager (SCVMM), can you use SCVMM, how does it integrate? The Citrix XenDesktop solution requires SCVMM as a component of that architecture for VM provisioning but not so for RDS. In the case of RDS, VMM not only is not required at all but there really isn't a very direct integration path between the products. SCVMM here should be seen as an external management tool to compliment the base set of tools used to manage your Hyper-V Failover Clusters, storage and VMs. So what can you do with VMM in an RDS deployment?
SCVMM can be used as a basic deployment enabler of the environment or a provisioning/ mgmt tool for unmanaged collections, but does not integrate directly with the RDS farm or the RDCB. This means that SCVMM cannot be used to provision any VM intended to exist within a managed pool owned by the RDCB. You can use SCVMM to create VMs for an unmanaged collection or deploy your RDSH VMs while also benefitted from using a much larger pool to manage assignable MAC addresses without worry of conflict or shortage.
To fully appreciate what is possible here it is important to understand the concept of unmanaged and managed collections in RDS. Managed collections are pools that the RDCB creates and maintains using a template VM, including the ability to recreate VMs as needed. Unmanaged collections are pools to which the RDCB brokers connections, but there is no template VM therefore you have to create and manage the pool manually. Everything I've shown so far in this series has been "managed" which is the most common deployment style due to ease of ongoing maintenance. If you want to use SCVMM to manage your desktop pool VMs and take advantage of features like Intelligent Placement and a massive MAC address pool, then you will need to use an unmanaged collection. This model is best suited for a 1:1 persistent desktop deployment and as you can see below, can still make use of UPDs.
For example, in this deployment I have SCVMM 2016 running SQL Server 2014 on a dedicated Server 2016 VM. I wish to deploy and manage a large RDS pool of persistent desktops using SCVMM. The first step is to create an unmanaged collection. This is specified during the creation of the collection by unchecking the "Automatically create and manage virtual desktops" option. Select any additionally desired options and deploy.


Once the collection is created, clone however many VMs required using SCVMM via PowerShell and spread them across the cluster using SCVMM’s Intelligent Placement feature. There is no way in the SCVMM GUI to clone multiple VMs so this operation is scripted, see Resources at the bottom. This method eliminates the concerns about too few or overlapping MAC addresses and balances the VMs across the cluster automatically based upon available capacity. Once the VMs are created, they then need to be manually added to the new unmanaged collection. This can be done using PowerShell or Server Manager. Once this has been done users will be able to see the collection in RD Web Access and the RDCB will be able to broker user connections to the pool. Thousands of VMs could be deployed this way and brokered using RDCB.
Add-RDVirtualDesktopToCollection -CollectionName Name -VirtualDesktopName Clone1 -ConnectionBroker RDCB.domain.com


Alternatively, VMs can be added to the unmanaged pool using Server Manager.


But wait, can't I manually add existing VMs to a managed collection too? Nope! You can add additional VMs to a managed collection but they must be based on the template already assigned to the collection thus ensuring consistency.


Service Templates
The other use case for SCVMM in the RDS context is for deployment and scaling of the surrounding infrastructure using Service Templates. Within SCVMM, one can create a Service Template to deploy entire or individual pieces of an RDS deployment. The Service Template element within SCVMM provides a visual method to build a master script that is used to provision management server VMs using a specific hardware configuration, with specific applications installed, in a specified order of execution. The possibilities here are nearly limitless as you can have at your disposal the full capability of any application, PowerShell or script. Lock down your Service Templates and you could build, rebuild or expand any deployment with the push of a button.


Scaling for Compute

I’ll talk about HA next which inherently brings scalability to the management stack but first, consider compute as part of the architecture. Compute in this context refers to the physical Hyper-V hosts that provide resources for desktop or RDSH VMs, exclusively. The limitations of the compute layer will almost always be based on CPU. It is the one finitely exhaustible resource not easily expanded unless you upgrade the parts. Adjusting resources to provide additional IO, memory or network throughput is a straight-forward process linearly scalable via the capabilities of the server platform. To get the best bang for the buck, most customers seek to deploy the highest reasonable number of users per compute host possible. Hyper-V provides a great deal of CPU efficiency at the expense of slightly higher IO. Depending on the workload and VM profile, one could expect to see 5-10+ VMs per core in an RDS deployment. Compute hosts used for RDSH VMs will require few total VMs per physical host but have the potential to host a much larger number of total users. NUMA architecture alignment is important to ensure maximum performance in these scenarios. A higher number of cores per CPU is generally more important than the clock speed. Considering that it is easy to achieve 256 VMs on a single compute host (default MAC address limit provided by Hyper-V), the appropriate host hardware mix should be selected to ensure the maximum performance and end user experience. Compute hosts can be added to a deployment in block fashion to satisfy a total desired number of users. Keep in mind the nuances of managing a native RDS stack at scale and whether or not it may make sense to invest in 3rd party solutions to bolster your deployment.

Solution High Availability

High-availability can be configured for this solution in a number of different areas. The general principles of N+1 apply at all service levels including physical components. The following guidance will provide a fully redundant RDS infrastructure:
  • Add Top of Rack switching infrastructure for physical port redundancy
  • Add Hyper-V compute and mgmt hosts for failover
    • Hyper-V hosts configured in a failover cluster to protect physical compute resources also using Cluster Shared Volumes to protect storage (ideally cluster mgmt and compute separately)
  • Add load balancers to manage SSL offload and HTTPS connections from clients for RD Gateways and RD Web Access servers
  • Add additional RD Gateway and RD Web Access servers to provide resiliency and redundancy
  • Add additional RDCB servers configured to connect to a clustered SQL Server instance
  • Add a 2nd license server VM configured with temporary licenses, deploy both via GPO but list the primary instance first. Should the primary fail, the secondary will serve the environment using temporary entitlements until the primary is restored.
  • Cluster your file server or add a clustered NAS head back-ended by redundant shared storage for UPDs and user data

Here is another look at the larger architecture but within the context of providing HA:


RDCB HA

The RD Broker itself is the most single important role that needs special consideration and configuration to make it HA. Configuring HA for the RDCB creates a cluster with a DNS name assigned for load balancing that keeps track of the location and assignments of user sessions and desktops. First, create a new database on your SQL server with the RDCB server configured to have dbcreator permissions.


With SQL setup, install the SQL Native Client on all RDCB servers and launch the Configure High Availability wizard from the Deployment Overview.


Choose shared SQL mode, name the clustered RDCB instance and provide the SQL connection string in the following format.
DRIVER=SQL Server Native Client 11.0;SERVER=VMM16.dvs.com; Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDSQL;
         

Once successfully completed, the RDCB will show as HA mode in the Deployment Overview and additional brokers can be added using the same dialog.


RDSH HA

An RDSH collection can be scaled or made HA by adding additional RDSH VMs. Once your new RDSH VMs are created and have the appropriate applications installed, they must be added to the "All Servers" management pool within Server Manager.



Once all hosts or VMs are added to the server management pool, you can add the new VMs to your existing RDS deployment.


After additional RDSH servers are added to the overall RDS deployment, they can then be added to a specific session collection from the Host Servers dialog of the collection management page.


Once successfully added to the collection, all added server instances will be visible and available to accept connections.


Load balancing between multiple RDSH instances can be configured from within the collection properties dialog to ensure equal distribution or bias, if desired. Making a server "heavier" via relative weight will cause the Connection Broker to push more connections to it accordingly.



RDWA HA

Additional RD Web Access servers can be added at any time from the Deployment Overview or Deployment Servers dialogs. Select the new server instance you wish to add, confirm and deploy. As always, make sure this server instance is added to the “All Servers” management pool. Behind the scenes IIS is configured on each selected instance to host the website and feed for RDweb.


Once deployed, you should see the new RDWA instance(s) in the RDS Deployment Properties accessible from the RDS Overview page.

Any Collection made to be visible in RD Web Access will be accessible from any RDWA instance. RDWA instances can be accessed directly via URL, load balanced with DNS or put behind a hardware or software load balancer (F5/ Netscaler).

RD Licensing

RD Licensing is one of the trickier roles to make HA as there is no easily exploitable native method to accomplish this. This is generally true regardless of broker solution selected in this space. There are a couple viable methods that require manual intervention that can be used to protect the RD License role. The first method requires two VMs each configured with the RD Licensing role, hosted on separate physical hosts. The first instance has the purchased licenses installed and validated by the Microsoft Clearing House. The second VM is configured with temporary licenses. Both instances are configured via GPO for users but the server with the validated licenses is on the top of the list. Should the primary fail, users can still connect to the environment using temporary licenses until the primary is back online.
The other method also involves two VMs. The primary VM is configured with purchased licenses installed and validated by the Microsoft Clearing House. The VM is cloned, shut down and moved to a separate physical host. Should the primary instance fail for whatever reason, the cold standby can then be powered on to resume the role of the primary. The caveat to this method is that if anything changes from a licensing perspective, the copy to cold stand-by clone process needs to be repeated.

RD Gateway

To optimize and secure connections to the RDS farm from untrusted locations (the interwebs), RDGW can be used and made HA. RDGW terminates SSL for remotely connecting clients, one tunnel for incoming data one for outgoing. UDP can also be utilized for optimized transport of data over WANs using the HTTP transport.  RDGW is installed like any other RDS role and includes IIS as a requisite part of the install. RD Gateway Manager is used to manage the configuration and policies of the gateway including SSL certs and transport settings that provide the ability to change HTTP/UDP listeners. RDGW can also use RD Connection Authorization Policies (RD-CAP) which can be stored locally on the RDGW installed or managed centrally on an NPS server. RDGW can be load balanced as a regular HTTP web service including the offloading of SSL termination. DNS Round Robin is not supported and cannot be used in this scenario.

Failover Clustering and RDS

Lastly, a quick point on the role of Failover Clustering in RDS environments. Failover Clustering is recommended to provide HA for the Hyper-V environment and component level protection of the RDS deployment. Should a node fail or require maintenance in a Failover Cluster, it’s VMs will be restarted or evacuated to another node with available capacity. RDS is cluster aware in that it remains aware of the location of VMs within a Failover Cluster, including if they move around, but it does not integrate directly nor make direct use of the Failover Cluster. In this context the resources for the VMs themselves can be protected giving the management VMs a place to migrate or restart should a failure occur. Any storage added directly to the cluster should be converted to a Cluster Shared Volume enabling multiple simultaneous writers to each volume. RDS itself doesn’t care what the underlying storage is nor whether the environment is clustered or not. Remember that any provisioning activities you perform will address RDVH hosts directly with the RDCB providing the ability to select the number of VMs deployed on each host.

Part 1: The Basics
Part 2: RDVH
Part 3: RDSH
Part 4: Scaling and HA (you are here)

Resources

Creating Service Templates for RDS in SCVMM
Deploying multiple VMs from a template in SCVMM (PoSH)
Hyper-V Dynamic MAC addressing for RDS

Native RDS in Server2016 - Part 3 - RDSH

Part 1: The Basics

Part 2: RDVH

Part 3: RDSH (you are here)

Part 4: Scaling and HA

image[27]

 

In the first two parts of this series, we explored the basic constructs and architecture of RDS in Server 2016, how to create a farm and how to deploy virtual desktops. In this part we'll look at integrating RDSH into this environment to provide published applications and shared sessions which compliment a virtual desktop deployment. Many actually start with RDSH or published apps as step 1 then move into virtual desktops to provide greater control or performance.

Looking at the overview page of your RDS deployment, you'll notice the session host options are greyed out, this is because the deployment (farm) does not currently have these features installed.

image

 

To add RDSH hosts to an existing RDS deployment, you have to first modify the RDS deployment to enable session-based services. Once your RDSH VMs are created and running within Hyper-V, run the Add Roles and Features Wizard and choose session based deployment. You're going to have deja vu here but remember, this is all to modify the existing deployment and this is the last time you should need to run this wizard. The wizard will check for the existence of a broker and web access roles which should already exist. Once you get to the RD Session Host part of the dialog, here is where you add your session hosts to the deployment and install the RDSH role on each. Select your target VMs, confirm and deploy. The VMs receiving the RDSH role will be restarted as part of this process.

image     image     image

 

Via PowerShell (change to your server names):

New-RDSessionDeployment -ConnectionBroker CBname.domain.com -WebAccessServer WAname.domain.com -SessionHost RDSHname.domain.com

 

Make sure the new servers are added to the Servers pool within Server Manager. At this point you will be able to create a new session collection from the overview page in Server Manager which will no long be greyed out. Give the collection a name, specify the server(s) you want to host the collection and add the user groups you wish to entitle.

image     image     image

    

Via PowerShell (change to your server names):

New-RDSessionCollection -CollectionName RDSH -SessionHost RDSH.domain.com -ConnectionBroker CBname.domain.com

 

If you want to use UPDs to persist user settings between sessions, configure the location and size of the UPDs, confirm you selections and deploy.

image

 

Keep in mind that UPD's are collection-specific, they cannot be used in more than one collection.     

image

 

Via PowerShell (change to your server names):

Set-RDSessionCollectionConfiguration -CollectionName RDSH -ConnectionBroker CBname.domain.com -DiksPath C:\ClusterStorage\Volume1\RDSH_UPD -EnableUserProfileDisk -MaxUserProfileDiskSizeGB 1

 

RD Licensing

By default, RDS will offer a 120-day grace period for licensing, after which you will need to use an RD License server instance with a proper license to suit your licensing mode. The license server activity is a light weight role and can be safely combined with the RD Connection Broker role. From the Deployment Overview page on the main RDS screen, select Add RD Licensing Server. Choose your broker VM and confirm.

image

 

Edit the deployment properties of your RDS Deployment and choose the RD Licensing section. Select your desired licensing mode and RD License server.

image

 

To manage your RDS Cals, launch the RD Licensing Manager from the Server Manager Tools menu. Connect to your license server, right-click and select Activate. Complete the information forms and start the Install Licenses Wizard. The wizard will contact the Microsoft ClearingHouse real-time to authorize your server. Microsoft takes licensing of RDSH servers very seriously as there is a tremendous opportunity for software license abuse. Enter the particulars of your license agreement to activate your deployment.

image     image

 

Another useful tool is the RD Licensing Diagnoser which can help identify problems as well as help achieve compliance. This tool can be launched from the Tools/ Remote Desktop Services menu within Server Manager.

 image

 

Via PowerShell (change to your server names):

Add-RDServer -Server RDLicName.domain.com -Role RDS-Licensing -ConnectionBroker CBname.domain.com

Set-RDLicenseConfiguration -ConnectionBroker CBname.domain.com -LicenseServer RDLicName.domain.com -Mode PerUser

 

Managing the Collection

Once the collection is created it will become available for management in Server Manager. Entitlements, RD Web visibility, client settings and UPDs can be manipulated via the collection properties. Idle sessions can be force logged off while active sessions can be shadowed, disconnected, messaged or logged off. RemoteApp Programs provides application virtualization for programs running within the RDSH servers of the pool to RD Web Access. Session collections can offer full session desktops or published applications, but not both. Virtual GPU is not supported for session collections, you'll need to look to Citrix XenApp for that.

image

 

Once the collection is created you can either publish specific applications or full shared sessions themselves. Individual applications will launch seamlessly and can even be tied to specific file extensions. If you wish to publish a full shared session desktop, this is very easy to do. Simply edit the properties of the collection via the Tasks dropdown on the collection page and ensure that the box is checked to "Show the session collection in RD Web Access." This will provide an icon in RD Web that users can click to launch a full desktop experience on the RDSH server.

image

 

To publish specific applications, select "Publish RemoteApp Programs" from the tasks dropdown in the middle of the page. RDS will poll the RDSH servers currently part of your collection for available apps to publish. As the note at the bottom of the initial dialog says, make sure than any program you wish to publish is installed on all RDSH servers within the collection. Confirm your selections and publish.

image     image     image

 

Via PowerShell (use $variables and script for multiple apps or repeat command for each):

New-RDRemoteApp -CollectionName RDSH -DisplayName "OpenOffice Calc" -FilePath "%SYSTEMDRIVE%\Program Files (x86)\OpenOffice...scalc.exe" -ShowInWebAccess 1

 

Connecting to Resources

At this point, anything you have published and entitled will be available in RD Web Access. By default this URL as created within IIS will be https://<RD Web Access name>/RDWeb and should be secured using a proper certificate.You can see below that I now have a mix of RDSH published apps, a RemoteApp Program from a desktop collection, a session collection, as well as a desktop collection. What users will see will vary based on their entitlements.  To enable direct connection to a collection using the Remote Desktop Connection (RDC), a collection within RD Web can be right clicked which will trigger a download of the .rdp file. This file can be published to users and used to connect directly without having to log into RD Web first.

image

 

Editing the .rdp file in a text editor will reveal the embedded characteristics of the connection which include the client settings, connection broker, gateway and most importantly the collection ID which in this case is "RDSH2". 

image

 

RemoteApp Programs can also be delivered directly to a users' Start menu by connecting the client session to the feed of the RD Web Access Server. This can be configured individually or delivered via GPO. A proper security certificate is required.

image

When a user initiates a connection to a resource with an unknown publisher for the first time they will be greeted with the following dialog. The resources allowed by the remote host can be restricted via deployment properties or GPOs. The RemoteApp will launch within a seamless session window and to the user will appear to be running locally.

image     image

 

At this point the connection broker does as the name implies and connects users to resources within the deployment while maintaining where VMs are running and which VMs users are logged in to. In the next section we'll take a look at scaling and HA.

 

Part 1: The Basics

Part 2: RDVH

Part 3: RDSH (you are here)

Part 4: Scaling and HA

 

Resources:

RDS Cmdlets for Server 2016

Native RDS in Server2016 - Part 2 - RDVH

Part 1: The Basics
Part 2: RDVH (you are here)
Part 3: RDSH
Part 4: Scaling and HA
image[27]
In part 1 of this series we took a look at the over all architecture of RDS in Server 2016 along with the required components  contrasting the function performed by each. If you're not new to RDS, things really haven't changed a great deal from Server 2012R2 from a basic architecture perspective. In this chapter we'll take a look at the RDVH role, what it does, how to get going and how to manage it.

Test Environment

Here is a quick rundown of my environment for this effort:
  • Servers - 2 x Dell PowerEdge R610's, dual X5670 (2.93GHz) CPUs, 96GB RAM, 6 x SAS HDDs in RAID5 each
  • Storage - EqualLogic PS6100E
  • Network - 1Gb LAN, 1Gb iSCSI physically separated
  • Software - Windows Server 2016 TP5 build 14300.rs1
  • Features - Hyper-V, RDS, Failover Clustering

Installation

The first step is to create an RDS deployment within your environment. Consider this construct to exist as a farm that you will be able to install server roles and resources within. Once the initial RDS deployment is created, you can create and expand collections of resources. An RDS deployment is tied to RD Connection Broker(s) which ultimately constitute the farm and how it is managed. The farm itself does not exist as an explicitly addressable entity. My hosts are configured in a Failover Cluster which is somewhat inconsequential for this part of the series. I'll explain the role clustering plays in part 4 but the primary benefits are being able to use Cluster Shared Volumes, Live Migration and provide service HA.
On one of your management hosts that already has Hyper-V enabled, fire up the Add Roles and Features Wizard, select Remote Desktop Services installation and choose your deployment model. "Standard" would be what is chosen most often here unless doing a POC then "Quick Start" may be more appropriate. MultiPoint is something entirely different which carries a different set of requirements. You don't have to use this wizard but it is an easy way to get going. I'll explain another way in a moment.
image     image 

Next choose whether you'll be deploying desktop VMs or sessions. Desktops require the RDVH role on the parent, sessions require RDSH and can be enabled within Server VMs. For this portion we'll be focusing on RDVH.
SNAGHTML463b08fe      image

Next select the hosts or VMs to install the RD Connection Broker and Web Access roles. For POCs everything on one host is ok, for production it is recommended to install these RDS roles onto dedicated Server VMs. You'll notice that I pointed the wizard at my Failover Cluster which ultimately resolved to a single host (PFine16A).

image     image    

The third piece in this wizard is identifying the host(s) to assume the RDVH role. Remember that RDVH goes on the physical compute host with Hyper-V. Confirm your selections and deploy.
image     image

The installation will complete and affected hosts or VMs will be restarted. In order to manage your deployment, all Hyper-V hosts and server VM roles that exist within your deployment must be added to the Servers tab within Server Manager. This can be done at the very beginning as well, just make sure it gets done or you will have problems.
image

At this point your RDS deployment should be available for further configuration with the option to create additional roles or a desktop collection. Unless you are building a new RDS deployment, when adding additional server roles, it is much easier to select the role-based installation method from the Add Roles and Features Wizard and choose the piece-parts that you need. This is especially true if adding singular roles to dedicated server VMs. There is no need to rerun the "Remote Desktop Services Installation" wizard, in fact it may confuse things.
image

Desktop VM Templates and Collections

Before we create a new collection, we need to have a template VM prepared. This can be a desktop or server OS but the latter requires some additional configuration. By default, the connection broker looks for a desktop OS SKU when allowing a template VM to be provisioned. If you try to use a Server OS as your template you will receive the following error:
image[20]

To get around this, you must add the following registry key to any host that sources or owns the master template. Reboot and you will be allowed to use a Server OS as a collection template.
HKLM\System\CurrentControlSet\Services\VMHostAgent\Parameters\SkipVmSkuValidation   REG_DWORD     1
Your template should be a normal VM (Gen 1 or 2), fully patched, desired software installed and manually sysprepped. That's right, RDS does not integrate the ability to auto-clone a template VM to new unique VMs, you need to do this manually as part of your collection prep.
image

Make sure whatever template you intend to provision in your desktop collection is already added to your RDVH host or cluster and powered off.
image[2]

Launch the Create Collection wizard within Server Manager, give the collection a name and select pooled or personal desktops.
image     image


Select the template VM to use to create the collection, if using a Server OS make sure you completed the steps above to make the template VM visible and selectable in the RD Collection wizard. Keep in mind that a template VM can only be used in a single collection, no sharing allowed. Provide an answer file if you have one or use the wizard to generate the settings for time zone and AD OU.
image     image     image

Specify the users to be entitled to this collection and the number of desktops you wish to deploy along with the desired naming convention. For allocation, you can now decide how many VMs of the total pool to provision to each available physical host. Take note of this, VMM is not here to manage Intelligent Placement for you, you can accept the defaults or decide how many VMs to provision to a host.
image     image
    
Select where to store the VMs: this can be a local or shared drive letter, SMB share or CSV. The ability to use CSVs is one of the benefits of using Failover Clustering for RDS deployments. Next, if you intend to use UPDs for storing user settings, specify the path and size you want to allocate to each user. Again, CSVs work fine here. Confirm and deploy.
image     image     image

Behind the scenes, RDS is making a replica of your template VM's VHDX stored in the volume you specified, which it will then clone to the collection as new VMs.
image

The pooled VMs themselves are thin provisioned, snapped (checkpointed) and only consume a fraction of the storage consumed by the original template. When reverting back to a pristine state at log off, the checkpoint created during provisioning is applied and any changes to the desktop OS are discarded.
image

UPDs are ultimately VHDX files that get created for each user that connects to the collection. By default all user profile data is stored within a UPD. This can become unwieldy if your users make heavy use of the Desktop, Documents, Music, etc folders. You can optionally restrict which pieces should be stored within the UPD and use folder redirection for the others if desired.
image

When UPD is enabled for a collection, there is a template UPD created within the volume specified then each user gets a dedicated UPD with the SID of the user as the file name. Selected settings are saved within and follow the user to any session or desktop they log into within the collection. This file will grow up to the maximum allotted.
image

Managing the Collection

Depending on the speed of your hardware, your pooled VMs will deploy one by one and register with the broker. Once the collection is deployed it will become available for management in Server Manager. Entitlements, RD Web visibility, client settings and UPDs can be manipulated via the collection properties. Desktop VMs can be manipulated with a basic set of controls for power management, deletion and recomposition. RemoteApp Programs provides a way to publish applications running within the desktop pool to RD Web Access without requiring RDSH or RD Lics which may be useful in some scenarios. Virtual GPU can also be enabled within a desktop collection if the host is equipped with a supported graphics cards. Server 2016 adds huge improvements to the Virtual GPU stack.
image

Notice here that RDS is aware of which VMs are deployed to which hosts within my cluster. Should a VM move between physical hosts, RDS will see that too. When removing VMs from a collection, always do this from the Collections dialog within Server Manager as it's a cleaner process. This will turn off the VM and remove it from Hyper-V. If you delete a VM from Hyper-V manager, the RDS broker will report that VM as unknown in Server Manager. You will then need to delete it again from within Server Manager.
image     image         

If you have an AD object that already exists with the same machine name, that VM will fail to provision. Make sure that if you redeploy any collection using the same names that AD is also cleaned up before you do so.
image

As is always the case when working with VMs in Hyper-V, manual file system cleanup is required. Deleting a VM from Hyper-V or RDS in Server Manager will not remove the files associated with the VM. You could always add them back if you made a mistake but otherwise you will need to manually delete or script an operation to do this for you.
image[17]

RemoteApp Programs can be used to publish applications for users of a desktop collection. This does not require RDSH but it will only allow a single user to connect to a published resource, just like a desktop VM. If you use RemoteApp Programs within a desktop collection, you will be unable to publish the desktop collection itself. For example, I have Google Chrome published from one desktop within my collection, this prevents the entire collection from being presented in RD Web Access only allowing the published app. To make this collection visible in RD Web Access again, I have to unpublish all RemoteApp Programs from the collection then select to show the collection in RD Web Access. The same is true of session collections. You can publish apps or you can publish sessions but not both simultaneously within a single collection.
image

Connecting to Resources

Logging into RD Web Access is the easiest way to access published resources. By default this URL as created within IIS will be https://<RD Web Access name>/RDWeb and can be secured using a proper certificate. Depending on user entitlements, users will see published apps, sessions or desktops available for launching. To enable direct connection to a collection using the Remote Desktop Connection (RDC), a collection within RD Web can be right clicked which will trigger a download of the .rdp file. This file can be published to users and used to connect directly without having to log into RD Web first.
image

Editing the .rdp file in a text editor will reveal the embedded characteristics of the connection which include the client settings, connection broker, gateway and most importantly the collection ID which in this case is "RDC". 
image

At this point the connection broker does as the name implies and connects users to resources within the deployment while maintaining where VMs are running and which VMs users are logged in to. In the next section we'll take a look at integrating RDSH into this environment.

Part 1: The Basics
Part 2: RDVH (you are here)
Part 3: RDSH
Part 4: Scaling and HA

Recent Comments

Popular Posts

Powered by Blogger.

Twitter Feed

.

.