Microsoft gaat Excel 4.0-macro's standaard uitschakelen in Microsoft 365

Microsoft start in november met het automatisch uitschakelen van XLM's oftewel Excel 4.0-macro's in Microsoft 365-apps. Volgens het softwarebedrijf is de nieuwe standaardinstelling veiliger voor gebruikers.

Microsoft gaat de instelling Enable XLM macros when VBA macros are enabled standaard uitzetten en zo XLM-macro's uitschakelen in Microsoft 365, dat voorheen Office 365 heette. Dat zal eind oktober gebeuren in Insiders-Slow-updatekanalen voor Microsoft 365 en begin november voor 'Current Channel'. Voor Monthly Enterprise Channel van Microsoft 365 wijzigt de instelling halverwege december. Dat meldt Microsoft in zijn Microsoft 365-berichtencentrum volgens het niet aan Microsoft gelieerde M365 Admin, dat het bericht doorplaatst.

Gebruikers en beheerders konden de instelling zelf al handmatig uitzetten en straks kunnen ze de macro's als ze dat willen weer inschakelen via de Excel Trust Center-instellingen. Excel 4.0 verscheen in 1992 en XLM was de standaardtaal voor macro's in die versie. Excel 5.0 maakte de overstap naar VBA of Visual Basic for Applications voor macro's.

Microsoft ondersteunt XLM nog steeds, maar adviseert gebruikers al lang om te migreren naar het veiliger VBA, dat integratie biedt voor de Antimalware Scan Interface. Bleeping Computer wijst er op dat via XLM kwaadaardige aanvallen uitgevoerd worden, zoals met onder andere TrickBot, Qbot, Dridex en Zloader gebeurde.

Reacties (60)

[Nextron]

Het betreft dus Excel 4-macro's en niet over VBA-macro's waar de meeste reacties over gaan. Excel 4-functies gebruik je bijvoorbeeld in de named range manager of op een speciale macro sheet.

[MiesvanderLippe]

Is het niet eens tijd dat ze bijvoorbeeld een Javascript gebaseerd alternatief gaan maken voor VBA macro's? Bijvoorbeeld zoals Adobe doet met JSX of OpenRCT2 d.m.v. Duktape?

[nesva072]

Microsoft heeft als alternatief voor VBA een Office add-in voor in JavaScript geschreven macro's, genaamd 'Script Lab', maar dit is wel een experimentele add-in, en recent is de minimaal vereiste Microsoft Office-versie hiervoor verhoogd naar Office 2021.

Zie de volgende links voor meer info:

https://appsource.microsoft.com/nl/product/office/wa104380862

https://docs.microsoft.com/en-us/office/dev/add-ins/overview/explore-with-script-lab

https://github.com/OfficeDev/script-lab

[Yucon]

Dat is er al: office JS. https://github.com/OfficeDev/office-js. Ik kwam het afgelopen week bij toeval tegen. Nu volg ik het niet helemaal op de voet maar deze ontwikkeling lijkt toch wat stilletjes gegaan te zijn.

[Laurens-R]

Van mij mogen ze macro support er helemaal uithalen. In een bedrijfsomgeving leid het alleen maar tot non-supported business kritische applicaties. Dan word er moord en brand geschreeuwd vanuit een business als er iets mis gaat, maar waar IT wel voor opdraait.

[Mastofun]

Klopt, en dan meestal nog ICT personen die support doen en geen programmatie achtergrond hebben moeten het dan snel snel oplossen .

[Rinzwind]

Als je niet degelijk kunt scripten heb je weinig te zoeken in systeembeheer. Helaas komt dat veel te veel voor (knopjes drukkers) en die roepen da het hardst dat je Office niet mag automatiseren omdat ze zelf geen weet hebben van automatiseren. De ironie.

[Mastofun]

Waarschijnlijk omdat je zelf kan scripten denk je dat iedereen dat moet kunnen? Er zijn zoveel specialisaties dat je niet alles moet kunnen. Ik wil gewoon geen tijd steken in die zelf gemaakte office programmatie die ze dan zelf niet kunnen oplossen.
Groot verschil dat je het zelf maakt en ondersteund en dat iemand anders die een trainingske office heeft gevolgd het gaat maken. Daarna half werkt en dan moet je het oplossen en zorgen dat het goed werkt natuurlijk want jij ben de laatste die er naar gekeken heeft.
Daarna ben je ook gebombardeerd tot specialist van deze toepassing.

