Aloha Question about OS on master of 10+ terminal site

[alohaakamai3]

Hi guys,
I’ll get right to the question, with an explanation of the problem below if you feel like reading it, but what I really need to know is: I know there is a connection limit of 10 on XP Pro computers, and when you cross that threshold with terminals trying to connect to the master on aloha systems, I know you can run into “cannot locate master and other network anomalies. I know one solution on large sites is to put something like Win2kServer on one of the terminals and make it be master, but I thought someone responded before by saying that Aloha released a patch or edit (or maybe even a version release) that got around this issue.
What’s the number of Aloha computers on can have with XP pro as master with Aloha, and does such a work around exist?
Here the details surround exactly what’s going on for further explanation:
We’ve got a larger Aloha client (12 terms) that has been without some computers for a while due to remodeling and not using certain areas of the restaurant for some time.
Now that we are including those stations once again (some of which are new units), we’re getting some terminals that occasionally flash “Cannot Locate Master” periodically and similar loss of connection/network anomalies. On slower business volume nights or when some of the computers are off, it’s usually not an issue. It’s a mixed mode of WinXp, Win98, and Win2k terminals.
In general, I believe things to be setup properly, including the patches for Windows 98, etc, and network information looks ok. I know I used to see this problem I some locations where all computers were allowed to me MASTER CAPABLE, and I am in the process of turning that off on all but a few terminals now. But I was actually starting to wonder if it might be this connection limitation issue- and even if it’s not, I’d like to know for future reference.

Thanks!

 

[DTSMAN]

We use to use Win98 for terms 1 and 2 and they were the only ones that could become servers.
Do you have access to the AKBs? You now load RFS, remote file storage, on the system, and this directs aloha around the Windows file sharing and now terminals to not use a cal.

Bo

Remember,
If the women don't find you handsome,
they should at least find you handy.
(Red Green)

http://www.redgreen.com

 

[alohaakamai3]

Thanks for the reply Bo.

At this particular site, I have a few 98 computers and then a Radiant box running 2kSever, which was probably done originally for just that reason- so it could accommodate 10+ connections (an expensive way to tackle that problem for sure, but not something I put into place).

What puzzles me are why the problem wasn't there before. I don't think any of the stations were limited who could be master for the most part (which makes me think they would have seen issues if an XP box became master). We've always had close to 10 running or right around that number, can't say for sure. Sometimes certain areas of this huge place will go unused for months, like a patio station.

However, I do know since this has occurred, I believe it's always been an XP machine that has been master (to the best of my knowledge), so it does account for a problem on some level if more than 10 connections are required.

I don't have article to that RFS at the moment- what is the symptom of XP reaching it's connection limit? Is it this "Cannot Locate Master" blinking intermittently on various terminals?

Thanks.

 

[mmantion]

RFS Troubleshooting Tips

Overview : The aim of this document is to assist users in troubleshooting RFS related errors that are encountered when using Iber/IberQS in a multi-terminal setup using RFS for terminal communications.

The RFS subsystem is used only by Iber.exe, Iberqs.exe, and PayRecon.exe. RFS is enabled and configured using Aloha Manager\Maintenance\Store Settings\System\RFS tab.

The RFS modules are registered on the FOH at FOH startup by IberADM.dll if it detects that the binaries (RFSSvr.exe, RFSSvrps.dll, ComMsgSt.dll) have changed or any of the
RFSSvr settings have changed.

Verifying RFS is Enabled
You can determine if RFS is in use by checking the FOH terminal debouts for UNC paths to the fileserver instead of mapped drives (Z:\ paths). There are no mapped drives on the terminals when RFS is in use.

If RFS is enabled and running, the terminal debouts will show these messages:
Feb 02, 14:27:10 [3852] RFS has been installed
Feb 02, 14:27:10 [3852] RFS libraries have been successfully initialized!

For NT-based machines, you can confirm that the RFSSVR service is running using the Service Control Manager, and verifying the service is in the “Started” state.

Finally, using the Windows Task Manager, if there is a process named “RFSSVR.EXE”, then RFS is running. If RFS is running but does not seem to be responding, first try restarting RFS, and then rebooting the terminal. RFS can be restarted in several ways. You can use the Services MMC Snap-In (Service Control Manager), use NET STOP or SC STOP commands, have RFS shut itself down by issuing the “kill” switch (RFSSVR.EXE /K), or ending the process in Task Manager. Once RFSSVR has been stopped, restarting FOH or Windows should restart RFSSVR. Note – the RFSSVR service will be automatically restarted if another machine on the Aloha network attempts to communicate. For example, if you stop RFSSVR on the Fileserver while the terminals are up, it will immediately be restarted by the master terminal.

Communications Errors
RFS uses DCOM for communication between terminals. If there is an error in establishing RFS communication, errors similar to the ones below will be reported both in the Iber/Iberqs terminal debout, and the RFS client (DEBRFS.*) debouts. Depending on the error, FOH terminals may display a message box and fail to go to the floating logo.

