No Supported Way to Deploy Outlook VBA Projects
http://blogs.msdn.com/b/mstehle/archive/2005/12/01/outbox-no-supported-way-to-deploy-outlook-vba-projects.aspx

Using Visual Basic for Applications in Outlook
https://msdn.microsoft.com/en-us/library/office/ff863909.aspx

"Outlook Visual Basic for Applications code was designed to be a personal macro development environment, and was not designed to be deployed or distributed. To move a project from one computer to another, for example, moving the project from your work computer to your home computer, you can export the forms and code modules from the work computer and import them to the home computer. You can also copy and paste the source code of the project to Project1 on the home computer using the Visual Basic Editor. "

When there is a need for Outlook enhancement for multiple users, our recommendation is to create an Outlook add-in for that purpose. It offers multiple features like customizing ribbon apart from using Outlook Object Model or MAPI (for a C++ add-in). I'm sharing additional info on building add-in in Outlook using Visual Studio

• Walkthrough: Creating Your First Application-Level Add-in for Outlook
  http://msdn.microsoft.com/en-us/library/cc668191.aspx
• Outlook Object Model Overview
  http://msdn.microsoft.com/en-us/library/ms268893.aspx
• Best Practices in Developing Managed Outlook Add-Ins
  http://msdn.microsoft.com/en-us/library/office/bb611563(v=office.14).aspx
• Extending the User Interface in Outlook 2010
  http://msdn.microsoft.com/en-us/library/ee692172.aspx#OfficeOLExtendingUI_Explorer
• Developing an Inspector Wrapper for Outlook 2010
  http://msdn.microsoft.com/en-us/library/office/ff973716(v=office.14).aspx
• Deploying an Office Solution
  https://msdn.microsoft.com/en-us/library/bb386179.aspx