[MiesvanderLippe]

Van mij niet! Er zijn altijd edgecases die gemakkelijk op te lossen zijn met een macro en onmogelijk in een interface te gieten zijn.

[Arrogant]

Als het aan IT ligt, zijn er geen gebruikers.

[MazDaMan1970]

Waarom? Je werkt toch met een Microsoft product, dus dan is VBA voor de hand liggend. En de voorbeelden die jij aanhaalt zijn ook niet bepaald standaard te noemen, ondanks dat het op Javascript gebaseerd is.

[MiesvanderLippe]

Omdat Javascript moderner is en er in de interpreters altijd al rekening gehouden is met sandboxing. Ik snap niet zo goed wat er niet standaard is aan mijn voorbeelden? Het aanbieden van extra API's? Dat is juist wel heel gebruikelijk.

[MazDaMan1970]

Ik dacht dat je doelde op standaarden. Sandboxing is inderdaad een belangrijk pluspunt.

[Laurens-R]

Zouden macro's in z'n geheel niet standaard uitgeschakeld moeten zijn - ook VBA? In elk bedrijf waar ik geweest ben als consultant zijn het non-prefered of simpelweg verboden oplossingen. (Even los van het feit of je deze dagen nog bezig wilt zijn met VBA ) Er zijn zat alternatieven voor business users zoals Power Platform, waar de IT iig nog wel grip op kan hebben.

Een thuisgebruiker kan het dan altijd nog aanzetten als ze echt die macro's perse willen gebruiken.

[Reactie gewijzigd door Laurens-R op 23 juli 2024 13:27]

[MazDaMan1970]

Ik heb bij diverse bedrijven gewerkt & ik kan je verzekeren dat macro's veel gebruikt worden. Ik zelf ben er ook geen voorstander van (vanuit een systeembeheerders-oogpunt), maar begrijp heel goed dat users het volop gebruiken; het is gemakkelijk & goedkoop. En om eerlijk te zijn werkt het vaak beter dan allerhand 3rd-party oplossingen, die vaak ook nog eens belachelijk duur zijn, om nog maar te zwijgen over consultancy kosten...

[cricque]

Tsja het is gemakkelijk, ken nog genoeg bedrijven die excel gebruiken voor alles inclusief vba. Dan zeg je dat geen goed idee is … geen tijd, het werkt, en dat kost geld en nog belangrijker, we werken al x aantal jaren zo, waarom veranderen, het werkt toch ….Ik heb een saas applicatie, daar zit oo, een kale,der in … ja maar ik moet dit in xexcel hebben, je mag 10.000 geldige redenen hebenne, dikwijls willen mensen gewoon excel. Nu als het aan mij ligt wordt excel verboden, dat zal wel niet gebeuren, maar de gedrochten die ik in ecel al gezien heb … vroeger werd er nog een screenshot geplakt in word … dit is tegenwoordig excel. Je moet maar eens proberen en zeggen tegen een klant … ik kan geen excel openen …. Dan staan ze te kijen en dan vragen ze zich af hoe werk jij. Je bent toch ITer hoe kan het nu zijn dat je geen excel hebt … deze ben ik dus ook liever kwijt dan rijk.

[Reactie gewijzigd door cricque op 23 juli 2024 13:27]

[batjes]

Excel wordt vaak misbruikt, maar vergis je er niet in hoe duur het kan zijn om een geschikte applicatie te gebruiken.

Excel kent iedereen en belangrijker, heeft -praktisch- iedereen. Leuk als je de precies geschikte applicatie erbij hebt voor je project, het is niet ongewoon dat zulke zaken gedeelt worden met partners, klanten of whatever. Men kan er thuis bv ook nog wat mee gezien ze vaak wel Office hebben.

Het is wat minder leuk vanaf een support oogpunt, wat een gedoe al die uitzonderlijke shit in Office. Maar vanuit een gebruikers perspectief is MS Office echt ontzettend krachtig. Het is echt niet zonder reden dat Microsoft Office de markt compleet domineert.

[bussie66]

Ben je kennelijk nog niet in veel bedrijven geweest?