For example, the following error appeared in terminal debout – debout.20060126.01:
[SEVERE], ProcessTXNSystem() Failed to establish RFS Terminal Communication with Term9

As one would expect, this indicates that Term1 was unable to communicate with Term9. The RFS service is likely not running on Term9. This may be due to underlying network failures, or a configuration issue with RFS on that terminal.

First, verify that the terminal is using RFS using the steps listed above. If RFS is not running, determine the problem by examining the debouts and error messages showed by FOH. The Windows Event Log may also have useful messages for discovering why the RFSSR service cannot start.

If the RFSSVR service cannot start due to a logon failure, verify the configuration in BOH and perform a Refresh Data. Make sure the terminal actually restarts Windows. If the terminal comes up and still cannot start the RFSSVR service, verify the service logon information in the Service Control Manager. If the terminal cannot synchronize BIN and/or Data, then manually copy those files from the fileserver to the terminal, then restart the terminal. If RFS will not work after manually synchronizing BIN and DATA, close FOH on the terminal and manually un-register the service using the steps provided below. Next, reboot the terminal. Once FOH loads, it should re-register RFS and restart again. At which point, RFS should be registered and should start when FOH loads.

If the RFSSVR service is started and running, but the terminal cannot communicate, check the network communications between this machine and others on the Aloha network.

RFS uses DCOM, which in turn relies on TCP/IP. Continuing with the example from above with Term9 and Term1:

1) Check if you can ping Term9 from Term1. This is done to ensure that Term9 is on the network, and is reachable from Term1 via TCP/IP.

2) Check to see if DCOM has been enabled.

Win9x/ME systems – Ensure that the correct version of DCOM98 has been installed. The version we need is DCOM98 1.3 (version 4.71.0.3328 or greater).

DCOM98 is not redistributable. However it is available for download from
Microsoft.

http://www.microsoft.com/downloads/...1b-7a11-43e8-b59d-0867f9bdda66&displaylang=en

Run DCOMCnfg and verify the following:
Default Properties Tab
‘Enable Distributed COM on this computer’ is checked

Default Security Tab
‘Enable remote connection’ is checked

WinNT systems - (WinNT, Win2000, WinXP, Windows Server 2003)
DCOM is supported natively in Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003. However it can be disabled. Ensure that DCOM is enabled.

1. Run Dcomcnfg.exe.
2. If you are running Windows XP or Windows Server 2003, perform these additional steps:
a. Click the Component Services node under Console Root.
b. Open the Computers folder.
c. For the local computer, right-click My Computer, and then click Properties.
d. For a remote computer, right-click Computers folder, point to New, and then click Computer.
e. Type the computer name.
f. Right-click the computer name, and then click Properties.

3. Click the Default Properties tab.
4. Click to select (or click to clear) the Enable Distributed COM on this Computer check box.
5. If you want to set more properties for the computer, click Apply to enable (or disable) DCOM. Otherwise, click OK to apply the changes and quit Dcomcnfg.exe.
6. Restart the operating system for the changes to take effect.

3) Check to see if there is a firewall enabled on Term1 or Term9. Either disable the firewall or configure the firewall to allow RFS communication. RFSSvr uses a static port for communication, which defaults to 60050. This port can be overridden via the Aloha.ini – RFSPORTNUMBER setting.

If the Firewall is required to be enabled then refer to RKS ID 7959 – Configuring RFS and Windows Firewall.

4) The RFS modules consist of the following binaries
RFSSvr.exe
RFSSvrps.dll
ComMsgSt.dll

These files are automatically registered on the BOH Fileserver by Ctl4x.dll, and on the FOH terminals by IberAdm.dll. However, they will need to be manually registered on machines that are not running BOH (CTLSvr) or FOH (Iber or Iberqs). Examples would be a BOH terminal dedicated to EdcSvr only. In this case, use of a batch file to register RFS is recommended. The above files must be copied to the BIN folder on the remote machine.

Registration commands –
RFSsvr.exe /Service
Regsvr32 rfssvrps.dll
Regsvr32 commsgst.dll

Please note that RFSSvr accepts a number of optional command line parameters at registration. These parameters correspond to the options available in Aloha Manager. If you have configured RFS to use a specific port number, you should include the Port switch to specify to RFS which TCP port it should use.

1) Register RFSSvr under the Local System account

RFSSvr.exe /Service </LOCALACCOUNT> </DeboutDays 20>
</SeverityLevel 1>

2) Register RFSSvr under a user account

RFSSvr.exe /Service </ACCOUNTNAME Aloha> </PASSWORD hello> </DeboutDays 20> </SeverityLevel 1>

You can also specify the TCP port that RFSSvr should use (RFC 46297)

RFSSvr.exe /Service </LOCALACCOUNT> </DeboutDays 20>
</SeverityLevel 1> </Port 60050>

A “NET START” or “SC START” command should be included at the end of the registration batch file to start RFSSvr (instead of rebooting the terminal):

SC START RFSSVR

or

NET START RFSSVR

 

[alohaakamai3]

Thanks so much! I'll give this is shot and let you guys know if I have any questions!