Home
TeamSite
Logon very slow for non-admin users after upgrading to 4.5 SP2
Phead2
Logon processing is very slow for non-admin users after upgrading to 4.5 SP2 from 4.0 SP1. There is no noticeable issue with admin users. When logging on the non-admin user the CPU usage on the mediabin server goes to 100%. The user will eventually get logged on and everything appears correctly.
Any known reason for this? My guess is that in this version the entire container list is pre-loaded when logging on (container tree response is much faster than on 4.0). While this is a nice feature the logon process is taking way too long - is there anyway to speed it up?
Find more posts tagged with
Comments
Migrateduser
I'm guessing you may have made some permissions changes or added a new folder "branch" after the upgrade. Below is an explanation previously posted that may cause this problem.
Before you set up your permissions, you should be aware that MediaBin clients display a folder to which a user has "no access" permissions if that user has access to any of its child folders. You should avoid creating deep folder trees immediately under the root folder, that may have permissions set to "no access" for the entire branch or to some point deep in the branch. MediaBin web client displays all folders immediately under the root folder when a user logs in. Therefore, if you have several very deep branches off the root that are inaccessible to that user, MediaBin server still traverses the branch, checking permissions on each folder to see if the user has access to any of them. It stops either at the first folder the user has access to or at the end of the branch. The side effect of this is that it takes a long time for the MediaBin web client to display the primary page after login.
We can make a patch available that may help, BUT ONLY for branches that originate under the root that are completely inaccessible to the non-admin user. For example, if you have MediaDatabase\CantSee and MediaDatabase\CanSee, we can generate a patch that will cause the web client to request the CanSee tree explicitly, rather than ask MediaBin Server for all child folders of MediaDatabase. Also, CanSee must not change. The GUID for the folder(s) is explicitly included as part of the patch. (in fact, the web admin would have to edit the patch to supply the GUID(s))
Phead2
This is our first test pf 4.5 SP2, there haven't been any changes made besides the upgrade at this point - that being said, yes, we do have some deep folder trees directly in the root directory which user(s) may not have access to. It basically looks like:
Media Database>
Section 1 (access restrirctions)
Section 2 (access restrirctions)
Section 3 (access restrirctions)
Section 4 (access restrirctions)
etc.
Before deciding what to do, can you explain to me a little more clearly what happens when a user logs on (specifically relating to retrieval of permissions settings)? If I understand correctly you are saying that all users should have some level of access to any container in the root (Media Database).
For example change structure to:
Media Database>
New Folder (all users have list access)>
Section 1 (access restrirctions)
Section 2 (access restrirctions)
Section 3 (access restrirctions)
Section 4 (access restrirctions)
etc.
If that's the case I could probably change it accordingly. I would be interested in the patch as well if it's for the web client specifically especially if can help performance of the web client as the vast majority of the items in MediaBin do not need to be accessed by web client users.
One final question - what are the permissions on 'Media Database' supposed to be? In our deployment there are no permissions on this section.
Thanks!
Phead2
I changed the container structure as I outlined above, it did cut the logon time by ~50% but it is still quite lengthy. The user(s) now see the main logon page right away allthough it still takes awhile for the folder tree to come up (it displays "Loading" for about 2 minutes). I am curious as to what exactly is different in 4.5 SP2 from 4.0 SP1 in this regard...
I am a little confused by the suggestion of not having deep branches with no access in the root - if the server is going to check every branch anyway before showing the container tree what difference does it make if a no access container is in the root?
At any rate it seems that a modification to allow for only certain containers to be checked/displayed via the web client would be necessary to have acceptable logon times. Is this simply a configuration change or (ie a config file) or does something else need to be changed?
Migrateduser
There is no difference in the client software from 4.0 to 4.5.2 in terms of populating the folder tree. I wasn't aware of any changes on the server-side, but I can't be 100% certain. We have customers running 4.0 that have this problem. The patch I wrote about was developed for a customer running 4.0.
As far as your change, the web client looks two levels under the root in order to determine if a plus sign (+) should be displayed beside a folder, indicating that it contains subfolders. If a user doesn't have access to any of the subfolders, the plus sign is omitted from the display. For this reason, I'm surprised it had any effect. Sorry, I realize I omitted this detail from my original post.
Since you have entire folder branches restricted from view for some users, the patch will work for you. The only issue would be that the top level folders that are accessible are static. Otherwise, the patch would have to be updated each time a new top level folder was added. The patch is a set of modified ASP files that include a list of GUIDs for folders that should be displayed by the web client immediately under the root container. Normally the web client relies on the server to determine what subfolders should be displayed to a user. This change circumvents that. Instead of the web client asking the server for "all child folders" of the root folder, it asks for each folder explicitly by GUID.
Another solution would be to use LIST permissions instead of NOACCESS. We have a permissions application that would facilitate propagating permissions down folder trees in MediaBin if that is the route you choose to take. You would set all folders that are now permissioned as NOACCESS to EVERYONE LIST.
Your MediaDatabase permissions should be set like any other folder permissions. They govern what a user can do in the root folder.
To answer your question:
if the server is going to check every branch anyway before showing the container tree what difference does it make if a no access container is in the root
When a user logs into the web client, the web client asks the server for a list of all child folders of the root folder. The server determines what this list is by examining permissions for each subfolder under the root. If a subfolder is set to NOACCESS for the current user, the server must check the subfolders of that child folder recursively, to determine if the top level child should be returned to the web client. It does this because MediaBin allows you to restrict access to a parent folder (NOACCESS), and allow access to its child folders. If this is the case, the user must at least see the parent folder to be able to navigate to the child folders.
Phead2
We would be interested in this patch for the web client, setting all containers to Everyone List permission would not be ideal. How can we get it?
Migrateduser
Please contact Product Support for the patch. When you contact Support, you may also ask them for instructions for adjusting the MediaBin server Security Cache. This may also help. MediaBin server will cache security tokens for folders. The time consuming part of the permissions check operation is getting the security token from your user directory (Active Directory?). However, note this is a cache that is populated as security tokens are required. Therefore, after restarting the MediaBin server, the first user logging in would still see a long delay before the primary page of the web client is populated. Subsequent attempts may be faster.
