• State Suggested Answer
  • Replies replies
    12
  • Answers answer
    1
  • Subscribers subscribers
    19
  • Views views
    483
  • Users 0 members are here

Tool for editing domain databases

Prindl

Recently I checked the database entries for my MTAs, Internet Agents and POAs, because i saw a path in a log, which does not exist since years.

In this case it was the UNC-path (attribute-ID 59003), which is totally wrong for this agent, because it points to a server, which was removed several years ago. I know, that one could set this attribute via C1 as long as the groupwise system was integrated into eDir, but now, I don't see any tool to change this value. Although that value seems to be not used any more I see this value still popuated in a newly installed internet agent, but it does not show an UNC-path - it simply shows the linux filesystem-path to the internet agent.

How can I get rid of those irritating entries, because if someone has to take over the administration of this system, this will at least lead to unneccessary thoughts. And I hate carrying along wrong entries - even, if they do not harm and apparently are not used.

  • 0   in reply to   

    Hello Rob,

    yesterday I wanted to write that it is an orphand entry in GroupWise. In my Life GroupWise system which runs on LINUX, the UNC path for the primary domain is a Windows path ( \\hermes\gwise\pri-dom) which comes from a GroupWise 6.x system which was still running on Novell Netware.an ldapsearch against GroupWise LDAP did not produce any results either.  I have to say that I hope my query was executed correctly to find the attribute identifier that it concerns

    In my case, I solved the problem by swapping the primary domain with the secondary domain. Then I deleted the gwia of the now secondary domain. From this point on, there were no more objects in the secondary domain so that it could be deleted. Now I recreated the CA with gwadminutil force and redistributed it to the POAs. Created a new secondary domain, then swapped the primary and secondary domains again, then created a new gwia. Everything fine after that.  Maybe this is a possible solution to get the path out of the GIWA. As always - backup everything beforehand

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • 0 in reply to   

    Yes, I tested it now a second time, but it seems to be unchangeable - although the result of the put request is OK. Probably the value is read only in the database itself.

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.