If you have gotten the "Invoke-RestMethod : The underlying connection was closed: An unexpected error occurred on a send." error while using PowerShell then add the line below to your script.

    ​[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

PowerShell calls uses TLS 1.0 for web requests by default. However, Exchange is expecting a higher level of TLS, so you need to tell PowerShell to use 1.2 instead of the default of TLS 1.0.

Below are links for additional information.

An Update on Office 365 Requiring TLS 1.2
https://blogs.technet.microsoft.com/exchange/2018/02/09/an-update-on-office-365-requiring-tls-1-2/

    Preparing to use TLS 1.2 in Office 365
    https://support.microsoft.com/en-us/help/4057306/preparing-for-tls-1-2-in-office-365

Ahhh "foreach". Usage of foreach can be either a blessing or a curse. Unfortunately, a lot of developers don't understand that it can cause issues. The need to avoid it when code in a foreach will do an operation (move, delete, etc.) is something which blows the minds of even seasoned developers.

What you will see happen when an operation like a delete or move is done on the iterating item is that the position of where the underlying code is in the collection will be thrown off and the next item to be processed will be skipped. This can/will cause items to not get processed and can otherwise introduce leaks into your application. This isn't limited to working with .NET, OOM or when COM objects are used – it happens for all types of code.

To work around this, you should look at using a reverse for-each loop on the index of the item in the collection instead. Yes, sometimes the best way to do things is backwards.

All Outlook object model calls run on the main thread

Threading in an Outlook Addin

Add-in threading issue causes Outlook to crash or hang

partial class TaskRegion

{

    Outlook.TaskItem _task = null;

					#region Form Region Factory

    [Microsoft.Office.Tools.Outlook.FormRegionMessageClass

					(Microsoft.Office.Tools.Outlook.FormRegionMessageClassAttribute.Task)]

    [Microsoft.Office.Tools.Outlook.FormRegionName

					("ReleaseTaskRegion.TaskRegion")]

					public partial class TaskRegionFactory

					{

					// Occurs before the form region is initialized.

        // To prevent the form region from appearing, set e.Cancel to true.

        // Use e.OutlookItem to get a reference to the current Outlook item.

					private void TaskRegionFactory_FormRegionInitializing(object sender,

            Microsoft.Office.Tools.Outlook.FormRegionInitializingEventArgs e)

        {

					Marshal.ReleaseComObject(e.OutlookItem);

        }

    }

					#endregion

					// Occurs before the form region is displayed.

    // Use this.OutlookItem to get a reference to the current Outlook item.

    // Use this.OutlookFormRegion to get a reference to the form region.

					private void TaskRegion_FormRegionShowing(object sender, System.EventArgs e)

    {

        _task = this.OutlookItem as Outlook.TaskItem;

        _task.Write += new Outlook.ItemEvents_10_WriteEventHandler(_task_Write);

    }

					private void _task_Write(ref bool Cancel)

    {

        System.Diagnostics.Debug.WriteLine("Write fired!");

    }

					// Occurs when the form region is closed.

    // Use this.OutlookItem to get a reference to the current Outlook item.

    // Use this.OutlookFormRegion to get a reference to the form region.

					private void TaskRegion_FormRegionClosed(object sender, System.EventArgs e)

    {

        _task.Write -= new Outlook.ItemEvents_10_WriteEventHandler(_task_Write);

        System.Runtime.InteropServices.Marshal.ReleaseComObject(_task);

    }

}

"...a COM client manages an internal reference count provided by IUnknown to free a coclass, a .NET client relies on the runtime garbage collector provided by the .NET platform to free an object..."

...That is why RelaseCOMObject is so important - in the Outlook world of item in reuse we cannot rely on the runtime garbage collector provided by the .NET platform to free an object.

Scoping Variables Appropriately in Event Handlers

Systematically Releasing Objects

A huge area of trouble is in the handling of events and how to structure code and understand the code in the PIA to prevent item leaks.  I'll be posting more information on this topic soon - in the meantime read the following two articles for some background information...

Connecting to Custom Event Handlers

Events in the Outlook PIA

Outlook Processes Reuse Cached Item References

If an item is in memory in Outlook.EXE then Outlook will reuse it when another action requests it. For example, if a COM AddIn leaks an item reference and a user is interacting with that item through the UI they might not be able to save their changes all of a sudden. This is especially true if the item were to be modified in the MAPI store after it has been leaked. An easy test would be to modify the suspected leaked item using MFCMAPI while Outlook is running then open the item in the Outlook UI and try to modify it. You will get a dialog saying that the item cannot be saved if you have leaked the item.

Do Not Chain Child Object References

One of the advantages of pure .NET programming is that you don't have to worry about memory management because the garbage collector and the dispose pattern handle all of that. What we have to remember that OOM programming in .NET is not pure .NET programming ***it is COM programming in .NET*** because of that the rules of COM apply here. Every object referenced must be released. When you chain objects you lose track of a reference that you need to release.

See the example below...

// This leaks an Attachments reference ProcessAttachments(email.Attachments);

// This doesn't leak Outlook.Attachments oAttachs = email.Attachments; ProcessAttachments(oAttachs);

Marshal.ReleaseCOMObject(oAttachs);

oAttachs = null;

Since the reference to the Attachments object is maintained it can be released properly.

Leaking a Child Item Leaks the Parent

If a child item that holds an internal reference to its parent – such as attachments or recipients - is leaked then the parent is in turn leaked. In the example above, chaining and leaking the child Attachments collection of the email will cause the email itself to leak. The parent object will never get cleaned up regardless of how many times GC.Collect or ReleaseCOMObject are called.

Be Careful with foreach Loops

The basic use of a foreach loop to iterate through items in a collection that have an internal reference to their parent – see above - will leak items. Either avoid foreach loops altogether by using for loops...

// This leaks, GC.Collect will not help

foreach (Outlook.Attachment oAttach in oAttachs)

{

Marshal.ReleaseCOMObject(oAttach);

oAttach = null;

}

// This doesn't leak

        for (int i = 1; i < oAttachs.Count; i++) 

for (int i = 1; i =< oAttachs.Count; i++)

{

Outlook.Attachment oAttach = oAttachs[i];

// Do nothing with attachment

Marshal.ReleaseCOMObject(oAttach);

oAttach = null;

}

…or follow the notes in this discussion to articulate the handling and cleanup of the underlying objects in the enumerator created by the foreach loop to ensure that things get cleaned up properly…

IEnumerator attachsEnum = oAttaches.GetEnumerator();

while (attachsEnum.MoveNext())

{

Attachment at = (Attachment)attachsEnum.Current;

Marshal.ReleaseCOMObject(at);

}

ICustomAdapter adapter = (ICustomAdapter)attachsEnum;

Marshal.ReleaseComObject(adapter.GetUnderlyingObject());

Marshal.ReleaseComObject(oAttaches);

The bad thing about .NET is that it allows you to quickly write applications with very little concern for how all that happens...

Exchange Web Services Push Notifications can be used to gain unauthorized access
    https://support.microsoft.com/en-ca/help/4490060/exchange-web-services-push-notifications-can-provide-unauthorized-acce

The article points to setting a throttling policy for push which will prevent Push notifications from being sent from the server to the client.

Set-ThrottlingPolicy
https://docs.microsoft.com/en-us/powershell/module/exchange/server-health-and-performance/set-throttlingpolicy?view=exchange-ps

Keep in mind that push notifications sent from the server to the EWS listener have very basic information – such as item ids and the event which fired.