The challenge for today – Dynamics GP Outlook Allow/Deny prompt

A Client recently deployed a new RDS Server farm to run a variety of applications, including Dynamics GP. We are big fans of RDS, and encourage the use of the technology for running Dynamics GP, as it greatly simplifies management and is generally more stable due to the higher-quality hardware typically used for server-based workloads.

About a week after going live on the new environment the client ran a monthly process that involves generating emails from an add-on software package intended to simplify AR collections. The emails notify past due customers of their status, and it also attaches the invoices that need attention.

Unfortunately, on the new server, when the user triggered the email, the following prompt showed up:

This error message is commonly seen when sending emails directly via Outlook; It indicates that the email software is using the MAPI protocol/API to generate and send an email. Outlook, being a good citizen, is concerned that something might be wrong and prompts the user to ensure it is okay to send the email. In cases like this, where the software should be permitted to send emails unhindered, Microsoft has an article outlining two configuration options:

• Install proper antivirus software that will register itself with Outlook, permitting the emails to flow
• Change a sensitive security setting in Outlook, bypassing the security check altogether

Bypass security?

I am not a fan of bypassing security checks; they were, after all, added into the software for a reason. However, since Windows Server does not support Windows Security Center, Outlook is prevented from checking the status of antivirus software, leaving no other option.

The Microsoft article shows the appropriate registry setting to choose to “Never warn me”. Using that information, I configured Outlook appropriately and proceeded to test again, yielding very interesting results.

We can see that antivirus software status is unavailable in the Programmatic Access Security tab

Testing the change

I started by using the Send Test E-mail window in Accountable’s Forms Printer software. Forms Printer enables automated distribution and emailing of all manner of documents from within GP, and provides a very flexible toolset to fully customize that functionality. MAPI is among the list of email configuration options, making it a great tool for testing this change.

The email was generated and sent with no errors, so I reported the problem as solved.

User acceptance testing; or, there is probably more to do

The user tested the collections software again and received the same security warning message from Outlook. I worked through all of the steps to ensure the settings were applied consistently, and that no simple mistakes had been made. I finally concluded that something else was going on.

More digging on Google showed that Outlook distinguishes between MAPI and Simple MAPI. The Programmatic Access window only controls MAPI access. Simple MAPI access can only be addressed directly in the registry. I suspect this is because Microsoft is clearly not interested in supporting the ancient protocol:

The entry that solved this issue was to add a DWORD of PromptSimpleMAPISend to HKCU\Software\Policies\Microsoft\Office\16.0\Outlook\Security. Note: the path may vary based on bitness and version of Outlook.

I found other settings related to Simple MAPI on a site called Group Policy Home.

After this entry was added, the collections software was able to send emails without prompting the user.

Conclusion

As is normally the case with technology, the problem is never as simple as it seems. I assumed that I knew the answer when I first saw the error message, but the different technology used by the collections software fooled me. It is important for me to remember that the first answer is rarely the right answer, and above all, to never underestimate the effort required to solve a new problem.

If you are facing an issue with your Dynamics GP system that has stumped everybody, reach out to us. Telmar doggedly pursues unusual problems like this one on a daily basis. Please use our Contact Us page to reach out, or call us at: (720) 891-4302.

Telmar Computer Solutions, Inc. is providing the information in this publication as a courtesy, free of charge, to share information with the general public. Nothing in this publication is intended to be, nor should be, interpreted as advice or consultation on any matter, including taxes, accounting, business management, system configuration or operation, or any other similar topic. Please engage the services of an appropriate professional for assistance in these areas. Telmar Computer Solutions, Inc. is not responsible for any loss, including downtime, lost files/data, rework, or other expenses sustained by you, your company, or any person who relies on this publication.

OTHER POSTS YOU MAY BE INTERESTED IN…