Emerson Exchange 365

In reply to Youssef.El-Bahtimy:

Interesting... I am quite new to this plant, and learning the.. Quirks. We are still on version 12.3.1 and this was likely configured around 2003.

Private Sub CommandButton1_Click()
Dim shellcont
shellcont = Shell("C:\Program Files (x86)\Internet Explorer\iexplore.exe", 1)
End Sub

If there is a better way to do it, I'm interesting in trying. Can you show me how I would use frsruntask? I'm not very familiar with programming, I can just decipher what is already written. Thanks for the pointer.

In reply to Brodie Hinch:

We actually have a PCSD Faceplate to reference (it opens up a Syncade MES interface, but it is generic enough to do what you need):
Private Sub CommandButton1_Click()

'These Error Handler lines are standard practice, nothing special here
On Error GoTo ErrorHandler

'This is Where you can put the URL to your Web Application
'You can define it once or if you want to indirect it from somewhere else you could.
Dim strPath As String
strPath = "https://hostname"

'This is frsruntask. Notice how explorer and not internet explorer specifically is called.
'This will defer to windows setting for how URLs are handles (your default browser, which is typically IE)
frsruntask "explorer", strPath

Exit Sub

'More Standard Error Handler Lines
ErrorHandler:
frsHandleError

End Sub

One thing to note about using a web browser from inside the control system is that even if these are not able to get out to the internet , the application itself poses a cyber security risk that should be mitigated with proper lockdown of the browser. (Essentially disables menus, shortcuts, features, and other vectors that can allow unintended access to the OS or network).

I believe that a workstation hardening template exists for group policy implementation of workstations that would be a good starting point, but as this could also prevent access to necessary functions, you would have to test it in development and/or bring in experts on the hardening process before deploying.

Good luck.

In reply to Brodie Hinch:

I'm gonna agree with Yousef that the FRSRunTask function should be used. However, it likely would not help your case.

The FRSRunTask provides some additional error Checking and calls the FRSHandleError. The script above has no error handling. So if there is something amiss, you have no additional information. FRSRunTask is a more robust approach and should be used rather than the above code.

The FRSRuntask uses MyAppID - Shell (strApp + " " + strExecutable + " " + strParameters, 0)

It constructs the path with some string variables you pass to the function, but still uses the SHELL command. The difference I see is FRSRunTask sets the last term to 0 rather than 1. I'm not sure what that does.

Flexlock uses an alternative desktop that restricts access to windows functions. It has no task bar or start menu. you cannot access the Windows applications except via the DeltaV Operate button, and then only the applications that are exposed within Operate, such as your button to launch Explorer.

If you are an administrator or have been granted access to the Windows Desktop, you can select this in the Flexlock window. If the current user does not have windows desktop privilege, they stay in the DeltaV Desktop. it is part of the access security built into DeltaV.

Back to your problem, it does seem to be a user security/privilege issue. The Administrator account has "god like" privileges in a system that can bybass some security settings. If certain privileges were to not be explicitly assigned to anyone, the Administrator account can save the day. However, we highly recommend disabling this account once you have created your own administrator account(s) and if you are both a DeltaV user and a DeltaV Administrator, create two accounts and only use the admin account when needed. Use a Regular windows account for normal DeltaV activity and logons.

This may relate to some Global Policies on your system. But why did this only affect one of your 16 stations?

You can disable Flexlock's Auto Switch Enable so that you can log on with the normal user accounts and stay in the Windows desktop. That will allow you see if any user can launch Operate and the IExplorer. Right click on the upper left icon in Flexlock to see a drop down menu. Deselect Aut Switch desktop. This only affects the station you do this on. Once you've finished your tests/investigation, be sure to turn this back on. you need to be logged on with a DeltaV administrator account.

DeltaV has a button to open an IE browser for use with DeltaV LogBooks. it is hard coded to open the window with the URL to the Logbooks server. This is done with a Global Variable in FRSVariables called gs_DeltaVLogbooksURL.CurrentValue. If the variable has a string in it, the button will be visible in the Toolbar. You could set this variable to point to your internal web server and see if that opens the browser successfully.

The Button is in the Toolbar_1920x1080_XP picture under the grpToolbar/grpMainButtons/bmpOpenOpLog bitmap.
You can't copy this and change it as the underlying code (below) is locked and uses the global variable. The visibility on the Bitmap checks the variable has been defined.

This button does not use FRSruntask or the Shell command. It creates an instance of Internetexplorer and sets various parameters including the URL, visibility, and disables the Address bar, Status Bar, Toolbar and menubar. This leaves the user in restricted Browser and they can't go off to websites they shouldn't be visiting.

The function code looks like this:

Public Sub frszOpenOpLog(PicObj as object)
On Error GoTo Error Handler

DimoIE1 as Object
Set oIE1 = CreateObject("INTERNETEXPLORER.APPLICATION")
oIE1.Navigate frsvariables.gs_DeltaVLogbooksURL.CurrentValue
oIE1.Visible = 1
oIE1.AddressBar = 0
oIE1.Statusbar = 0
oIE1.Toolbar = 0
oIE1.Menubar = 0
Exit Sub

Error Handler:
frsHandleError
End Sub

Why does this affect one station (Thin CLient and not others) I'm wondering if there might be something in the Thin client Remote desktop connection. Does this thin client log on differently than the other thin clients to the VM? uses a default Thin Client user that is not the same as the VM OS user? Hmm. Could this be leaving the Windows account with different windows privileges than on other VM's?

