Asked by:

June security patch and issue with custom forms

Question

I'm having an issue with my custom form not working after the June security patch a couple of days ago.

I have MS Office Professional Plus 2010 installed but I'm seeing this with 2007, 2013 and 2016 as well. This issue happened after KB3203467 was installed. For 2007 it's kb3191898, for 2013 it's KB3191938, and for 2016 it's KB3191932.

I have a custom form that's published to my personal forms library that I use for new contacts. When I create a new contact I get the below message and none of my VBScript behind the form will run. If I uninstall the security update the
problem goes away.

"To help prevent malicious code from running, one or more objects in this form were not loaded. For more information, contact your administrator."

It looks like it thinks the form is a one-off, however, "send form definition with item" is unchecked and it is published to my personal forms library.

Any ideas or suggestions?

Edited byNick at HomeFriday, June 16, 2017 1:12 PMAdded 2007 to the list of versions affected.

I use an office calendar custom form that visualize a webpage, used to plan the the staff in the entire organization. To interact with this page, the GUID of the appointment is send to the web server using a few lines of script.

Now the form is blocked, and today no one could follow up on their schedule.

It just shows the error message mentioned by Nick. Why block code embedded in installed custom forms??? It there for a reason, and intended to run.

I tried to insert the "EnableUnsafeClientMailRules" in regedit, but with no effect.

Uninstalling the patch does the job, but is not the way to go.

I urgent need a solution, just like Nick .. please someone help!!

Is there any alternative way to interact between the calendar item and the web element?

Do any of you have a sample solution that you could send me that repro's the issue? Or, if its really complicated I might need to assist in opening a support case. I have checked with the Outlook MVPs and they do not have a repro to check this
with and we don't have one internally right now. If you have something straight forward and willing to share please email me. My alias is gbratton at Microsoft dot com.

I've sent you an email to your Microsoft account which has a link to a video that shows the steps to reproduce the problem. I will post the link to the video here as well but am waiting for my account to be verified. I will
link it here as soon as that happens.

Let me know if there's anything else you need from me and thanks again for your help!

Here's the video that shows the steps to reproduce the problem. I'm using Outlook 2016 in the video but I have the same behavior in 2007, 2010, & 2013. In the video I create 2 custom forms.

For form 1 I do the following:

Design a new form based on the Contact form in the Standard Forms Library

Add a Microsoft Outlook Contact Photo Control

Add this line of VBScript: MsgBox "Hello"

Publish the form to the Personal Forms Library

When the new form is opened it shows the malicious forms warning and the VBScript is blocked. The message box is not displayed. When I rollback to the June 7th version of Outlook the form works fine and the message box pops up.

For form2 I do this:

Design a new form based on the Contact form in the Standard Forms Library

Add this line of VBScript: MsgBox "Hello - No Control"

Publish the form to the Personal Forms Library

When the new form is opened the VBScript is blocked. No message box is displayed. When I rollback to the June 7th version the form works fine and the message box pops up.

I have the same issue with O365 (corporate-provided) - I don't have any of those updates listed above.

We have a corporate form for Out Of Office which no longer works and I get the above-mentioned error: "To help prevent malicious code from running, one or more objects in this form were not loaded. For more information, contact your administrator."

When I click through the error message and the form loads, it is missing certain fields all of which are drop-down boxes containing specific entries, as well as two calendar controls.

Looking at "Programs and Features" by Installed On date, I see "Microsoft Office 365 ProPlus - en-us" has an installed On date of 24/06/2017 - just a co9uple of days ago.

