An issue has been raised that some sites are not able to log onto or update the manager password for the AllTalk server.
Symptom: Attempting to open the Manager mailbox results in Error 550 - Unknown Error "0"
The problem is that quite often, during the trial period, a "Temporary" domain is configured for the testing process.
When the system goes live, typically the Manager mailbox is simply copied to the live environment "as is." During the configuration process the temporay Domain is changed to the "Live" Domain name. This leaves the manager's ACI domain details out of sync with the server's domain.
Now because AllTalk supports multiple domains, when you attempt to log on as Manager, AllTalk will automatically hunt for the manager password in ALL domains - that is why it is possible to still log on and manage other accounts. However when you attempt to access the actual Manager account, AllTalk cannot find the correct ACI file for the default domain and returns the "0" error.
Resolution:
In windows explorer, navigate to and open the AllTalk manager's Mailbox folder
1. Change the name of the mangagers ACI file to include the correct DOMAIN name.
2. Change the "TheirDomain" parameter to the correct domain
3. confirm that the "IPAddress" parameter is set correctly for the "REAL" (public) IP address.
Save changes.
(if you have trouble with any of the values, look at the domain name and IP in a recently created AllTalk account)
A new update is available for AllTalk server. Testing has been completed
This update overcomes the problem where Servers unable to access outbound ports would not return a Error messages for unknown sites when using the CERT command.
4) place the updater in a easily accessible location (so you can make many copies of it)
5) Place a copy of the updater into the outbound folder of the Manager profile for each intended client ensuring you rename the file in the format <mailboxName>_AllTalk.exe
6) Transmit the files.
You should monitor the Server logs to ensure that the clients you have updated report a successful update. IF you DONT see a successful update within 1 to 2 minutes after the client has downloaded the file, then contact them immediately as it is likely you will need to do a manual restart (or worst case a manual reinstall).
Updating EQuery clients
As mentioned for the some versions of EQuery, it may be possible to use this updater. You would need to rename the Updater file <mailbox>_equery.exe. We do not recommend this method though as many versions of EQuery did not support remote update.
We recommend for EQuery clients, installing AllTalk and let it run to the Download Popup and click "cancel". This should trigger the Auto Upgrade process from EQuery to AllTalk for those clients running on a scheduler. For EQuery clients that do not automatically update then:
1) locate the EQuery folder.
2) copy the EQI files from this folder into the AllTalk folder.
3) Open the Profile editor and RE-SAVE each profile (you might have to temporarily change an entry to get the Apply button to activate)
4) Uninstall EQuery using the ADD/Remove programs function in control panel.
6) IMPORTANTLY CHECK FOR A WINDOWS SCHEDULED TASK pointing at EQUERY. Update the Scheduled task to point at AllTalk instead. You will need the schedule users password to make the change.
7 IF there is NO scheduled task, recreate the Schedule and Re-Tick "Enable Scheduler at Startup"
Glen.
From: alltalk-avp@... [mailto:alltalk-avp@...] On Behalf Of Glen Kleidon Sent: Sunday, 28 December 2008 3:46 AM To: alltalk-avp@... Subject: [alltalk-avp] Updating Client Installs
Dear All,
To take advantage of the recent updates in AllTalk Server and Client, it is all of our interests to begin a campaign of updating the clients to the most recent version and to begin ensuring that the clients fill in the Provider details.
The new features are :
1. Notify the server that files have been imported into the practice software (ie have disappeared from the download folder)
2. More easily return HL7 Acknowledgements to the Server
3. Be able to receive from any Alltalk client on any AllTalk server.
4. Notify the server of the current version of AllTalk being used.
The Provider details as we have mentioned on a number of occasions allows sites to add the Doctors at the practice to the AllTalk address book and more importantly, now the inter-server relay services are being rolled out, allows AllTalk to delivery PIT and HL7 messages to the clients by just using the Provider number. As always and Opt in list like this perpetuates apathy - if they dont need to do it, they wont. Whenever installing, we encourage you to ask the practice manager to take ownership of this list and manage it accordingly. They are likely to be only ones who really know whats going on.
Performing the Updates
For versions after 1.1.1.89 there is a simple update method from the AllTalk Menu Bar. Click Help--> Update AllTalk and follow the instructions on the web page. This requires the end user to be involved but is a generally safe and reliable update method. All that happens really is a new install is performed after making sure the user has closed AllTalk and AVP to ensure that no critical files are locked. This works automatically for clients that were installed into the c:\alltalk directory. For clients installed using the SVHM installer or the older Barwon EQuery version this will only work if the client uses Scheduled mode - where the new profile editor will detect the presence of the older installation. The Profiles are copied from the old location into the c:\AllTalk folder and AllTalk will restart with the copied profiles.
Updating via download method.
AllTalk has had since the very early versions (and even in EQuery) the ability to update automatically when the Manager user delivers an updated AllTalk Exe via the normal AllTalk download process.
IE to update the site ABC123 to the latest version of AllTalk exe:
1. using an AllTalk profile configured with the Manager users account, simply place a copy of the new exe called "abc123_AllTalk.exe" into the outbound folder.
2. The transmitting account will pick up the file and transmit it to the ABC123 client.
3. The AllTalk client at the other end will automatically detect the updated executable, and place it into the c:\alltalk\update folder.
4. At the end of the download process, AllTalk will fire the Message Viewer (even if Popups are not turned on).
5. The Message Viewer updater will close AllTalk and apply the update if it is newer, and then restart it.
The same goes for all of the other components in the suite including ATMessageViewer.exe, ProfileEdit.exe, (and atPKI.dll, and the ZIP dlls after 1.1.1.94). AVP updates can also be delivered this way.
There are two problems however. In quite a few cases, the older versions of AllTalk, while the update is sucessfull, the client does not always restart and the user is required to restart manually. Second, when there is more than 1 file to update, it requires that you first update the site to the Lastest AllTalk client, then after that is completed, update the other components.
So we have developed a new auto Update method based on the older one. An AllTalk Self extractor program has been created which will be delivered as "pracName_AllTalk.exe". It will replace the existing AllTalk.exe and be executed by the old update process. It will then self extract a complete new version (no prompts) and restart with the new full version. This technique should allow you to remote update any client without them needing to do anything.
In the next few days, we will be posting in this thread:
a) Detailed examples and Instructions for performing the update.
b) the link to the self extractor
c) Suggestions on how to go about distributing the update.
To take advantage of the recent updates in AllTalk Server and Client, it is all of our interests to begin a campaign of updating the clients to the most recent version and to begin ensuring that the clients fill in the Provider details.
The new features are :
1. Notify the server that files have been imported into the practice software (ie have disappeared from the download folder)
2. More easily return HL7 Acknowledgements to the Server
3. Be able to receive from any Alltalk client on any AllTalk server.
4. Notify the server of the current version of AllTalk being used.
The Provider details as we have mentioned on a number of occasions allows sites to add the Doctors at the practice to the AllTalk address book and more importantly, now the inter-server relay services are being rolled out, allows AllTalk to delivery PIT and HL7 messages to the clients by just using the Provider number. As always and Opt in list like this perpetuates apathy - if they dont need to do it, they wont. Whenever installing, we encourage you to ask the practice manager to take ownership of this list and manage it accordingly. They are likely to be only ones who really know whats going on.
Performing the Updates
For versions after 1.1.1.89 there is a simple update method from the AllTalk Menu Bar. Click Help--> Update AllTalk and follow the instructions on the web page. This requires the end user to be involved but is a generally safe and reliable update method. All that happens really is a new install is performed after making sure the user has closed AllTalk and AVP to ensure that no critical files are locked. This works automatically for clients that were installed into the c:\alltalk directory. For clients installed using the SVHM installer or the older Barwon EQuery version this will only work if the client uses Scheduled mode - where the new profile editor will detect the presence of the older installation. The Profiles are copied from the old location into the c:\AllTalk folder and AllTalk will restart with the copied profiles.
Updating via download method.
AllTalk has had since the very early versions (and even in EQuery) the ability to update automatically when the Manager user delivers an updated AllTalk Exe via the normal AllTalk download process.
IE to update the site ABC123 to the latest version of AllTalk exe:
1. using an AllTalk profile configured with the Manager users account, simply place a copy of the new exe called "abc123_AllTalk.exe" into the outbound folder.
2. The transmitting account will pick up the file and transmit it to the ABC123 client.
3. The AllTalk client at the other end will automatically detect the updated executable, and place it into the c:\alltalk\update folder.
4. At the end of the download process, AllTalk will fire the Message Viewer (even if Popups are not turned on).
5. The Message Viewer updater will close AllTalk and apply the update if it is newer, and then restart it.
The same goes for all of the other components in the suite including ATMessageViewer.exe, ProfileEdit.exe, (and atPKI.dll, and the ZIP dlls after 1.1.1.94). AVP updates can also be delivered this way.
There are two problems however. In quite a few cases, the older versions of AllTalk, while the update is sucessfull, the client does not always restart and the user is required to restart manually. Second, when there is more than 1 file to update, it requires that you first update the site to the Lastest AllTalk client, then after that is completed, update the other components.
So we have developed a new auto Update method based on the older one. An AllTalk Self extractor program has been created which will be delivered as "pracName_AllTalk.exe". It will replace the existing AllTalk.exe and be executed by the old update process. It will then self extract a complete new version (no prompts) and restart with the new full version. This technique should allow you to remote update any client without them needing to do anything.
In the next few days, we will be posting in this thread:
a) Detailed examples and Instructions for performing the update.
b) the link to the self extractor
c) Suggestions on how to go about distributing the update.
At last, the long awated Server update is available for download. Apologies for the delay, but there was a problem with the AllTalk (main) service which we needed to get right. This version has been tested now for 3 weeks on three sites without any operational problems (the current build has fixed the service problem.)
This is a very important update as it provides updated Tracking information to allow users to report when files have been imported into the practice software and when HL7 acknowlegements have been generated and returned.
It also allows you to pre-load the users profile with the AllTalk Folders (eg Health message folder), when used with AllTalk versions 2.0 and later.
The update also provides the first layer of interoperability between servers. There will be more details on this feature in the new year.
Extract this folder on top of the existing AllTalk web pages - the files are loaded into the Zip file in the right location at the level of the "AllTalk" folder. (eg if you are using the default Inetpub folder for AllTalk extract to c:\inetpub\wwwroot\AllTalk. Alternatively, extract to a temporary folder and move the files manually to the web page location.
To confirm you have done the update correctly, check the "Create Users" page and confirm is shows "Directories and Programs", the User Page shows "Directories" and that the AllTalk Server config page shows "Enable Standard Email (SMTP) Port"
Remember to take advantage of the additional tracking information you must done the previous updates to your ATTrack Service and Client AND the clients need to be running AllTalk Version 1.1.1.98 or later.
AllTalk Client:
The current version of AllTalk Client is now 2.0.0.3. This is the version allowing which allows easy "New By Download" install (where known servers are shown in a drop down list). see the demo at http://www.lrsupport.com.au/downloads/demos/AllTalk%20Receive%20Only%20install.htm It also supports the server based folder settings.
As there are a large number of AllTalk (and even EQuery) clients out there - at some point we need to begin moving the clients onto the newest version. AllTalk has built in features for updating the client so this is not as daunting a task as it sounds. Watch out for a Yahoo user group discussion thread entitled "Updating Client Installs"
Future Clients:
The Java client is next in line for updating to support then new reporting and "new by download" features. This is in the first Quarter of 2009.
Watch also the Yahoo group for Argus-AllTalk inter-operability news.
These indexes are not required and some may not be useful depending on your site. Below is a discussion about the ATTRack indexes from some time ago (REPOSTED)
From: Mark Rose, St Vincents Pathology (Melbourne)
Hi Glen.
I have a couple of queries I was wondering you could help me with.
1. Size of the Tracking file
We would like to archive the Tracking file in the EQTrak database, as it is getting large, and can take some time to access the data through the application. It is straightforward to create an second copy of the file and to move the archived data in, however, I was wondering whether you would have a tool or preferred method to do this. Also is there a way of accessing this second file through the application / setting up the app to point to another file.
<<< Mark, I think you might need to schedule some time with your SQL Experts.
a) The default install does not create any indexes. With properly defined indexes, then there should not be a performance issue regardless of your database size. Making second copies of a database on SQL server should not be necessary and is strongly discouraged. I remember discussing with John very early on in the piece about creating indexes so I wonder which ones have been defined? Also SQL Indexes need maintenance and should probably be rebuilt once every couple of months. Attached is a document containing a full set of indexes that are likely to give you better performance. Don't apply them all at once! I am assuming that space is not actually the issue here rather performance? Adding the index will probably make the file size half as big again but a 1000 times faster than with no indexes. All of these indexes are going to create a performance hit on Insertion so you might want to try the 4 most important which are MsgID, EQDeliveryTime, EQReceiveTime and PracID and see how you go. The correct indexes to create for your query side will depend on what you commonly search by eg Do you search most commonly by lab number, Patient or Doctor name? The key will be to add indexes slowly until you get the performance you need. But here's what I recommend straight up. Most Important indexes for the Tracking Table http://www.galkam.com.au/images/attrack_common_indexes.png
EQDeliveryTime Create this now!
MsgID Create this Now!
In the index options create non-clustered indexes using the Pad Index option with a fill factor of 65 for all indexes.
Try those 2 first- these not quite the primary key of the table (being so flat as it is) but if you don't already have them, then this should solve your problem immediately. If you already have these indexes, they probably need rebuilding. Next I Recommend adding:
EQReceiveTime
PracID
As for Lookups as mentioned before: index those fields you common search by. Eg Patient and Lab Number, You can also Create a composite index if your most common query involves more than 1 column
Eg if you commonly search for Patient (surname) & date, then a composite index of PATIENT_EQReceiveTime might be suitable (but is sort of inefficient since EQReceiveTime is already indexed).
Another common query is likely to be PATIENT_PracID, but just don't get carried away with creating indexes for everything.
The HM_CONTENT table does not need indexes as it is only ever referenced by MessageID from the result of a Tracking table query.
If none of these solve the problem, we probably need to run the SQL Profiler and Index tuning wizard to get to the bottom of the problem.
b) As for splitting up the datafile, the Preferred method is to not do it. But if you really must create a second copy of the database, then: 1. Create a new DATABASE called "ATTrackArchive" then use the transformation tool (or a SQL statement if your SQL is really good) to export the data older than say "6 months?" to the new database 2. Copy EQTrack and the UDL file (and a copy of the settings file) into a new folder. Double click on the UDL and point at the new "ATTrackArchive" database instead of the original and that should be it.
There are a couple of reasons for this.
1) what are the indexes on your system?
I am trying to locate the document relating to ATTrack Indexes
but in short it should not matter what size your ATTRack database
is. With proper indexes, no search should take more than a few
seconds. I have just posted an old Thread regarding which indexes to
create.
2) Have you the ATTrack client that has the 5 minute timeouts?
http://au.groups.yahoo.com/group/alltalk-avp/message/70
Glen.
--- In alltalk-avp@..., rodneyebird <no_reply@...>
wrote:
>
> Hi Glen,
>
> We are starting to experince 'timeout' errors when using attrack,
even
> for the simpilest of searches.
>
> The current size of our database is 25GB.
>
> Any suggestions/thoughts.
>
> Rodney
>
Dear All,
We have held back the release of the December 1 release of AllTalk
server due to some Tracking Message issues.
I will post details tomorrow relating to an additional change in the
Tracking database settings. This is to do with the size of the "Mailbox"
property. This change needs to be made in your ATTrack database before
using the new release.
ATTrack Service update has been completed. Final testing complete in the
next few days.
ATTrack updates have been running on 2 sites for 2 weeks. All is going
well. There seems to be a number of minor issues - all of these are
non-critical.
Importantly the new pre-set "Health Message" folder option will be
available - it requires the use of the new-by-download function to work
properly to be released in the new Client.
AllTalk client 2.0.0.5 is now in final testing. It implements all of
the new changes discussed in earlier postings. Importantly HL7 message
Acknowledgements can now be easily returned. An acknowledged tracking
message is also being generated. We will release this as a beta next
week.
Glen.
Hi Glen,
We are starting to experince 'timeout' errors when using attrack, even
for the simpilest of searches.
The current size of our database is 25GB.
Any suggestions/thoughts.
Rodney
For Sites Sending HL7 data and using AllTalk Tracking.
I am updating the Tracking record default settings to match HB262-2008 and I would appreciate a few examples from each of you so I can see where I can make improvements. In particular where the the results are requested a copy-to (ie requested by DR A, this copy to Dr B).
In our work from about 18 months ago on Victorian Cytology's Medipath System, we spent a great deal of time generating HL7 messages that were "Generic" ie worked for pretty much every practice software package. Alas all our previous work making it HB262 compliant had to be undone! So we understand the reason why there is non-conformance.
Most significant variance is with the managment of Addressee Doctors and Copy-to Doctors. HB262 says for Unsolicited Results (ie ones without an electronic order) MSH5 should contain the Addresee Doctors details in AUSHIC format eg
MSH|^-&\|QMLPTX|QML^2184^AUSNATA|Dr Harry Green^012345XY.GREEN.HARRY^DR^AUSHICPR|GX32615492^GOLD^L|199710291523+1000||
Most HL7 generators tend to put its Original Intention which is Receiving Application (eg Medical Director etc).
For copy-to information, HB262 (and AS4700) says to use OBR 28 with repeating fields to Identify the doctors that also received a copy (but it is not clear if you are supposed to put the Addressee doctor in this list too...)
Most packages still use a combination of OBR 17 and 18 to manage this. Most use
OBR16 - Requesting Doctor
OBR17 - Addressee (if not same as OBR16)
occasionally OBR18 for Copy to Doctors (HL7 Placer field 1)
occasionally OBR20 using value pair format eg DR=1234567F, CP=Y (indicating the intended doctor's prov num is 1234567F and they are a COPY doctor, not requestor)
If you could send me some de-referenced results for comparison, that would be greatly helpful.
I probably didnt make this so clear,
But of course DNS resolution is also required. The server needs
also to be able to resolve the host names to contact the remote
alltalk servers.
Glen.
--- In alltalk-avp@..., "lrs_y_gk_07" <glenk@...>
wrote:
>
>
> Dear AllTalk Server owners,
>
> There is now an important new requirement for network access for
AllTalk
> server to allow AllTalk server intercommunication.
>
> AllTalk server now must be able to access remote Alltalk servers
on port
> 21025. IE AllTalkServer must have outbound access on port 21025
for all
> IP addresses.
>
> Can you please ensure that before the Update on December 1, that
the
> computer hosting your Alltalk server has permissions to access
21025 at
> any IP address.
>
> The reason for this is to allow intercommunication between AllTalk
> servers - Alltalk server must be able to contact other AllTalk
servers
> to verify credentials and send Delivery notifications. If your
server
> doesn't have permission for outbound 21025 permissions, you wont
be able
> to seemlessly communicate with other AllTalk servers.
>
> A detail explanation of the new services follow.
>
> 1) Remote CERT.
>
> AllTalk server can now return credentials for users on other
servers. IE
> AllTalk clients can now request the encryption certificate for any
other
> AllTalk client regardless of the server on which the account is
held.
>
> The Alltalk server wil respond to the CERT command from an AllTalk
> client by returning the current encryption certificate for the
requested
> address. If the account is not local, the AllTalk server will
attempt to
> connect to the server on which the account is held and if
connection is
> successful, it then replays the CERT command and returns the
response to
> the client.
>
> eg. glen@... <mailto:glen@...>
> connects to the Galkam server and issues "CERT
> abc555@..." . The Galkam server identifies that the
> account is not local and attempts to connect to the LRSupport
server. On
> successful connection, the Galkam server replays the cert
command "CERT
> abc555@...". The LRSupport server returns the
> appropriate response. The Galkam server, then replays the response
back
> to glen@... <mailto:glen@...> .
>
> As far as the glen@...
> <mailto:glen@...> client is concerned, the response
> is no different than one received directly from its own server.
>
> 2) Remote Authentication.
>
> In keeping with AllTalk's Anti-Spam policy, no message can be
accepted
> unless the sender has been authenticated.
>
> AllTalk (or other SMTP) Clients wishing to send secure messages to
an
> AllTalk server for which it is not a member MUST use remote
> authentication. Remote authentication works by the allowing the
client
> to request Authentication from the RECIPIENT'S server and that
server
> relaying the request back to the Senders Server. On receiving a
request
> for remote authentication, the Recipients server makes a
connection back
> to the SENDERs (claimed) server. The client then authenticates as
> normal and the RECIPIENT's Alltalk server "PROXY's" the
authentication
> process - so in effect, the calling client simply authenticates
against
> its own server. For Example:
>
> The Sender (glen@...
> <mailto:glen@...> ) having already determined the
> encryption details for abc555@...
> <mailto:abc555@...> from a previous CERT command,
> connects directly to the LRSupport server on the standard AllTalk
> Messenger port (21025). Because the client knows it does not have
an
> account on that server, it issues a request for remote
authentication
> "AUTH RCRAM-MD5 glen@...". The LRSupport server then
> attempts to make a connection to the Galkam server (the Senders'
claimed
> server) and issues the "AUTH CRAM-MD5" command. The Galkam server,
> simply responds with the standard Challenge string which the
LRSupport
> server returns to the client (glen@...
> <mailto:glen@...> ). The client then authenticates as
> normal using the returned challenge string. The LRSupport server
> monitors the connection for a successful authentication, and once
> satisfied that the Sender is who they claim to be, will then accept
> messages from that client.
>
> Note: There is NO RISK of compromising the sending clients
credentials
> during this process. The CRAM-MD5 authentication protocol is based
on
> MD5 signing and the actual passwords are never sent during the
exchange,
> nor is there any way to derive the password from the exchange.
Further,
> it is not possible to replay the exchange to trick the server into
> providing a logged-on session as the server issues challenges that
can
> never be re-used.
>
> 3) Remote Delivery Notifications
>
> In order that delivery notifications (ATTrack CSV files) are
returned
> to the Sender regardless of which server the recipients mailbox is
> located, AllTalk server supports Remote Delivery Notifications.
>
> AllTalk server generates delivery notifications at the time the
> recipient downloads a message and indicates a successful
decryption (or
> not as the case may be). For Senders on the same server, the
AllTalk
> server simply writes the tracking record directly into the senders
> mailbox in the tracking folder. For senders who are on a different
> server the Recipients AllTalk server will make a connection to the
> senders server on the Messenger port and issue a NOTIFY command.
The
> Senders AllTalk server on receiving the NOTIFY will write the
tracking
> record in the senders Mailbox. Note: should the Senders server be
> unavailable at the time, the recipients server will store the
tracking
> record for sending later when the Senders server is back up.
>
> 4) Remote Address book
>
> It has been proposed in the past that AllTalk servers will be able
to
> exchange Address book details. This is no longer be required as the
> Remote Authentication process now allows clients wishing to
retreived
> address book details to do so directly from any server they wish.
> Together with the fact address book maintenance might represent
> significant traffic for the Server owners, it is no longer our
intention
> to provide this functionality.
>
> However, for the clients who have elected to publish their Doctor
> details in "Organisations and People" the expectation is that other
> AllTalk clients wanting to communicate with them will be able to
do so
> with no more detail than their Published ID (eg Provider Number).
>
> The ability for AllTalk server to deliver messages based on the
Provider
> number is based on the "Entitiy index" which is automatically
built from
> published details in the address book. This index is quite small
(no
> more than a few Kbytes generally) and contains only the link
between the
> Published ID and the AllTalk mailbox. Alltalk servers will
automatically
> exchange Entity Index details ensuring that the details are always
up to
> date.
>
> This information is used by the CERT function to retreived the
mailbox
> for a given Provider number.
>
> eg. glen@... <mailto:glen@...>
> wants to send a message to a doctor whos provider number is
1234567F.
> The client connects to the Galkam server and issues "CERT
12345678F".
> The Galkam server checks for a mailbox of that name and does not
find
> one. It then checks the Entity Index and finds that the provider
number
> is associated with a malbox on the equery.lrsupport.com.au. It then
> carries on as if the client had requested "CERT
> 12345678F@...
> <mailto:12345678F@...> " and as for the remote CERT
> example above, it connect to the LRSupport server and replays the
CERT
> command, returning the response to the client.
>
Sent: Monday, 17 November 2008 2:53 PM To: Glen Kleidon Subject: Mac Question - Crontab / scheduler
Glen,
I have a crontab / scheduler question for the non-mac person (me).
I have seen that the AT2J install package creates the getresults, getresults.cron and eq2jcrontab files from scratch.
Does the mac automatically start Alltalk and then close again according to the scheduler ie, Alltalk does not run in the background, like a PC ? If the mac is restarted the scheduler will just start Alltalk again according to the schedule ?
When I tried to run the macOSX_AT2Installer.app on a Jeff's mac, I got an "error of type -31070 has occurred" error. The mac is not connected to the network / internet. I assume this is what this error is ?
Thanks,
From: Glen Kleidon
Sent: Monday, 17 November 2008 3:22 PM To: ROSE Mark Subject: RE: Mac Question - Crontab / scheduler
Dear Mark,
Yes thats exactly it. It is exactly like using the method for running AllTalk on the Windows Scheduler. IE Windows scheduler starts AllTalk according to the schedule - it runs through all of the profiles and and then terminates.
The Mac version is the same, the CRON daemon calls getresults.cron according to the schedule which in turn executes AT2j with the '/c' (console) switch . This runs without the windows, running through all of the profiles and then it terminates.
The MAC version does not have an internal scheduler or Timer based logins.
As for Jeffs Mac, the Installer does not include the AT2j Jar file. It initiates a HTTP request using applescript to download the ATj 2 from the LRS website. In the normal case, using AllTalk without an internet connection would be pretty pointless - but if you want to use it in an internal LAN, then you would need to set up manually.
The process is :
Open the users home folder. create the folder called EQ2j. Copy the ATj2 into it.
Double Click the JAR and it should open up. Click on Profiles to create the profiles.
Thats all you need to make it work.
But to set up the schedule, you will need to create thegetresults.cron. Open up Text edit and enter ( remember - CaSe SeNsItiVe)
There is now an important new requirement for network access for AllTalk server to allow AllTalk server intercommunication.
AllTalk server now must be able to access remote Alltalk servers on port 21025. IE AllTalkServer must have outbound access on port 21025 for all IP addresses.
Can you please ensure that before the Update on December 1, that the computer hosting your Alltalk server has permissions to access 21025 at any IP address.
The reason for this is to allow intercommunication between AllTalk servers - Alltalk server must be able to contact other AllTalk servers to verify credentials and send Delivery notifications. If your server doesn't have permission for outbound 21025 permissions, you wont be able to seemlessly communicate with other AllTalk servers.
A detail explanation of the new services follow.
1) Remote CERT.
AllTalk server can now return credentials for users on other servers. IE AllTalk clients can now request the encryption certificate for any other AllTalk client regardless of the server on which the account is held.
The Alltalk server wil respond to the CERT command from an AllTalk client by returning the current encryption certificate for the requested address. If the account is not local, the AllTalk server will attempt to connect to the server on which the account is held and if connection is successful, it then replays the CERT command and returns the response to the client.
eg. glen@... connects to the Galkam server and issues "CERT abc555@..." . The Galkam server identifies that the account is not local and attempts to connect to the LRSupport server. On successful connection, the Galkam server replays the cert command "CERT abc555@...". The LRSupport server returns the appropriate response. The Galkam server, then replays the response back to glen@....
As far as the glen@... client is concerned, the response is no different than one received directly from its own server.
2) Remote Authentication.
In keeping with AllTalk's Anti-Spam policy, no message can be accepted unless the sender has been authenticated.
AllTalk (or other SMTP) Clients wishing to send secure messages to an AllTalk server for which it is not a member MUST use remote authentication. Remote authentication works by the allowing the client to request Authentication from the RECIPIENT'S server and that server relaying the request back to the Senders Server. On receiving a request for remote authentication, the Recipients server makes a connection back to the SENDERs (claimed) server. The client then authenticates as normal and the RECIPIENT's Alltalk server "PROXY's" the authentication process - so in effect, the calling client simply authenticates against its own server. For Example:
The Sender (glen@...) having already determined the encryption details for abc555@... from a previous CERT command, connects directly to the LRSupport server on the standard AllTalk Messenger port (21025). Because the client knows it does not have an account on that server, it issues a request for remote authentication "AUTH RCRAM-MD5 glen@...". The LRSupport server then attempts to make a connection to the Galkam server (the Senders' claimed server) and issues the "AUTH CRAM-MD5" command. The Galkam server, simply responds with the standard Challenge string which the LRSupport server returns to the client (glen@... ). The client then authenticates as normal using the returned challenge string. The LRSupport server monitors the connection for a successful authentication, and once satisfied that the Sender is who they claim to be, will then accept messages from that client.
Note: There is NO RISK of compromising the sending clients credentials during this process. The CRAM-MD5 authentication protocol is based on MD5 signing and the actual passwords are never sent during the exchange, nor is there any way to derive the password from the exchange. Further, it is not possible to replay the exchange to trick the server into providing a logged-on session as the server issues challenges that can never be re-used.
3) Remote Delivery Notifications
In order that delivery notifications (ATTrack CSV files) are returned to the Sender regardless of which server the recipients mailbox is located, AllTalk server supports Remote Delivery Notifications.
AllTalk server generates delivery notifications at the time the recipient downloads a message and indicates a successful decryption (or not as the case may be). For Senders on the same server, the AllTalk server simply writes the tracking record directly into the senders mailbox in the tracking folder. For senders who are on a different server the Recipients AllTalk server will make a connection to the senders server on the Messenger port and issue a NOTIFY command. The Senders AllTalk server on receiving the NOTIFY will write the tracking record in the senders Mailbox. Note: should the Senders server be unavailable at the time, the recipients server will store the tracking record for sending later when the Senders server is back up.
4) Remote Address book
It has been proposed in the past that AllTalk servers will be able to exchange Address book details. This is no longer be required as the Remote Authentication process now allows clients wishing to retreived address book details to do so directly from any server they wish. Together with the fact address book maintenance might represent significant traffic for the Server owners, it is no longer our intention to provide this functionality.
However, for the clients who have elected to publish their Doctor details in "Organisations and People" the expectation is that other AllTalk clients wanting to communicate with them will be able to do so with no more detail than their Published ID (eg Provider Number).
The ability for AllTalk server to deliver messages based on the Provider number is based on the "Entitiy index" which is automatically built from published details in the address book. This index is quite small (no more than a few Kbytes generally) and contains only the link between the Published ID and the AllTalk mailbox. Alltalk servers will automatically exchange Entity Index details ensuring that the details are always up to date.
This information is used by the CERT function to retreived the mailbox for a given Provider number.
eg. glen@... wants to send a message to a doctor whos provider number is 1234567F. The client connects to the Galkam server and issues "CERT 12345678F". The Galkam server checks for a mailbox of that name and does not find one. It then checks the Entity Index and finds that the provider number is associated with a malbox on the equery.lrsupport.com.au. It then carries on as if the client had requested "CERT 12345678F@..." and as for the remote CERT example above, it connect to the LRSupport server and replays the CERT command, returning the response to the client.
a) Fixed wrongly reported "Decrypt Failed" for PKI messages when in fact, it had not failed.
b) Fixed faulty Quoted Printable decoding in insecure EMAILs
Features:
a) added Alltalk address to Caption of AllTalk form
b) improved temporary file handling
c) switched to direct write for email data to free up memory for very large downloads (ie AllTalk memory usage does not increase as very large messages are downloaded - only when decrypting).
c) IMPORTANT - updated Send process to identify Mailbox name from HL7 MSH-5 (HB262 standard) or PIT 004, OR attempt to use Provider number by querying AllTalk Servers Entity Index. IE it is no longer strictly required to use the "mailbox_filename.ext" convention. Rules are:
+ if the filename does not contain an underscore. Check for "Argus convention" of line 1 containing "msgrecipient=<emailaddress>" assume email address is Alltalk address or standard email address. (Note: 1.99 does not currently remove the header - this will be fixed shortly)
+ if HL7 or PIT message and Filename does not contain and underscore
+ if HL7 look in FIRST MSH 5 for (as per HB262 13.6 - MSH 5 becomes "Doctor for which a Result is intended"):
+ if an email formatted address is present (anywhere) use the email address as mailbox name
+ if the field contains just a single string (no hl7 fields) assume the field is the alltalk address
+ if the field contains AUSHICPR directive as per AS4700, use the Provider number to test against the Alltalk Entity Index
+ if the field contains standard EI form as per HL7 use MSH5.2 as AllTalk Mailbox name.
+ If PIT Look for:
+ if Surgery Code in 004 (must be greater than 3 and up to 7 characters) use that as the alltalk mailbox (short form)
+ if Provider numbers listed in 010, use the first valid Provider number to identify the intended Mailbox by checking against the AllTalk servers Entity Index
+ if Provider numbers are listed in 123 use the first valid Provider number to identify the intended Mailbox by checking against the AllTalk server Entity Index
Note - above assumes that all results in the PIT or HL7 file are intended for the same Mailbox. So we still intend you to use the Bulk file mover in preference to this approach as it is much more controllable and also fires the autosend (this method does not). It also gives further impetus to get the Doctors to keep their "Organisations and People" updated in AllTalk - the entity Index is only as good as what is put in by the users.
From: alltalk-avp@... [mailto:alltalk-avp@...] On Behalf Of lrs_y_gk_07 Sent: Sunday, 2 November 2008 7:06 PM To: alltalk-avp@... Subject: [alltalk-avp] New Beta Releases
Dear All,
A new alltalk Client beta (Windows) is available for trials. It is version 1.1.1.98 AllTalk 1.1.1.98 Beta
Important fixes:
1. Stack Overflow occasionally seen on close fixed.
2. Client Downloads Address Book more than once per day. The client no longer downloads at startup if address book is current
3. Lost Tray icon, but client still running. If the system tray icon cannot be created due to busy start up process, AllTalk will not minimise.
New Features:
1. Profile Editor "New By Download" feature has been updated. Clients have had poor sucess with this feature due to issues with DNS entries and poor E-Domain name choices. The user longer needs to specify the full mailbox name: they can now select the server from a drop down list see New By Download. IMPORTANT also see thread entitled "Getting Company Names added to the drop download list of Providers"
2. Corrupted files will be deleted from the server after 3 failed downloads and generate a "Failed Download" notification. IMPORTANT See message separate thread entitled "New Features in Tracking Data"
5. Extended Notification features support has been added allowing the sender to be notified when Health Message files have been imported by the server. The feature is will become active when the server is updated the December 1 2008 release.
6. Updated Insecure Email client features allowing AllTalk profiles connecting to standard Email servers to download and automatically extract all attachments to the appropriate folders. For emails containing Plain text Bodies only, the text will be extracted into a text file. For Multipart alternate messages with no attachments, the eml file will be saved unchanged. (Note: the text body is ignored for all emails with attachments).
This is a full release and testing has been completed. To install the update, simply stop the 3 AllTalk services using Windows Management Console. Replace the existing AllTalksvc.exe with the new one and then restart the services.
This is a replacement for the recent Server update (V1.0.0.159 13 October) which an incomplete fix for the Address.IN file problems. Users of that version reported that the while the Address file remained small, the temporary address files were not being cleaned up and that the address data was incomplete. So please ensure that you delete any temporary address files that may be in the mailboxes folder (there may be hundreds).
Deeper investigation the problem revealed that faulty XML data in the some of the clients address details was causing the Address File re-indexing service to terminate abnormally leaving behind the incomplete Address files. This new version overcomes the problem by checking the quality of the XML data before trying to apply it.
NOTE: I thought I sent this message before but I couldnt find it anywhere in the group. So please forgive if it this message is a repeat!
Two important changes to AllTalk Tracking are about to be released.
Decrypt Fail
The "Decrypt Failed" notification is a function that has been present for some time in the Server but has not been used in the past (mainly due to the high reliablility of Alltalk Proprietary encryption). As more clients change over to PKI encryption, the likelyhood of decrypt failures increases due to things like expired/lost certificates etc. AllTalk will attempt to download files 3 times. If it is unsuccessful on the 3rd attempt, the message is flagged for deletion with "Decrypt Fail Notify". Corrupt message are normally skipped by AllTalk (ie wont hold up delivery of other messages)- but on on rare occaions, corrupt files have caused the AllTalk client to crash. The method for tracking the number of failures is robust and will cope with this situation - ie the message will be flagged for deletion on the 3rd unsuccessful attempt to decrypt regardless of whether the AllTalk has crashed.
The tracking records generated by AllTalk indicate different status using "Special" Delivery dates. For example the date used to indicate "Undeliverable" is January 1 1900. The "Decrypt Fail" date is July 6th 1905. The reason for using the date as a flag was to allow sorting of Failed messages in a sensible sort order when browsing the database. Below is a list of the special dates.
There will be a new ATTrack released at the same time as 1.1.1.98 to reflect the new status, but in the mean-time, it is important for you to watch for the decrypt Fail date to identify messages that need resending.
For Medipath/MediRad users:
The background process will be updated to manage the dates. Initially, this will be in the form of a warning
For other systems consuming tracking messages (eg Dorevitch GGG) , you will need to update your systems to manage these special dates.
READ Status Flag
The AllTalk server to be released on December 1st, 2008 will support methods for identifying when Health Messages have been "imported" into the practice software. The flag will be an integer from 1 to (initially) 5. This is implemented in the tracking data using Field 18 of the tracking record. The values are:
1 - Unprocessed. The message has been received and written into the Health message folder 2 - Processed. The message no longer appears in the Health message folder (ie processed by the practice software) 3 - Acknowledged. The message has been acknowledged by PRACTICE SOFTWARE (ie not AllTalk PIT acknowledgement) 4 - Folder Moved. The message was written into a folder which no longer exists (ie AllTalk cant tell what happened to it). 5 - Forwarded By Email . The file was forwarded by an AllTalk email forward rule.
AllTalk Client Version 1.1.1.98 already supports READ status flag 2 (Processed) and 4 (Folder moved) and will become active for sites running the new version of December 2008 AllTalk Server. Flag 1 is the "normal state" and AllTalk client will not be implementing it. Other applications choosing to access the AllTalk server via SOAP services may choose to implement it.
Medipath/MediRad and even the oldest version of ATTrack will manage the change in field so the changes in the format of the Tracking record should not affect successful importation of the records.
For Other systems, you will need to check sucessful importation of the new format using the test files at Tracking File changes . Remember that the design is that the Message ID should always be the LAST Field in the tracking record. It occurs sometimes in 17, sometimes in 18 and (now) sometimes in 19. This was for historical backward compatibility reasons to support the older versions of EQuery Tracking records still in widespread use.
As mentioned in other threads, the new AllTalk Profile editor now allows the users to pick a list of Providers in order to create a new profile. New By Download Profile Editor View
If you would like your company names included in the standard download, please send me the names of the company/s you want to appear AND the alltalk server's Host name (or IP address if there no public DNS for it).
On the client site, the details are filled from a text file of Name/Value pairs called AlltalkServers.txt. Pairs look like this:
Last Resort Support=alltalk.lrsupport.com.au
Royal Womens and Childrens Hospital=alltalk.lrsupport.com.au
You could of course override this file with an custom version of AllTalkServers.txt if you chose to deploy clients yourself.
If for some reason you dont wish your company name to appear (why you would not want that I cant fathom) then please let me know and I will remove it.
I have fudged the entry for ARL and SydPath in this list because I dont know your server address. Can you guys please contact me to get it corrected before the final release?
A new alltalk Client beta (Windows) is available for trials. It is version 1.1.1.98 AllTalk 1.1.1.98 Beta
Important fixes:
1. Stack Overflow occasionally seen on close fixed.
2. Client Downloads Address Book more than once per day. The client no longer downloads at startup if address book is current
3. Lost Tray icon, but client still running. If the system tray icon cannot be created due to busy start up process, AllTalk will not minimise.
New Features:
1. Profile Editor "New By Download" feature has been updated. Clients have had poor sucess with this feature due to issues with DNS entries and poor E-Domain name choices. The user longer needs to specify the full mailbox name: they can now select the server from a drop down list see New By Download. IMPORTANT also see thread entitled "Getting Company Names added to the drop download list of Providers"
2. Corrupted files will be deleted from the server after 3 failed downloads and generate a "Failed Download" notification. IMPORTANT See message separate thread entitled "New Features in Tracking Data"
5. Extended Notification features support has been added allowing the sender to be notified when Health Message files have been imported by the server. The feature is will become active when the server is updated the December 1 2008 release.
6. Updated Insecure Email client features allowing AllTalk profiles connecting to standard Email servers to download and automatically extract all attachments to the appropriate folders. For emails containing Plain text Bodies only, the text will be extracted into a text file. For Multipart alternate messages with no attachments, the eml file will be saved unchanged. (Note: the text body is ignored for all emails with attachments).
As for faxes received before Downloads - we must remember that downloading is NOT supposed to be a way for practices to get results faster than faxes - that is what Online web access (Webstro) is for. The purpose is so that they dont have to type or scan them in!
You could improve download time by having the client log in every 10 minutes or so either by creating a schedule with 10 minute intervals OR switch to timer mode and set the "Check for Results Every.." to 10 minutes.
The other thing to remember is that even if the files download within 10 minutes of their release - there is no guarantee that the process at the client end that imports results does so at on a regular basis.
Glen.
From: Glen Kleidon
Sent: Friday, 24 October 2008 11:25 AM To: Warren, Rob Subject: RE: AllTalk question
Dear ROB,
The schedule is geared toward collection of results.
When you are using the Bulk File Transport module to transmit files, the send/receive process is ALSO triggered whenever there are files to send regardless of the schedule.
Glen.
-----Original Message----- From: Warren, Rob
Sent: Friday, 24 October 2008 10:12 AM To: Glen Kleidon Subject: AllTalk question
Hi Glen
A query on how the AllTalk scheduler works:
We have the schedule set to 8:00;10:00;12:00;13:00;14:00;15:00;16:00;17:00;18:00;19:00 each day but there is also activity at other times eg: <<SNIP>>
I know our client picks up files from \equeryfiles\Pitfiles every 10? seconds but what determines when they go to the LRS Alltalk server?
The reason I ask is because of a report from the Austin that they typically get faxed results before electronic ones. They download hourly so there shouldn't be much of a delay there and the messages don't seem to be held here for very long.
I don't know if the faxes are being released before the electronics by us but I wouldn't expect that to happen consistently.
Just stop All 3 AllTalk services.
Replace the EXE with the new one.
Restart the services.
Glen.
-----Original Message-----
From: Robbins Kerrie (SVHM) Sent: Tuesday, 14 October 2008 9:34 AM
To: Glen Kleidon
Cc: ROSE Mark; BRYANT David (SVHM)
Subject: RE: [alltalk-avp] Re: Client dowloads 'freezing' at address
information
Hi Glen,
do we just need to replace the alltalksvc.exe and restart, or do we
need to uninstall / reinstall the windows service
thanks
kerrie.
--- In alltalk-avp@..., "Glen Kleidon" <glenk@...>
wrote:
>
> Dear All,
>
> We have completed the trials of the latest Version of AllTalk
server.
>
> This release overcomes the increasing size of the the address file
problem.
>
> This release also includes Remote Download notifications - ie
notifies an
> AllTalk remote server of a successful or failed download where the
message
> has originated from a different server from the recipient.
>
> The download is located at
> http://www.lrsupport.com.au/downloads/alltalksvc.exe
>
> _____
>
> From: alltalk-avp@... [mailto:alltalk-
avp@...]
> On Behalf Of lrs_y_gk_07
> Sent: Wednesday, 27 August 2008 11:31 PM
> To: alltalk-avp@...
> Subject: [alltalk-avp] Re: Client dowloads 'freezing' at address
information
>
>
>
>
> Dear Rodney,
>
> There have been reports of the Address.In file increasing to very
large
> size (many MB). Inspection of the address file reveals many
duplicates
> of the address data.
>
> The root of the problem appears to be stray the temporary
> Address.in.tmp file not being deleted each refresh cycle. This issue
> will be resolved in the next version of the AllTalk server.
>
> For the present we suggest scheduling a batch file to delete daily
the
> Address.in file and ESPECIALLY any address.in.tmp files that may be
> present. Schedule this before the standard first schedule login time
> when most AllTalk clients will request the address data. This should
> keep the address file down to a sensible size. Note though that the
> only reasonable explanation for the temporary address file not being
> delete is that there is a file lock issue. Ie it might be that a
batch
> file will not be able to successful deleting the temporary file
when it
> gets into the faulty state.
>
> The temporary address file should only exist for a minute or two in
any
> case, so if it is older than 3 minutes - it is faulty.
>
> --- In alltalk-avp@ <mailto:alltalk-avp%40yahoogroups.com.au>
> yahoogroups.com.au, rodneyebird <no_reply@> wrote:
> >
> > Hi Glen,
> >
> > We have had three users, over the last day, reporting Alltalk
> downloads
> > freezing at the 'Address file download' entry. They have all now
> > resolved, although one took 48 hours. All three were using version
> > 1.1.92 of the client.
> >
> > Rodney
> >
>
We have completed the trials of the latest Version of AllTalk server.
This release overcomes the increasing size of the the address file problem.
This release also includes Remote Download notifications - ie notifies an AllTalk remote server of a successful or failed download where the message has originated from a different server from the recipient.
From: alltalk-avp@... [mailto:alltalk-avp@...] On Behalf Of lrs_y_gk_07 Sent: Wednesday, 27 August 2008 11:31 PM To: alltalk-avp@... Subject: [alltalk-avp] Re: Client dowloads 'freezing' at address information
Dear Rodney,
There have been reports of the Address.In file increasing to very large size (many MB). Inspection of the address file reveals many duplicates of the address data.
The root of the problem appears to be stray the temporary Address.in.tmp file not being deleted each refresh cycle. This issue will be resolved in the next version of the AllTalk server.
For the present we suggest scheduling a batch file to delete daily the Address.in file and ESPECIALLY any address.in.tmp files that may be present. Schedule this before the standard first schedule login time when most AllTalk clients will request the address data. This should keep the address file down to a sensible size. Note though that the only reasonable explanation for the temporary address file not being delete is that there is a file lock issue. Ie it might be that a batch file will not be able to successful deleting the temporary file when it gets into the faulty state.
The temporary address file should only exist for a minute or two in any case, so if it is older than 3 minutes - it is faulty.
--- In alltalk-avp@yahoogroups.com.au, rodneyebird <no_reply@...> wrote: > > Hi Glen, > > We have had three users, over the last day, reporting Alltalk downloads > freezing at the 'Address file download' entry. They have all now > resolved, although one took 48 hours. All three were using version > 1.1.92 of the client. > > Rodney >
Dear Rodney,
There have been reports of the Address.In file increasing to very large
size (many MB). Inspection of the address file reveals many duplicates
of the address data.
The root of the problem appears to be stray the temporary
Address.in.tmp file not being deleted each refresh cycle. This issue
will be resolved in the next version of the AllTalk server.
For the present we suggest scheduling a batch file to delete daily the
Address.in file and ESPECIALLY any address.in.tmp files that may be
present. Schedule this before the standard first schedule login time
when most AllTalk clients will request the address data. This should
keep the address file down to a sensible size. Note though that the
only reasonable explanation for the temporary address file not being
delete is that there is a file lock issue. Ie it might be that a batch
file will not be able to successful deleting the temporary file when it
gets into the faulty state.
The temporary address file should only exist for a minute or two in any
case, so if it is older than 3 minutes - it is faulty.
--- In alltalk-avp@..., rodneyebird <no_reply@...> wrote:
>
> Hi Glen,
>
> We have had three users, over the last day, reporting Alltalk
downloads
> freezing at the 'Address file download' entry. They have all now
> resolved, although one took 48 hours. All three were using version
> 1.1.92 of the client.
>
> Rodney
>
Hi Glen,
We have had three users, over the last day, reporting Alltalk downloads
freezing at the 'Address file download' entry. They have all now
resolved, although one took 48 hours. All three were using version
1.1.92 of the client.
Rodney
It is always good practice to check what profiles exist when upgrading from EQuery and make sure that no profiles get left behind.
Alltalk should be able to detect any versions of EQuery running on a scheduler, and automatically copy all the profiles. However the very old copies of EQuery did not use the scheduler and AllTalk wont be able to detect them.
In the general case, just copying the EQI files from the old directory is sufficient.
I think I can say we are all guilty of tripping up on this one (Yes, even I have done it - sorry). It should be everyone's policy to ensure that you do not break anyone else's profiles when you add your profile to a site or upgrade.
Please take care.
Thanks
Glen.
From: alltalk-avp@... [mailto:alltalk-avp@...] On Behalf Of kerrie_svh Sent: Monday, 2 June 2008 5:39 PM To: alltalk-avp@... Subject: [alltalk-avp] Reminder : Clients with multiple pathology providers using AllTalk
Just finished reconfiguring profile, moving keys, eqi files etc. with a client who tells me that SJG pathology visted and changed him from EQuery to AllTalk. SJG let him know that St.Vincent's would probably have to come and fix their downloading after the update. We faxed him because he had outstanding files and he contacted us with this info.
It would seem reasonable that if you see other providers' keys in the EQuery directory, and you are changing the client to AllTalk, or moving the program etc, that you move all of the keys over. This doc had gps and svhm keys that weren't moved.
Just wondering what policies other providers have about this?
Just finished reconfiguring profile, moving keys, eqi files etc. with
a client who tells me that SJG pathology visted and changed him from
EQuery to AllTalk. SJG let him know that St.Vincent's would probably
have to come and fix their downloading after the update. We faxed him
because he had outstanding files and he contacted us with this info.
It would seem reasonable that if you see other providers' keys in the
EQuery directory, and you are changing the client to AllTalk, or
moving the program etc, that you move all of the keys over. This doc
had gps and svhm keys that weren't moved.
Just wondering what policies other providers have about this?
The new installer is called "NEW Macintosh AllTalk Java Client Beta"
Download and run this. The Installer will download the AT2j from the LRS website, Create the /Users/<currentUser>/EQ2j folder if it doesn't exist and create new getresults and getresuts.cron scripts.
The new getresults scripts simply contain a SINGLE AT2j entry which asks it to run all profiles each time, so there is no need to specify a profile name at the outset.
AT2j will start, then you can click on Profiles to add the first profile (next release will automatically start the profile editor when there are no profile specified).
To make a Desktop shortcut, simply make an Alias to AT2j.jar (works on the newer versions of OSX). For older versions (<10.3) use the old Run All profiles script - this will still work fine.
Updating a site from Older Version
To update, a site on either EQ2j or older versions of AT2j, simply run the new installer and it will overwrite the old getresults scripts and start running immediately. Just make sure that the old version is not running.
For Linux and Unix Systems
1. In getresults and getresults.cron, remove All but 1 of the java statements
2. Replace the text "EQj2.jar" with "ATj2.jar" in that statement
3. Also remove the Profile Name (eg 'default') in the statement
4. Copy the new AT2j.jar into the folder pointed to by the script.
In the future...
I have also completed the Transmission utility (but this is currently disabled). Watch for new releases which will provide methods for transmitting from Java to windows clients.
It appears that all versions of AllTalk server do not allow mailboxes with 3 letters (eg ABC@alltalk.galkam.com.au) to be accessed via the web interface!
This problem is isolated to Web App (alltalkwi.exe CGI) as using the 3 Letter Name account works fine with AllTalk and EQ2j/AT2j by copying or emailing the key works fine.
Sent:Friday, 23 November 20073:51 PM Subject: FYI Smartrooms on Mac
FYI the install you helped me with this morning was to download into Smartrooms on Mac. Their software has a “feature” that doesn’t allow you to specify the result directory. There is also another “feature” that imports all results into the name of whoever is logged on at the time. Example, GK is logged on and we’re downloading GK and DM results into result directory. GK imports files, but all results for GK and DM import under GK’s name! Thought you might be interested to know that one.
>GK>>> Ah, thanks for that useful tid-bit!! <<
So basically I have to go and move one of the profiles onto another machine. Question, how do I remove an EQ2j profile? Just delete the <profile>.eqi file??
<<snip>>
Regards,
Darius Monaghan
From: Glen Kleidon
Sent: Friday, 23 November 2007 4:44 PM Subject: RE: FYI Smartrooms on Mac
So actually,
“DumbRooms” is a better name for it then?
Ah, yes to remove a profile on EQ2j Versions before 1.2.J.0 (2008).
Just removing the <profile>.eqi would be BAD (causes 'could not be set' error).
There are actually 2 (3?) steps –
Open getresults and getresults.cron using TextPad (or VI for old school Hackers!!)
For both scripts, remove the entry relating to the profile you want to get rid of, then save. eg to remove the EP2 profile,
Sorry, what do you mean by creation of a pseudo-destination directory?? Do you just mean like when the Windows client prompts you to create it if the folder doesnt exist?
Sneak Peak
Notice:
1. AllTalk look and feel
2. Drop down list of Profiles
3. All Profiles run from the same instance,
4. CRAM-MD5 authentication (Authenticating as...rather than logging on as)
5. Send button (havent quite got a far as re-enbling the Remote send and Investigation path fields yet...Working around other projects.)
Glen.
From: alltalk-avp@... [mailto:alltalk-avp@...] On Behalf Of rodneyebird Sent: Monday, 12 November 2007 9:05 AM To: alltalk-avp@... Subject: [alltalk-avp] Re: Mac Clients
Sounds good. Another problem I have with the current Mac/Java client is the creation of a psuedo-destination directory, when the actual destination directory is unavailable (for whatever reason).
Looking forward to the christmas release of the new client.
Offline 
Send Email
