Microsoft Backtracks on Blocking Office VBA Macros by Default

Posted on July 8, 2022 by Laurent Giret in Cloud, Office 365 with 16 Comments

Microsoft is backtracking on its plan to block all Office VBA macros obtained from the Internet by default. The company had been testing this change on the Current Channel (Preview) since April with a general rollout planned for June 2022, but these plans have unexpectedly changed this week.

“Based on feedback, we’re rolling back this change from Current Channel. We appreciate the feedback we’ve received so far, and we’re working to make improvements in this experience,” the company said on the Microsoft 365 Admin Center yesterday (via Bleeping Computer).

Microsoft previously blamed VBA macros downloaded from the Internet for being a well-known source of malware. By blocking these macros by default in Office, users would no longer be able to enable them with just the click of a button. Microsoft had been testing the following banner in Word, Excel, PowerPoint, Visio, and Access since April.

Office message bar with security warning about blocked VBA macros

To run these VBA macros, Microsoft was going to require Office users to save the file to a trusted location such as a local hard drive, network drive, or cloud storage service like OneDrive, and then unblock the file manually. That’s a definitely a big change that many organizations needed to digest, and that probably explains why Microsoft decided to backtrack at the last minute.

If Microsoft rolling back this change based on feedback is certainly making things confusing for Office users and IT pros, it’s not clear yet what kind of changes Microsoft is going to implement to protect Office users from malicatious VBA macros. “We’ll provide another update when we’re ready to release again to Current Channel,” the company announced on the Microsoft 365 Admin Center yesterday.

Tagged with ,

Join the discussion!

BECOME A THURROTT MEMBER:

Don't have a login but want to join the conversation? Become a Thurrott Premium or Basic User to participate

Register
Comments (16)

