Hi Carla;

   This file is built automatically by the Cloud App Launcher and it includes information on the App Start-up and the last parameters passed to the App on start-up from the last time used.  HTH

For example ...

[dwcenter]
appname=PBCrypto_PC_32P
url=http://localhost:80/PBCrypto_PC_32P/1.01
showStartPage=1
shellPath=C:\Users\Chris\AppData\Local\Launcher\CloudAppShell.exe
startParam=cloudapp://http://localhost/PBCrypto_PC_32P
preloadEvent_Executed={A77E7A71-3DBA-4BC1-998D-198098610EF1}
[shortcut]
appname=PBCrypto_PC_32P
desktopshortcut=1
startmenushortcut=1
startmenushortcut_uninstall=1
desktopshortcutname=C:\Users\Chris\Desktop\PBCrypto_PC_32P.lnk
startmenushortcutpath=C:\Users\Chris\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\PBCrypto_PC_32P (2)

Regards ... Chris

Thanks Chris,

I am in the process of working through how to setup a remote server which will have multiple clients

Here is a sample of how I have it setup so far.

The first application (CloudApp, CloudAppPublisher,ps) are my initial deploys from the IDE and used as a sample.

The two other applications would represent two different clients (QP.CloudApp, QP.CloudAppPublisher, Qp.ps) having the same app.

I modified the Server.json file for each client as below:

"AllowedHosts": "*",
"PathBase": "/QP.CloudApp",

I also modified the webapiurl using the below but did not know how to do this for each client since they each will have a different URL? But on the same website and server?

dotnet CustomizeDeploy.dll -url=http://xxxx.com:80/QP.CloudApp

I also noticed that once the cloudapplauncher downloaded the files to the desktop, the pbapp.ini was putting in QP.ps as the app name - so I am assuming it is pulling that from the folder name?

Not sure if this is the correct setup?

Your thoughts and ideas are greatly appreciated.

Thanks.

Carla

Hi Carla;

  FWIW: I am using a slightly different approach (the Chris Pollach weird way of doing things - LOL) to my PS App deployments, as follows:

1) I always use the FILE (install) approach for both the PS App itself & also a separate file its related PowerServer deployment. This allows the IT team for control the deployment to each environment as they see fit.

2) I only have one website for the CAL and PS Apps that are using HTTP/HTTPS protocols (only).

That means that ...

A) There is only one CAL deployment ever required (one per PB runtime of course).

B) All PowerClient and PowerServer Apps are in the one HTTP/HTTPS website off the primary WWWROOT folder.

3) App PowerServer deployments have there own website

That means that ...

A) Each PS can be varied online/offline/restarted without affecting the other running PS servers.

B) Each PS server can have it's own deployment folder. Less chance of a mix-up file wise. Also, easier for the IT team to identify which is which.

C) Each PS can be bound to it's own IP (Port) Address (as required). .Better security as well.  ;-)

4) In production, I can even split each PS or group of PS's into one IIS instance for better performance. This is also easier to manage for the IT team and for setting up clustering.

5) having one HTTP/HTTP website for App deployment is easier to manage and the activity volume would be low as the access to this area is only when a new user activates a PS App or an App MR is pushed out which then requires PS App users to "refresh" their Cloud App(s). Otherwise, the activity here is almost zero most of the time.

Anyway - just another Chris way of doing things and thus offering some more Food for thought. HTH

Regards ... Chris