However, our Out Of Office form was working OK for me prior to that date (for instance Monday 19th June 2017

We (100 users, 1 admin) have a custom form in Outlook 2013 we use to submit expenses to our Accounting Dept. KB3191938 zapped this form's ability to populate pulldown menu data from Access. At first I just uninstalled the update, assuming Microsoft would,
like many times before, fix the KB in time before users re-updated with the problem. Not so much. So now, at least until I get word of a fix, I've hidden the update for all users. This was trickier for Windows 10 users, who I used the
Windows 10 Show or Hide Updates Troubleshooter for (Google it...new account I cant link things yet)

The Outlook Team is working on a fix for the forms issue. It is not checked in yet but should be soon. Once it is checked in I can update the ship schedule. If you are using Office 2016 and need to test it the fix will first get to Insider
Fast first, https://products.office.com/en-us/office-insider. The Insider Fast build coming out today is 16.0.8319.1000. I expect the fix to be in the build that immediately
comes after that one.

The latest update is that the fix is being targeted to the August 8th public updates for MSI versions of Office. For Click to Run we don't know the schedule yet but it should be sooner. It will go out first to Insider Fast. I will post
back when I know the Insider Fast build in case anyone wants to test it.

I have been playing with this issue this week too. Il removing the update is not an option, you may try to play with GPO. I have set Outlook security ones and now I get a warning message, which match the setting "Warn if macro is signed....".
Due to a french environment, I can't tell which settings were changed. There was one about enabling custom form/macro and another one about choosing the setting of the GPO instead of user or public folder ones. Actually, I would not say the update was bugged.
It is more liked they patch a huge hole in Office.

My custom forms no longer work in Outlook 2013; the only code is Outlook's own date selector (OlkDateControl1). I can't uninstall the security update since it isn't listed on my machine; is it possible it was bundled with a Win10 security patch on June 13?

Any other work arounds? I use custom forms to track communication details with clients

After further testing at least with Outlook 2010 and 2013 and 2016 installed via MSI and Click to Run, the issue seems to be fixed when using a custom form in my mailbox however now in a shared mailbox the vb script is disabled not only for new items
but for existing items as well. This is worse than the initial problem.

Please respond to all theses comments to let us know if Microsoft is aware of the new issue, are they going to address it? If so when? Unfortunately our clients that use our custom forms are getting fed up.

The July 27th patch did not fix the issue in a shared folder as reported. It is actually worse because the error is not only with new contacts but also with existing contacts now. Not only that, but after uninstalling the July 27th update, our shared
folders still continue to fail. How can we get back to a working custom form for both personal contact folders AND shared contact folders???

When I click the button, it does not launch the application. However, if I go to the Developer toolbar and click Design This Form, then click Run This Form, the form will relaunch and the button will work. But that is an onerous workaround to teach all of my
users.

This is the same issue I have been having since the June 13th update. The July 27th update had no effect on the issue.

As Gregor616 and Iwhitman have pointed out, there is still an issue with opening custom forms in a shared mailbox. We are seeing this problem in Outlook 2010. I tried Javier's suggestion and added the reg key to allow ActiveX One-Off forms. Was then able
to open a form in a shared mailbox without error, but the form still did not look right; labels missing, text boxes overlapping, etc. The form opens fine in my own mailbox.

Our forms have a variety of text inputs, radio buttons, and checkboxes. There's a vbscript behind it that chooses recipients and/or populates text in the body of the read page of the form. We do not get an error message when loading or using the form. The
vbscript simply does not execute. If we revert back to version 1705 it all works again.

This is frustrating, because even if we uninstall the buggy update from our workstations, then disable updates under the accounts screen in office 2016, the user still gets prompted periodically that updates are needed. Invariably, the well-meaning user
installs it and breaks their outlook forms. This turns it into a (terrible) game of whac-a-mole.

We rely on forms so heavily I unfortunately wound up opening a ticket with Microsoft when this all started in June. They've been holding my $500 hostage since. This needs to get fixed.

When I look a a form in the designer, none of the fields show, it's just a blank form. Uninstall KB4011089 and all the fields reappear so there's something in KB4011089 that's seriously broken. A lot of our forms are really simple i.e. just a bunch of fields
with no macros so why this should break that I have no idea.

Your recommendation works wonderfully when the custom form is opened directly. However, we modified the following registry entries to ensure that our custom contact form is always used in place of the standard contact form. In that case, the script
in the custom form is still disabled, even if I add IPM.Contact to the TrustedFormScriptList key.

Hmm. It's working here with the registry keys forcing the custom form. Both the custom form and the default form are in the TrustedFormScriptList key. (i had the
default in to test 'run this form'.)

I'm assuming you tested opening it directly on the same computer, which guarantees the new keys are correct and outlook was restarted... misspellings or using the wrong keys for
the windows bitness would be the most likely cause otherwise. (I know those two from experience. :))

