Support 1

[Support 1]

Thanks for the additional information.

>To rule out any Novell client interference

Could you elaborate on what you mean by the above? You do need the Novell Client installed for the GroupWise Admin API (that Archive To Go uses) to operate correctly.

>The logged in user has full rights to the domain directory.

From a quick look at the Novell Communities, this post indicates that incorrect Samba group Read and Write permissions can result in administration issues.

I have confirmed that the error ‘This is not a primary domain path.’ was reported by the customer mentioned previously. No other error was reported. I think it’s very likely this is due to the Samba share on Linux. Unfortunately we cannot offer specific advice on how to reconfigure this share; we have not tested Archive To Go in this environment. Archive To Go is a GroupWise Windows client based solution which uses the GroupWise client Object and Admin APIs to access the GroupWise server. Apart from any difference in potential rights allocation and folder access methods between the different operating environments for administering GroupWise, Archive To Go’s operation is independent of the GroupWise server’s operating system.

For reference, if your GroupWise system consists of several eDirectory Trees, you will need to log into all trees before attempting system discovery. Archive To Go Creator uses system discovery to list the GroupWise Post Office objects to help you create a system definition. Not logging into all Trees is a known cause of error ‘eDirectory Tree could not be set’. In this circumstance, in the Novell Client Connections dialog, it is also recommended that you set the GroupWise system to be the Primary system connection.

If the problem persists, testing your environment may be a little quicker by using our stand-alone GroupWise System Discovery utility, which attempts an administrative GroupWise system login and discovery of all domain and post office objects. If there is a rights issue or folder access problem, the utility will still log a similar error because it uses the same technique as Archive To Go. The utility is available from:

http://support.advansyscorp.com/utilities/groupwise-system-discovery.zip

After downloading, double-click the MSI file to install GroupWise System Discovery. Operation should be straightforward. Given the appropriate connection information and access rights, it will attempt to connect to your GroupWise system and identify the Domain and Post Office objects. It will not attempt to list or access User objects. It should create a log file which you can return to us via email (click the “Create email…” button and use support@advansyscorp.com).

Regards,
Advansys Support

[This message was edited by Support 2 on June 06, 2010 at 08:11 PM.]

[Support 1]

Further to the comments by Support 3, please check the version of Internet Explorer on the affected workstations:

• Which versions of IE are installed the affected machines?
• Which versions if IE are installed on the unaffected machines?

I look forward to your reply.

Regards,
Advansys Support

[Support 1]

Thanks for reporting these problems.

>On XP, the application hangs when clicking on the “Define” link.

Unfortunately I am not sure what might cause this. Which version of the Microsoft Framework for .NET is installed on the workstation?

I believe that the problem with setting the domain path is most probably caused by the sharing configuration from Linux to Windows. You are likely to see the same behavior with versions 1.5 and 2.0. Another customer wrote the following:

quote:

---

Here is my environment.
– Only one NDS tree and Only one GroupWise server
– Netware client 4.91 sp5 installed
– GroupWise Client 7.03 is installed
– Groupwise 7.03 server is running on Linux OES1
– Mail is shared by Samba to Windows 2003 server for running Archive To Go.
– User account have read/write permission on this share and the domain directory

---

This customer was unable to create a GroupWise system definition with Archive To Go Creator. Here is how the customer resolved the problem:

quote:

---

I need to move gwdomain folder to the NSS volume and create a symbolic link. (Before I moved to NSS, Gwdomain was located in linux partition and created a samba share) Novell client causes Windows to lookup the UNC path on NCP share first, then samba.

The samba share does not work in OES.

We don’t have this problem if GroupWise is installed SLES9 or SLES10.

---

I hope this helps you. Please let me know how you go.

Regards,
Advansys Support

[This message was edited by Support 1 on June 03, 2010 at 05:21 PM.]

[Support 1]

That’s great news, thanks for letting me know.

Regards,
Advansys Support

[Support 1]

Thanks for reporting this problem.

I think one or more XML files used by A2Go have become corrupted, perhaps because of a forced reset of the machine.

I suggest you try the following:

• Navigate to your Archive To Go settings folder:

  C:Documents and Settings[Windows User Name]Application DataAdvansysArchive To Go

• Rename each file listed below as shown. Try to restart Creator after each name change because only one file is likely to be corrupt; Creator will recreate the file with its original name.

  1. settings.xml -> settings.bak

  After this change you will need to redefine the general settings in Creator.

  2. systems.xml -> systems.bak

  After this change you will need to redefine the systems for Enterprise Access in Creator.

I look forward to your reply.

Regards,
Advansys Support

[Support 1]

Thanks for the feedback, that’s great news. By the way, this problem has been addressed in version 2.0, which is due for release this month.

Regards,
Advansys Support

[Support 1]

Thanks for your question.

Unfortunately Archive To Go does not support hand-picking emails for archiving. However you may be able to achieve what you need by doing one of the following:

• Use GroupWise to mark as Private all the emails that you do not want to hand over. Then in Archive To Go Creator, on the Filtering Options screen, choose the option Exclude items marked Private. You can do this in combination with a folder selection and/or date range filter.
• Use GroupWise to move all emails that you want to hand over to a new ‘handover’ folder. Then in Archive To Go Creator, on the Folders screen, choose the option Selected folders and mark the folder containing the emails.

