nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Are groups limited to 1000 members?

Robert_Davies_(unlondonadmin_-_(deleted))

Hi.I was speaking to someone about Livelink and they mentioned that it had a limit of 1000 users per group. Is this true?If it is can someone from OTC indicate what is the nature of this restriction? It seems a little arbitrary, and rather small. I'm hoping it's a 7 thing that has since been fixed.For example I have ~12K students in my LDAP server at the moment. I do *not* want to have to break them into separate groups to synchronize with LL. This would be a real mess to manage!Any thoughts?Best regards/matt.

Find more posts tagged with

Comments

Trevor_Sharpe_(trevor_(Delete)_309647)

Hey Matt,In the opentext.ini file, (\OpenText\config\opentext.ini) you can edit a line called "MaxUsersInGroup=1000".You can change the value to whatever you want, although I have not experimented with this setting to ensure that it supports large values.It may be worth a try on a test (not *production*) system.

Robert_Davies_(unlondonadmin_-_(deleted))

Thanks Trevor.I'll post again when I have had a chance to test that this works ok. Thanks also because it highlighted some other important items in the opentext.ini file such as 'MaxUsersToListPerPage'.Good stuff.Best regards/matt.

Stu_Baker_(NWUAdmin_(Delete)_1936065)

In training we were cautioned against exceeding the 1000 member limit. Not clear why this is a problem. It will definitely be worth figuring our because we will share the same problems with our student population.

Brad_Maybee_(bmaybee_(Delete)_178992)

As Trevor says, you can increase the value in the opentext.ini file. However, you should be aware that there is a hard limit of 8192 and increasing the number will affect performance (how much is hard to say - you'll have to experiment in your environment).

Robert_Davies_(unlondonadmin_-_(deleted))

Hi Brad.I'm interested in this hard limit. Can you explain in a little more detail what that means? Given that we are running on top of a scalable enterprise database I am concerned that there seems to me to be a low thresholds for such a value.What are the issues with raising the limit? What causes performance to slow down?If this is a real problem (and that's how it's sounding) what are OTC doing about making Livelink more scalable in this regard?I am also concerned that this probably isn't the forum to discuss this and remain on-topic. However since the other (non-SDK) groups appear to be all but deceased I'd prefer to leave it here for now.Best regards/matt.

Brad_Maybee_(bmaybee_(Delete)_178992)

Matt,As I recall, the issue here is that a RecArray of size 8K is allocated to hold the users. So, if you have more than 8192 users in a group, you blow the array. The performance problem I mentioned has mostly to do with building HTML pages that will display all members of a group.As for scaling, I don't think this should be a problem. I didn't make it clear that the 8192 number is for direct members; these could be other groups. That is, GroupA could have all groups as its 8192 members. These groups could in turn be made up of other groups. So, while GroupA doesn't have more than 8192 members, the number of people underneath GroupA could be in the many, many thousands. We thought of this with an organizational chart in mind and didn't think that many companies would have a department with more than 8192 direct members who weren't actually in sub-departments.Brad

Robert_Davies_(unlondonadmin_-_(deleted))

Hi Brad.I take your point about using Sub groups, and in fact in our environment I could group students by:Group:-YearOfEntry98--lots of students-YearOfEntry99--lots of students-Students--YearOfEntry98--YearOfEntry99and so on, and this might well work. However from the point of view of LDAP integration, this is not convenient and it is this that I am primarily worried about.How feasible would it be to up the limit on the size of the RecArray to a higher value? In my case I would almost certainly raise it to 16K. Do you have any hints about where to look for this value (he said after thoroughly checking his opentext.ini file!)I figure that the number of members per group/HTML issue should be handled by the opentext.ini settings for handling items on pages shouldn't it?Kind regards/matt.

Brad_Maybee_(bmaybee_(Delete)_178992)

Matt,I don't think it is possible to change the size of the RecArray; it is in the code and used in more than just this spot.Cheers,Brad

Robert_Davies_(unlondonadmin_-_(deleted))

Hi Brad.Ok that's not good news, but could I add this as a request for a future version? Who should I contact about this?Best regards/matt.

Jonathan_Morgan-Jones_(TMATelecomAdmin_(Delete)_14

We already have our TMA members group populated to over 1000 members and I have to admit I was not even aware of the Opentext.ini file setting. All appears to be functioning normally.Cheers,Jon.

Dany_Riopel_(alcateladmin_-_(deleted))

We are concerned about this limitation as well, since we are planning to implement LDAP integration.From the information that I received on this matter from OT Support, the issue is that your browser may time out if you are trying to display the entire group contents for a group with more than 1000 members. We have no plans to manage these types of groups from the Web interface , since we will use LDAP.We plan to test this as well.

Brad_Bosley_(bradbosley_-_(deleted))

The 8192 limit was lifted in 8.0.0 Motorola currently has over 12,000 users in DefaultGroup (although I don't recommend it).

Robert_Davies_(unlondonadmin_-_(deleted))

Hi.Sorry can I just confirm that you are saying that Livelink no longer has this hard coded limit of 8192 members-per-group? Or has the limit just been raised?It doesn't sound like you are entirely happy with it either. Can you hint at what the problems are? Speed? Instability? Best regards/matt.

Brad_Bosley_(bradbosley_-_(deleted))

There use to be a hard limit of 32k records for an array and 8k if you tried to sort the array. These limits have been lifted to something like 2.2 million.We have an auto-registration feature that allows users to create their own account (it validated against our LDAP directory). Currently we are dumping all of these users into DefaultGroup. One of the biggest problems I see is just simple ACL management. When these users are creating items they end up inheriting the owner group ACLs from the parent and giving them out to everybody in DefaultGroup (probably not what they were going for, but who ever looks at the actual ACLs...). Another problem occurs when they create a project. DefaultGroup is added to the membership list and ALL of those users get a notification that they where added to the project. They then turn around and contact our help desk because they don't understand why they belong to the project. If you do get a project like this make sure not to go to the project participants tab. When you pull this tab up it generates a mailto link to every member (not good with 12,000 email addresses). Anyway, we are going to modify our auto-registration script to also create department level groups and place the users in there.I'm not sure if there have been any performance issues with having a large group. We are investigating some slowness in the notification agent right now. I'll let you know if this is an issue.

Robert_Davies_(unlondonadmin_-_(deleted))

Hi Brad.Thanks for the info this is very useful.I think the management side of Livelink is going to need a radical rethink as more people start using the product in the kind of configuration you are talking about.Best regards/matt.

Michael_Pate_(aflacadmin_-_(deleted))

We ran into a problem with groups of more than 1000 members in our NTLM domain from which we inherit our users. When one of our groups enlarged to more than 1000 users, Livelink ignored users beyond the 1000th, resulting in lost permissions for certain users. Fortunately, this group was not the one that populates our users, but only populates a group that controls access to certain content. When we increased the opentext.ini setting to 3000, we saw no performance problems and it works as expected. I just hope we can upgrade to a directory service soon so I am not stuck with the flat structure of NTLM.