Understanding AD Authentication

It sounds like you need more horsepower to do what you want.  With 5,000 users, on what platform are you running Astaro?

In my experience, you can't have your own whitelist if there's no user defined in Astaro.  I haven't experimented with NOT allowing autocreation.  You've probably already thought about leaving auto-create off and limiting the pre-fetch to managers and some deparments.

What about changing the inactivity timeout to 36000 so that you just have to sign on once a day?  I do that anyway and just have a short time-out requiring password on my desktop.

Cheers - Bob

Two servers running in Active-Active cluster, they are HP DL385 G1's, Dual XEON 2.6Ghz with 4GB or Ram.

I think you answered my question with the statement about not having a whitelist if you do not have a user defined on Astaro. I do not want to prefetch at all, even if we only did staff and faculty, we are looking at 4000 accounts, and that caused too much of a slow down in the interface.  It effects more than just the login, anytime you click on the folder icon to choose a network, host, user, group etc, you are looking at the caching of all 4000 objects, so increasing the timeout, which we have done, only helps with the login portion.

What I would love is a straight answer from Astaro on what type of hardware you need to implement a large scale user sync like this.  Surely we are not the only organization with 50,000 mailboxes, I hope.

It sounds like you need more horsepower to do what you want.  With 5,000 users, on what platform are you running Astaro?

In my experience, you can't have your own whitelist if there's no user defined in Astaro.  I haven't experimented with NOT allowing autocreation.  You've probably already thought about leaving auto-create off and limiting the pre-fetch to managers and some deparments.

What about changing the inactivity timeout to 36000 so that you just have to sign on once a day?  I do that anyway and just have a short time-out requiring password on my desktop.

Cheers - Bob

Just wanted to add a note, that even when we are experiencing the slowness in the interface, the "Resource Usage" on the dashboard, never goes far beyond 20% CPU and 30-40% memory utilization.

It sounds like you need more horsepower to do what you want.  With 5,000 users, on what platform are you running Astaro?

In my experience, you can't have your own whitelist if there's no user defined in Astaro.  I haven't experimented with NOT allowing autocreation.  You've probably already thought about leaving auto-create off and limiting the pre-fetch to managers and some deparments.

What about changing the inactivity timeout to 36000 so that you just have to sign on once a day?  I do that anyway and just have a short time-out requiring password on my desktop.

Cheers - Bob

I think you should open a support ticket with Astaro.  If you have slowness when the CPU isn't over 20%, then there must be a bug.  It might be in a device driver or maybe code produced by Astaro.

Are you certain that all of your devices are approved on the HCL including your drive controller?

We have a support case open.  Our hardware is approved.  You should be able to reproduce, if you want to see for yourself, just prefetch about 4000 users. After further testing we have narrowed it down to just these two issues, which are apparently due to the database design structure in Astaro.

1)  With a large amount of objects, not just users, but in our case mostly users, when you first login it will take some time to cache everything, you will see the progress counter working.

2)  The first time you access the object container folder for drag and drop, it will cache every object and this could take some time, as indicated by the progress counter and a message.

The good news is that if you are using Fire Fox you will not have to cahce those objects again, for instance if you were just in an area where you were using drag and drop and you cached all the objects, and now you are in another area and initiate the drag and drop menu it will pop up in about 1-2 seconds.  Doing this in IE however, the pop up for the drag and drop menu takes around 20-30 seconds, even after the menu has been fully cached.

We have made some design change suggestions to Astaro that should help environments with large amounts of objects with respect to the drag and drop menu.  One is that the caching of that menu should be done in the background along with an index of that table.  Also, rather than having the default filter for the drag and drop menu be "All Objects", it should be a search mode so you can type in a filter for objects and the "All" objects selection would be a secondary option.

We are going to live with it for now, but it has changed our deployment plans for this version 7.x, there is no way we can allow for our student body to manage their own whitelists with End User Portals if it involves the creation of over 40,000 Astaro profiles to be created.

It is clear that some design decisions were made for this version that negatively impact the large enterprise sized organizations, with respect to the removal of bulk management with whitelists, and now this design flaw when used with thousands of objects.

There are ton of other awesome features however that make it definitely worth our while to implement now and use over our version 6.x boxes.

I think you should open a support ticket with Astaro.  If you have slowness when the CPU isn't over 20%, then there must be a bug.  It might be in a device driver or maybe code produced by Astaro.

Are you certain that all of your devices are approved on the HCL including your drive controller?

Thanks very much for your posts above.  Let's hope Astaro quickly resolves the caching problems.

Cheers - Bob