The World Simplified is a Virtual World

The Adventures of Justin Zarb and Dave Falkus in the Virtual Jungle

Micro Branch Scenario

Micro Branch Scenario

  • Comments 1
  • Likes

I saw this great little discussing around the Micro Branch Scenario that Gene Ferioli was discussing. In the 4.5 Help file we describe the Micro Branch Scenario as the following;

Micro Branch Scenario
This scenario is ideal for environments where you need to deploy applications to Clients on workstations in small branch offices where server-class machines are not available to host Application Virtualization Management or Streaming Servers. This scenario was designed to provide the following solutions:
•    Deliver virtual applications to small branch offices that lack server-class machines
•    Maintain a consistent virtual application distribution practice between all offices
•    Deliver virtual applications through Load from File delivery
•    Deploy virtual applications to a single device that can then act as a file server
•    Distribute applications from the file server through unattended operation (script automation)

 

The branch office scenario is absolutely supported in 4.5. 

The recommended deployment strategy is to up a HWS (full SG server; SQL dependency) as your DC refresh (hosted in HQ) server but use the LWS to host/stream content (in the branches).  Remember, LWS is a streaming server only.  The LWS cannot perform DC refresh.   

So the scenario would be the following:

1)  Setup HWS in corp datacenter (i.e. HQ).

2)  Import packages to HWS and configure

3)  Setup LWS, in the branch office, and add packages to the content directory.

4)  The client has some new features in 4.5.  Take look the Application Source Root (ASR).(HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\Configuration).  The ASR is a feature we've added to configure the client to always stream content from a local server (in your case in the branch office). 

For example, if the HREF in the OSD was set to the following:

OSD = RTSP://HQ.mycompany.com:554/Office2007/Off2K7VPCoLM.sft

But the ASR was to:

ASR = RTSP://LWS.mycompany.com:554

Result on what the client will call when the application is launched will be:

RTSP://LWS.mycompany.com:554/Office2007/Off2K7VPCoLM.sft

We've also added an OSD and Icon source root (OSR and ISR) feature to the client too.  This setting can be used so the client will always source it's OSD's and Icons from a local server during DC refresh. 

For example:

Set the OSR and ISR to the following:  \\LWS.mycompany.com\content

When the client performs a DC refresh, it will ignore the OSD and Icon source locations contained in the xml returned to it from the HWS server and use the client OSR and ISR settings instead to retrieve the data.

We also support file streaming in 4.5 so if your branch does not have server class hardware, you could place the packages on a file share (not running SG Server service) and allow the clients to stream from file.

This scenario would like the following.

1)  Client at the branch performs a DC refresh using HWS in HQ (over the WAN).

2)  User now sees applications and launches.

3)  Since ASR (in the case Fille://\\Sever.mycompany.com\Office2007\Off2K7VPCoLM.sft) is being used, the client connects to the file server, downloads FB1 and launches.

Comments
  • Right down the pickle barrel guys!  Is there a way of specifying multiple servers in the ACR, OSR or ISR if the first specified location in the registry key should be unavailable as during maintenance, outage, network issue, etc.

    Thanks....Great improvement!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment