Microsoft gaat VBA-macro's in Office toch blokkeren na gebruikerskritiek

Microsoft gaat macro's in Office-software op termijn toch blokkeren. Het bedrijf kondigde eerder aan dat te doen, maar draaide die beslissing vervolgens weer terug. Nu zegt het na feedback van gebruikers toch weer macro's te blokkeren.

Microsoft besloot in februari Visual Basic for Applications-macro's in Office-programma's standaard niet meer te tonen. Daarvoor werden macro's in Word of Excel standaard niet geladen, maar konden gebruikers die wel inschakelen met een druk op een knop. Dat is jarenlang een bron van gevaar geweest, omdat via die macro's malware makkelijk kon worden verspreid. Microsoft zei in februari dat macro's standaard geblokkeerd zouden worden en dat gebruikers die alleen nog konden inschakelen door in de eigenschappen van het bestand macro's toe te staan.

Beveiligingsonderzoekers juichten de beslissing destijds toe, maar Microsoft kwam er enkele weken geleden op terug. In april kwam de nieuwe beveiligingsfunctie beschikbaar in het Preview-kanaal en in juni voor alle gebruikers in het Current Channel. Al snel na de algemene uitrol kregen gebruikers en systeembeheerders in Office te horen dat macro's alsnog zouden worden geladen en dat de extra waarschuwing en bescherming zouden worden teruggedraaid. Microsoft gaf daar toen geen verklaring voor.

Nu maakt Microsoft opnieuw een draai, opnieuw zonder duidelijke verklaring. "Op basis van feedback draaien we deze beslissing uit het Current Channel weer terug", schrijft het bedrijf in een update. Het is nog niet bekend in welke previewversie en definitieve versie van Office-programma's macro's alsnog geblokkeerd gaan worden.

Reacties (126)

[Verwijderd]

@TijsZonderH vergeet in het artikel te noemen dat het gaat om Office bestanden "afkomstig van Internet".

Bovendien gaat het voorlopig om enterprise versies van office, en juist daarvoor bestaat een policy waar je dit allang mee kunt afdwingen.

Nb. Office group policies in bijv. Office Home & Business worden kort na opstarten van Windows gedisabled (had je maar een duurdere versie moeten kopen). In Office 2016 Home & Business werkten ze aanvankelijk wel (foutje bedankt), maar dat heeft Microsoft later met een update uitgezet.

Bleeping Computer legt uit om welke policy het gaat, en laat zien hoe de gewijzigde waarschuwingsbalk (getoond onder de ribbon) er uitziet. Maar nogmaals, policies werken niet in non-enterprise versies van Office.

In veel gevallen (maar zeker niet altijd) krijgen bestanden "gedownload" van internet een extra (grotendeels onzichtbaar) tag (label): het "Mark of the Web" ook bekend als MotW (of MoW). Nb. dit is een Windows "feature" die bijv. ook door Firefox wordt ondersteund.

Als zo'n tag aanwezig is, zie je dat in de bestandseigenschappen (vanuit verkenner en tools zoals Total Commander): er is dan een "unblock" optie zichtbaar (zal wel iets als deblokkeren zijn in het Nederlands).

De MotW gaat o.a verloren bij drag & drop van bijlagen in Outlook (bron). Verlies van MotW bij drag en drop zou wel eens bij veel meer programma's kunnen gebeuren.

Uitsluitend opslagmedia geformatteerd met het NTFS bestandssysteem ondersteunen "ADS" (Alternate Data Stream) waar het MotW gebruik van maakt. Als het bestand via een met Ext-FAT o.i.d. USB-geheugenstick of via een Samba share wordt gekopieerd, verlies je het MotW.

Eric Lawence heeft uitgebreide info (Last update: June 21, 2022) over hoe MotW werkt en het gedoe eromheen.

7-Zip (7Zip) sinds versie 22.0 kan als de zip file een MotW heeft, dat toevoegen aan uitgepakte bestanden, maar default staat dit uit.

Didier Stevens ontdekte dat als je een zip-bestand met MotW (per ongeluk) wijzigt (bijv. door een daaruit geopend bestand te wijzigen en weer in de zipfile op te slaan), dat het MotW van de zip-file verdwijnt.

