Adobe Connect Support Blog

September 24, 2012 /Administration /Application /General /

Using mode=xml to Debug or Obtain Additional Information in ACP


While navigating and performing tasks in the Adobe Connect Manager (all server versions), it is sometimes useful to further identify properties of the account, the item(s) you are viewing, the server you are currently connected to, the session, and any error messages you may be encountering.  Using an additional URL query string in the browser’s address bar, you can display additional XML data in the bottom of each browser page you visit in your active Adobe Connect Manager session.

Using mode=xml

A typical URL to an Adobe Connect login page would look like this (using Adobe Hosted as an example):

If you wish to also get the XML data displayed at the bottom of the page, you can append ‘?mode=xml‘ to the URL above and hit enter or go on your browser to navigate to that page.

(so the url would now be:

The current page and each page after this (during this browser session) will have the XML data displayed in a nice debugging window in the bottom of the page (scroll all the way down after navigating to the page, to view).  You will notice now the ‘mode=xml’ will be present in each subsequent URL in the address bar during your session in the Adobe Connect Manager.  It will automatically get added to each query after this, in that session.

If you are already logged into Adobe Connect and are browsing around in the Adobe Connect Manager and wish to add the XML data at the bottom of an existing page, you can add ‘&mode=xml‘ (not the ‘&’ in place of the ‘?’) to the end of the URL you are currently on (and hit refresh in the browser to resend the query and obtain the debugging window at the bottom of the browser session).  This is because you would already have a ‘?’ present in the query string in the URL.  Everything parameter added after that initial query will have the ‘&’ preceding it.

So a an example would be if you were actively viewing the Home page in your Adobe Connect account at:

You would then add ‘&mode=xml‘ to the end so it would now appear as this:


Some useful information returned from this XML output is:

  • status code: This will generally have an ‘ok’ value unless an error is encountered.
  • cookie: This is your current session value
  • host: This is the Adobe Connect URL (domain)
  • local host: This is the actual server name you are connected to
  • version: The Adobe Connect Server version
  • account-id: The account ID (only applicable to Hosted accounts as a Licensed/On Premise account is always = ‘7’)
  • user information (user-id, name, login of the user currently connect to the Adobe Connect session)

…along with many other parameters and data for the current page/account you are connected to and viewing.

Use Cases


  • When doing this, one thing you’ll recognize is that in Internet Explorer, Firefox, Chrome, Opera, and Safari (all the browsers I’ve tested) you will get the server name (Local Host value) in the Tab’s description of the page you are viewing.  This is very helpful in quickly testing (for example) an Adobe Connect cluster.  You may want to make sure all servers in the cluster are accepting requests for the web application piece of Adobe Connect.  You can append the ?mode=xml parameter to the URL, hit refresh on the browser, and see the actual server that is handling that request to the web application.  You can keep hitting refresh and see what servers you are on in subsequent requests.
  • While using an Adobe Connect cluster (whether it is a Licensed/On Premise deployment or an Adobe Connect Hosted account), you may want to see what local host you are on when making a request, so you can go back and look at server logs (or notify Adobe support with specific information regarding what server you were connected to).  For Licensed/On-Premise installations, it is very useful because if you run into an error or problem with a specific function of the Adobe Connect web application, you can identify what server you are on and that will help you pinpoint exactly what server in the cluster handled the request.  You can then go straight to that server to review the applicable server logs.
  • You can also obtain a little more information to an existing/visible error message that may be appearing in the UI.  Sometimes you may have a situation where you get a ‘Request Not Processed’ or other non-descript error message in the browser.  To get more information on what could be happening, you can get some additional logging by looking at the response and status in the XML results that get printed in that XML debugging window by adding the mode=xml parameter to the URL.



Administration, Application, General

Join the discussion