- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-28-2019 01:21 PM
I am facing an issue preventing service mapping of Citrix XenApp based application in the way described here.
At a stage of Controller discovery by pattern Delivery Controller => Identification step 6 {get application in xml format} obtains all configured applications by a PowerShell command. Customer has ~ 1000 entries. On the next step the output of the entries generate an error message
setAttribute(xml_output,The max object size reached the maximum limit of [1000]. To adjust this use the mid property mid.sm.discolog.max_object_size.)
Despite documentation indicates this property to be only for Horizontal Discovery Log objects it also effects behavior of Service Mapping in Discovery log. https://docs.servicenow.com/bundle/madrid-servicenow-platform/page/product/mid-server/reference/r_MI...
Meanwhile the Debug Mode of the pattern doesn't give such error message. I think it should be taken into account in future releases.
I have increased the default value 10 times to 10000 and it increased the output part shown in the service mapping log but it is not sufficient since one application entry in XenApp bring ~500 characters. I am not sure that it is safe to set the value to 500000. Please clarify how can we proceed to get the XenApp applications discovered by the pattern??
Solved! Go to Solution.
- Labels:
-
Service Mapping

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-28-2019 07:33 PM
I ran into this exact same issue in two different scenarios.
1) XenApp Mapping as you described
and
2) Discovering core routers with extremely larger SNMP Tables
I did change this property, but to 5000000 (5,000,000) and it fixed the issue.
As a note, This will cause the sensor processing in the ecc queue for these records to take a little longer (because the payload is much larger) and will use more memory anywhere the payload is stored (mid and instance), but I haven't noticed any adverse impact from it and we are running Discovery and Service Mapping quite a bit across hundreds of schedules.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-28-2019 07:33 PM
I ran into this exact same issue in two different scenarios.
1) XenApp Mapping as you described
and
2) Discovering core routers with extremely larger SNMP Tables
I did change this property, but to 5000000 (5,000,000) and it fixed the issue.
As a note, This will cause the sensor processing in the ecc queue for these records to take a little longer (because the payload is much larger) and will use more memory anywhere the payload is stored (mid and instance), but I haven't noticed any adverse impact from it and we are running Discovery and Service Mapping quite a bit across hundreds of schedules.