Web Interface slow performance

Question

Hello -

It seems we've been experiencing some slow performance via the web interface lately. It was reported to me that it seem to have gotten bad within the last week. It happens more so when an object is clicked on after a search, but also on a regular search.
We are on version 3.7.12818.0. No major changes to our AD infrastructure, so I'm not sure where to start to troubleshoot.
We only have 1 server that caters to Adaxes.

Thank You

Comments

Its a VM, so I added 2 more processors totaling 4, and bumped up the memory to 8GB from 4GB.
Didn't seem to make a difference. There is also over 40GB on the hard drive free where installed.

---

Hello,

To help us troubleshooting the issue, could you clarify the following:

It happens more so when an object is clicked on after a search, but also on a regular search.

So, as far as we understand, the main issue that it is slow to open an object after a search. What about the search itself, is it also slow? What about other operations, for example, browsing the AD or creating an object?

Does it take a long time to log in to the Web interface?

What about the Administration Console? Is it as slow when performing the same operations in the Administration Console?

Can you log in to the Web Interface as Adaxes default service administrator (the user that you specified when installing Adaxes service) and perform the similar operations. Is it also slow when logged in as the default service administrator?

---

on a regular search it takes a while, but not as long as clicking on the object once located. I conducted the same search in admin console, and it was fine.
browsing is intermittent with the slowness. Via the admin console, works fine.
Logging in, i see no issues.
creating a new object appeared ok so far.

---

What about the last test, did you have a chance to check the following:

Can you log in to the Web Interface as Adaxes default service administrator (the user that you specified when installing Adaxes service) and perform the similar operations. Is it also slow when logged in as the default service administrator?

Also, a couple of additional questions:

How many AD domains do you manage with the help of Adaxes? Do you have at least 1 domain controller for each domain in the same AD site where Adaxes is installed?

When you try opening an object that you searched for, does the slowness occur for objects from all domains or only specific domains?

---

my apologies, totally missed that part.

Same thing applies regarding the slowness when logged on using the service account via the web interface.
browsing does seem to take a bit longer that the other account.
We have 1 domain that we manage.

---

Hello,

Can you check whether the dynamic RPC ports used by the Web interface to connect to your AD are open? For a list of the necessary ports, see article What ports does Adaxes use?, footnote To enable communication through dynamic RPC ports.

If the necessary ports are open, can you do the following for further troubleshooting:

1. Enable tracing in the Web Interface. For information on how to enable tracing, see instructions below.
2. Log in to the Web Interface and try performing several operations that usually cause the biggest delays.
3. When tracing is enabled, the trace information is saved to a file. Attach the file to and send it to our support email (support[at]adaxes.com).

To enable Web Interface tracing:

1. Find the Web.config file and open it with any text editor. It is located in the folder for the Web Interface site you need, which is C:\Program Files\Softerra\Adaxes 3\Web Interface\*<Web Interface Name>*\ by default.
2. Set the enabled parameter of XML element configuration\system.web\trace to true.

    <i class="text-italic">
    <configuration>
      ...
      <!-- Web settings -->
      <system.web>
        ...
        <!--- Trace settings -->
        <trace <strong class="text-bold">enabled="true"</strong> pageOutput="true" requestLimit="40" localOnly="false" mostRecent="true" /></i>

3. Find XML element configuration\system.diagnostics\trace\listeners and uncomment the add element embedded in it.

    <i class="text-italic">
    <configuration>
      ...
      <!-- Web settings -->
      <system.diagnostics>
            <listeners>
              <span class="color" style="color: #FF0000;"><s class="text-strikeout"><!--</s></span>
              <add name="xmlListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="[PathToTraceFile]" traceOutputOptions="Callstack" />
              <span class="color" style="color: #FF0000;"><s class="text-strikeout">--></s></span>
            </listeners></i>

4. In the initializeData parameter of the add element, replace [PathToTraceFile] with a full path to the Web interface trace log file that will be generated.
   <add name="xmlListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="C:\TraceOutput.svclog" traceOutputOptions="Callstack" />
