09-26-2019 01:12 PM
Hi, We're having issues with getting ACT Marketing Automation to work, and I wonder what other users of Act Marketing Automation have as their network setup.
- Version of Act! you are using:
On Windows 10 workstations: Act Premium 184.108.40.206, Update 4
On Windows 2016 Server: Act Premium Web 220.127.116.11, Update 4
- If the issue involves Microsoft Office (Outlook, Word , Excel), state the version of Office you are using
Doesn't involve Office
- Is your database on your local machine (private database) or is it being shared from a server (shared database)?
Shared from a server.
- Operating system you have Act! installed on (i.e., Windows 7, Windows 8)
Windows 10 on the workstations. Windows Server 2016 on the Act server.
- As much detail regarding the question or issue as you can provide:
We have about 20 Act users running Act Premium (nonweb) on their Win10 workstations accessing the Act (.pad) database on the server. This is purely an on-premises network setup and is not exposed to the internet. We have been told that purchasing an SSL certificate for our web server will be required to get Marketing Automation to work. While we do have a website that is professionally hosted at a web host with its own SSL cert, our on-premises domain is .local, and you cannot get a public CA certificate for anything.local.
I have been told that the only other way for this to work is to use Act Connect Link. I don't think that is an option for us because we actually also use the act web api, which interacts with a custom app that we have developed in house that makes ACT work with JAWS screen reader software.
So my questions are these; what is the preferred network setup for Marketing Automation to work? Will Act Connect Link break the existing act web api that we already use internally?
Any insight would help greatly, thanks.
09-27-2019 06:47 AM
There are two ways to access AMA in case of premium web.
1, If the database is not hosted from premium web (i.e from website admin tool) , then you can install the Act connect link. Can access AMA from workstations and make sure the connect link is not installed on the workstations.API on the workstations should point to server connect link URL
2, If the database is hosted from premium web, then we should not install connect link. Need to get valid certificates, port 443 should be open and the hosted URL should be secured https://
Hope this answers your query.
09-27-2019 07:25 AM
My post from last night just disappeared. Good thing I saved it. Here it is again.
As someone who just got this working I can help at least a little. I have a somewhat similar setup. Only the local server runs act premium for web. Everyone else uses the non-web PC version or uses a web browser with the server's website. My server's website is also accessible via the net however.
First things first:
"Your purchase includes a complimentary configuration call with an Act! technician who will assist your organization with getting Act! Growth Suite configured with your current Act! Subscription."
If you are eligible see if you can get your free phone call. That might help. My experience with that was less than stellar but we did eventually get it going. I can tell you how this went down for me and my phone call. The guy I spoke to always had to put me on hold a long time and speak to someone else behind the scenes, so you can gauge yourself how much to trust anything he said to me.
Before I start, we need to define the two levels of "working". AMA is working if you can click on the marketing automation in ACT and get the screen with a sidebar that says Drip Marketing, Templates, Landing Pages..etc. If you get a blank screen with a line about "Invalid JWT Token" error then no, you have problems.
AMA is truly working if when creating a campaign, you can get a drop-down list of your ACT groups to select as the email list. If that is empty then you don't have a proper link from the cloud to your web api server. I suggested a proper status screen with actual connections status information on it but I'm sure that went nowhere.
Another good note is you have to be the administrator or have been assigned all the role permissions for act marketing in order to access that feature.
My server had a self-signed certificate and that wouldn't work for AMA. I thought like you, just use act connect link but I was told I couldn't use that. No idea why. He had me uninstall it completely. Maybe connect-link uses an extra level of authentication or a different protocol on top of the web api? AMA is out in the cloud and must access your on-premises act web api directly far as I know. Maybe some expert will clarify for us...
AMA uses an URL stored in your database under a parameter called "APCAPIURL" to connect from the cloud to your web api. There is a batch file that allows you to view & change the URL. It's called GetSetApiURL.bat
Here's a line from the batch file:
"Make sure to use an API endpoint that will always be online. Dedicated database servers with valid SSL certificates are recommended, but you can use a primary server with Connect Link. This server should house the publisher database for any remotes."
This of course conflicts with what I was told on the phone, and my experience.
There's an act plugin called AMA Debug which will give you some configuration information including this URL and some others. Use that and make sure all the URLs are set correctly.
I certainly did try using the act connect URL myself and it didn't work. I tried all sorts of URLs at that stage. I might randomly get into AMA or sometimes I would get the "Invalid JWT Token" error. If I got in I could create templates and whatnot but not create a campaign. I didn't have the debug plugin at the time so now I wonder if I'd had all act connect link URLs 100% correct.... maybe I will go back and try it for kicks.
So eventually I had to give in to the guy on the phone and I created a free certificate with letsencrypt.
My APCAPIURL URL is something like this: https://my.domain.com/act.web.api/
After that was set up I've been able to create campaigns and send out emails.
So supposing you at least have a dedicated ip address you could self-host the act web api. I'll give you a high level walkthrough of how to go about this.
Since you already have a domain name with a web site hosted somewhere, edit your DNS records and create a subdomain, point it to your office IP address. I will use "my.domain.com" as an example. You might have to wait some time for the changes to propagate and the AMA cloud app to get the new dns records. That depends on your DNS settings, I wont get into it.
On your office router, direct incoming ports 443 and 80 from the internet to your act server's ip. Test it, make sure the site is reachable on port 80 from the general internet.
I used the letsencrypt app "win-acme" aka WACS to create and install the free certificate.
In your IIs manager, make sure you have a binding for the APFW site like this:
host name: my.domain.com
ip address *
The host name is vital for WACS to work. Be certain to close any instance of IIs manager, and then run WACS (as administrator) and go through the simple setup steps (google it). WACS will get you a certificate, install it, and create the https binding for the site all by itself. It also sets up a scheduled task to renew the certificate. It's pretty impressive.
I don't know if renewals can use port 443 from then on or if you have to keep port 80 working.
After this is all set you should be able to surf from the outside world to
You should see some screen about the api documentation. Check the certificate in the browser, make sure it's all valid.
If that's working then run GetSetApiURL.bat and set the URL to https://my.domain.com/act.web.api/
With any luck emarketing will magically work.
One more thing... my setup guy rushed me off the phone so fast so I had to sort this out on my own. If your domain name has an SPF record you will need to include the servers they will use to send emails on your behalf, otherwise most of your marketing emails will be considered forgeries and discarded. I spent some time on this and came up with this entry to add to my domain's spf record:
This says that if the IP address of the sender has a dns record that resolves to an address, it is legit.
For example, suppose the server they send the email with is this:
For SPF to pass as valid a host name of 18.104.22.168._spf.sparkpostmail.com must resolve. (It does).
(If you have no clue what I'm talking about then you really should bring in a guy for this.)
09-27-2019 10:06 AM - edited 09-27-2019 10:08 AM
For the most part you're on point on these items, but I need to explain a few parts of this.
I was the guy your support agent put you on hold to speak to. He had not dealt with self-signed certificates before, and even after you got your SSL Cert sorted the next day, we were getting varying results on the cert's validity. The cert was sometimes showing as self-signed, and other times showing as verified. This caused some confusion, as we couldn't tell if any further issues were due to an improperly installed certificate.
You're actually wrong about the SPF record. If you view your email headers you'll see that we actually handle SPF on AMA ourselves. We don't spoof the entire email, only a small portion of it, and that pushes back to our own SPF records. If you need further deliverability help we can supply you with a DKIM record. The advice you've given here doesn't work, as the part of the SPF verification process you're doing won't actually be looked at by recipient servers.
Additionally the advice you've given about the batch file is not best practices. There are two preferences that can be used to configure AMA properly. The one you've suggested the 'APCAPIURL' is not recommended and is only used as a last-ditch effort to make sure a deployment works. It's how our Act! Premium Cloud system enforces urls between remote database deployments. The UPWARD_API_STREAMER is the recommended preference to change. Act! has the ability of editing this preference itself, unlike the APCAPIURL that you've suggested.
If your URL changes, all of your databases would not have access to AMA when using the APCAPIURL fix. While we supply this file to make the change this should be your last option when trying to correct JWT issues.
You can use Act! Connect Link for Act! for Web, though many deployments have conflicts between port bindings in IIS when you use it. That is why we're not recommending using this system to supply your certificate needs at this time. That doesn't mean it won't work, it can just get very complicated.
Our support team isn't going to help with IIS configuration outside of the base setup, and SSL certs are by nature not a part of our base setup.
If you are having JWT errors and are reading this thread, I invite you to instead look at our KB article where the recommended steps are updated as needed, and where these batch files are available: (This was linked in the last post, I just want to reiterate this is updated frequently)
09-27-2019 10:47 AM
Thank you everyone for the information. What I'm hearing is that people have gotten this to work with an internal setup similar to ours, but they have to go get an SSL cert from a public CA for their ACT web server. That's not going to work for us being that our ACT server is on a .local internal domain "servername.companyname.local". So it sounds like use of Act Connect Link and Act Web API are mutually exclusive.
09-30-2019 06:45 AM
Hi Billy. Thanks for taking the time to make some corrections and clarifications. I still have questions but this isn't my thread. I was trying to write down everything I know to help the next guy.
Regarding the APCAPIURL issue, when I first read the JWT Token help page, the text on the page and the batch files conflicted with each other. I opted to believe the batch file contents. I see someone has revised the batch files since then and swapped the parameters. Now that you brought it up, I assume the prefix APC means act premium cloud...
My current configuration, although working, is apparently not what you recommend based on your post.I will removed the APCAPIURL setting and set the STREAMER url instead. Currently my streamer URL is an old one set by act connect link which I had uninstalled.
You're totally right about the SPF thing. They say it's already handled but I didn't believe them I had to review the SPF spec to understand why. My bad.
09-30-2019 07:18 AM
Hi Bfoster. I'm afraid you got me wrong there. I was trying to give you a high level overview of what my setup was, how you can get a certificate (for free) and set up your act web api to be reachable from the internet. Your .local domain has nothing to do with it really. That's a windows domain which has no relationship to the internet domain name setup I was referring to.
From what Billy has said, ACT Connect link could still be an option but there might be technical complications to be resolved. I would love to test that out myself but I don't have that kind of time.
In any event, I see no reason why you can't use their recommended setup. You may need to bring in outside support to make it happen. The right guy could probably run through those steps in an hour.
11-07-2019 09:27 AM
Hi, a brief update. While dealing with my own issues I had to reinstall ACT Connect. eMarketing was working just fine with the act connect url. There were no port conflicts with the web server.
My problem is I can't get rid of it now. It keeps on using the act connect url long after it's been uninstalled. Keep that in mind if you install it.
I had remote clients stuck on the act login screen for an extra 5 minutes or so when there was any nonworking emarketing url in their configuration.