Share via

Cannot Edit My Custom Forms (Outlook Classic)

Shawn Metzler 0 Reputation points
2026-03-31T10:55:45.81+00:00

I have Office 365 Business Premium using Outlook Classic. Version 2603 (Build 19222.20114 Click to Run).

I have been using custom forms but I can no longer use them.

I made these changes, but when I try to even edit the default contact form I get the error noted in the image below - https://support.microsoft.com/en-us/office/custom-form-script-is-now-disabled-by-default-bd8ea308-733f-4728-bfcc-d7cce0120e94

All has been working until yesterday.

User's image

Below is what I see after I click OK on above.

User's image

Outlook | Windows | Classic Outlook for Windows | For business

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Michelle-N 14,470 Reputation points Microsoft External Staff Moderator
    2026-03-31T12:46:14.86+00:00

    Hi @Shawn Metzler

    Based on the details you provided, I understand that as of yesterday, you are unable to use or edit custom forms in Outlook Classic (Version 2603), and you are receiving an error even when trying to edit the default contact form. I also note that you have already applied the registry or Trust Center changes recommended in the Microsoft support article.

    In my testing environment, I am still able to use this feature. While you applied the changes from the support article (which likely involved adjusting the DisableCustomFormItemScript registry key), that step alone is sometimes not enough. This is because custom forms can also be restricted by a completely separate ActiveX security rule.

    Please try adjusting the ActiveX settings with the following steps:

    Press Win + R on your keyboard, type regedit, and press Enter to open the Registry Editor > Navigate exactly to this path: HKEY_CURRENT_USER\Software\Microsoft\Office\Common\Security > In the right pane, look for a DWORD (32-bit) Value named DisableAllActiveX.

    Note: If it does not exist, right-click in the empty space, select New > DWORD (32-bit) Value, and name it DisableAllActiveX.

    Double-click it and set the Value data to 0. (If it is currently set to 1, that is the default "block all" setting causing your issue) > Click OK, close the Registry Editor, and restart your entire computer (not just Outlook) > Open Outlook and try opening or editing the Contact form again.

    Important Security Note: Setting DisableAllActiveX to 0 does reduce your system's overall security protection, which is exactly why Microsoft changed this default behavior recently. Please only apply this change if you fully trust the custom forms you are utilizing.

    Since I don't have full visibility into your specific environment, I do have one quick question:

    -If you try to create a brand new form from scratch, does this same error still appear?

    -Do you currently have any third-party add-ins active in Outlook? If so, what happens if you temporarily disable them and try accessing your forms again?

    Please let me know how the steps above go, and feel free to share any updates so we can get you back on track!

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

  2. Q&A Assist
    2026-03-31T10:56:14.9766667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The behavior is caused by the recent change where custom form script is disabled by default in classic Outlook for Windows. After the July 2025 updates, VBScript and other custom form code will not run unless explicitly re‑enabled, and forms that rely on that script can show the “malicious code” warning and fail to load objects.

    To restore the ability to design and use custom forms in classic Outlook, both of the following must be configured:

    1. Enable custom form script globally via the registry
      The new registry value DisableCustomFormItemScript controls whether any custom form script can run. Its default is 1 (do not run script). It must be set to 0 under the correct key for the Office/Windows bitness:
      • 32‑bit Office on 64‑bit Windows
        HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\16.0\Outlook\Security
      • 32‑bit Office on 32‑bit Windows or 64‑bit Office on 64‑bit Windows
        HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Outlook\Security
      Under the appropriate key, create a DWORD (32‑bit) value named: DisableCustomFormItemScript = 0 This re‑enables the ability for Outlook to run custom form script at all.
    2. Trust each custom form message class
      After script is enabled globally, each form’s message class must be registered as trusted. For example, if a custom form uses message class IPM.Contact.Custom or IPM.Note.Custom, that exact class name must be added to the trusted list under the Outlook security registry path. Once registered, Outlook will allow the script for those forms and the design surface will load correctly without the malicious code warning.

    Additionally, be aware of the VBScript deprecation timeline on Windows:

    • VBScript is currently an optional feature and will later be disabled by default, and eventually removed from future Windows releases.
    • Starting in phase 2 (around 2027), VBScript must be re‑enabled in Optional features in Windows before Outlook custom form script can work, even with the registry keys set.
    • In phase 3, VBScript will be fully removed and custom form script in classic Outlook will no longer be re‑enableable.

    If the issue started “yesterday,” it likely coincides with an Office/Windows update that applied these new defaults. Verifying and correcting the DisableCustomFormItemScript value and ensuring all relevant message classes are trusted should restore the ability to edit and use the custom forms, as long as VBScript remains available on the OS.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.