Ken zat bedrijven waar helaas VBA nog toegestaan is.

Waar ik werk ook, echter wij geven daar als IT compleet geen support op.

Eigen risico Business ook als de boel om wat voor reden opeens het niet meer doet tijdens een belangrijke periode.

[centr1no]

Wat me altijd is opgevallen is dat er bijna nooit (officiële) support vanuit IT is voor de standaard functionaliteit van een applicatie die aan iedere medewerker verstrekt wordt.
Die uitspraken als 'eigen risico' hoor ik regelmatig, maar dat is simpelweg onacceptabel. Als IT binnen een bedrijf heb je net zo goed als niet meer de verantwoordelijkheid om te voorkomen dat 'de boel om wat voor reden opeens het niet meer doet'.
Te vaak heb ik in bedrijven gezien dat de IT helpdesk domweg mensen afwimpelt met de mededeling dat voornamelijk Excel-documenten met macro's inhoudelijk niet ondersteund worden terwijl er wel gewoon mensen zitten die de hele dag bezig zijn met SQL o.i.d. en meer dan voldoende kennis hebben om een simpele VBA-macro te ontleden.
Het komt vaak over alsof de IT-afdeling weigert met het bedrijf mee te denken.
Het rare is dat er vaak wel onderkend wordt dat er een enorme kloof is tussen IT, die zich vaak uitsluitend bezig houd met de achtergrond, en de medewerkers die normaal uitsluitend inhoudelijk met de voorgrond bezig zijn, maar dat men die kloof zelden probeert te overbruggen.

Als VBA veel gebruikt wordt door gebruikers dan is daar een reden voor. Als je, in plaats van domweg te zeggen dat je er niets mee te maken wilt hebben, het gebruik in beeld kunt brengen kun je misschien bepalen of er al een applicatie is die gebruikers beter kan faciliteren of zijn er misschien structurele verbeteringen nodig.
Voor sommige werkzaamheden is het misschien zelfs wel de makkelijkste en/of goedkoopste manier om het in Office met VBA te doen en waarom zou je dat dan niet gestructureerd willen opzetten en ondersteunen.

Als er al een IT-club is met waarschijnlijk een specialist voor de prijzige enterprise systemen die een bedrijf heeft, waarom dan niet een specialist of project-engineer o.i.d. die wel met medewerkers kan meedenken?
Simpelweg een dagje meekijken met de werkzaamheden en het inventariseren van issues die soms verrassend makkelijk op te lossen zijn levert altijd wat op.
Vele malen heb ik hele afdelingen vrolijk gekregen met een herindeling van de mappenstructuur, heldere naamgevingen van en in netwerklocaties en documenten, afspraken over layouts en formattering en het opnieuw gestructureerd opzetten van oude Excel documenten waardoor de kans dat een macro niet meer functioneert door een ongeldige verwijzing (wat naar mijn ervaring de meest voorkomende foutmelding geeft) drastisch af neemt.

Ik heb meerdere keren de opmerking gehoord dat dit soort dingen niet horen bij de werkzaamheden van een IT afdeling. Als er al aandacht voor is wordt het vaak neergelegd bij een verbeterteamachtige club of projectpersoon waarbij het vrijwel altijd ofwel ontbreekt aan kennis op IT vlak of inzicht in de bedrijfsprocessen en daadwerkelijke werkzaamheden.
Uiteindelijk maakt het natuurlijk niets uit waar het organisatorisch onder valt, zolang maar onderkend wordt dat dit bij veel bedrijven een onderschat gebied is waar vaak winst valt te halen.

[evilution]

Tja, IT'ers stellen zich liever op als BOFH dan als faciliterend aan de primaire processen van het bedrijf. Je ziet dat in o.a. dit draadje ook weer volop.

[Miuccia]

Ik vind het heerlijk om af en toe een macrotje te tikken in Excel. Zeker als je wat externe data wilt verwerken of je blad specifiek wilt provisionen. Heerlijk.

Als het allemaal zo onveilig is enzo, waar gaat Microsoft niet aan de slag met een mooie universele nieuwe scriptingtaal? Python ondersteuning bijvoorbeeld?

[jorisporis]