KB4011090 took down our Outlook custom forms in 2013, just like KB3191938 did in June/July.

Will this patch take over a month as well?

I love Patch Tuesdays.

This change is permanent - you'll need to set the keys to allow scripting in custom forms. See my post above or
Custom Form Security Changes (I have reg files available - edit with your form names and run.)

For me, the custom form works if I use Choose Form or Design/Run This Form tools, but if I just double click a contact, it opens in a disabled version of the custom form. I modified the registry and tested the results in Outlook on the same machine,
fwiw.

thanks for the information Diane. I have been able to get those reg keys to work with 2010 and 2013 but cannot get them to work for 2016. The code still does not run. This is a C2R version using v1707 build 8326.2107 released 9/12/17. Even with
the reg keys in place I still get the malicious code error and the code behind the form does not run. This is 32bit Outlook on 64bit Windows. Any thoughts?

Trying out your update and not sure what to put as the name as I do not have it working.
Our forms are in the Organizational Forms Library.
One of the forms is 'Arc Vacation Request', I tried 'IPM.Arc Vacation Request' and that didn't work.
Do I need define it different as it's in the Organizational Forms Library?

I set the default form for the folder and created a new contact using that form (which I confirmed via the Message Class field.) Unfortunately, the form still doesn't work. It'll work if I Choose Form, but not otherwise.

The form name has a space in it (ie. IPM.Contact.Company Contact), so I am trying to publish it without the space to see if that will resolve the issue. Unfortunately, I am having problems opening the newly published form. Another day, another
problem.

The custom form is IPM.Appointment.ExacAppt I put that under the TrustedFormScriptList as well as IPM.Appointment

I added the DisableCustomFormItemScript as well.

I still cannot get the scripts to execute. They work in designer...just not when I open the custom form manually...or just create an appointment as we have this form set to the default for everyone.

I am using ClicktoRun and I am adding to the Wow6432Node folder.

thanks

UPDATE: My custom form is now working since the update 1708(Build 8431.2079) but the update alone is not the fix...I think the registry edits proposed by Diane are part of the solution. Verifying that now with a clean install as I have tried many fixes on
this computer

Same here: 32-bit Outlook 2016 on 64-bit Windows 7 & 64-bit Windows 10. For what it's worth, I even tried adding ALL possible registry entries (for Outlook 12/14/15/16, with and without WOW6432Node, including both my custom Message Class and its parent).
Furthermore, since the Click-To-Run environment uses registry virtualization, I also tried duplicating the settings under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Outlook. I don't currently have
access to MSI-based Outlook 2016 from Volume Licensing, but it definitely looks like the registry solution doesn't work with retail setups of Outlook 2016 based on Click-To-Run.

Update: Resolved by updating to 16.0.8431.2079, consistent with yesterday's article linked by Amol. Nice timing, Microsoft. Maybe next week, they'll get around to warning the Titanic about an iceberg in the area.

thanks for the information Diane. I have been able to get those reg keys to work with 2010 and 2013 but cannot get them to work for 2016. The code still does not run. This is a C2R version using v1707 build 8326.2107 released 9/12/17. Even with
the reg keys in place I still get the malicious code error and the code behind the form does not run. This is 32bit Outlook on 64bit Windows. Any thoughts?

New post:

The reg key workaround only fixes the form in shared folders if you open the users contacts folder through opening their full mailbox. It does not work if you simply open their contacts folder as a shared contacts folder.

Any thoughts?

Also, it looks like the update released on 9/12/17 is no longer considers a critical update?

I did updates to my Outlook 2016 this morning as it said I had some. No clue what it installed but my outlook 2016 is working with your updates and it does REQUIRE them. I removed one of the reg_sz just to see if your registry updates were required and yes
they are.
I use IPM.Note for my forms but had to leave the IPM.Contact and IPM.Contact.Custom as removing them killed my
objMe.AddressEntry.Manager.Name where I get the manager's name from MAPI

I was able to get one of my forms working on Office 2016 C2R 64-bit by installing the latest update, adding the first registry DWORD under the security settings and then the separate SZ registry keys for IPM.Note and IPM.Note.Formname.

