title: How to avoid Outlook Security Alert when sending Outlook message from VBScript?
body: <p>I have this situation:</p>
  
  <ul>
  <li>Code <strong>must</strong> be in VBScript (outside of my control)</li>
  <li>Unable to disable programmatic access restrictions in Outlook preferences (group policy, not admin, and Windows doesn't recognize the valid virus scanner which is installed)</li>
  <li>Can't use SMTP because it is disallowed.</li>
  </ul>
  
  <p>I thought there would be <em>no</em> way to send an email using Outlook in an automated-ish manner (on an unattended box logged in as a user with the screen locked). I tried many different approaches but would always get the security warning message. How can I fix this?</p>
  
  <p>I've already tried everything at <a href="http://www.outlookcode.com/article.aspx?id=52" rel="nofollow">this</a> helpful site and eliminated each option as follows:</p>
  
  <blockquote>
    <p><strong>Strategies</strong><br>
    Ideally, applications that automate Outlook should avoid code that triggers these security prompts.</p>
  </blockquote>
  
  <p>This is <strong>exactly</strong> what I ended up doing (see my answer below), which is why all of the other options on that page are irrelevant. Let's take them one by one:</p>
  
  <blockquote>
    <p><strong>Sending messages</strong><br>
    It is not necessary to use Outlook objects at all if your goal is simply to create and send an email message. Microsoft provides the CDO for Windows library for creating and sending messages with SMTP. Using this library totally bypasses Outlook and MAPI and does not trigger security prompts. For code samples, see ...</p>
  </blockquote>
  
  <p>SMTP. No-go. Disallowed by network policy.</p>
  
  <blockquote>
    <p>Use Extended MAPI instead of Outlook objects, Simple MAPI, or CDO 1.21 for all code that potentially triggers security prompts.</p>
  </blockquote>
  
  <p>Extended MAPI may work, but it is extremely cumbersome and verbose and involves lots of C/C++ code (which is not on topic for this question; see above), and seems to be impossible to use it without prompting the user for their password.</p>
  
  <blockquote>
    <p>Use a third-party library -- Redemption or MAPI33 -- for all code that potentially triggers security prompts. This approach is easier than using Extended MAPI, which has a steep learning curve, and almost as secure. These libraries also offer additional features to help with Outlook code projects.</p>
  </blockquote>
  
  <p>The problem with third-party libraries is four-fold:
   - They cost money;
   - They introduce licensing issues even if they're free (some organizations require extensive vetting from lawyers before allowing the software into the ecosystem);
   - Most environments where this entire problem is even a concern are those where the user <strong>cannot</strong> disable programmatic access warnings in Outlook options. Hmm, what possible cases would those be? Could it be... <em>corporate environments</em>? Procurement of software in a corporate environment takes an excessively long time, to the point of being impractical unless the cost savings of using it will exceed several million dollars. But there are many practical process improvements that can be made which do not yield as high of a cost savings, but would cost more money and labor to procure the third-party software than the total savings, if software procurement is necessary.
   - Network administrators may not trust the software to reside on a system, since it could be used for malicious purposes.</p>
  
  <blockquote>
    <p>Deploy with your application a tool to suppress the security prompts.</p>
  </blockquote>
  
  <p>This assumes that <strong>suppression</strong> of the OMG prompts is necessary, which, in my case, it is not, just to send a simple email (see my answer).</p>
  
  <blockquote>
    <p>For Outlook 2007, make sure the machine is running an up-to-date anti-virus application and do all coding with Outlook objects, avoiding CDO 1.21 and Simple MAPI code.</p>
  </blockquote>
  
  <p>The virus scanner is up to date, but it is completely out of my control to change its version or vendor, and Outlook doesn't recognize it. It says: "Antivirus status: Invalid. This version of Windows supports antivirus detection, but no antivirus was found."</p>
  
  <blockquote>
    <p>In Outlook custom form code, Outlook VBA code, and COM add-ins, derive all objects from the Outlook.Application object provided by VBA or the add-in architecture. For example, see the sample VBA "run a script" rule procedure below.</p>
  </blockquote>
  
  <p>Interesting, and possibly useful, but not necessary. This creates an unnecessary dependency on setting up a rule in Outlook in order to deploy the software, which complicates deployment.</p>
  
  <blockquote>
    <p>Deploy Outlook security settings that "trust" certain COM add-ins or that allow all applications to have unrestricted access to certain features, such as accessing addresses. In versions before Outlook 2007, this requires Microsoft Exchange Server. For Outlook 2007, see the section on version-specific considerations below.</p>
  </blockquote>
  
  <p>Cumbersome: administrative access would be needed to install a COM add-in, and it can be hard to come by administrative access in some organizations.</p>
  
  <blockquote>
    <p>In a corporate environment where Exchange is the email server, direct access to the data on the server is available through the WebDAV API beginning with Exchange 2000 and, starting with Exchange 2007, through Exchange Web Services.</p>
  </blockquote>
  
  <p>Disabled in my environment, and likely others.</p>
  
  <blockquote>
    <p>In a corporate environment, the administrator may choose to loosen Outlook security for some or all users.</p>
  </blockquote>
  
  <p>Sure, but this requires communication/coordination/cooperation with the network team. If administrative access is not available for installing a COM addin, it probably is not available for loosening group policy, either.</p>