Je kan in je macro gewoon een commando stoppen om keylogger.exe ofzo uit te voeren en naar je collega sturen. Je moet wel even een administrator bevestiging geven, maar veel users gaan daar gewoon op in. Dit is toch echt een klassieker, ik ben er 15 jaar geleden zelf eens in getrapt.
Een nieuwe scriptingtaal lost niets op, omdat je daarmee dezelfde mogelijkheden hebt. In Python kan je trouwens alles doen wat je met VBA kan. https://www.pyxll.com/docs/userguide/vba.html
Microsoft zou systeemadministrators een veel detailleerdere controle moeten geven over wat er met VBA mag en wat niet. Ik begrijp niet dat dat er niet is, office is toch echt een melkkoe voor microsoft. Of het zou zoals een javascript moeten zijn dat ook niet zomaar ontsnapt uit je browser.

[Reactie gewijzigd door jorisporis op 23 juli 2024 13:27]

[Sebazzz]

Microsoft had een initiatief voor Excel uitbreidingen in javascript, maar dat draait in de Internet Explorer engine.

[The Zep Man]

Je bedoelt Windows Script Host, met de Microsoft's variant van JavaScript of Visual Basic Script.

Daarmee heb je nog steeds dezelfde problemen.

[nesva072]

Microsoft heeft ook een experimentele Office add-in voor macro's die zijn geschreven in JavaScript, genaamd 'Script Lab', maar dit staat inderdaad los van het beveiligingsaspect.

[Sebazzz]

Nee, niet WSH - echt IE.

[Bas Boss]

Het lijkt mij een veel betere optie om een verplichte review in te bouwen. Zodat alleen goedgekeurde vba projecten gebruikt kunnen worden.

Het low code aspect werkt gewoon erg prettig voor complexe sjablonen / formulieren. Ik heb zelf ook geen idee wat een geschikt alternatief zou kunnen zijn.

[ReZpie]

Dit is er wél, althans enigszins.
In het e5 pakket zitten attack surface reduction rules, daarin kun je processen/mappen/bestanden redelijk makkelijk excluden.

[Ablaze]

Of zoals in Google workspace, gewoon js gebruiken en dat alleen online ondersteunen.

[field33P]

Ik denk dat R dan een geschikter uitgangspunt is voor een scriptingtaal, gezien die taal ontworpen is voor het managen van data.

[alexbl69]

Dit inderdaad...

Programmeer al m'n hele leven. C64 (basic en assembly), VB en sinds een jaar of 15 VBA.

Vind het heerlijk ontspannend om af en toe op een avond lekker een VBA routine te maken voor iets dat ik zakelijk kan gebruiken.

Vaak zijn dat 'quickies' voor eenmalig gebruik.

Heb één werkblad dat ik dagelijks gebruik met flink wat VBA code. Zit daar nog regelmatig zaken in aan te passen, 'moderner' of gewoon netter te maken.

En passant spaar ik ook een klein kapitaal aan automatiseringskosten uit.

[Saven]

Mwa, dynamisch gegevens van een ander blad ophalen in dezelfde sheet, kan simpelweg zonder macro niet. Dat gebruik ik toch wel veel Bijvoorbeeld als je voor elke maand een blad hebt, en gegevens van de vorige maand wil pakken ter vergelijking.

[Reactie gewijzigd door Saven op 23 juli 2024 13:27]

[mjz2cool]

Het ligt eraan op welke manier je het wilt doen, maar je kunt perfect gegevens uit een ander blad ophalen, zelfs vanuit andere bestanden.

[beerse]

Je kan toch gewoon aan de andere cellen refereren? Zoiets als "='2020'.E165" (al is dit direct uit LibreOffice gehaald).

Als programmeur heb ik een gigantische afkeer van alles wat naar basic ruikt, dus ook vba. En als beheerder heb ik 20 jaar geleden al begrepen dat macro's en dergelijke in principe uit moeten staan en alleen aan kunnen/mogen als zaken als antivirus, firewalls en dergelijke uit staan, anders werken ze niet

Dat in LibreOffice java als script taal gebruikt kan worden is overigens ten opzichte van visual basic geen echte verbetering, al is het wel meer een echte taal.