In deze Github pagina van Nobutaka Mantani vind je een recent overzicht van "archivers" (compressieprogramma's) die wel, deels of niet het MotW ondersteunen.

De Duitse Heise (uitgever van o.a. het Duits- en Nedertalige tijdschrift c't) heeft op diens website de mogelijkheid om je "office files vanaf internet" te mailen, idem zip-files (om te testen of je instellingen goed staan), wel Duitstalig: https://www.heise.de/secu...mit-Anhaengen-777837.html (bron).

Overigens kun je ook zelf eenvoudig een bestand met een MotW taggen (met notepad; Eric Lawrence beschrijft hoe je zo'n ADS toevoegt - en Didier Stevens heeft er een tooltje voor).

Edits t/m 14:57: typo's, urls gefixed en enkele toegevoegd.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:11]

[LogOffShutDown]

Ik denk dat het stukje "from the internet" uit het Microsoft artikel belangrijk is "block macros in files from the internet".
Wanneer je binnen je bedrijf dus met macros werkt dan heb je hier geen "last" van omdat die bestanden lokaal of op eigen netwerk staan.
# Macros from the internet will be blocked by default in Office
https://docs.microsoft.co...y/internet-macros-blocked
# How Office determines whether to run macros in files from the internet
https://docs.microsoft.co...n-files-from-the-internet

[Frituurman]

Godzijdank. Voor bepaalde sheets zijn een aantal specifieke macro's toch echt van belang (totdat we over zijn naar een stuk maatwerksoftware wat dezelfde functionaliteit biedt) en dan zou 't toch echt vervelend zijn dat macro's an sich geblokkeerd zouden worden. Zolang het gaat om macro's vanaf internet, heb ik er geen probleem mee. Bedankt voor deze nuttige informatie!

[SunnieNL]

Als je nou de macro's zou ondertekenen met een intern certificaat ben je security technisch stuk beter bezig en hoef je je sowieso geen zorgen te maken.
Kun je gelijk de security van office omhoog gooien door alleen 'signed' macro's te accepteren en kan ook niet elke medewerker of iemand anders die bij de data kan, zonder meer de macro aanpassen of nieuwe macro's injecteren in dat document.

[Frituurman]

Vanuit de overheidsorganisatie waar ik nu werk (in vergelijking met de overheidsorganisaties waar ik héb gewerkt), denk ik dat we juist een van de weinige zijn die een intern certificaat afgeven. Dat is tegelijkertijd het enige certificaat wat wordt vertrouwd. De titel en tekst (als je niet doorklikt op de links) geven de indruk dat álle macro's worden geblokkeerd, terwijl dat niet zo is. Daar schrok ik eerlijk gezegd een beetje van, omdat juist heel veel (complexe) sheets afhankelijk zijn van een aantal functionele, zelfgeschreven macro's. Het feit dat het hier alleen gaat om macro's van het internet, betekent dat er bij ons dus eigenlijk niets veranderd.

[Bob Popcorn]

In het MKB ga je niet zo snel over naar maatwerk software helaas, wij werken voor onze prijslijsten en offertes 100% met Excel/VBA software...

[supersnathan94]

Ooit gehoord van moneybird?

Uiteindelijk zijn dit gewoon standaard processen in bedrijfsvoering die je nodig hebt. Daar heb je ook niet per se maatwerk oplossingen voor nodig. Die heb je alleen nodig omdat je afwijkt van bepaalde standaard procedures die de rest van alle bedrijven gebruiken.

[BlueZero]

Klinkt makkelijker dan het is, er zijn zat bedrijven die in een sector werken waar er niet met stuksprijzen wordt gewerkt. Toevallig ben ik softwareontwikkelaar gespecialiseerd in dat soort oplossingen.

Stel u koopt een zonnescherm, deze prijs is gebaseerd op een matrix (breedte x hoogte), daar bovenop komen nog meerprijzen die allemaal gebaseerd kunnen zijn op bepaalde voorwaarden (vanaf x breedte, vanaf x aantal m2, i.c.m. specifieke optie) en de prijzen zelf kunnen berekend zijn door middel van percentuele meerprijzen op een andere prijs, vierkante meter prijzen, meter prijzen, matrix prijzen etc.

U begrijpt dat het niet handig is om maar bij elke offerte even het prijzenboek van de fabrikant te gaan doorbladeren om te kijken wat de bruto inkoop is voor de gegeven specificatie.

[supersnathan94]

Oh ja uiteraard. Dat geloof ik meteen.

Ik geloof alleen niet dat AL die bedrijven wereldwijd allemaal maatwerkoplossingen daarvoor hebben.

Want wat je beschrijft over zonneschermen geldt bijvoorbeeld ook voor gordijnen qua meerprijzen en waarschijnlijk ook voor tegelzetters en pvc boeren.

Sterker nog, ik denk dat stuksprijzen slechts een heel klein deel van retail business behelzen.

[Mellow Jack]

Hoewel ik het je gun klinkt jou uitleg niet echt als maatwerk. Mijn ervaring is, iig in de ERP wereld, dat bedrijven eigenlijk allemaal hetzelfde zijn maar liever hun software aanpassen naar hun eigen inefficiente manier van werken.

Heb meerdere implementaties gedaan, veel complexer dan jou voorbeeld, terwijl ik besefte dat ze hetzelfde hadden kunnen bereiken vanuit de software.

[dasiro]

zijn punt is: het wérkt al volledig in excel, dus hij was bang dat VBA volledig werd geblokkeerd waardoor macro's onbruikbaar zijn en hij naar andere oplossingen moest gaan zoeken die op maat gemaakt moesten worden voor zijn bedrijf. Er zijn 1001 verschillende pakketjes voor dit soort dingen, maar dat wil niet zeggen dat ze out-of-the-box direct inzetbaar zijn.

[supersnathan94]

Uiteraard. Maar ik weet vrij zeker dat het voor het MKB goedkoper is om niet naar maatwerk oplossingen te grijpen, maar eerder naar proces standaardisatie op basis van bestaande processen die anderen ook al succesvol toepassen.

Ik had mijn facturatiesysteem ooit ook in excel. En dan ook nog bijna volledig handmatig. Schoot niet echt op.

[LOTG]

Ik vraag mij 9/10 keer af waarom het überhaupt maatwerk moet zijn en waarom alles aan elkaar gemacrod is.

Er zijn zat off the shelf oplossingen die alles doen wat je nodig hebt en dan krijg ik weer een opdracht om het wiel opnieuw uit te vinden want wij willen het anders doen.

Met de verwachting dat je in een maandje wel even een maatwerk oplossing maakt wat exact het zelfde doet als een applicatie waar jaren aan development tijd in zit.

[MC trouble]

Inderdaad ja!

Ik heb meerdere product configurators gemaakt voor bedrijven die van heel veel macro's afhankelijk zijn. Was even bang dat ik mijn klanten moest vertellen dat ze hun office niet meer mogen updaten oid.

[FPSUsername]

Zou er geen add-on gemaakt kunnen worden, zoals Kutools. Ik had ergens gezien dat je met deze tools bijv. worksheets van naam kan wijzigen door middel van velden in een andere worksheet. Dit is bijv. een feature dat je anders via een macro moet doen.

[Frituurman]

Dit lijkt me een beetje op trollen, maar hoezo? VBA code en macro's zijn bij uitstek functionaliteiten die zich goed lenen voor spreadsheets e.d. en vergemakkelijken vaak bepaalde repetitieve taken, leveren gebruikersgemak, etc. Waarom zou je een functionaliteit die geboden wordt (en die je helpt!) niét horen te gebruiken?

[jvo]

Tja, je kan er in Excel bijvoorbeeld ook een eigen functie mee definiëren. Lijkt me niet dat je dan meteen verkeerd bezig bent. Het zou in mijn ogen handiger zijn om de VB code in een sandbox te draaien in plaats van deze alles of niets discussie.

[Verwijderd]

Deze 'discussie' gaat al meer dan 10 jaar en gezien de bakken met legacy code gaan ze het niet fixen. De sandbox methode is al lang geprobeerd en gefaald. Feit is gewoon dat verborgen uitvoerbare code in een bestand wat niet een uitvoerbaar bestand had moeten zijn, een slecht idee is...

Documenten zijn documenten, uitvoerbare bestanden zijn uitvoerbare bestanden. Wie denkt dat die twee combineren een goed idee is is een beveiligingsrisico

[Ablaze]

Html is ook een document maar kan eveneens uitvoerbare code bevatten. Met een sandbox die niet gefaald is

[Verwijderd]

HTML is statisch, je praat over JavaScript of server-side code. En de sandbox in browsers faalt regelmatig. Daarom updaten browsers ook zo vaak. Browsers zijn daarnaast ook een groot doelwit al is het bij lange na niet zo’n valkuil. Mede vanwege het updaten maar ook omdat steeds meer front-end developers kiezen voor een framework dat de code omzet in, jaja, html code wat ondermeer security sterk verbeterd.

Je kunt meer een match vinden in Adobe Flash. Ook zo’n gedrocht en beveiligingsdrama waar we al lang en breed afstand van hebben gedaan.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:11]

[MC trouble]

Ik heb eigenlijk geen idee hoe groot het risico is van bijvoorbeeld een macro die sheets archiveert en inleest. Dit is bij klein productie bedrijf dat een .RDP server waar een paar verkopers en werkvoorbereiders op werken.

[Verwijderd]

Zolang je het maar goed afsluit tot die specifieke macro locatie en de organisatie aangeeft eens verder te kijken. Als je moderne werkplek krijgt dan moet je daar tot afscheid van nemen.

Zulke functionaliteit zit ook al ingebouwd in bijvoorbeeld Office 365. Daar kun je per cel de wijzigingen terug zien.

[Verwijderd]

Goede verduidelijking, ik zou er nog een willen toevoegen:
Systeembeheerders, faseer en schakel macro's uit in je omgeving.

Er is een reden voor de opmerking 'Beveiligingsonderzoekers juichten de beslissing destijds toe'.
Macro's zijn simpelweg niet meer van deze tijd (al heel lang niet), zijn een essentieel onderdeel van veel vormen van malware (zoals crypto malware) en moderne oplossingen hebben niet de enorme beveiligingsproblemen die macro's introduceren.

Als je hiervan afhankelijk bent, geef in de organisatie aan dat dit er uit gaat en dat de organisatie bezig moet met de vervanging van deze functionaliteit. Laten we er hier geen Internet Explorer situatie van maken dat organisaties nog jarenlang met legacy ellende zitten. Ik zie veel mensen opmerkingen maken zoals 'Godzijdank' maar realiseer je dat je onderdeel bent van het probleem, niet de oplossing

[P_Tingen]

Niks mis met macro's, maar alles heeft zijn plaats. We kennen de voorbeelden van over-de-top macro misbruik, maar - mits juist gedoseerd - is er juist niks mis met een macro. Op het moment dat een macro te groot wordt, wordt het tijd om te kijken naar een betere manier, maar tot die tijd is het een prima smeermiddel voor situaties waarin een gestructureerde oplossing te duur is.

[Verwijderd]

We kennen de voorbeelden van over-de-top macro misbruik, maar - mits juist gedoseerd - is er juist niks mis met een macro.
Er valt hier niets te doseren, dat is het probleem. Er is geen rechten structuur, er zijn geen gematigde macro's. Wanneer je macro's toestaat dan leg je jezelf volledig bloot of helemaal niet.

maar tot die tijd is het een prima smeermiddel voor situaties waarin een gestructureerde oplossing te duur is.
Dat is vaker een leugen dan de waarheid. Wie gaat die macro onderhouden? Wie garandeert dat deze in de toekomst probleemloos werkt? Ze zijn een gevaar voor de organisatie op vele manieren.

Kort door de bocht zijn macro's gewoon zelf geschreven ongedocumenteerde niet-onderhouden stukken software. Zelfs een upgrade van Office (waar ze op draaien) kan ervoor zorgen dat alles omvalt of erger niet meer goed functioneren zonder dat iemand het in de gaten heeft.

[matroosoft]

Ik heb een aantal VBA tools ontwikkeld die in ons kleine team afgelopen paar jaar ruim 40.000x gebruikt zijn, die hebben ontzettend veel tijd bespaard. De code is goed gedocumenteerd en ik heb ruim 80 updates uitgebracht. De tools worden nu vervangen door een maatwerk oplossing.

Budget en knowhow voor een maatwerk oplossing was er destijds niet dus dat had voor ons jarenlang veel extra werk gekost wat bovendien foutgevoelig was. Nu hebben we een prima tussentijdse oplossing gehad die ons bovendien de knowhow heeft gegeven wat we precies willen hebben in de maatwerk oplossing.

VBA kan echt heel handig zijn als je het op de juiste manier gebruikt.

[Verwijderd]

VBA kan echt heel handig zijn als je het op de juiste manier gebruikt.
Snap ik, uiteraard. Het is een fantastische oplossing geweest en heeft veel werk bespaart. Het heeft misschien wel mensen over doen stappen naar programmeur. Maar het is al jaren dood en wordt helemaal niet meer bijgewerkt of ontwikkeld. Er is hier geen polsslag meer te bekennen. Een interessant verhaal wat ik gisteren nog las: https://www.thespreadsheetguru.com/blog/are-vba-macros-dead

Het beschrijft heel goed (met voorbeelden) de status van macro's maar hou echter in gedachte dat dit verhaal ook alweer 3 jaar oud is en niet up2date is met de huidige uitfasering meldingen van Microsoft. Hij had wel een voorspellende blik met het jaar 2022.

[qlum]

Het probleem is niet macro's in bestanden die je eigen bestanden, maar door dat macro's standaard aan staan is het wel relatief eenvoudig om malware binnen te kreigen. als er in de beilage een exe staat weet je meteen dat dit geen factuur is, dit maakt een excelbestand met een macro zo gevaarlijk. Extra / standaard blokkeren helpt hier tegen.

[Rinzwind]

Ze zijn van alle tijd om geavanceerde maatwerk stappen uit te voeren op Office documenten. Juist een sterk pluspunt als je weet waar je over praat. Dat valt niet uit te faseren. Je kunt de automatisering hoogstens verplaatsen en daarmee het risico. Wat wel helpt, is om automatische processen niet zomaar te laten uitvoeren, dat geldt net zo goed voor een batch file of eender ander programmatisch bestand.

[Verwijderd]

Ze zijn van alle tijd om geavanceerde maatwerk stappen uit te voeren op Office documenten.
Uitvoerbare code in documenten verstoppen is niet van deze tijd. Het komt uit een tijd dat security niet belangrijk was. Als het van deze tijd was, dan hadden moderne werkplek oplossingen zoals Google docs en Word online hier ook wel ondersteuning voor ingebouwd.

Juist een sterk pluspunt als je weet waar je over praat.
99,999999% van office gebruikers weet niet waar je over praat.

Dat valt niet uit te faseren.
Dit is prima uit te faseren, dat doet Microsoft nu. Er zijn ook toolkits, GPO's en configuratie opties zat om dit uit te faseren. Het kost alleen tijd en moeite.

Je kunt de automatisering hoogstens verplaatsen en daarmee het risico.
Dus het uitschakelen van een primaire aanval factor is 'hoogstens risico verplaatsen'?

Wat wel helpt, is om automatische processen niet zomaar te laten uitvoeren, dat geldt net zo goed voor een batch file of eender ander programmatisch bestand.
Aha, dus macro's zijn prima als je ze maar niet automatisch uitvoert...

dat geldt net zo goed voor een batch file of eender ander programmatisch bestand.
Batch files en executables worden bij iedereen standaard geblokkeerd via email. Tevens moeten uitvoerbare bestanden digitaal ondertekend worden anders worden ze geblokkeerd. Maar je fout hier is dat je een uitvoerbaar bestand vergelijkt met een bestand dat geen uitvoerbare code zou moeten bevatten. Het is namelijk een document..... Macro's zijn verborgen code.. dat kunt je niet goedpraten want geen enkele eindgebruiker snapt dat. Tevens leer je de eindgebruiker beveiligingswaarschuwingen negeren... wat ook een ramp is... Ten minste, ik hoop dat het niet nog erger is en alle uitvoerbare code gewoonweg toegestaan is....

[mkllrpim]

Misschien nog een goede toevoeging is dat je in Google Sheets prima uitvoerbare code kan stoppen in de vorm van Apps Script. Het grote probleem van Macro's is dat het op een locale machine draait, en daarmee kwaad kan op de machine. Code 'in de sheet' uitvoeren met alleen access tot de Google Sheet of specifiek daartoe gespecificeerde informatie binnen Google Cloud lost 1:1 de huidige uitdagingen op die Macro's achter laten, maar dan zonder het security risico. Ik kan me zo voorstellen dat voor Excel Online vergelijkbare oplossingen bestaan.

[Finraziel]

Dus dan gooien we maar functionaliteit weg omdat het veiliger is?

[Verwijderd]

Dus dan gooien we maar functionaliteit weg omdat het veiliger is?
Je verdraait woorden:
Dus we gooien maar functionaliteit weg omdat deze niet veilig is?

Ja. Waarom denk je dat Microsoft dit anders zou doen? Ze willen echt niet gebruikers pesten maar weten ook dat dit niet te fixen is of ooit in een moderne werkplek zal passen.

[GekkePrutser]

De vraag is, zien ze dan bestanden uit cloudopslag als 'van internet'? Ik neem aan van wel.

Op het werk gebruiken we cloud opslag (box.com) en de meeste mensen gebruiken de webclient omdat de sync client echt een draak van een ding is.

Niettemin juich ik het einde van macro's wel toe hoor, daar niet van. Op zich zijn macro's niet eens slecht overigens, maar het probleem is dat je er veel te veel mee kan. DLL's aanroepen in het hele systeem, allerlei onzin die niks met een spreadsheet te maken heeft. Een van de naieve acties van Microsoft uit begin jaren '00 tijdens hun fase dat ze het internet wilden veroveren, net als ActiveX (wie zou er ooit denken dat het aanroepen van DLL's op je systeem vanuit een random webpagina een slecht idee is ). En mensen die het echt nodig hebben kunnen het alsnog aanzetten.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 16:11]

[Verwijderd]

De vraag is, zien ze dan bestanden uit cloudopslag als 'van internet'? Ik neem aan van wel.
Dit wordt geregeld via een ADS property: https://www.howtogeek.com...w-can-i-easily-remove-it/

[amx]

Dat "from the internet" is tenzij ik me vergis DNS zone 3, iets dat vrij triviaal om te zetten is.

[dePannenkoekjes]

Wij werken met Google Drive en daar kwam dit probleem helaas wel naar voren, dus macros van "the internet" blokkeren is niet helemaal een goede oplossing vind ik

[divvid]

wow, ik schrok mij al te pletter. Hele analyses zou ik niet kunnen doen zonder macro's (al hebben we inmiddels een hoop al naar R geport)

[divvid]

@dieAndereGozer soms wil je geen Don Quichot spelen en de ICT molens bevechten. Dan dus maar een macro in Excel schrijven en hopen dat het proces van aanvragen van niet-standaard software geen maanden gaat duren.

Probleem met de datasets is dat die processen jaren geleden begonnen met 500 records, doorgroeide naar 30000 records (nog best te behappen in Excel), maar nu al gauw naar 600K records gaan, met telkens wijzigende kolommen en data formats (dus ook geen DB oplossing). Helaas betrof het hier medische gegevens, dus een oplossing 'buiten de muur' was geen optie.

[dieAndereGozer]

Telkens wijzigende kolommen is toch iets waar je dan met je macro's ook rekening mee moet houden, dus ik weet niet wat voor argument dat is. Verder heb je binnen de muur vast ook wel iemand die kan programmeren dan?

[divvid]

Ha, jij hebt nog nooit binnen een ziekenhuis research omgeving gewerkt. Nul budget en eigen applicaties laten auditen kost jaren
Dan is het aanpassen van een macrootje peanuts
Juiste weg? Nee! Iets met molens en vechten? Wil je niet

[MC trouble]

*of bij een klein tot middelgroot productie bedrijf gewerkt.

Voor kleine bedrijven is het volkomen kansloos en financieel niet rendabel. Een Excel sheet waar wat gegevens in genoteerd worden die vervolgens automatisch een rapport in Word maakt maken kost een paar uur, maar dit bespaard echter een paar uur per rapport.

Voor dit soort dingen een alternatieve app oid maken is op zich geen probleem, maar dan moet je voor elk klein dingetje terug naar maker.

[dieAndereGozer]

Ik werk bij een bedrijf met 100 man in dienst, klein tot middel bedrijf niet? We maken alles inhouse, in excel? Zou er niet aan moeten denken.

@divvid

Toevallig heb ik daar wel een paar jaartjes versloft, juist bij research maakte we alles zelf, in matlab.

[MC trouble]

Ik heb het over een bedrijf waar 8 man op kantoor zit en 20 in de buiten dienst.

[dieAndereGozer]

Bij zo'n bedrijf ooit stage gelopen. Die maakte ook alle software inhouse.

[MC trouble]

Dat gaat de mensen hier zonder enige twijfel niet lukken. Ik denk dat overigens geld voor een groot deel van de productie, bouw en installatie bedrijven in Nederland

[dieAndereGozer]

Dan hoop ik dat ze in de risicoanalyse hebben meegenomen wat het gaat kosten wanneer(niet als) het fout gaat. Anders ben je zo failliet.

[ArawnofAnnwn]

Jammer. Toch maar eens gaan kijken of we alles kunnen laten werken in een ander office pakket. Ik zal eens gaan testen met OpenOffice, die kan, voor zover ik weet, goed overweg met VBA.

[biteMark]

Misschien is dit het moment om te overwegen of VBA iets is wat je moet willen. Ik begrijp dat het handig kan zijn in sommige gevallen maar soms is er een betere oplossing. Behalve dat VBA potentieel behoorlijk gevaarlijk is, is het een uitstervende taal. Ontwikkelaars die de boel moeten onderhouden zullen steeds schaarser worden en de meeste programmeurs zullen het niet eens willen gebruiken:

• de editor is verschrikkelijk (ik durf het geen IDE te noemen);
• debugging is een drama (errors zijn onduidelijk en worden ergens onderaan de call stack gegooid waardoor de oorsprong van een error bijna niet te vinden is in een grote code base);
• versiebeheer? Nope! De VBA code wordt met een rare encoding en embedded in het document opgeslagen. Je kan het document wel in versiebeheer zetten maar daarmee zie je nog niet welke veranderingen er zijn aangebracht in welke commit/check-in, je enige optie is alle bestanden exporteren naar een mapje en die in versiebeheer zetten;
• de toekomst is onzeker, de runtime (msvbvm) is ontwikkeld voor Windows 98(!) en hooguit onderhouden zodat het werkt op moderne Windows versies, het is heel goed mogelijk dat MS op een dag de stekker eruit trekt. Als ontwikkelaar wil je daar niet op inzetten.

Er zijn alternatieven, zo is het heel goed mogelijk om in C# een programmaatje te ontwikkelen waarmee bewerkingen uitgevoerd kunnen worden op Office documenten. De offciële OpenXML SDK is open source en als je dingen met spreadsheets wil doen is ClosedXML een echte aanrader. Het enige nadeel is dat je de documenten niet geopend kan hebben op het moment dat je met je C# programmaatje de bewerkingen wil uitvoeren.

Je kan het ook niet doen maar ik ben bang dat je dan vroeg of laat tegen problemen aanloopt: als Microsoft de stekker uit VBA trekt, en dat zit eraan te komen, dan moet je last-minute nog ontwikkelaars gaan opzoeken die in alle haast de boel moeten omzetten naar bijv. C#.

[!mark]

VBA/Macro's zijn geweldig en handig om kleinere dingen heel snel te kunnen automatiseren binnen een Office programma zonder meteen de overhead te hebben van het ontwikkelen van een standalone programma. Daarnaast is het ook voor mensen zonder IT achtergrond laagdrempelig genoeg om voor eigen gebruik repeterende handelingen met de Macro-recorder te automatiseren. Veel Macro's binnen bedrijven zijn gemaakt nadat een niet-IT medewerker bij de ITafdeling het verzoek heeft gedaan iets te automatiseren maar is afgewezen is op kosten/tijd (vul iets in), geeft ook wel hoe weinig resources je nodig hebt om iets bruikbaars te krijgen in VBA.

En ja de Macro-recorder genereert inefficiënte brol code welke je met een klein beetje programmeer kennis zo 100x sneller kan laten lopen als je het zelf schrijft, maar in vrijwel alle gevallen is die brol code nog steeds een veelvoud sneller dan al die zaken met de hand steeds opnieuw uitvoeren

Waar ik het wel met je eens ben is dat je vanaf een bepaalde grootte/complexiteit je beter naar iets anders kunt switchen. En juist daar is het mijn inziens een beetje mis gegaan, doordat het zo laagdrempelig is zijn dit soort eigen tools uit de hand gelopen tot iets dat veel te groot is om binnen zeg Excel te draaien maar eigenlijk gewoon een stand-alone stukje software had moeten zijn.

Om nog even in te gaan op je puntjes:
- 1. Eens, is een oude interface die 20 jaar geen update meer gehad heeft
- 2. Het kan inderdaad beter, maar voor kleine automatiseren is het goed genoeg tbh. Daar staat tegen dat als je met F8 regel voor regel door je code draait je on-the-fly je code kunt aanpassen (m.u.v. functie namen en parameters etc.), voor het debuggen op fouten in kleine projecten werkt dat prima. Als je hier tegen problemen aanloopt is je codebase mijn ziens te groot/complex aan het worden om met Macro's binnen een Office pakket te implementeren.
- 3. Met meerdere mensen tegelijk aan één VBA codebase werken is inderdaad vrijwel onmogelijk. Maar als je dat nodig hebt dan is vrijwel altijd je project qua complexiteit/grote al op het punt dat het te groot is (zie punt 2).
Embedded in het document kan juist ook weer een voordeel zijn dat alle code gewoon native in één bestand staat, ik kan jou gewoon mijn spreadsheet opsturen zonder na te hoeven denken over compileren of het feit dat andere afhankelijkheden zoals een Runtime nodig zijn om het uit te kunnen voeren op een ander systeem.
- 4. Dit is het grootste gevaar inderdaad, maar ik zie het voorlopig echt nog niet gebeuren gezien het aantal grote bedrijven die er gebruik van maken, dat is juist de grootste inkomsten voor MS.

Alternatieven met dezelfde combinatie van laagdrempeligheid(recorder en niet na hoeven te denken over compilatie en afhankelijkheden voor het kunnen uitvoeren) én mogelijkheden zijn er nog niet echt.
Officescripts komt het meeste in de buurt maar de mogelijkheden tot bijv. het bestandsysteem zijn een stuk minder dan met VBA. Daarnaast zijn Officescript (momenteel) uitsluitend te gebruiken bij een zakelijke O365 subscriptie, de hobbymatige thuisgebruik die privé wat dingen in Macro's heeft staan heeft er voorlopig niks aan dus.

[Jorritdorman]

Je slaat de spijker op de kop. Ik maak regelmatig in excel een macro om een repetieve taak makkelijker te maken. Werkt fantastisch, maar ik denk dat ik zelden een script heb van meer dan ~25 regels.

Voor complexere zaken moet je er inderdaad niet mee werken. Maar voor ff on-the-fly een snelle oplossing maken is het prima.

[GekkePrutser]

• de editor is verschrikkelijk (ik durf het geen IDE te noemen);

Ik vind hem wel aardig maar hij is geschreven in eind jaren '90. Het is gewoon een kloon van Visual Basic 6 uit 1998 met wat extra beperkingen Sindsdien is de IDE doorgegaan met Visual Basic .net maar de macrotaal VBA en de bijbehorende taal is achtergebleven en er is nooit meer wat aan de editor gedaan. Ik vind hem wel logisch maar ik heb destijds veel ontwikkeld met de 'echte' VB6 dus voor mij 'klikt' het wel. De errors zijn inderdaad stomvervelend en wijzen vaak zelfs naar de verkeerde regel, dat was bij VB6 ook zo.

Ik vraag me af wat MS nu gaat doen. Een paar jaar geleden had ik nog een nieuwe taal verwacht die wat meer aan de eisen van deze tijd zou voldoen. Maar nu met hun focus op alles op het web / cloud denk ik dat het gewoon verdwijnt.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 16:11]

[fre_]

...
en dat zit eraan te komen,
...

Lijkt me toch pure speculatie, of heb ik iets gemist?

Zal ook eens speculeren: als MS de stekker uit VBA zou trekken lijkt het me dat er veel bedrijven (misschien eerder de kleinere bedrijven die software op maat zich minder kunnen permiteren) het nut van de betalende MS Office minder hoog zullen achten en rapper geneigd zullen zijn om over te stappen naar gratis alternatieven.
Aangezien Office toch een belangrijke bron van inkomsten vormt voor MS, zal dat volgens mij niet gebeuren.

[HansvDr]

Alsof Office 2019 opeens niet meer werkt. Het enige wat MS hiermee voor elkaar kan krijgen is dat bedrijven office niet meer van updates voorzien.

[biteMark]

Yep, is pure speculatie.

[DrVic]

Voor mij is C# niet echt een alternatief, ik ken die taal niet en om nu iets volledigs nieuws te leren voor het automatiseren van een paar excel sheets…

[Erazher]

Microsoft zei in februari dat macro's standaard geblokkeerd zouden worden en dat gebruikers die alleen nog konden inschakelen door in de eigenschappen van het bestand macro's toe te staan.

Je kan de scripts nog steeds gebruiken, ze willen een mogelijk aanval stoppen om het standaard uit te zetten.

[Morelleth]

Klinkt bijna als dat standaard het als een .xlsx save voor Excel wordt geopend zodat macro's niet meer werken. (ookal is het een .xlsm)

Idem voor de andere office programma's.

En externe files moeten wellicht eerst worden omgezet?
Of via een optie geaccepteerd worden te mogen openen. (als in externe bronnen vertrouwen)

Edit: Uitleggen is nog een vak apart. Dus gepoogd het te verduidelijken.

[Reactie gewijzigd door Morelleth op 22 juli 2024 16:11]

[aadje93]

Macro's kun je niet opslaan in xlsx....

[Morelleth]

Snap ik.
Ik kan duidelijk niet uitleggen wat ik bedoel.

Maar gelukkig ben ik niet degene die het uit werkt.

[Room42]

Ik weet niet of OpenOffice dan een betere keuze is dan LibreOffice. Voor zover ik weet is de ontwikkeling van OO redelijk stil komen te vallen na de fork naar LO maar ik heb me in OO niet meer verdiept.

[mjtdevries]

Zodat je dan hetzelfde risico in OpenOffice hebt.
Wat heb je dan opgelost?

Het probleem is niet het office pakket. Het probleem is de eindgebruiker.

[jpfx]

En in het verlengde daarvan zijn Macro's en scripts niet het probleem, maar de eindgebruiker.

[CybernDystopia]

*LibreOffice

Kijk ook eens naar de mogelijkheden van Python Macro's in LibreOffice, van daaruit waarschijnlijk ook een stuk makkelijker groeien naar een gedegen applicatie, daar Python ook niet vies is van C libraries

[Reactie gewijzigd door CybernDystopia op 22 juli 2024 16:11]

[DeCo]

Wat is de use case om malware mogelijk te maken in VBA script binnen Office? Ik bedoel.. waarom zou VBA script niet zodanig af te schermen en in te perken zijn, dat malware technisch niet meer mogelijk is en VBA binnen Office dus geen potentieel gevaar meer oplevert? Moet ik dan denken aan het automatisch ophalen van data elders, om dit weg te zetten in Office documenten?

[TwiekertBOB]

Met VBA kun je eigenlijk alles.

Zo kun je bestanden laden en opslaan op de harde schijf of het netwerk. Je kunt een webservice aanroepen. Je kunt zelfs met een shell functie het register benaderen (mits de gebruiker afdoende rechten heeft).

[Bas170]

Mails opstellen en direct versturen, zonder dat de gebruiker het verzonden ziet worden

[sprankel]

De malware zit bijna nooit in de VBA, meestal krijg je iets in de trend van een "factuur" met een knop die doet alsof je erop moet drukken om de zogenaamde factuur te kunnen zien. Daar zit dan vrij eenvoudige VBA code achter die kijkt wat voor machine het is en welke payload geschikt is (afhankelijk van welke updates zijn geinstalleerd, java wel/niet, etc). Vervolgens word de payload gedownload en het is pas dan dat de malware naar boven komt.

Je zou VBA in een container kunnen steken en niet toelaten om externe files te benaderen maar als VBA zuiver in Excel zaken mag doen haal je het bestaansrecht van VBA min of meer onderuit. Vergeet ook niet dat als je op dat niveau begint dicht te timmeren, je zit met veel VBA code die iemand ooit geschreven heeft maar die persoon is al lang weg.

Kan je wel zeggen dat bedrijven maar hun zaken op orde moeten stellen, die bedrijven worden beheerd door non Tweakers waarvan ik sommige in staat zie juridische stappen te nemen tegen Microsoft als hun processen niet meer werken omdat MS iets veranderd heeft.

Een tussenoplossing is het signen van VBA code maar dat zou veel meer user friendly moeten zijn, gewoon signen met je AD account in plaats van te beginnen vragen achter certificaten, end users die VBA schrijven snappen daar niets van.

[Finraziel]

Maar ze gooien het nu toch ook dicht? Als ze dat nu doen zouden ze volgens mij toch ook het zo kunnen doen dat vba niet buiten het eigen document mag komen.

Mijn eigen scripts werken alleen binnen het document en zouden gewoon blijven werken terwijl dat nu maar de vraag is. Waarom het dan geen bestaansrecht zou hebben zie ik niet, je kunt alsnog heel veel meer dan als je alleen maar met Excel functies kan werken.

[Verwijderd]

je zit met veel VBA code die iemand ooit geschreven heeft maar die persoon is al lang weg.
Ik heb een keer een fileserver moeten migreren... Daarop stonden honderden access databases die via macros gegevens ophaalden via vaste padden. Niemand in de hele organisatie snapte ook maar iets van de code of waarom dit complexe spinnenweb gebouwd was. Toen ze een Office upgrade uitvoeren viel alles in duigen. De databases werden bij de eerste keer openen geupgrade en dat zorgde voor corruptie in access databases die nog niet geupgrade waren (of anders om).

Het heeft de organisatie tonnen gekost om die bende uit elkaar te trekken.

[qlum]

Dat is leuk, tot dat je bedenkt dat een belangrijke reden om VBA te gebruiken is om te verbinden met externe bestanden / data.

[Luminair]

Op zich begrijpelijk, omdat een scripting taal toch een groot beest is om te onderhouden binnen een platform, maar hiermee beperkt Microsoft echt wel de mogelijkheden binnen Office.

Gerelateerd: Weet iemand hoe je anders RegEx (dus niet de neppe versie) kunt gebruiken in Office?

[Yggdrasil]

VBA scripting wordt niet verwijderd, alleen wordt het inschakelen wat moeilijker gemaakt dan voorheen. Je moet het nu in de documenteigenschappen inschakelen i.p.v. in de toolbar waar mensen iets te snel op klikten. Het is een enorme vector voor aanvallen dus ik kan me hier best in vinden.

[Verwijderd]

Reken er maar op dat deze verwijderd gaat worden. Probeer het maar eens in te schakelen in Excel online..... Het gaat alleen heel lang duren net zoals Internet Explorer.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:11]

[SinergyX]

Daar is nu toch die xlsm versie voor gemaakt? Zolang je die wel gewoon (gezien het bestand) kan openen zonder blokkade, vind ik alles prima, ik gebruik meer dan genoeg VBA scripts in excelsheets (maar ook Word) voor wat simpele toevoegingen/tools.

[Mickman]

Dan zou je die zaken wellicht kunnen signen en je Office beveiligingsinstellingen daarop aanpassen.

[JustFogMaxi]

Helemaal in lijn met Powershell/VSCode en VisualStudio. Daar kun je ook niet zomaar gedownloade code draaien, deze moet je eerst trusten. Top.

[RoestVrijStaal]

Op den duur gaat zo'n workflow-blokkade erg irriteren, waardoor een catch-all-uitzonderingsregel of het uitvinken erg aantrekkelijk is.
Voor beginnelingen snap ik het wel, maar voor degenen die weten wat ze doen™ is het enkel irritant.

[GekkePrutser]

En mensen die niet weten wat ze doen, weten ook niet hoe ze die code moeten controleren en drukken toch wel op ja.

Ik zie het meer als een manier voor MS om zichzelf in te dekken tegen klachten dan een serieuze oplossing.

Sowieso moet je als ontwikkelaar gewoon weten wat je doet. Dat is je werk.

[RoestVrijStaal]

Klopt.

De safe.directory instelling van git is ook zo'n leuke "feature"

[DefaultError]

Je zou toch willen dat half het land niet standaard z'n office documenten heen en weer stuurt. Dat voorkomt een actieve macro in je OS.

Worden bij cursussen de mensen voorgelicht om naast het promoten van MS Office ook instructies te geven om standaard de bron bestanden mee te sturen?

Een beetje leesbaarheid begint met de bestanden om te zetten naar een pdf. Dit is over de hele linie beschikbaar, Linux, Mac, en Windows.

[0vestel0]

PDF is in principe een executable en ook niet zonder gevaar. Nooit zomaar een PDF openen.

[mjtdevries]

Standaard staan macros al uit.

Het probleem is dat er teveel domme gebruikers zijn die macros activeren als een verdacht mailtje vraagt om dat te doen.

Dus willen ze dat nu moeilijker maken.

(en dat heeft geen zier te maken met office of pdf. Als je het van een onbekende bron krijgt zou het geen executable code moeten kunnen draaien. Maar PDF zit daar ook vol mee)

[DefaultError]

Volgens mij zijn pdf’s te zegelen, certificeren, zodat de afkomst is te herleiden.

[mjtdevries]

Dat kan je ook bij Office macros doen, maar in de praktijk extra werk wat vrijwel niemand doet.

[MazDaMan1970]

Dat heeft tijd nodig & training. Met 365 is het delen van documenten een stuk gemakkelijker geworden, maar daar moet je de mensen wel op wijzen, aangezien velen nog de "ouderwetse" file/mail-server werkwijze gewend zijn.

[DefaultError]

En je hebt een outlook account nodig, nou ja, er is een lage drempel om in te stappen.

[grimlock]

Het zou mooi zijn als het artikel duidelijk zou omschrijven dat dit niet gaat om trusted VBA macro's. Toch?

[SunnieNL]

Nee gaat om untrusted locations...
Dus documenten gedownload van untrusted locaties op het internet (anders zouden we ineens onedrive, sharepoint en teams blokkeren) of van de untrusted zone in je netwerk (waar het internet al jaren onder valt).

Je kunt het ook makkelijk omzeilen door de properties van een bestand te openen en dan het vinkje te zetten bij 'unblock'. Dus veel gaat dit ook niet helpen, maar het is een kleine extra beveiligingstap.

Beter schakel je in dat alleen ondertekende macro's worden gestart, maar dat brengt natuurlijk wat werk met zich mee in het ondertekenen van alle macro's en het distribueren van het certificaat naar alle endpoints.

[Reactie gewijzigd door SunnieNL op 22 juli 2024 16:11]