An Escalation Engineer in Outlook put together a script to help automate setting the registry keys if you have a lot of forms. I posted the script and his instructions on OneDrive, https://1drv.ms/f/s!AobSYdEz_BdhhrtDqcEulHXTPYXVFw.
I am trying to get it added to the formal documentation but this is where it is for now. Let me know if you have any issues getting to it.

I have tried the recommended registry fixes, along with adding each individual form class to the registry list, without success. At this point, due to the business need of these forms, we have uninstalled KB4011089 from the machines until a fix is
released that actually works for us.

Is everyone having success using the recommended fixes? Our environment is using x86 Windows 7 OS, and x86 Office 2010. We are at a loss right now.

I appreciate you guys and the work you have been doing to provide a resolution to these issues.

We use a custom appointment form in Outlook 2013.
The form is available in the library for organizational forms.

This form is provided in shared calendar folders.
On the one hand, in calendar folders of an additional mailbox that is also included in Outlook and, on the other hand, in shared calendar folders of Exchange users.

In Outlook version 15.0.4927.1002 (May 2017) this works fine in all calendar folders.

In Outlook version 15.0.4971.1002 (October 2017), the form works for the calendar folders of the additionally included Mailbox if the registry entries are set according to the instructions above.
But if the form is called for a shared calendar of an Exchange user, the message appears:
"To help prevent malicious code from running, one or more objects in this form were not loaded. For more information, contact your administrator."

We use a custom appointment form in Outlook 2013.
The form is available in the library for organizational forms.

This form is provided in shared calendar folders.
On the one hand, in calendar folders of an additional mailbox that is also included in Outlook and, on the other hand, in shared calendar folders of Exchange users.

In Outlook version 15.0.4927.1002 (May 2017) this works fine in all calendar folders.

In Outlook version 15.0.4971.1002 (October 2017), the form works for the calendar folders of the additionally included Mailbox if the registry entries are set according to the instructions above.
But if the form is called for a shared calendar of an Exchange user, the message appears:
"To help prevent malicious code from running, one or more objects in this form were not loaded. For more information, contact your administrator."

We have exactly the same issue with shared contact custom forms. Could MS please comment on when a patch can be expected?

We use a custom appointment form in Outlook 2013.
The form is available in the library for organizational forms.

This form is provided in shared calendar folders.
On the one hand, in calendar folders of an additional mailbox that is also included in Outlook and, on the other hand, in shared calendar folders of Exchange users.

In Outlook version 15.0.4927.1002 (May 2017) this works fine in all calendar folders.

In Outlook version 15.0.4971.1002 (October 2017), the form works for the calendar folders of the additionally included Mailbox if the registry entries are set according to the instructions above.
But if the form is called for a shared calendar of an Exchange user, the message appears:
"To help prevent malicious code from running, one or more objects in this form were not loaded. For more information, contact your administrator."

We have exactly the same issue with shared contact custom forms. Could MS please comment on when a patch can be expected?

We have similar issues with custom Appointment forms being used on shared calendars. I've tried all these registry edits (carefully) and I'm able to get the malicious code message to go away, but the script behind refuses to run except when
I enter design mode of the form. My current version of Outlook is 15.0.4963.1000

KB4011090 took down our Outlook custom forms in 2013, just like KB3191938 did in June/July.

Will this patch take over a month as well?

I love Patch Tuesdays.

This change is permanent - you'll need to set the keys to allow scripting in custom forms. See my post above or
Custom Form Security Changes (I have reg files available - edit with your form names and run.)

Microsoft can't fix this and decided to disable forms scripts altogether? Or forcing customers to switch to Sharepoint and/or JS Addins? Ok, I can understand this. But why there is no option to revert this back with ONE registry setting?

I just wasted almost an hour investigating this and creating registry keys for 20+ forms (not ready to run an unofficial script against my client's exchange server). And because forms have localized names, I ended up counting characters and replacing
them with underscores. Something like:

IPM.Task.___ __ __

Hope this helps someone who is also using localized forms.

And do you have any info about when MS going to drop custom Outlook forms? Such 'features' make me think that this may happen soon.