/ Forums / Advansys Archive To Go, Advansys PST Creator / Archive To Go / Enterprise Access via Trusted API not working
-
CreatorTopic
-
October 18, 2006 at 10:36 am #4915
Hi,
I have compsed a Word doc with all the details including printscreens. You can access that document at:
http://www.episd.org/Steve_Files/archive2goProblems.docThanks,
Steve Crye
Network Infrastructure Manager
The El Paso Independent School District -
CreatorTopic
-
AuthorReplies
-
October 18, 2006 at 5:02 pm #9329
Thanks for the information. At this stage we don’t know the cause of the problem, which appears to be that the GroupWise APIs we use in Archive To Go cannot ‘see’ or recognize your system domain.
Just for our reference, are you able to perform Archive To Go exports in Enterprise mode when a user has admin rights to the domain?
To help gather further information, it may be worthwhile using a utility to troubleshoot this problem. The utility is available from:
http://www.advansyscorp.com/utilities/groupwise-system-discovery.msi
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).
Just as additional background information, are you using Reveal 1.5 with Archive To Go 1.1?
In addition, from a couple of the workstations with the problem, could you please send us (support@advansyscorp.com) the systems.xml and settings.xml files from the following folder:
C:Documents and Settings[Windows User Name]Application DataAdvansysArchive To Go
Regards,
Advansys Support
October 18, 2006 at 8:00 pm #9331Upon further review, to enable Archive To Go (A2Go) to perform initial system discovery, for Enterprise Mode you will need to provide each A2Go user with Read, Filescan and Write rights to the primary domain directory.
The advice above assumes that the A2Go trusted app key has already been created for that user on the worksation being used.
Please let us know if this does not solve your problem.
Regards,
Advansys Support
October 18, 2006 at 8:55 pm #9330Hi,
Thanks for the prompt and detailed reply.
Yes, when logged in with full admin rights we can use the archive creator with no problems in Enterprise mode. We are not currently using Reveal, although we did run it for 30 days about 6 months ago in trial mode. We deleted the Reveal trusted app via Console One.
I’ll test it in the morning with a non-admin user that has RWF rights to the pridom folder, and let you know ASAP the results of that test. If it still fails we will send the diag info as requested.
However, granting the Write right makes us nervous – does that not expose the entire system to the danger of someone accidentally opening up any of the critical files such as wpdomain.db and altering them? (We are using clerks to do the archiving).
A couple more questions about the procedure for setting up the trusted app key on a clerks workstation. We have been logging in via C32 on that workstation as an Admin equivalent, creating the trusted app key, and then having the clerk login with his usesrid to perform the archiving. Is that the correct method? Also, where exactly is the trusted key stored on the workstation, and where is the object in the tree?
Thanks,
Steve
October 19, 2006 at 3:18 am #9327quote:
We deleted the Reveal trusted app via Console One.
No problem, just gathering all information. A2Go integrates with Reveal 1.5. There are no conflicts with any other versions of Reveal.
quote:
…does that not expose the entire system to the danger of someone accidentally opening up any of the critical files such as wpdomain.db and altering them?
It will increase risk but to what extent really depends on your staff. It would probably have to be intentional rather than accidental. Unfortunately, due to the Admin API requirements, A2Go requires this for Enterprise mode. For the next version we will look at caching techniques which may mean these rights will be required only the first time system discovery is performed.
quote:
Is that the correct method? Also, where exactly is the trusted key stored on the workstation, and where is the object in the tree?
It is the correct method but it depends on what you mean by login: login to the network or login to Windows workstation. The difference is relevant to the second part of your question.
The Trusted Application key information and the system settings are stored in XML files within the current user’s application data folder:
C:Documents and Settings[Windows User Name]Application DataAdvansysArchive To Go
This means that you can login to the Windows User who will be using A2Go, login separately to the network as administrator (i.e. a NetWare login), create the tapp key, then login to the network as the ‘user’. This means all A2Go information is available in the appropriate user’s Windows application data folder.
Alternatively, just copy the XML files above from one Windows user’s app data folder (the Windows user which created the tapp key) to the equivalent Windows user’s app data folder (the user who will use A2Go).
The Trusted Application key is stored within the GroupWise domain database. There is a function to list and manage them in ConsoleOne.
I hope this helps.
Regards,
Advansys Support
October 19, 2006 at 1:26 pm #9325Hi,
Well, it tried harder but still failed. Please see this link for the details:
http://www.episd.org/Steve_Files/archive2goProblems2.docI also sent the email with the GW system tester results and the .xml files.
Thanks,
Steve
October 19, 2006 at 11:00 pm #9324Thanks for the additional information and the files.
quote:
After we run the program, we can no longer logout/login via C32… Windows will then not restart or shutdown – we keep getting popups about “dummy window not responding”
We are not familiar with this problem. To avoid assumptions on our part, can you confirm what C32 is and what the login/logout process is?
Has this problem occurred ever since you started using Archive To Go or did it just manifest recently?
If you review the process list in Task Manager, is a2goengine.exe still listed?
As this has not been reported previously, we do not know the cause. To solve the issue we need to know how to replicate the problem. If you cannot readily determine the environmental factor which precipitates these symptoms, we will need to discuss a troubleshooting action plan with the developers.
quote:
but this time with two identical EPSID-ADMIN entries.
This is usually because two definitions now exist in the systems.xml file because another has been added at some point. You can check the systems.xml file to confirm.
quote:
2006-10-19 08:46:47.156-06:00 User ID: aapoklud
2006-10-19 08:46:47.156-06:00 [I] Command Line:
The blank command line in the log entry above and the [i]”Will the command line arguments “ text in the error dialog indicates that the Post Office definitions do not have the IP address or Port numbers specified. While you did send a systems.xml file with these completed, it does not seem to correlate with the log/error information. Can you confirm that the system definition you are using has all Post Office properties completed? Not completing this information is the most common cause of trusted login failure. While you may already seen this information, a quick reference can be found here: a2g_poa_settings.pdf
As a benchmark, could you also confirm that if you have system admin rights, you can export successfully?
Regards,
Advansys Support
October 20, 2006 at 10:54 am #9328Hi,
We had already tried specifying the TCP/IP info for our post offices.
However, while looking at the systems.xml, I noticed that it listed the path to the Primary Domain as K:pridom, and realized that for the low-power users, I had map rooted K: directly to \episd15mail6pridom. I changed that mapping to match what I use when logged in as an Admin-equivalent . i.e.
map k:=episd15/mail6:I deleted the previous trusted keys, edited the systems.xml and cleaned out the previous GW systems, and re-created the trusted keys.
I shutdown the laptop, and restarted it, logged in via Client 32 (C32 in Novell slang 😉 ) as a low-power user, but into windows as the same local user. This time we did not get the “(not available)” after EPISD-ADMIN, and after about 30 seconds could see the users in the post offices.
It now works as expected.
We will be very glad when the new version that does not require Write permissions to the Primary Domain folder is available.
Thanks,
Steve
Steve
October 20, 2006 at 4:22 pm #9326Hi Steve,
Thanks very much for the update and the detailed explanation.
We will certainly be investigating the options to avoid the write permissions after an initial system cache is created. Even so, if you change your system topology or add users, the system cache would need be refreshed by a user who has write rights (unless the GW API requirements change).
Regards,
Advansys Support
-
AuthorReplies
- You must be logged in to reply to this topic.