Office omgevingen zijn geen programmeer omgevingen. De programma's zouden naar mijn idee buiten die applicaties moeten draaien, dus onafhankelijk van gebruikers. Gewoon rechtstreeks op de bestanden. En sinds het formeel allemaal xml is met een goede beschrijving, kan dat ook

[matroosoft]

Kan toch gewoon met een query?

[Alex3]

Elke maand op een ander blad is meestal een slecht idee. Voor maandelijkse overzichten gebruik je een draaitabel.

[P_Tingen]

Bij het bedrijf waar ik zit gebruiken ze VBA in Outlook om orders via email op te slaan op een netwerkschijf. Wat voor alternatief zouden ze dan beter / veiliger kunnen gebruiken voor on-premise Exchange?

[crazyx]

Een extern programma of via een powershell script zou absoluut mijn voorkeur hebben.

[mjtdevries]

via powershell is het inderdaad super simpel om zoiets te doen.
P_Tingen heeft het over on-premise Exchange. De kennis die een Exchange admin al van powershell nodig heeft is voldoende om zo'n script in elkaar te knutselen. Dat weet ik omdat we het ooit zelf hebben gedaan voor een migratie traject.

[Rinzwind]

Wat lost PS op? Een scripttaal vervangen door een andere scripttaal... niets. Nog afgezien van dat VBA een stuk leesbaarder en beginnersvriendelijker is. Ook altijd 1 van de hoekstenen voor Office power users geweest. 1 van de kernpunten van Office: Automatisering van Office handelingen. Het is meer het probleem dat Windows rechten afhandeld op gebruikersniveau ipv taak/feature. Je kunt trouwens best veel afschermen terwijl je nog steeds macro's mag gebruiken.

[Primuszoon]

Ik denk dat er, spijtig genoeg, nog heel wat bedrijven aan elkaar hangen met excel/VBA macro's. Waarom upgraden 'als het al werkt'. Niet dat ik er mee akkoord ga, maar de realiteit is soms hard.

[Metalfreak]

En ik heb echt nog veel oplossingen gezien waar bedrijven van afhankelijk zijn die met macro's werken. Dat zorgde er regelmatig voor dat de policy met betrekking tot uitvoeren van macro's juist losser gezet moest worden ipv strikter.

Juist in het bedrijfsleven wordt dit echt nog heel veel gebruikt.

[JDFS]

Ik heb bij twee multinational US conglomeraten gewerkt waarvan 1 grote consultancy club - VBA wordt hier nog steeds heel erg veel gebruikt bij beiden en ook bij bedrijven om mij heen wordt VBA nog steeds als no. 1 quick stop oplossing gebruikt. Ben het met je eens, weinig grip erop en macro's zuinig de energie uit mij als er iets aangepast moet worden.

Ik gebruik zelf Alteryx hiervoor, maar kan me voorstellen dat niet iedere werkgever erop zit te wachten om een licentie af te nemen van een paar K per jaar.

[SunnieNL]

Die staan standaard toch ook uit met een notificatie bovenin? En een bedrijf kan er altijd voor kiezen om dat via een gpo helemaal uit te zetten. Maar ik kan de meeste beheerders dan wel verzekeren dat ze een hoop shit over zich heen gaan krijgen, want er zijn tig processen in bedrijven afhankelijk van excellijsten met macro's.

[HakanX]

Moet IT wel in contact staan met de werkvloer. Excel heb je altijd tot je beschikking in zowat elk bedrijf. Kan je vanalles in scripten en het dagelijks werkleven makkelijker maken. Of je gaat als standaard werknemer de IT afdeling en het management ervan overtuigen om een bepaald softwarepakket aan te schaffen of te installeren op hun computers als je ze al te spreken krijgt. In heel veel bedrijven een onmogelijke missie. Daarom lekker blijven scripten in Excel.

[Yucon]

De charme is natuurlijk de innige integratie met office. Maar met de office javascript api's is MS dat stukje los van de macro-omgeving aan het weken. Op die manier kun je ook met andere script-achtige oplossingen zoals het power platform of python precies hetzelfde voor elkaar krijgen als met de klassieke vba macro's. Hoewel ik er nog niet helemaal ingedoken ben heb ik wel de indruk dat dit het geheel net wat beheersbaarder maakt.

[SkiFan]

Goede zaak, en zoals hierboven, software uit 1992 is nauwelijks meer op een zinnige wijze veilig te houden (wat het dus ook niet is).

