Any POA will need file access to the PO directory so creating a second POA on another server also means the second server needs to have the first server PO directory mounted which on itself can cause lots of issues ( filesystem/network etc)

Having a second POA on the same server does not improve much, it even might bring the performance down as the 2 POA's cant balance things fr each other

So is there any specific reason you want this as when a DVA on another server then the POA is running this should be fine for performance as it offloads conversion work from the POA server.

These days i dont see the need to have more then one POA for a PO anymore

In recent days there were considerations for a second poa; but usually for handling large libraries. However document managent is out of (GroupWise) business now.

I have one case where I had to use two poas. The second poa supported soap without ssl. This was necessary because a third party utility failed if soap was secure ...

Thanks. I am going to abandon this idea (read other post suggesting this might work on Windows server, but not on SLES).

Hmm, I do not really understand your answer. Nobody told you that it does not work on sles ...

However why do you need full time indexing? I prefer to set indexing in this way. I start at 6 am and repeat indexing every 6 hours. You will find non-indexed items even in between - but slower.

I've settled on a 4-hour index cycle, starting at 04:11, that the clients were generally very happy with.
Overnight messages were included in the morning, the mornings' were included in the afternoon, the evening workaholics had the bulk of the day.
A couple exceptions wanted it run every hour, and they never had performance issues.

The problem is I do not understand indexing. I believe that the DVA is used to perform indexing. There is an Opentext video on the process. But I see old posts discussing that the POA does indexing. Then there are knowledge base posts saying that to better perform indexing you need another POA doing the task, but then the same documentation says you can only have another POA do indexing if you are running under Windows server. If you ask me the whole indexing thing is a cluster.

I have indexing set the same way as AK. The live messages are indexed fine. The issue we have is that we need to search and access 20 years of archived messages. We tend to keep about 4 months of data live, and archive the rest after 120 days. There is basically zero reliable way to search archives. May as well destroy the archives if you can not search and find things in them. Just my 2 cents.

The DVA is part of the indexing process, but not the indexing itself. DVA is the piece that looks at / reads the documents to feed the indexer part of the POA, the words of the documents, ignoring the formatting and all that other stuff that is in so many file formats of files that are sent around (drawings, spreadsheets, pictures, etc..)

You can see some of the indexing happening in the POA logs, especially in verbose mode, by searching for QuickFinder.  The POA's http console, log tab, is great for this.

Searching for 'QuickFinder index' will show you the progress of your indexing, with a line per DB on every run.  Ex of a doc lib or shared folder from anther PO.
     04:11:05 4B9F Updating QuickFinder index: pu080101.db (0)
or a user
     04:11:07 4B7E Updating QuickFinder index: userFID.db (8)

The number in brackets is the one to watch, as that is the number of unindexed messages at the start of the run. If that number is higher than the configured "Number of items to index per user (in thousands):" for the POA, then indexing is falling behind.  Either there is a problem blocking indexing for that user, or you need to increase how many are being indexed over the day. Sometimes it is just one 'troublesome' user who gets so much email, such as the IT lead that gets ALL the logs sent to them, that you end up having to adjust for, like I did for one IT Manager.

As for Archives, how are you doing it? A good archiving system has indexing baked in. The built-in GroupWise archiving and PST files are so not good for that, such as being a real problem for legal discovery.  OpenText Retain (originally GWAVA) is an example of a proper and good archive for many email systems), and very useable for legal discovery.   One of my clients does the same of limited time retention in the live system, but with Retain doing the archiving, search is still very much there, both for the users, in addition to if we need a legal hold/discovery done.

To add some additional information: GWcheck tells you how many items are not indexed. In the last line for each mailbox there is a "pending jobs" information. The counter tells you how many items are waiting for an indexing process ...

By the way this is a hint to read your gwcheck logs. It will help you to find out if you have an indexing problem.

Thanks much for all responses. This explanation makes good sense. It ought to be footnoted in future documentation updates, as should the GWcheck reference of DR. I checked the POA logs, and Quickfinder is working well on our POA.

I will check out the Retain product for handling archives. All users complain about archive searching.