So, I don't know what is causing this, but you should update how you launch apps like IE and consider locking them down.

One last point (I always seem to have one). As Yousef mentioned, you can end up with a bunch of open hidden windows when you have a button like this. Even if the windows are opening, DeltaV Operate will hide them as soon as the operator clicks on Operate window, which is full screen. Hitting the button again in Operate opens a new instance. this is true with the Open DeltaV Logbooks button.

I'm not a programmer either, but I did enhance the button to first check if an IE window is open and to set that one to be in the focus. If there was no IE window open, I would then open it. This had two benefits: It prevented endless windows from being opened over time, and if the user was in the middle of a form, it reopened the same window so they could continue on rather than open a new one at the root menu or welcome page. I've since lost that script and frankly it was not fully baked. I'd encourage you to seek out some help and make the overall solution more robust.

Maybe someone can offer a solution in this forum...

Andre Dicaire

In reply to Andre Dicaire:

So, I've noticed the behavior Brodie mentioned recently, where trying to invoke another application outside of Operate while in the DeltaV desktop causes it to open, then mysteriously close or scuttle to the Windows desktop after a moment.
I figured it was a v14 security improvement, and thought that as long as I used frsruntask I would be within the authority to spawn the process needed. To be clear, Internet Explorer has Read and Execute rights assigned to the DeltaV windows user group (same rights as the admin for this application), so as long as the OS user is within the DeltaV windows group, I think running it from either desktop should work, provided it does not trigger this "other process checker".
Furthermore, this behavior is exhibited even when the OS user is an administrator, but the DeltaV user is not. When the DeltaV user has authority, the application invocation outside of Operate works. Clearly a DeltaV process trying to restrict this application launch is interfering. Now, I've tested both my code and Brodie's and they both work, so I am a bit stumped.

In reply to Youssef.El-Bahtimy:

So I made this change and it works great for most of our stations, however it doesn't fix my issue where internet explorer closes immediately after opening on the one thin client.

It has to be some sort of permissions issue that I can't track down.

In reply to Andre Dicaire:

Thanks, this will give me something to look into. I'll have to re-read it a few times I think.
However to your last point, the thin client has 3 profiles: Administrator, VirtualizationAdmin, User.

I am able to use admin credentials to login to the VM from all but the User account. And of course when doing that I don't have any issues using Internet Explorer. Using the User profile, it automatically logs in, and I can't see any login information. I was wanting to try using the User profile and logging into the VM as an administrator but I don't have the option...

All of our thin clients have a numbered username to login, that is not an administrator. I'll have to keep digging.

In reply to Brodie Hinch:

What's great about thin clients and terminal servers is that because the real action happens at the server, we usually have more data point samples (i.e. the other thin clients on the same terminal server), or less variables to worry about (i.e. the client build itself is irrelevant, typically).

Let's build a table to correlate:

Client	Terminal Server	DeltaV Session	Client Session / OS User / DV User /  License / Other Properties
Problem Client	Problem Client's Terminal Server	Problem Client Session
OK Client	Problem Client's Terminal Server (is there an OK client assigned to the Problem Client's Server?)	OK Client Session
OK Client 2	OK Terminal Server	OK Client Session 2

We need to determine if another OK client is assigned to the same terminal server as the problem client.

If so, then we only need to compare the properties of how that OK client connects to the terminal server, and especially to DeltaV to isolate it.

Additionally, we can correlate to another terminal server and an OK client on that one for added data points.

I have added several properties which could impact the client once they connect. They are:

1. Client Session : Is the client programmed to automatically grab and hold on to a particular remote client session as depicted in DeltaV Explorer (Under the terminal server operation station's remote client subsystem?) .  Is this session markedly different than others?

2. OS User: Is the client programmed to automatically log in to windows on the terminal server as a different OS user than the ok client on the same terminal server

3. DVUser: Is the client programmed to automatically log in to DeltaV on the terminal server as a different DeltaV user than the ok client on the same terminal server

4. License : Is the dedicated Client Session in DeltaV Explorer licensed differently than the OK client dedicated session

If you don't have another client on that same terminal server, I would ask to put one on temporarily (configured identically to a client on the good client terminal server(s)) and compare.

If you do have another client that works ok on the same terminal server, log it off and log it back on.  If it starts behaving like the problem client after this, (the same goes for a client on any other terminal server) then it is a more global problem.   If we start seeing this or no differences between this client and the others, then we'll have to dig deeper.

In reply to Youssef.El-Bahtimy:

So I'm not exactly clear on all the terminology so I'll answer the best I can.

1. All of the clients automatically login to the terminals servers after a restart, they each have their own username. I've tried delete the non working account and copy over a working one as they are identical.

2. They all have the default user 'operator' once logged in the FlexLock screen, and that is where the Internet Explorer should work. It also works if people log in with unique accounts with more privileges. And again it works on 15/16 stations.

3. So, on our system all usernames are both an OS account and a DeltaV account.

4. In DeltaV Explorer, I don't see a dedicated client session in the Licensing Report. All of the assigned license features are the same.

I'm thinking I'll have to get a hold of our local emerson partner, as I shouldn't spend too much more time with this. Thanks for your help and time,

In reply to Brodie Hinch:

Are you using an RD server (Remote Client Server) or are these windows 10 Virtual machines on a VM host?

Agree its time to get some support.

Andre Dicaire