5. Save changes.
6. Restart IIS for the changes to take effect.

---

ports are good to go.
I sent the email. thanks!

---

Hello,

It looks like the delays are related to Office 365. Did you register an Office 365 Tenant in Adaxes? How long ago did you do that? Were there any changes related to Office 365 recently? For example, maybe you added a big number of users to Office 365 or migrated a bunch of mailboxes to the cloud?

Also, can you send us a copy of Adaxes Event log? For information on how to access it, see the following help article: http://www.adaxes.com/help/?ServiceAdmi ... ntLog.html.

---

Hi,

We upgraded to the current version 3/24/16.
I will find out about how many accounts were migrated from then until now, although I don't believe its a ton.
I will send the logs in the interim via email. Thank You.

---

As per the Helpdesk about 5 accounts were created and or migrated give or take.

---

Hi,

just checking in to see if anything was found via the logs.

Thanks

Answer 1

Hello,

Judging by the Event Log, there are indeed certain issues with connecting to your Office 365 tenant. Are you able to manage Office 365 properties of users with the help of Adaxes? Are you able to assign or revoke Office 365 licenses? It seems like Adaxes cannot perform any operations in Office 365 at all. Since Adaxes cannot normally connect to Office 365, time is wasted to fetch Office 365 properties of users, which causes the Web Interface performance issues.

Also, judging by the errors, when Adaxes fails to perform an operation in Office 365, this caused by the fact that the Azure AD Module for PowerShell receives malformed XML responses from Office 365. Do you have some sort of proxy or something like that in between the computer where Adaxes is installed and Office 365? It looks like there is some proxy that alters headers of HTTP responses from Office 365, which results in the ability to interpret those responses by the Azure PowerShell Module.

We recommend that you try removing all items from the Activity Scope of your Office 365 Tenant and checking whether this fixes the Web Interface issue.

Comments

Thank You.

I will take a further look.
Upon an initial look via Cloud Services in the Adaxes Console, the dirSync date reflects march 28, 2016. Does that indicate the last time the DirSync took place according to Adaxes ?
When I view the Synchronization Service Mgr, the last sync data reflects today.

We typically do not use proxies here, so don't believe there's one between O365 and the Adaxes server.

I just viewed some objects and tried to look at the O365 properties, and it said "the user doesn't have an office 365 account". So, there is a disconnect...this is weird b/c when it was upgraded I tested a few accounts and was able to see the properties. Not sure when and how that disconnect happen.

Also - reg the managed tenant, I've only listed my account there. Since the helpdesk uses Adaxes to manage etc, would their accounts need to be listed there as well? They have admin right within O365.

I've removed the items and the performance is definitely back to normal, i.e fast and as expected.

---

Hello,

The behavior that you describe clearly indicates that Adaxes cannot connect to Office 365. To help you troubleshooting the issue, on the computer where Adaxes is installed, can you launch the Microsoft Azure AD PowerShell Module and try establishing a connection to your Office 365 Tenant using the Connect-MsolService cmdlet and the credentials you specified when registering the tenant? Can you try the same from the computer that performs directory synchronization?

Also, alongside with XML errors, there are also Access Denied errors when connecting to Exchange Online. Can you check that the account you used when registering the tenant is assigned either to the Global Administrator or the User Management Administrator role in Office 365?

Also - reg the managed tenant, I've only listed my account there. Since the helpdesk uses Adaxes to manage etc, would their accounts need to be listed there as well? They have admin right within O365.

You need to assign a Security Role that allows Office 365 account management to your helpdesk guys. For more information, see Grant Permissions to Perform Office 365 Management Tasks. If they also need to perform certain operations with Exchange Online mailboxes, also have a look at Grant Permissions to Perform Exchange Tasks

---

Hi -

I was able to successfully connect via Azure AD Module from the Adaxes and from the same computer that performs Dir sync using the credentials used when registering the tenant.
The account being used is a Global Admin.
yes yes, HD already has the permission to write O365 properties.