RSView authentication problem

[linkman]

Background: hard drive failure, no .mer or .apa files found on the recovered drive. No backup of the application. Installed new hard drive, installed RSView SE server 25 and RSView SE view client and recovered licenses. RSView is version 4.00 CPR 7. An outside vendor setup the PLC and RSView. I am a newbie to all of this and it is unlikely I can get any information from that vendor, if they still exist. I only have a demo version of RSView Studio. This is the only PC used for this so I assume everything is local and not network (until I need to connect to the PLC of course).

I was able to copy the SE client files from the failed drive. When I launch it using RSView SE client, it pops up with "You do not have security privileges to access this application."

I am logged into FactoryTalk locally. I have configured this account for full access to this application using the FactoryTalk Administration Console. I know I'm using the correct password because I get a different message when using the wrong password.

Did the vendor setup the application to require a different userid? Is there a way I can discover it? Am I totally out of luck trying to recover the application in this manner?

 

[Ken Roach]

Ugh. Recovering damaged RSView SE systems even if you have all the source information is difficult enough.

Was this a "Distributed" or a "Standalone" RSView SE system ? Distributed systems always use the FactoryTalk Network Directory, while Standalone systems use the FactoryTalk Local Directory. The activation key might tell you, or the part number of the Server if you know it.

The best thing to do is create a user called Administrator, who is actually a Windows Administrator. That usually gets you into the default account for the project. Users linked to a Windows Domain are different from local Windows users, even if they have the same name; was this system integrated into a Windows Domain ?

RSView SE is a very server-centric system; all of the graphics and datalogs and scripts are stored on the server side. Did you recover those files ?

If the Server project no longer exists, you will get that same "you do not have security privileges" message. It's like thinking you have the wrong door key, but in fact the house is missing.

RA Technical Support might be able to help walk you through this disaster recovery.

 

[linkman]

It is a standalone system. I tried using local FactoryTalk userids Administrator and admin. Same results for both: "You do not have security privileges..."

The system (before the HD crash) was on a domain, but I am currently using the local Windows credentials. I think that the previous setup did not use the administrator Windows login because almost nobody (and certainly not the vendor) knows the password for that account.

I am not certain that I recovered everything on the server settings/files -- it would have been on the same PC/hard drive. In what folders would they normally be stored? Or are there some specific file names to search for?

When I recovered everything I noted that the .cli file was present but had zero bytes in it. Is that normal?

 

[Ken Roach]

The exact path differs by OS and version of RSView SE, but in general the server files are in Document and Settings\All Users\Documents\RSView Enterprise\SE.

The most characteristic files are the *.GFX files for the graphical Displays.

The principal project file is the *.SED file, which contains pointers to all of the system components.

In general, the procedure to create a new RSView SE project out of the bones of an old one is to:

1 - In FactoryTalk View Studio, create a new SE Stand-alone application.
2 - Give a name to your application.
3 - Select Import...
4 - Select RSView Supervisory Edition project (*.sed)
5 - Point to the existing project file that you want to convert and select the *.sed file.

A zero-byte *.CLI file doesn't sound right to me. I guess I've never looked at the size of the file. It's really just a pointer to the project.

FactoryTalk Users can be either Windows-Linked (using the Windows authentication) or ordinary FactoryTalk-specific usernames. Windows-Linked users can furthermore either be Domain users or Local users, so "\Domain\JoeWilson" is a totally different user than 'JoeWilson'.

Most of the time, the local PC's Administrator account is left as a general purpose Administrator account in the RSView SE project. Not always.

 

[linkman]

The exact path differs by OS and version of RSView SE, but in general the server files are in Document and Settings\All Users\Documents\RSView Enterprise\SE.

The most characteristic files are the *.GFX files for the graphical Displays.

The principal project file is the *.SED file, which contains pointers to all of the system components.

In general, the procedure to create a new RSView SE project out of the bones of an old one is to:

1 - In FactoryTalk View Studio, create a new SE Stand-alone application.
2 - Give a name to your application.
3 - Select Import...
4 - Select RSView Supervisory Edition project (*.sed)
5 - Point to the existing project file that you want to convert and select the *.sed file.

A zero-byte *.CLI file doesn't sound right to me. I guess I've never looked at the size of the file. It's really just a pointer to the project.

FactoryTalk Users can be either Windows-Linked (using the Windows authentication) or ordinary FactoryTalk-specific usernames. Windows-Linked users can furthermore either be Domain users or Local users, so "\Domain\JoeWilson" is a totally different user than 'JoeWilson'.

Most of the time, the local PC's Administrator account is left as a general purpose Administrator account in the RSView SE project. Not always.

It looks like all of the necessary files are there. The GFX files are named appropriately for the project. The .sed file is there.

I followed the 5 steps you outlined, yet I still receive the security privileges error. You mentioned "FactoryTalk View Studio." I assume you meant RSView Studio? It does bark at me stating that the demo mode isn't licensed for more than 5 displays. Am I out of luck trying to get it to work without the full version? Or might this be fixed by an uninstall/reinstall of RSView?

 

[linkman]

I figured it out. I needed to configure the application security within SE Studio. From these instructions on Rockwell's page:

https://rockwellautomation.custhelp.com/app/answers/detail/a_id/33103/related/1


Adding the RSView User Accounts

1. With the SE application open in Studio, go to the menu bar and select "Settings - RSView User Accounts". The user accounts window will appear. (For CPR9: select "Settings - Runtime Security..." and then select the "Security Accounts..." button on the Runtime Security dialog box.)
2. Then on the menu bar select "Setup - Add Users/Groups". The security settings window will appear.
3. Click the "Add" button and select the users or groups to add and click "OK". If you do not want to be prompted for a username and password add the Windows Linked User that will be running the application. Then click "OK". Check the "Allow" checkboxes for the security codes desired for those users or groups for the SE application.
4. With the SE application still open, on the Explorer Tree navigate to the top and Select Network or Local, right-click and select Security. Add the user accounts or groups that need access to run the application and check the appropriate Allow check boxes.

I was also able to find the .mer on the old hard drive -- but it didn't do any good for me because I don't have a license for RSView ME and it has more than 5 displays.

Once I did get the SE application running I found out that what the vendor did was nearly useless! It shows a static drawing of the equipment with a few clickable spots, but no dynamic updates as to the status of any I/O. Just as useful as a piece of paper. According to the maintenance techs I have it working now exactly as it was before (well, maybe better). They said they didn't know they could click on any of it. The vendor had setup a web browser based screen that did what they wanted. Grrr...

Ken Roach, thanks for your help.