From Developer Community
This document gives a brief description of most of the GroupWise Administrative Object API related defects submitted to GroupWise Engineering by Developer Services during the past several years. The list includes both resolved and unresolved defects. It also includes numerous notes about individual methods and properties found in the Administrative Object API.
The list is arranged alphabetically according to Object name. Within each Object is another alphabetically arranged list of the Object's properties and methods. If there have been any submitted defect descriptions or notes that relate to a particular method or property, these descriptions or notes will be listed immediately below the method or property (in no particular order).
The list will always be a work in progress. The intent is to keep it informative and current with input from both Novell and third parties wishing to contribute information.
On Novell's part, information may be periodically inserted regarding any new recently discovered issues. When fixes become available for any unresolved defects in this list, the defect may be updated to inform developers of the fix. Notes may be added from time to time.
Third parties wishing to contribute to this document are encouraged to do so. There is a vast wealth of information regarding the use of the Administrative Object API that developers have learned over the years. This information needs to be collected and identified. Hence, any developer wishing to contribute information can click the "Post Comment" button at the bottom of this document and add his/her comment. The contributor should include the object(s) and method(s) that the comment relates to. The comment will then be reviewed by Novell. If accepted, the comment will be inserted into the document. These comments will be labeled "CUSTOMER COMMENT" and dated. Note, however, that there is NO guarantee that these comments will be independently verified by Novell.
Finally, note that this document may not include information about when interface enhancements were made.
Novell hopes the publication of this document will help all developers quickly determine if there are any known Administrative Object API issues in the area of their interest.
WARRANTY DISCLAIMER. This information is provided "AS IS" without any warranties or representations. Novell expressly disclaims any warranties or representations as to the accuracy, currency, or completeness of the contents and disclaims any implied warranties of merchantability or fitness for a particular purpose.
LIABILITY DISCLAIMER. Novell will not be liable for any indirect, special, or consequential damages (including loss of profits, business, or data) which may arise out of or result from the services or use of this information.
Trademarks. Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.
Internal Use. This information may only be used internally within your organization. The contents are not suitable for use in all situations, and any use by you of the contents is at your own risk. You are responsible for verifying the validity of any information that you use. This information may be updated or modified by Novell at any time, including to correct errors.
Copyright Novell, 2005. All rights reserved.
GENERAL
NOTE: You should not use both the NDS and GroupWise APIs together. There
are synchronization issues. For example, if you have a user in both NDS
and GroupWise, and you delete this user from NDS using an NDS API, (making
this user an external GroupWise user), you cannot then use GroupWise to delete
the remaining GroupWise association (using User.Delete(eadGW). It will not
work. However, if the NDS association was deleted initially with the
GroupWise APIs rather than the NDS APIs (using User.Delete(eadNDS), you could
then use User.Delete(eadGW) successfully later to delete the GroupWise association. This is working as designed. The NDS APIs do not know about the GroupWise system. Therefore, if you try to only use NDS APIs to administer a
system with GroupWise users on it, troubles will occur.
NOTE: Although the Admin API returns much valuable administrative information,
there is other administrative information that is not available. Not all
GroupWise information is in the NDS directory, therefore some information
cannot be synchronized. Not all GroupWIse information that IS in the
directory is available in the Admin API.
NOTE: You cannot change a user from a Full Mailbox to a Limited (WebAccess only) Mailbox - programmatically - using the Admin API. This can be done one-by-one in Console One. The DirXML driver does not set any client options and even if the Admin API did set client options, it does not know about this option.
NOTE: There are no guarantees that there may not be popups when trying to
use the Admin API in an NT service.
NOTE: It is not possible to get GroupWise Alias information from the GW
Admin API. The GroupWise Snapin gets this alias information from internal
GW code, that is not exposed to third party developers. Using aliases is discouraged anyway.
NOTE: There is no way to programmatically rename an NDS account, that has
a GW association, and do so without breaking the link to GroupWise.
NOTE: The Admin API requires the NetWare Client to be installed to provide
NDS access. This differs from the Object API. The Object API makes no NDS
calls, and does not need the Netware Client.
ADMINOBJECT OBJECT
Commit:
NOTE: In general, to change User object properties you need to call the
AdminObject "Commit" method. However, you do not need to call this method
after calling User.MoveWithinTree or User.Move. If you do so, it may work
incorrectly. The User move methods have their own commit.
Name:
NOTE: You can't rename a resource object using the Admin API.
ObjectID:
NOTE: The ObjectID of a user has the same value as the GUID value in
the system address book. Replication errors could sometimes cause this
value to be missing.
Visibility:
Defect #315861, #319888: If you set the Visibility property to none
(that applies, for example, to a User object), this was suppose to
correspond with the VisibilityTypeConstant = 4. These constants range
from 1 to 4. However, it was set to "1" instead - meaning visibility at
the PO level. Fixed in GW 6 SP3 and GW 6.5, Dec, 2002.
Defect #315861, #319888: Setting the Visibility level to 4 (none) created
a problem with the Object API. An iteration of the address book entries
using the Object API would not find any hidden entries, but the
AddressBookEntries.Count level would "include" these types of entries.
Thus, an iteration through all the address book entries would finish
before the maximum count was reached. Fixed in GW 6 SP3 and GW 6.5,
Dec, 2002.
DISTRIBUTIONLISTS OBJECT
ItemByDN:
Defect #313392, #316253: The DistributionLists.ItemByDN doesn't work the
second time. If a user gets the DistributionLists object and attempts to
find a specific item in the list (a DistributionList object) by using the
DistributionLists.ItemByDN method (using the distinguished name of the list
as a parameter), it works fine the first time. However, if you attempt to
use it a second time, no object is returned and you get an error. Fixed in
GW 6 SP3 and GW 6.5, Oct, 2002.
DOMAIN OBJECT
DomainType:
Defect #260009, #100256681: Problem with addeding a user to a "foreign
external domain" as opposed to a "GroupWise external domain". Attempting
to use this method resulted in an error message saying the domain was not
an external domain. In addition, the Domain.DomainType property was "4",
which was undefined. Fixed in GW 5.5.5 and GW 6.0 in March, 2001.
Name:
Defect #368646: In some circumstances, when the Admin API is used to
get a user in a secondary domain and report the name of that domain, in
the following way -
Set usr = objAdminSystem.Users.Item("bbaggins", "books", "secdom")
UserDomainName = usr.Domain.Name
the Admin API will report the name of the primary domain instead. In
addition, your Admin API application now thinks that any user in
the secondary domain now belongs to the primary domain. Defect reported
to GroupWise Development.
POSTOFFICESITERATOR
Defect #234033: You could not iterate between post offices in GW 5.5.3 and
in GW 5.5.4. GW 5.5.2 and the Enhancement Pack worked fine. Fixed in
GW 5.5.5.
SYSTEM OBJECT
Connect:
Defect #343123: The Admin API won't release drive mappings. The way
that mappings are suppose to work is illustrated by the following
facts.
The Admin API shared code with administration snapin code. When this
code opens a domain database it will use the UNC path to open the
database. If a drive is already mapped then it should not be creating
a new mapping. The one exception to this would be when a third party
has used an IP address to map a drive, when the snpain code cannot detect
the match with the UNC path and it will create a new mapping.
It appears that the Admin API doesn't work like this. It appears that
even if a drive is already mapped, the Admin API does not use it and
maps another drive, even if it is duplicated. This behavior does not
match how the snapins work. The snapins should reuse a mapping if it
already exists and it contains the server and volume name. It looks like
the Admin API is creating a new mapping everytime reagardless of current
connections. Defect submitted to GroupWise Development.
NOTE: If the connect doesn't work, check to make sure you are passing
in the full and correct path. You must have sufficient administrative
rights.
Users:
The Admin API has a memory leak with the System.Users method. Fixed in
GW 6.5, Dec. 2002.
USER OBJECT
AdminDefined:
Defect #326023: Problem with commiting changes to user defined custom
fields in GW 6.5. Defect submitted to GroupWise Development.
Delete:
NOTE: You should not use both the NDS and GroupWise APIs together. There
are synchronization issues. For example, if you have a user in both NDS
and GroupWise, and you delete this user from NDS using an NDS API, (making
this user an external GroupWise user), you cannot then use GroupWise to
delete the remaining GroupWise association (using User.Delete(eadGW). It
will not work. However, if the NDS association was deleted initially with
the GroupWise APIs rather than the NDS APIs (using User.Delete(eadNDS), you
could then use User.Delete(eadGW) successfully later to delete the
GroupWise association. This is working as designed. The NDS APIs do not
know about the GroupWise system. Therefore, if you try to only use NDS APIs
to administer a system with GroupWise users on it, troubles will occur.
MailboxExpDate:
Defect #100256884: There was a mailbox expiration date discrepancy between
the Admin API and NWAdmin. The discrepancy was always around 318-319
days. Fixed in GW 5.5.5 and GW 5.5 EP SP3, April, 2001.
NOTE: There is no function to disable a user (prevent him from logging
into GroupWise) and at the same time allow him to receive email. As a
workaround, you can use the User.MailboxExpDate of the Admin API. This
method prevents the person from logging in, but also prevents the person
from receiving email.
MailboxID:
NOTE: The MailboxID is a 3 character alpha-numeric code which represents
a File ID or FID. This is used to create the user's database file (e.g.
a user with a Mailbox ID of "6m5" will have a user database file named
"User6m5.db" The MailboxID is unique within a PO.
Move:
NOTE: This method performs its own commit. You do not need to call the
User.Commit (AdminObject.Commit) after the move. If you do so, it may
work incorrectly.
MoveWithinTree:
NOTE: This method performs its own commit. You do not need to call the
User.Commit (AdminObject.Commit) after the move. If you do so, it may
work incorrectly.
SetPassword:
Defect #291848, #100276784: This method had a memory leak. Fixed in
GW 5.5 EP SP5 March, 2002 and GW 6.0.2 Feb, 2002.
USERS OBJECT
Add:
Defect # 251853, #100270063. The Users.Add method was faulty when adding
a prefixed distinguished name. When using a '.'-prefixed disinguished name
as 3rd parameter, such as ".user.ou.org", then 1st anything seemed to work
well, i.e. an NDS user with absolute DN "user.ou.org" is created and visible
in both views of NWadmin. But only in NWadmin's NDS view one can open the
user, not in the GW view. When trying to open it in GW view, there was an
error message. When viewing this user entry in the GW addressbook, field
'NDS dist name' contains ".user.ou.org", i.e. the leading dot is stored
which is not the case for users created through NWadmin. Fixed in GW 5.5.5
and GW 5.5EP SP4, both in Aug. 2001.
Defect #340741: Use C and the Admin API to add a new user to both NDS and
GroupWise. If the user's name had a special character at the end, like
VisBasé - then ConsoleOne could not translate the final é correctly - and
put the Greek letter theta at the end of the spelling rather than the é.
The problem does not occur using Visual Basic. Defect submitted to
GroupWise Development.
AddExistingUser:
NOTE: If you get a "User commit error", it is probably caused by one of
the following: 1) The user has insufficient NDS rights to the object, 2)
The disk is full, or 3) The User object he is trying to add already
exists in GroupWise.
AddExternalUser:
Defect #260009, #100256681: Problem with addeding a user to a "foreign
external domain" as opposed to a "GroupWise external domain". Attempting
to use this method resulted in an error message saying the domain was not
an external domain. In addition, the Domain.DomainType property was "4",
which was undefined. Fixed in GW 5.5.5 and GW 6.0 in March, 2001.
ItemByDN:
Defect #250150, #100257357: The ItemByDN method would not work if it were
given a NULL or empty tree parameter. Fixed in GW 5.5.5 and in GW 5.5 EP
SP4 in April, 2001.
--gmonson
