The first thing to do is check the connection between the Authentication Proxy and VistA. From the console of the Authentication Proxy server launch ApAdmin.exe (c:\Program Files\VistA\AP\Server\ApAdmin.exe). Select the Diagnostics tab. Choose the VistA system of interest from the combo box labeled Connection. Press the Basic Diagnostics button. Each element of diagnostic output will be labeled with ok or error. Find the first line labeled error and look below for a remedy.
xxx is the network name/address of the VistA server of interest. This indicates that there is no network connectivity between the Authentication Proxy server and the VistA server. This is not an ESSO problem but instead a basic networking problem.
xxx is the network name/address of the VistA server of interest. Telnet may not be running your server (only you know if this is a problem). This is not an ESSO problem but instead a basic networking problem.
where xxx,yyy is the network name/address and port number of the VistA system of interest. Things to check include: Is broker currently running on that port? Did you correctly enter the access and verify codes for the Authentication Proxy account on the AP Config tab of this tool? Is there a problem with the Authentication Proxy account? - try RPCTest.exe or telnet to that account to verify the account.
where xxx is the name of this machine. The first thing to check is that you are signed onto the Authentication Proxy server using a domain (and not a local) account with administrator privileges on this system. There are several problems that can occur that are correctable using the Microsoft utility dcomcnfg. Launch dcomcnfg. Select xuesap1 Object and push Properties button.
See above answer.
Maybe. When the workstation software contacts the Authentication Proxy it passes on the network address (or name) of the VistA server. It does not pass on the broker port of interest. The Authentication Proxy can only contact the VistA server at a single port which is configured when the Authentication Proxy is installed. When the Authentication Proxy contacts VistA (via broker) the state of the connection request is stored in a M global. The user's sign-on request references this state information in the M Global. If none of these comments alarms you then the Authentication Proxy will probably work in this situation.
Your verify code on VistA still exists. If it expires then you will be prompted to change it as before (this is handled by the Broker and not ESSO).
ApAdmin is always run on the Authentication Proxy server. It is used to configure/manage the connection between the Authentication Proxy and the VistA server. It signs onto VistA using Broker Silent SignOn.
EssoAdmin can be run from any workstation. It signs onto VistA using ESSO or access;verify codes. It is used to edit/configure higher level ESSO functions like deleting NT -> VistA account mappings or configure ESSO for Visiting.
No, only Windows NT and Windows 2000 provide the necessary security services.
Not on a day-to-day basis. But, verify codes still expire and are required to be replaced. For this you will still have to remember your verify code.
Today, the workstation is configured with the net address of the VistA server and the port number where broker is to be found. ESSO adds one piece of information to this configuration, the net address of the appropriate Authentication Proxy.
ESSO will map your NT account to a single account on a VistA server. If you want to change the VistA account that is mapped to:
No, the protocol takes care of this.
This may occur when you launch esso.exe and press the 'Connect' button. The Authentication Proxy (a DCOM service) must be registered on the workstation. Start the Microsoft utility 'dcomcnfg', select the 'xuesap1' service and press the Properties button. The path should point to 'c:\Program Files\Vista\AP\Support\APClient.exe' and this path and file must exist on the workstation. If the path points somewhere else then from a DOS prompt move to the directory 'c:\Program Files\Vista\AP\Support' and execute the command 'APClient /regserver'. If this path or file do not exist then you must reinstall the package on the workstation.
You are probably pointing to a non-existing Authentication Proxy. The typical cause of this is miss-typing the name or IP address of the Authentication Proxy. To fix, launch esso.exe and press the 'Config' button. Select the entry you are using and correct the Authentication Proxy address. Save and retry.
This message pops up once in a while. I have no idea why exactly. If you figure it out please let me know at bill@nist.gov.
There are two ways. If you want to delete your own mapping then:
If you want to delete a mapping for someone else (and you hold the XUMGR key on the VistA server of interest):
ApAdmin (which runs only on the NT/W2K server where the Authentication Proxy runs) uses a small database to maintain information about VistA system configurations. The utility ApAdmin.exe, in part, edits this database. Esso.exe, as an extension of Broker, uses the Windows registry to maintain information about VistA servers. Both of these must be updated when a port changes.
If you are reading this then there is a good chance you are trying to run Esso.exe on the Authentication Proxy server machine. This does not work!! It raises a conflict in the use of the Broker utility server Client Agent. Esso.exe should only be run on client workstations.
These programs are installed on every workstation in the directory c:\Program Files\VistA\AP\Support. They are used only during the installation of ESSO and could be deleted after a successful installation.
ApClient.exe is used to register the Authentication Proxy service on the workstation. This service runs on the Authentication Proxy server (an NT or W2K machine) associated with the VistA server. This registration is necessary so that DCOM can find the Authentication Proxy on the network.
RegAccess.exe performs a minor edit on the Windows Registry that is necessary for ESSO Visiting to work. By default, the Registry cell used to store VistA servers is configured to be read-only except by the Administrator account. For Visiting to work, this cell must be Read/Write enabled for Everyone.
ApAdmin.exe runs only on the NT/W2K box that hosts the Authentication Proxy server. It is used to configure and test the Authentication Proxy and its link to one or more VistA servers.
EssoAdmin.exe is used to configure all the 'higher level' functions of ESSO. EssoAdmin.exe can be run from any workstation. Upon launch you must sign onto a VistA system using an account holding the XUMGR key. All changes made by this utility effect that one VistA server only. It can:
A note on terminology. See entry What is a Visitor and what is a Traveler?
Early on in the project we used only the term Visitor. We were always confused as to whether we were referring to a user that has an account locally and wants to go visit another site or whether the user has an account somewhere else and wants to visit our site. To improve communications when discussing the Visit facility we created the new term Traveler. As used now the terms mean:
Traveler - a user who has access to your VistA server that wishes to "visit" another site.
Visitor - a user who does not have access to your VistA server that wishes to "visit" from another site
where "has access to your VistA server" means the same as "has valid access and verify codes". So, visitor and traveler refer to the same user but from different points of view.
ESSO manipulates the same Registry cell as regular Broker. The only difference is that ESSO stores a little more information there. Broker uses the Registry cell
HKEY_LOCAL_MACHINE:\Software\Vista\Broker\Servers
to store the list of Vista servers and their port numbers. A single entry in the cell looks like:
alice,9300: REG_SZ: 1
which translates to an entry named "alice,9300" with a value of 1. Broker uses "alice,9300" to mean that the Vista server alice will accept Broker connections on port 9300.
ESSO modifies the format of these entries to look like
alice,9300,ratbert: REG_SZ: 1
adds a third field to the name. This third field, ratbert in this example, indicates that the NT/W2K machine named ratbert offers an Authentication Proxy server that will offer ESSO style connection startup to Vista server alice.
Last Updated: August 23, 2001