16 responses to “Microsoft Backtracks on Blocking Office VBA Macros by Default”

  1. spiderman2

    Probably some companies cried out loud

  2. gregsedwards

    It is shocking to me how many organizations of all sizes still rely heavily on Excel macros for core business functionality. And even crazier is how slapdash and poorly documented these solutions tend to be. Some enterprising wannabe developer built a neat thing in Excel 20 years ago, and now that person is retired and the whole company runs on it.

    • christianwilson

      I worked at a place many years ago that had a sister company who managed billions of dollars with spreadsheets. Their whole life was Excel and Outlook. It was fascinating to me.

    • Daekar

      I am in the middle of seeing this happen before my eyes. Everyone wants to have IT develop solutions for them, but we have 1/3 the devs that we need to support operations. We went through an ERP transition 4 whole years ago, and there is STILL not functionality built out that we had in the old system, some of which was supposed to be on the MVP list. As a result, tools are being built by people to handle things as best they can. It's going to cause problems later, no doubt about it, but those problems are less bad than not performing any process improvements for a decade that aren't driven from the top because IT is too busy with other things.

    • ronmcmahon

      I believe that's called Appolution


      Smart guy builds a Word macro...it's really helpful to keep things consistent every month for that report for the Accounting team in Toledo. After a few years it's improved with an Excel source for data (nobody really notices this, because the tweak was made by a guy who quit a few months later and he only mentioned the change to Pat, who didn't understand). A year later an enthusiastic engineer from a company we just merged with was playing around and suddenly Access is used to store a history of actions and is now pulling more organizational data from Active Directory...of course there was that intern the next summer who added in automatic distribution lists, attachment routing and groups in Outlook based on numerous workflows that were jokingly suggested by his lead over a coffee break.


      This Word macro has been very successful, it now automatically provides key monthly financial and HR data to each division and is a significant component of the Federal G-556 reporting.


      No need to worry, our admin assistant Pat has a list of the steps she takes each month-end all written down in a notebook in her desk...she has no understanding of what her actions are doing, but she's confident that that smart guy made a good macro. When it 'burps' (her words, not mine) she just clicks ok or cancel until they stop. Sometimes she has to restart her PC, but it always works out...nobody has complained.


      The smart guy is retiring this Friday...his leadership, the IT Department and Accounting are completely unaware of this helpful Word macro he built a decade ago...in fact he's not even aware of how it's changed, as it's morphed and mutated in a division he's not been a part of for close to a decade.


      That cute little macro has now evolved into an invisible, mission-critical bomb with hair triggers ready to detonate with the slightest change to Active Directory, Office file format naming changes or Office Macro and VBA functionality changes from Microsoft. One can only wonder what goodies an e-discovery would reveal in the Access databases, or various Excel spreadsheets...too bad Legal has no knowledge of this either. Good thing organizations always follow the letter and spirit of the law and have no fear of a full exposure of internal corporate documents to the public and government.

      • hrlngrv

        | A year later an enthusiastic engineer from a company we just merged with was playing around

        | and suddenly Access is used to store


        So many IT departments REFUSE to give non-IT people any access to whichever RDBMS the enterprise uses for its major database needs. Non-IT department users relying on Access is one helluva lot better than relying instead on CSV files maintained by batch files.


        If enterprises were willing to spend the money on software and training to give non-IT users better software tools, it may be fair to complain about the overuse of VBA. However, without any serious alternatives, VBA is the EXCLUSIVE tool most/nearly all non-IT users have to get certain tasks done consistently and without unnecessary manual effort for manual effort's sake.


        Should there be better controls and documentation? Absolutely, but NOT with IT specifying either except in general terms. In most enterprises, most of the time, IT either has no interest in or insufficient resources for supporting non-IT department automation needs. Putting this another way, if you have someone with a broken leg and only Lincoln Logs and duct tape, what do you use to make a splint for the broken leg?

    • mattbg

      Agree with you, however... I do sympathize.


      Business users are increasingly being given better and better tools to do their own development. Especially BI tools - stuff like Tableau - which puts a lot of power directly in the hands of the people that understand the business logic the best.


      Business users' development processes need a lot of work, but the direction of having business do their own development rather than trying to explain what they need to IT is a good development, IMO.


      Having said that, I have an affinity for auteurs in general...


      Also, this whole push to "teach kids to code" is about exactly that. It's not to raise a new generation of IT workers - it is to raise a generation of people that can automate their own work, no matter what that happens to be.

      • hrlngrv

        | it is to raise a generation of people that can automate their own work, no matter what that happens to be


        If those people work for the typical Fortune 1000 enterprise, VBA is the nest too they have to use for automation. A few things may be better handled with batch files, a very few others with VBScript. Odds are less than 50-50 they could run .PS1 files due to group policy, so usually irrelevant outside IT departments.

        • mattbg

          It's still very relevant, but lots of people have moved past VBA.


          Here's an example: Jupyter notebooks (python). Lots of business users are getting into that. Python installs locally to your user profile (no admin privileges required), and you can create and tear down virtual environments within your local profile that include the packages you need.


          I'm on the IT side, and I know VBA, but I'd much sooner use something like Jupyter + pandas to deliver some automated process that had to deliver results in Excel format as an end result than I would write something in Excel directly these days.


          Also, stuff like Tableau is pretty impressive. It presents as a data visualization tool but it's great just at combining data from multiple data sources and wrangling with data. It has a server component that lets you publish your work for others to use. It requires admin to install, but there is a clear business case for tools like that, and once they are in, business users will find lots of creative things to do with them.


          I definitely recognize the problems of end-user development, but I'm equally as tired of IT getting in the way because they don't understand (or even care about) business use cases, and the tools for business users to help themselves are getting better.

          • hrlngrv

            If all Excel were used for were processing existing data, there are better tools to use.


            OTOH, if one needed to build complex, multiple year cashflow models which had to take into account US federal corporate income tax laws, especially exotica like insurance carrier reserve discounting or depletion allowances, Jupyter notebooks and Tableau aren't nearly as useful as spreadsheets.


            Then there's the kinds of things people actually automate. Usually those involve printing or copying sections of some files to other files. That's much more easily done with VBA using Excel's object model. Sure, it's possible to use Excel's object model with Python (or most other scripting languages), but one needs to know a lot more about Excel's object model when using environments other than the VBA Editor under Windows. [The VBA Editor for Mac is so bad one might be better off using ANYTHING else.]


            And it's wonderful that Python could be installed under %USERPROFILE%, but the IT policy I have at work expressly PROHIBITS installing any nonstandard software, and there's no option to install Python. NBD for me since I can install and use GNU R with a commercial RStudio license. I use it with existing data, but it's not a useful tool for building financial models which need to generate pro forma financial statements.


            There's an exercise for determining the suitability of different platforms for financial modeling: create an amortization table for adjustable interest loans. Those are highly regulated, so have fairly precise, legally binding specs, so the math is straightforward. It's the implementation which takes work. I know how to do it in spreadsheets so that all parameters are live inputs with any changes reflected immediately after automatic recalculation, and I know how to do that in scripting languages using input from parameter files up front. I'll admit I don't know enough about Jupyter Notebooks to know how to reproduce tables upon entering changed parameters. Maybe it's simple. But I know Tableau is NOT a useful tool for this. At least I haven't figured out how to use it effectively for this, and I haven't found any good approaches on the web.

    • hrlngrv

      Be as shocked as you want, but the typical enterprise gives non-IT employees exactly 4 ways to automate ANYTHING on work PCs: 1) batch files, created/edited using Notepad; 2) Windows Script Host/VBScript/JScript, created/edited using Notepad; 3) Powershell PROVIDED its IDE is included in the enterprises standard image AND mere users have permission to run .PS1 files; 4) VBA in Office programs.


      The reason non-IT departments rely on VBA is because IT has 1) no interest in automating a damn thing they themselves didn't think of automating, and 2) the IT department developers who might be assigned to such projects are so ignorant of non-IT department work-flows, business rules, and user needs that it just takes too much time to TRAIN them to convert anything from VBA. I've spent the bulk of my career in financial services observing this first hand.


      So it really shouldn't be shocking at all that VBA is so heavily used.

  3. jeremymoskowitz

    No wonder the ransomware guys are winning the battles. We have our doors and windows wide open.

  4. hensonr

    I'll never understand why Microsoft removed the (paraphrasing from memory), "Prompt to allow VBA macro to run" option. Now it's "Enable (all) VBA macros", and "disable with/without notification", and "disable except digitally signed". If you have a need to run some macros, the prompt to allow seems much safer than allow all.

    • lvthunder

      They didn't at least in Excel. When I open some of our spreadsheets with Macros It asks me to enable macros in the bar at the top.

  5. Daekar

    I can see how this would cause problems if they literally made it so folks couldn't open a shared macro-enabled file from its location in a SharePoint library. That would be insane.


    If they want to take the functionality of VBA away, that's fine, but they need to prepare for the torches and pitchforks that will come with that unless they have another solution ready to immediately replace it. As it is, VBA is a built-in development environment that every single worker at my company has access to, they can deploy the resulting tools without centralized control and delays, and there is an absolutely gobsmacking amount of reference material for it online. It's a wonderful solution from the perspective of a power-user looking for tool for solving their own problems, and it gets unfairly criticized because citizen developers typically don't write adequate comments on how things work or create a wiki page documenting functionality. That's not really the fault of VBA.

  6. wolters

    I've been the IT Director (and SOLO IT person) at my company for over 11 years now. Critical Excel spreadsheets in our office are all built on VBA code and some of them have massive amounts of VBA code. We live by VBA as I am going to guess a lot of small businesses do because it really helps customize Excel to how you need to do business. For example, we have a huge Excel project that uses Macros to verify the measurements and weights of roll forming metal and then when it is ready, another Macro does a critical conversation of the data that creates a file that can then be imported into a roll forming machine to make our building panels, purlins and trim.


    I honestly have seen this issue over the past few weeks. We send this sheets with Macros to an offsite consultant to work on, they send back to is and the Macros have been disabled. Easy to turn back on but it caused frustration for us.


    We NEED VBA.