The following content is intended for customers that are using Campaign in combination with <MadCap:variable name="MyVariables.Product_Short" /> and run into issues when accessing Campaign.
When launching the Campaign Module from within <MadCap:variable name="MyVariables.Product_Short" />, an OPTILAUNCH error is displayed.
This is due to the user not having actual rights on the Campaign side, after being granted Campaign access rights in <MadCap:variable name="MyVariables.Product_Short" />. Make sure the following steps are executed:
1. When a user account is created in Marigold Engage, it's automatically available in Campaign.
By default, it's in the User Group 'NEW Engagement Sphere users' (in the Configuration section of Campaign).
2. If you want the user to be able to access and work with Campaign too, you need to move (drag and drop) the user to the 'Administrators' group.
3. Keep in mind that the user also has no Campaign user rights defined by default.
This can be done by selecting the user to show its properties, choosing the Rights tab and editing the rights/roles.
What if the correct rights are set but Campaign can still not be launched?
Launching Campaign consists of several steps:
- The CampaignLauncher is invoked with the necessary data to locate and start the correct version of the Campaign tool.
- The Launcher performs a live check of the Campaign version.
- When this specific Campaign version is not yet available on the user's machine, the Launcher will download it.
- When the correct Campaign version is locally available, the Campaign Launcher invokes it and Campaign should start.
There are multiple steps in this process, so there are a number of things that might go wrong. Most importantly, you should first try to check if the launch issue is an issue with the Campaign Launcher, with Campaign or with the Portal:
Locate first where the problem is: Campaign, Campaign Launcher or Portal
- If there is a Campaign process icon in the windows taskbar after the launch attempt, it is a Campaign issue (the Launcher has successfully managed to start Campaign, but Campaign has an issue)
- If there is no Campaign process started, there's an issue with the CampaignLauncher.
- If the Campaign Launcher does not show any signs of life after trying to launch, there might be an issue with Portal.
Locate and fix potential Campaign Launcher issues
Step 1 - Start clean: Clear the contents of the following folders:
- %temp%\selligentlauncher\
- %appdata%\selligentlauncher\tools
- the current tools folder of the Campaign Launcher.
The current tools folder can be obtained by opening the contextual menu of the Campaign Launcher (via the system tray) and selecting 'show logfile'.
Then search the log for 'root directory'.
Copy paste the root folder in an explorer and make sure it's cleared (if it matches %appdata%\selligentlauncher\tools is has already been cleared in the previous step).
Step 2 - Make sure the latest version of the Campaign Launcher is installed.
The Launcher does not have unique versioning at the moment, so checking for the latest version can not be done accurately.
If the Campaign Launcher is not yet installed, install the latest version by logging into <MadCap:variable name="MyVariables.Product_Short" />, attempt to launch Campaign, and click the link in the pop-up mentioning the download link for the Campaign Launcher. If you are not quick enough, refresh the page and try again.
(Additionally, you can reach out to support to obtain the latest version.)
If you are uncertain you have the latest version, uninstall it via the windows 'add or remove programs panel' and install the latest version via the method mentioned above.
Step 3 - Make sure the Campaign Launcher is running.
This can be checked by searching for the Launcher icon in the system tray. If it is there and you can right click on it and configure it, the Launcher is running.
Step 4 - Make sure the Campaign Launcher is running with proper access rights.
When in doubt, open the contextual menu of the Campaign Launcher (via the system tray), and choose 'exit'. Then launch Campaign Launcher again with 'Run as Administrator' rights to ensure sufficient access. This may be needed to rule out access issues if you see access related errors in the launcher logfile.
Step 5 - The launcher is installed and running with proper rights, but still nothing seems to happen;
- Open the logfile via the launcher contextual menu > show logfile. Inspect it;
Tip: If for some reason the context menu doesn't work, check the %temp%/selligentlauncher folder for the logfile
- Check the file from bottom to top for the start of your last Campaign launch request. it should look like this;
2018-08-01 13:22:37 10 DEBUG Start processing request
2018-08-01 13:22:38 10 DEBUG Requesting url: https://abc/Portal/tools/toollauncher.aspx
If the toollauncher.aspx request fails, check the error listed and try the following;
- If you are running an older launcher and the request URL is an https URL, the remote site may not allow TLS1.0 anymore and connections will fail. You can verify the supported TLS versions by checking the installation via https://www.ssllabs.com/ssltest/ .
To avoid this issue, make sure that you are running the latest version of the launcher.
If you didn't verify it yet; make sure and uninstall and install it again as described in point 2.
- There may be some kind of access issue (bad certificate, unknown hostname, etc..)
A quick way to verify the most obvious issues is to try and copy/paste the toollauncher URL in a browser and see if you can browse to the page (it should redirect you to the Campaign portal login screen).
The browser should not indicate any certificate or security issues. Perform an ssltest as described above to check for more specific issues. For persistent issues however, the Campaign portal server logging should be checked for further hints (search for 'ToolLauncher' related entries)
- If the toollauncher request succeeds, but still nothing is happening, check the rest of the log for hints;
Obvious intermediate issues usually boil down to insufficient access rights; If point 4 has been checked, access to the root/tool directory should be ok and the launcher should be able to download the Campaign version if necessary and access it.
If all intermediate issues have been fixed, you should be able to locate the following lines (similar ones) in the log;
2018-08-01 13:25:17 5 DEBUG Performing version check for [ea6d56725e66003fb7035d264c700f37] ....
2018-08-01 13:25:18 5 DEBUG Starting tool
This indicates that the Campaign Launcher successfully performed its part of the job and has now passed on control to the Campaign tool. You should also have noticed the Launcher messages in the bottom right of your screen and a Campaign process should have been started (taskbar). Continue to investigate possible Campaign launch issues.
Locate and fix potential Portal issues
If the Portal consistently complains the Campaign Launcher is not running, it might be interesting to check the Portal's logfiles. If you notice recurring exceptions listing "Selligent.Portal.Web.Tools.ToolLauncher.Page_Load" in the stacktrace, try recycling Portal.
Locate and fix potential Campaign issues
If the end of the Campaign Launcher logfile contains the 'Starting tool' message and the Campaign tool is visible in the Windows taskbar, Campaign is running but may not be able to open properly. There are many possible reasons but the most common one is: Campaign shows a 'no server support for webqueries' popup;
This can have several causes, but it all boils down to the same thing; Campaign cannot or is not allowed to connect to its server component (webcontainer.dll). Possible causes, in order of how easy it is to check;
- Portal session may be expired: Close the Campaign tool, open Portal, logout from your session and login again with your credentials. If you were not logged-in just login with your credentials. Relaunch Campaign.
Make sure webcontainer is running and is accessible: take the toollauncher URL from the Campaign Launcher logfile, and replace /Portal/tools/ with /webcontainer/webcontainer.dll . It should display a version number similar to: [v6.3.14.0000 build 2772]
- Insufficient TLS protocols enabled ( if the launch error occurs right after infra security changes, this is the most likely suspect).
First, use https://www.ssllabs.com/ssltest/ to check what TLS versions are supported for the server you try to connect to: the host is visible in the Campaign Launcher logfile in the toollauncher.aspx URL.
Since Campaign uses Windows SChannel support to make it's secure connections, the user's supported TLS modes have to be checked/adjusted via Internet explorer's advanced settings:
- Start iexplore (not edge!), open its settings - internet options - advanced settings and scroll through the huge list of checkboxes for the security settings;
- Make sure at least one TLS version is enabled that the server supports as well (tls1.2 should always be checked at the time of this writing)
- An improperly configured certificate is deployed on the server.
A test via https://www.ssllabs.com/ssltest/ should reveal expiry, revocation list issues etc as well.
As a TEMPORARY verification (for revocation misconfiguration only), you can start iexplore (not edge!), open its settings - internet options - advanced settings, scroll for the security settings; and TEMPORARILY disable 'check for server certificate revocation'. If Campaign can be successfully launched now, please contact the administrator of that server to fix it. Enable the option again!
- Serverside configured security measures:
The customer may have configured IP restrictions to only allow the tool to be launched from specific locations. In order to check this, you need to be able to launch Campaign on another machine or have database access. Query the WEBCONTAINER_ACCESS table, which contains a list of enabled or disabled IP's/masks. If your IP does not match any of the masks; contact the customer and request approval for your IP to be added. The error should be in the webcontainer logfile ('Access denied').
The server requires the use of https, but the client is not using it. Check WEBCONTAINER_SSL and WEBCONTAINER_BASEURL settings. The error should be in the webcontainer logfile ('CALL START REJECTED')
Request replay protection; This protection is triggered when trying to replay requests from the past, but it can also be triggered when the server time differs more than X minutes from the time of the client machine. Make sure the time of both machines is synchronized to avoid such issues. The amount of allowed time difference is configured with the SECURITY_MAXPACKETAGE_SEC setting and defaults to 300 seconds. The error should be in the webcontainer logfile. ('Package REJECTED')
Request tampering protection; The request signature doesn't match The error should be in the webcontainer logfile. (various error messages)
The account used during the Campaign startup is not allowed access or is improperly configured in Campaign. The error should be in the webcontainer logfile ('Incorrect Account')
Forward the issue to support for further checking if you suspect this is the case. (Restarting the webcontainer apppool can also deal with caching issues)
- Other serverside errors: The error should be in the webcontainer logfile.