I hope this helps.

Regards,
Advansys Support

[Support 1]

Thanks for reporting this problem.

Which version of Archive To Go do you have installed?

Unfortunately some earlier versions required Write access to the Archive To Go installation folder, which is usually:

C:Program FilesAdvansysArchive To Go

I think you will need to allow Write access to this folder for that user.

Please let me know how you go.

Regards,
Advansys Support

[Support 1]

Thanks for your detailed enquiry.

It is most likely the ‘access denied’ errors relate to one or more folders on your users’ machines, not a network location.

>we’re changing our users from running their Windows XP profiles ad admins to power users.

Do you mean that your users’ effective rights have been reduced?

Do the ‘access denied’ errors include any information about which resource the application/s attempted to access? It may be easiest to send a screen shot to support@advansyscorp.com.

Which ATG applications show up this error?

Which version of ATG are you using?

I would expect the permissions granted to normal users (Read-only) to be sufficient for the ATG folder, which (just to be clear) we consider to be:

C:Program FilesAdvansysArchive To Go

However, this location is usually not relevant when viewing an ATG archive, because the Viewer and other applications are copied to a sub-folder of the archive.

You may wish to experiment with changing the permissions granted to the following folder, where user preferences are stored. Both Read and Write access are required:

C:Documents and Settings[Windows User Name]Application DataAdvansysArchive To Go

I look forward to your reply.

Regards,
Advansys Support

[Support 1]

Thanks for reporting this problem. Unfortunately we do not know the cause of this error, which seems to affect only .xls (Excel spreadsheet) files.

Please send samples of the .xls files (zipped) to support@advansyscorp.com. Note that Advansys treats all customer-supplied sample data as strictly confidential. Alternatively, please answer the following questions:

• Do the affected .xls files contain links to other documents (eg. Web addresses)?
• Do the affected .xls files contain plain text (eg. tabular data formatted as comma-separated values, ie. CSV)? You can see this by using a plain-text editor (eg. WordPad) to open the .xls file.

Was anti-virus software active during the indexing process? We recommend disabling any such software temporary while indexing takes place.

Which version of Indexer are your clients using? The error format looks like 1.5.0.3 or below. We recommend version 1.5.0.4, which minimizes the incidence of this problem. Anyone can obtain this version by following the directions in 1.5.0.4 updates for Indexer and Viewer.

Do you see these errors with Indexer 1.5.0.4? If so, is there a different pattern to it, eg. fewer errors per log file? Detailed information about your results will help our engineers to understand and fix this behavior. Please send sample log files (zipped) to support@advansyscorp.com. For all the machines where these errors come up:

• Which version (and service pack) of Microsoft Windows is installed?
• Which version of Microsoft Office is installed?
• Which version of Microsoft Excel is installed?

I look forward to your reply.

Regards,
Advansys Support

[This message was edited by Support 1 on April 08, 2010 at 07:33 PM.]

[Support 1]

Thanks for your question. At present we do not plan to change this behavior. However I will update the product wish list to register your interest in this feature.

Regards,
Advansys Support

[Support 1]

That’s great news, thanks for letting us know.

We will ensure that the product documentation mentions this ‘standard index location’, if it doesn’t already do so.

Regards,
Advansys Support

[Support 1]

Thanks for the clarification.

When the index is too large to be placed in the archive folder group, Indexer may move it to the ‘standard index location’ on the machine used to create the index. Since you have been able to search the network-based archive, I think your machine stores the index locally.

Have you tried to use the same machine to search the new copy of the archive? I would expect it to use the local index also for the copy.

To see whether the index for this archive is stored locally, please follow these steps:

• Open the file DiskX.info.xml using a plain text editor or a Web browser. The third line should look like this:

    <volume vol="1" archive-id="a37eb297-08e8-49a7-ba32-7caa6a31ce88" />

• Note the value at archive-id (‘a37eb297-08e8-49a7-ba32-7caa6a31ce88’ in the above sample).
• Use File Explorer to navigate to the following folder:

  C:Documents and Settings[Windows User Name]Local SettingsApplication DataAdvansysArchive To GoIndexes

• If this folder exists, does it contain a sub-folder matching the archive-id noted earlier? If so, you should find that it contains a sub-folder dat. In the last media-XX folder of the archive copy, create a sub-folder _index if it does not exist. Copy dat into this new sub-folder. You should be able to search the archive copy now.

I hope this helps.

Regards,
Advansys Support

[This message was edited by Support 1 on March 31, 2010 at 04:19 PM.]

[Support 1]

Thanks for the detailed description of the archive sub-folders.

If the sub-folder _index is not in the copied archive, this explains why you get the message ‘A text search index for this archive cannot be found…’

If you look at the the original archive folder on the network drive, can you see this sub-folder? If so, it appears to have been excluded from the zipfile you created, or it could not be copied to the other drive.

I look forward to your reply.

Regards,
Advansys Support

[Support 1]

Thanks for reporting this behavior.

It’s possible that some file or folder names in the archive are too long for the target media where the archive was copied. Can you confirm that the archive sub-folder _index and contents in the copy match the original?

I look forward to your reply.

Regards,
Advansys Support

[Author]

Replies