Information Centric Tagging Client taking too much time to get configuration
search cancel

Information Centric Tagging Client taking too much time to get configuration


Article ID: 172942


Updated On:


Information Centric Security


Information Centric Tagging (ICT) Client Taking too much time to get configuration from web-service, specially if using VPN.

The configuration retrival should not get long than 5 seconds – normally it will take 2 seconds


If getting an error such as “problem accessing the webservice – limited access to the network – please verify your settings” or “cannot compose a new message without any active classification level”, validate that the request is getting the server.

For this, open debug view and validate the time within the IIS logs. You should get something like as follows:

  • IIS logs

2015-12-11 12:17:35 GET /rightswatch/webservice/mlsservice.asmx - 80 - Apache-HttpClient/UNAVAILABLE+(java+1.4) - 401 2 5 162

2015-12-11 12:17:35 GET /rightswatch/webservice/mlsservice.asmx - 80 WFSW\jdoe Apache-HttpClient/UNAVAILABLE+(java+1.4) - 200 0 0 187

2015-12-11 12:17:35 POST /rightswatch/webservice/mlsservice.asmx - 80 WFSW\jdoe ksoap2-android/2.6.0+ - 200 0 0 581
  • Debug View

[15444] [11/12/2015 12:17:35] UsersBLL:CheckAndUpdateUserRolesAndLicensesAccordingToGroups: 0: WFSW\jdoe -> Starting CheckAndUpdateUserRolesAndLicensesAccordingToGroups()

[15444] [11/12/2015 12:17:35] UsersBLL:CheckAndUpdateUserRolesAndLicensesAccordingToGroups: 0: WFSW\jdoe -> Finished CheckAndUpdateUserRolesAndLicensesAccordingToGroups(). It took 0.0029611s to run.

As detailed above, both started and finished at the same time (2015-12-11 12:17:35) which means that there is not problem in the RightsWATCH operation – server is getting the request and the response is sent right away.

If there is a diference between the time the user started to get the configuration, in the device, and the first GET– when the user gets to the server – please validate the network trafic - Firewall blocking the request, VPN not working in the device for applications, etc.

If there is a delay between the first GET and the POST, this can be related to RightsWATCH operation in the server. You can validate how much time is it taking between the first and last line in Debug View.

In the RightsWATCH logs, you can also find some more erros that can explain the delay or failure. For example when it is failing to get to the AD to update the group membership:

System.DirectoryServices.ActiveDirectory.ActiveDirectoryServerDownException: The RPC server is unavailable.
Name: "DC01.WFSW.local"

For this example, try to verify what if the LDAP Global Catalog Path and the Ldap Pathc configured in the AD settings under the System setup of the Administration console.