Bad performances on secondary server

Question

Hi Adaxes team,

We have a second Adaxes server in Asia (main one in Europe) and replication is workgin fine. The problem is that using Web interfaces on this server is painfully slow compared to the first one, just like if it needs to contact his counterpart in Europe for each action. Is there something i can check ?

Thanks in advance

Comments

Hello,

It looks like the Web Interface in Asia fails to connect to the nearest Adaxes service...

What version of Adaxes are you using? There was a known issue related to Adaxes service location, but the issue is fixed in the latest versions of Adaxes.

Are the Web Interface and Adaxes Service in Asia installed on the same computer?

Please have a look at the Adaxes Event Log on the computer where the Web Interface is installed. Are there any errors related to the issue?

---

Sorry for late reply.

Version : 3.3.8123.0
Web interface is colocated with Adaxes service
But you're right, there are some errors in eventlog !

When it times out :

Softerra.Adaxes.Web.Utils.LogMessageWrapperException: Failed to fetch the list of groups the user 'ap00sroux@ap.loi.net' belongs to. ---> System.Threading.ThreadAbortException: Thread was being aborted.
at Softerra.Adaxes.Web.Common.ManagedDomainCache.DetermineIfDefaultContextBindable(String domainName, String defaultNamingContext, IAdmService admService, NetworkCredential credential)
at Softerra.Adaxes.Web.Common.ManagedDomainCache.LoadCacheInfo(IHttpContext context)
at Softerra.Adaxes.Web.Common.ManagedDomainCache..ctor(IHttpContext httpContext)
at Softerra.Adaxes.Web.Authentication.ActiveDirectoryRoleProvider.UserDirectoryGroupFetcher..ctor(String username, List`1 roleContainer)
at Softerra.Adaxes.Web.Authentication.ActiveDirectoryRoleProvider.GetRolesForUser(String username)
--- End of inner exception stack trace ---

or

A server-side sponsor for client '1|APHKGRES02.ap.loi.net|APHKGRES02$@ap.loi.net|480|2' has expired. Sponsorship for its '1' registered CAOs will be discontinued.

I will dig it this ev a little bit more and post update if necessary

Thanks

---

Hello

Can you please connect to the Web Interface in Asia, perform an operation, and have a look in the Adaxes Log of the Adaxes service in Europe. Does the log contains a record for the operation?

---

No, the operation is well logged in Asia Adaxes server.

---

Hello,

It looks like the Adaxes service in Asia fails to find any available domain controllers located in Asia and connects to a DC located in Europe. Please make sure there is a DC in Asia that can be accessed by the Adaxes service.

---

We have on the same site a DC for the root domain and the Asia domain. We don't want local IT to manage other domains (for which we don't have DC on that site). What is the good setup then in Adaxes ? Because as we share the configuration, others domains appear in the list.

Thanks

Answer 1

I suggest you unregister all AD domains that you don't want to be managed from Asia only on the Adaxes service located in Asia, so that when a user connects to the Asian Adaxes service, he/she would be able to view only two domains (the root domain and the Asian domain).
Unregistering the domains that are not located in Asia may solve the performance issues because the Adaxes service will not try to perform queries in those domains.

Another option is to install a read-only domain controller in Asia.

Comments

But if i remove a domain from this server, it will remove it from the Shared configuration so it means i will loose it from Europe too ? Or am i wrong ?

---

No, if you unregister (not remove!) a managed AD domain on an Adaxes service, the domain will be unregistered on that service only. The rest of the Adaxes services in the configuration set will manage the domain.

---

Ok gotcha.
I unregistered all domain without a local DC.
It's far better, not as fast as the EU server, but that's usable now.

Thanks for your help.

---

Sorry to bother you again with that problem, but we are once again facing slowness issue.

This time, this is while using the MMC (and i believe it explains why web access is still slow). Each time a want to explore a node, it takes dozen of seconds to open it (mmc using Adaxes service on that server). If i use the Adaxes service account, it works immediatly. I tried with an account with service administrators rights, still slow.

I tried to block all access to the first server (with a firewall rule) to check if the console was using the wrong server (even if i'm connected to the right Adaxes service) but that's not the case : i can still access object but it's terribly slow.

I checked Adaxes event log but no error.
Only one domain is connected and there is a local DC for that one.

I upgraded to the latest version available (3.3.8318.0)

Thanks for your help

---

Hello,

I tried with an account with service administrators rights, still slow.

What do you mean by 'account with service administrators rights'? Try adding that user to the list of Adaxes administrators and test it again. For details, see Add/Remove Service Administrators.

What happens if you expand a node, and then refresh it? Will the second attempt be any better?

---

You're right, i meant Adaxes Administrators. So the test has already been done with no luck.
And yes you're right again, the second time i try to access an object, it's fast but the problem is that if i close the console, this cache seems to be flushed, so back again the next time to trouble.

---

Hello,

Try restarting your Adaxes service.

Do you have a local Global Catalog server?

Please confirm that if you are connected using the account of the default service administrator, everything works fast, but if you are connected using the account of another Adaxes service administrator, the performance is bad. It's very important.

the second time i try to access an object, it's fast

Did you press F5 to refresh a node?

---

Ok i did a complete set of test to make sure you have all the information you need. But i want to describe the context first, it will help a lot i'm sure.

We have a multi domain forest :

LOI(Root), and several child domains (Europe-Americas,Asia-Pacific)
We use a global service account for Adaxes which is in the root domain
The first Adaxes server is in the Europe domain
The second one is in Asia-Pacific domain
We plan to deploy a third one in Americas domain (once current issue solved)

In Europe, which is the main datacenter, we have a DCs for every domain in the forest.
In Asia, we only have DCs for Asia-Pacific and Root domains
In Americas, we only have DCs for Americas and Root domains

So in Asia, we activated/registered only Root and Asia domains in Adaxes console

What we did

1. Restart Adaxes service
2. Try with the service account/default service administrator : performance ok
3. Add an Asian account as a service administrator, log-on to Adaxes : performance ok
4. log-on to Adaxes with an existing service admin account from Europe domain : slow
5. Remove the Asian account from service administrators (but still have rights to see all objects through security roles), log-on to Adaxes : slow
6. While connected with same account as #5, i open a node, or a Business Rule for instance : slow. But if i refresh with F5 : ok (fast).

We have 3 GC on the same site (2 from Asia domain, 1 from Root domain)

Note a strange thing : Adaxes can resolve SID/Guid to name (i can see all service administrators full name) if root domain is registered. If i unregister root domain, Adaxes only resolve local (Asian) account. I find it strange, because with Root domain registered it can resolve European account even if the Europe domain is not registered.

If i tried to list service admins with account in #5, i've got an error in the tab "Failed to fetch the service administrator list. The 'ConfigurationSetSettings (Adaxes)' object does not exist." which might be normal or not.

Hope it helps

Regards

Stephen

---

Hello Stephen,

Ooh, that wasn't easy to find the reason, but I think we managed to.

Today or tomorrow we'll release a new update that'll hopefully fix the slowdowns in environments like yours.
I'll update this post as soon as the new build is available.

Note a strange thing : Adaxes can resolve SID/Guid to name (i can see all service administrators full name) if root domain is registered. If i unregister root domain, Adaxes only resolve local (Asian) account. I find it strange, because with Root domain registered it can resolve European account even if the Europe domain is not registered.

That was the key to find the problem.

---

Great to hear my long post was helpful :-)

Thanks a lot, i wait for the fix.

Regards

Stephen

---

Hello Stephen,

We've uploaded the new latest version.

Download URL
Upgrade Instructions

Please let me know whether the issue has gone. Thanks.

---

It seems to be far better ! I will give you an update next week, after few days of use.

Thanks

Stephen

---

Great!