Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Published App
Does anyone have any experience using an OI App as a Published App from a Server rather a full Remote Desktop session?
We have a site that is trying to do this to standardise their access (they were a hodgepode of remote sessions, network access via drive mapping, network via UNC)
They are getting some issues around 'external' processes, like SMTP and API calls.
For example, they have proven that some automated API processes work when running full remote desktop but fail when run as a published App. We havent fully investigated down to the nitty gritty yet but it seems to be in the COM calls at this early stage.
Basically I am after any known caveats or gotchya that are known if running OI from a published app.
We have a site that is trying to do this to standardise their access (they were a hodgepode of remote sessions, network access via drive mapping, network via UNC)
They are getting some issues around 'external' processes, like SMTP and API calls.
For example, they have proven that some automated API processes work when running full remote desktop but fail when run as a published App. We havent fully investigated down to the nitty gritty yet but it seems to be in the COM calls at this early stage.
Basically I am after any known caveats or gotchya that are known if running OI from a published app.
Comments
I doubt very much that any problems are due to the app being published versus full remote desktop. My guess is that there are some differences in the method used to create the remote app or the resources available to the server that hosts the remote app. It could also be unrealistic expectations attributed to a remote app. For instance, some might think that because the app appears to be running locally on the the user's desktop, that it can access the same resources that an actual desktop app can.
Just out of curiosity, what is the site using to publish the app?
Most of our clients and their IT don’t seem to know much about published apps (TBH, neither did we) but we had one IT that was pretty good and did it for another shared client so we took their instructions and now give it to other clients that ask, with the caveat we are not the experts!
Who would be the SME on the matter in SRPland?
I believe this is the procedure that was followed:
Published Application Setup
Is there anything that stands out as being wrong/missing?
We do tell them that the app is Server based so they shouldnt think there is the same access as the desktop.
Published apps being server based I didn’t expect much behavioural difference for API calls. If I can make the same calls with a Remote Desktop session, I assumed the Published App would behave the same.
I am starting to think things like not having a user environment (and maybe not some environment variables set) might be worth investigating.
One user got a .NET CAS error when trying to SMTP. I haven’t had a chance to try and investigate that one yet.
The App Server has a 'local' client install but since the published App is UNC based, I am wondering if that might also be a problem.
Am I to infer from this that you've tried both the Published App and the Remote Desktop from the same server, but with different results?
That .NET error certainly looks like what you would get if .NET wasn't been installed (or "enabled").
If you ran the ClientSetup.exe (as you should) it should have been installed on a local drive. I know that it is possible for servers to be set up to hide the local drive and provide a home folder, but I think the resources on the local drive are still available.
- The RDP server that is hosting the remote apps must have all of the same configurations as a workstation. This includes the .NET 3.5, Client Setup, Registered OLEs, etc.
- If you are able to be logged into that server via RDP and access things, then you should be good. But also consider the permissions those users logging in might have verses an admin account that you are logging in with. It would be ideal to have an account that is failing log in via RDP and see if the problem persists.
- SRP highly recommends having the OLE controls registered locally on the system. This will reduce the risk of that connection being broken due to a network outage or something like that.
- I am not sure if the API calls are to a local server or to an outside resource but I would log into the system and do some ping checks and some tracing to make sure the traffic is routed properly. We have seen some things fail because the RDP server doesn't have the correct DNS entries for a local server resource.
- If you are using RemoteApp, you can expose Command Prompt to a session or two and run tests from there as a RemoteApp session so you can be confident that you are getting the same experience.
- It would also be worth checking to see if the local RDP server's firewall is blocking some activity. I would doubt it but it is worth confirming.
If I think of more I will share but I wanted to at least get these ideas out there.I think my statement was a bit misleading in hinndsight. I have NOT tried the publish App from the same server at this site. I.T. is being a bit prickly about clear seperation of purposes.
Admitedly this is one of our bigger clients so their infrastructure setup is more complex that the vast majority of setups, including our own.
What I have access to is a workstation that apparently replicates what the users have (non admin user) and direct access to the App Server (where we do have local admin access).
I should be able to source the publish rdp from the workstation and bring it over to the App Server myself.
So to attend to a point both you and @CorbyNagel alluded to, does the client setup also need to be installed on the remote workstation when only using a published app? I would have thought that since everything is being handled by the server that only the install on the server was necessary.
Having said that, I originally assumed that the individual workstations did have a client installed anyway since they have previously been accessing by UNC/mapped drives before but now am not so sure as the workstation I was presented to test with does NOT have anything Revelation/SRP done.
@CorbyNagel
The Application Server, from where the app is published, is fully setup like we would a workstation because that is where I tend to go to do any maintenance work and that is where OEngine services are running etc. Also, I do it for performance purposes, as well as I have local admin rights!
Therefore, I can log into this server via RD and do anything I want and it behaves as expected.
That is what I meant to indicate to Don, that since the Application Server runs fine I therefore expected a published app to that same Application Server to also run the same.
We always copy and register SRP Controls.ocx locally.
The API calls are to an external 3rd party logistics company. As I noted, these POSTs are successful when I log into the App Server via Remote Desktop. They also work, albeit a slower OI experience, when the user’s connect via their old UNC connection. Just not via the published app.
I do also have something odd. A updated revelation licence was put over today for them. It works fine on the App Server. I can see in the engine info a 2026 expiry. However, when loading via a UNC, to that SAME destination, I still get the expiry warning and the Engine Info says expiry of 2025! I have validated they are 100% the same path (I even dropped a file from one side and made sure I could see it appear locally in the other). I ran a hash from the remote workstation on the OEngine.dll file via UNC and compared to the hash I generated from the AppServer.
Definately the same. I have pushed but their IT assures me there is no chaching, shadow copies, etc at all in play here. Obviously I am not believing that but I am trying to also exlude that (potential caching ) being an influence on anything above.
*sigh*
I will reply back to the other items later as it is 1am here. I just wanted to give you the information about the RemoteApp so you could get that resolved.
That is very strange in regards to the API calls. I would definitely try to have IT expose whatever tools you need to check on the API routing and run that as a user. I think that will be helpful to understand what is happening and what error is being received. I can't think of a good reason for that to be failing other than a misconfiguration somewhere. It doesn't seem like it is due to RemoteApp.
I thought for sure I was going crazy even though some sort of cache was the only thing making sense.
The trick is to get them to reboot. They have load balancing servers, seperate Remote Brokering servers, etc etc.
6 different companies all accessing from across Austraia with close to no downtime and unfortunately our app isnt the only thing they use on that host.
Lets see what we can do.
You must be on team Don! Don't worry, I am too. Once upon a time, Don and I discussed this and he mentioned that a fully-localised client was a hot topic without unanimous support over there.
The servers I setup I copy the client files to C:\Revsoft\OIClient. Run the setup from there for there. I get the expected errors where it tries to copy some stuff that already exists but I pay that no heed.
This is also where I copy the SRP stuff to register, as well as the Universal Driver.
Like you said, local to the machine and pretty self contained on each system!
This particular API is using HTTPClient_Services to POST and seems to be struggling regardless of using Msxml2.XMLHTTP.6.0 or Msxml2.SERVER.XMLHTTP.6.0.
At first I thought it was to do with GetTempPath and not having a full desktop profile but I am not sure thats the case now.
I will see what I can get IT to expose.
I'm particularly curious about the API failures. I know you said you haven't gotten into the nitty gritty yet, so keep us apprised when you know more. It would help to know if your API calls are getting rejected immediately (and if there is a response returned) or if they are timing out and no response is being returned.