Introduction

This article attempts to help you understand the concept of primary server in the world of workspace streaming and virtualization. Starting 5.x version of Workspace Streaming (then called AppStream Windows Edition) this concept has been in place. Little bit of background to give you a better idea of primary server. Below a basic small scale configuration of streaming infrastructure setup

 
At a high level, streaming infrastructure consists of a backend component that is associated with a user data source and a database. This is the backbone of the streaming system. To this backend component, you can associate one or more frontend component which consists of the streaming server and streaming portal. The frontend components are the points of contact for the endpoints that are being catered to. Now, primary server is typically defined as the server which is the initial point of contact for an endpoint. This primary server is critical for several functions, most popular of which are pre-cache of applications or pre-cache of icons. Other internal functions include user provision checks, client reporting, etc. In the rest of the article, we’ll cover the various ways of configuring primary server based on scenarios and method of troubleshooting to ensure the right server is set as the primary server.

Configuring primary server

The primary server setting when applied through one of the methods defined below will appear in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Appstream\AppMgr\Apps\License

Method 1

Typically, the server from which the endpoint (streaming and virtualization) agents were installed defaults to be the primary server. This will happen if the end user happens to install the agent by visiting the streaming portal for the very first time from a machine that does not have the agent installed. It is also worth noting that the same effect applies when the agents are upgraded as well. For instance, in the above architecture example, if the end user were to install the initial version from server group 1, the server associated with that server group becomes the primary server. At a later time, if the servers were upgraded to a newer version and this time if the end user happened to visit the server group 2 portal and was upgraded, then this server now becomes the primary server.

Method 2

In a typical enterprise, agent deployment may not always be done this way, instead it could be pushed down using alternate means due to various reasons. In that case, the primary server may not be set unless appropriate property is set. During install, the streaming agent uses a config file called “setupcfg.txt”, this can be used to set the primary server. In this case the properties are split across multiple entries

SWS.STS_SERVER                            Name of the Streaming Server to which the Agent connects
SWS.STS_SERVER_PORT               Port used by the Streaming Server
SWS.USER_NAME                              User Name to configure portal log on and package pre-population
SWS.LAUNCH_SERVER_URL        URL of the portal server to which the Agent connects
 
Example:
 
SWS.STS_SERVER=myapps.company.com
SWS.STS_SERVER_PORT=80
SWS.USER_NAME=
SWS.LAUNCH_SERVER_URL=http://myapps.company.com/loginServlet

Method 3

In some cases, as in the cases of VDI or streamed operating system or agents deployed as part of the gold image it is possible server infrastructure may not be tied to the end points yet. In this case, the primary server may be defined using a registry file of the following format:

 [HKEY_LOCAL_MACHINE\SOFTWARE\Appstream\AppMgr\Apps\Licenses]
"InstallServerPort"=dword:00000050ßthis is for port 80, if the port is different choose the equivalent hex value
"InstallServerName"="myapps.company.com"
"InstallWebPageURL"="http://myapps.company.com"ßit’s preferable to use the same way everywhere, i.e. if using just host name vs. FQDN
"InstallServerIntegratedLogin"=dword:00000001ßequivalent to setting true for cases where integrated login is used. It is almost essential to set this to true if any of pre-cache functions are used.
"AppStreamUser"="<LOGGED_ON_USER_NAME>"ßthis should be a variable replaced based on logged on user
 
This as shown above could be created as a .reg file and deployed through group policy or logon script or equivalent means.

Note: We only need the AppStreamUser if you need something pre-popped before a user logs on, or if integrated login is off and you want something pre-popped as soon as the user logs in.

Method 4

In certain cases, mostly when overriding default settings defined by the policy or for troubleshooting purposes the primary server can be set using the command line API tool appmgrcmd.exe. Here is a sample of this

6.1 SP4 and later

appmgrcmd – sps myapps.company.com:8080 -url http://myapps.company.com:8080 -user guest1 discover
 
-sps                      set primary server
1^st parameter     streaming server name (note that, if port number is not provided it defaults to 80)
2^nd parameter    full portal URL prefixed with -url [optional]
3^rd parameter    windows logged on user prefixed with -user (need to be populated based on logged on user) [optional]
4^th parameter    "true" to have integrated login enabled | "false" to have integrated login disabled | "discover" to check the server setting

Up until 6.1 SP3

appmgrcmd – sps myapps.company.com:8080 http://myapps.company.com:8080  guest1 true
 
-sps                      set primary server
1^st parameter     streaming server name
2^nd parameter    full portal URL
3^rd parameter    windows logged on user (need to be populated based on logged on user)
4^th parameter    true to say it is integrated login enabled; false otherwise

Method 5

The streaming agent has a config file called "appstreamcfg.txt" that accompanies it. Here, the property that defines this primary server is PrePopulation.ServerURL. Note that this property DOES NOT exist in the config file by default. The syntax of this key-value pair is

PrePopulation.ServerURL=<streaming_server_host_name|ip_address>,<streaming_port>,<portal_URL>

Example: PrePopulation.ServerURL=myapps.company.com,80,http://myapps.company.com/loginServlet
[Notice that the fully qualified host name in the 1^st value is identical to the one in the 3^rd value. This is because both components are always installed on the same machine using the same host name.]

This only works for a fresh install.  In case of upgrade this will be ignored since there are already values present in the registry.  Also make sure you don't specify anything in the server field in the client install (or in setupCfg.txt if doing this silently), since those will also write values to the registry causing this value to be ignored.  [This configuration value is mainly for testing.]

Troubleshooting primary server configuration

The most glaring issue an end user will experience is, the pre-cached icons or applications will not appear. Well, for pre-caching to work primary server setting is not sufficient, integrated login user also should be known. So, the obvious test for primary server configuration is to check pre-caching. You can do this by simply right clicking on the tray icon and select “Update Applications” from the context menu. If there has been any changes to application provisioning that have pre-caching turned on must show up.
An alternate and equally simple way to troubleshoot is to run the following command from the command prompt
 
appmgrcmd –qp
 
-qp         query provisions
 
All that we are interested for troubleshooting purpose is the 1^st line of the output. It looks like
 
Provisions for on server myapps.company.com:80 for user guest1:

If the output does not include the server name and / or the user name then make sure proper values get placed in the registry.