Running RMS 1.2 on Windows 2003 Terminal Server

We are trying to migrate to a W2K3 Terminal Server environment. We have been testing RMS 1.2 on it using Thin Clients. The problem we are running into is that when we have multiple users logging into the Terminal Server, they are all assigned the same RMS Register Number. Is there anyway to designate a different Register Number for each user logging in?

Thank you,

John Bennett

Reply to
jbennett88
Loading thread data ...

John,

Not supported, there are other issues too, but its Friday and I'm going home!

Multi registry entries per user needed, install probs, printer probs, SQL probs, screen slowness, etc.

Never seen or heard of it working correctly for anyone.

Reply to
Jeff

I've heard it can be done with a few tweaks, but I never looked in to how. I wouldn't want to sell my customers something that isn't supported or recommended by the vendor.

Reply to
Jason Hunt

I have been running RMS v1.2 in a Win2k Terminal Server enviornment for three years. The problen that you encountered with duplicate terminal numbers can be resolved by launching the POS or Manager application from a .vbs script. In profiling the communication from the application I found that there is only one read of the registry when the application first loads. Therefore you can write a script that changes the registry before launching the application. I create a term1pos.vbs and term1manager.vbs script and then replace the RMS shortcuts in the profiles with shortcuts to each of these .vbs scripts. Ex. script:

' Begin code for term1pos.vbs ' Written by Ted Archer ' Version: 1.0 (February 25, 2003)

Option Explicit Dim WSHShell, RegKey, RegKey2 Set WSHShell = CreateObject("Wscript.Shell") RegKey = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Retail Management System\Store Operations\Server\Database\" RegKey2 = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Retail Management System\Store Operations\POSUser\Register\" WSHShell.RegWrite regkey & "Provider", "SQLOLEDB.1" WSHShell.RegWrite regkey & "Persist Security Info", "True" WSHShell.RegWrite regkey & "UserID", "sa" WSHShell.RegWrite regkey & "Password", "%TUOY" WSHShell.RegWrite regkey & "Data Source", "192.168.1.2" WSHShell.RegWrite regkey & "Connect Timeout", "45" WSHShell.RegWrite regkey & "Initial Catalog", "RMS" WSHShell.RegWrite regkey2 & "Number", "1" WSHShell.Run("soposuser.exe") ' End Code

You will want to modify the UserID, Password, and Initial Catalog to match what you have configured for your system. Also set the properties of the shortcut to start in "C:\Program Files\Microsoft Retail Management System\Store Operations". Then it is just a matter of setting the Number of the register to match what you have defined in Store Operations.

M$ has made such a push over the last few years towards supporting thin client computing, it is a shame that they cannot or will not write this support into RMS. I have fountd that thin clients are perfect for my receiving and processing operations as this is done in a warehouse environment that is very tough on PCs.

If you need any further help on using thin clients with RMS, please feel free to contact me.

Ted Archer CIO Fairvilla Megastores

formatting link
snipped-for-privacy@fairvilla.com

Reply to
Ted Archer

Hello Ted,

Thank you very much for your reply. I will be working on it over the weekend and will let you know how it goes. Very positive information and I really appreciate it!

Thanks again,

John Bennett

"Ted Archer" wrote:

Reply to
jbennett88

Hi again Ted,

I posted this question on the NewsGroups yesterday and wanted to find out if you experience the same thing by any chance:

I am running RMS 1.2 (SP2) and am experiencing performance issues when running standard reports. When I go into Store Operations Manager then Reports/Customer/List I click OK and the report generates itself. When I move the cursor/magnifying glass over any of the records (or the report itself), the processor on the machine I am on will stay at 90%+ and the macine will grind to a halt. If I move the cursor to another position on the screen (say the taskbar) or pull up a different window and make it active (say Word) the processor goes down to normal (99% Idle). I have confirmed that this is happening on all the computers I have RMS installed on (both XP and 2003). I even experience this on dual processor systems.

I did some looking up and feel that it might have something to do with the Active Reports feature built in to RMS? Has anyone else experienced this? If so, is there a fix available or a way to disable the Active Report feature?

Thanks,

John

"Ted Archer" wrote:

Reply to
jbennett88

You can use the Security Features built into RMS to disable the Reports Menu.

In SO Manager, click the Security Icon (It looks like a padlock). A dialog box will come up telling you how to use Security Mode...

Press Ctrl+Alt+S - this will activate Menu Security, and all of the Menu items will display in Blue.

Right Click the Reports Menu, and a dialog will appear that lets you disable that menu item for selected security groups. You should probably leave at least one one level unchecked, but it's up to you.

Click "OK" - the Reports menu will now be listed in Red.

Press Ctrl+Alt+S again to exit Menu Security

Click the Security button again to exit security mode...

Once this is done, any Cashiers in the Security Groups you selected will not be able to access any of the items on the Reports menu. There are still a couple of ways you can end up in an Active report though - Physical Inventory springs to mind.

If you disable Active Reports, you're going to have to do a lot of work to replicate all of the reports that it normally provides...

Reply to
Glenn Adams [MVP - Retail Mgmt]

Thanks for the reply Glenn. I guess what I am trying to accomplish is still be able to run reports but stop whatever it is trying to do in the background. For example, I would like to be able to just run a report and not have the report continually processing afterwards. This might not be possible but it is very strange if this is the way it was designed to run.

Thank you,

John Bennett

"Glenn Adams [MVP - Retail Mgmt]" wrote:

Reply to
jbennett88

RMS is a Fat Client. It was never intended to be run under Terminal Services and it makes no attempt to share resources nicely. Even accepting that, there are things going on under the covers that make me cringe sometimes (and laugh at others). I don't believe there is any way disable the "active" part of Active Reports while still allowing the basic reporting functionality. You could use Reporting Services (part of SQL Server) or just ASP pages to recreate the reports though. If you're willing to give up the nice end-user level report customization abilities, you can create basic versions of the reports without too much trouble - you're just getting yourself in for a lot of requests for new & modified reports that the users could probably get for themselves using the Active Reports features...

Good Luck!

Reply to
Glenn Adams [MVP - Retail Mgmt]

Thanks for the reply Glenn, I will try your suggestions.

John Bennett

"Glenn Adams [MVP - Retail Mgmt]" wrote:

Reply to
jbennett88

John,

Have you been able to successfully deploy RMS Headquarters on a Terminal Server? If so, what were some of the hoops you had to jump through?

We are looking into installing RMS Headquarters 1.3 on Windows Terminal Server. Our main reason for doing this is to have one place where users can view enterprise-level sales and inventory data, and run reports. Putting HQ Manager on a terminal server would keep us from having to install the same software and reports on a half-dozen machines in the office, and would allow our road-warriors to access the application over the Internet. 90% of our target users would have a very restrictive security setup, where all they can do is run some standard and custom reports and view (not edit) customer, sales, and item master information. The HQ Server would not be running on this machine, just the HQ Manager.

Bill Yater The Worth Collection snipped-for-privacy@worthltd.com

"jbennett88" wrote:

Reply to
Bill Yater

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.