We zien té veel hacks via Office applicaties. Nog steeds.

[cricque]

Tsja dat kan de meeste bedrijven dus niet schelen, het werkt, iets anders is te duur en we doen al x aantal jaren zo. Dat zijn zowat de meest gebruikte redenen om toch maar excel met vba en macros te gebruiken. Veiligheid hoort daar dus niet bij. En dat is een zeer spijtige zaak. Maar dan gaan ze wel staan janken nadien ls ze opelke pc een virus hebben of gehacked zijn … Dat is zowat de enige reden dat bedrijven hier vanaf stappen

[Gepetto]

Wie bedoel je met "bedrijven"? De gebruikers die er mee moeten werken, de directie, of de ICT afdeling?

Die laatste hecht wel degelijk aan een stuk veiligheid, (dat mag je in ieder geval van ze verwachten) en zijn het wel gewend dat dit soms ten koste gaat van het gebruikersgemak. Ze zullen de gebruikers er steeds van moeten overtuigen dat niet altijd alles maar mogelijk is.

[cricque]

Directie. Ict afdeling krijgt geen budget daarvoor, kost teveel en gebruikers moeten ets nieuw leren, en het werkt nu toch ook …. Gebruikers weten dikwijls niet wat en macro is of veilig, die willen gewoon hun resultaat zien. En in grotere bedrijven is de ict afdeling misschien wel op de hoogte, maar in kmos of de bedrijfjes met 2-3 man die zijn dikwijls niet op de hoogte, en daar heeft ooit iemand eens iets gemaakt en dat werkt … bij een update zoeken ze een freelancer ofzo die dit even kan aanpassen en dat is het dan, en we blijven rustig verder doen. Net hetzelfde als gdpr … vraag eens aan 10 schilders, slagers en taxi bedrijven wat gdpr is … als er van elke groep 5 zijn die het weten heb je een mooi resultaat. Maar je mag al blij zij als het 1 op 10 is. Er is de realiteit en er is “hoe het zou moeten.”

[gimbal]

"Microsoft gaat de instelling Enable XLM macros when VBA macros are enabled standaard uitzetten". Zie de screenshot bij het artikel, zo heet de optie blijkbaar niet...

[Tyrian]

Ik heb diep respect voor Microsoft dat ze zo veel doen voor compatibiliteit met eerder gemaakte software. Het feit dat ze nu pas een functie uit 1992 uitschakelen is hier een voorbeeld van. Ik ben me terdege bewust dat dit ook grote nadelen heeft (Legacy bloat, beveiligingsproblemen) is compatibility toch de voornaamste reden dat ik nog altijd zonder nadenken voor een x86 computer met Windows zal kiezen i.p.v. voor een technisch superieure ARM of RISC processor met Linux of MacOS.

Eigenlijk zei Intel het al in 1992:
https://www.youtube.com/watch?v=cgAI1AoLKOc

[wica]

Het is veiliger voor de gebruiker, vertaald naar, wij hebben geen zin meer om het onderhouden.
Wat op zich zeer terecht is voor uit 1992.

[mc_maarten]

De mensen die macro's gebruiken zijn toch de wat meer gevorderde gebruikers. Die krijgen dat knopje wel gevonden.

[mjz2cool]

De mensen die macro's gebruiken raken in paniek als het bestand waar ze in werken niet werkt als het uitvoeren van VBA uitgeschakeld staat.

[Alex3]

VBA-macro's blijven werken. XLM-macro's worden uitgeschakeld.

[SunnieNL]

correctie.. de mensen die macro's bouwen zijn de wat meer gevorderde mensen.
Mensen die macro's gebruiken zijn hele volksstammen die niet weten hoe het werkt maar het wel handig vinden dat de excel sheet doet wat die hoort te doen als ze ergens een waarde invoeren.

[Kwartjevankok]

1992 is 29 jaar geleden... In 1992 was 1963 29 jaar geleden. Wow. Voegt mijn reactie wat toe? Nee, een reflectie op vrijdagavobd. Maar wat was ik als PC gebruiker in de negentiger jaren blij met visual basic in excel. Hoefde ik niet maanden te wachten op een draaitabel en wat zoekfuncties. En nu agile werken...