Outlook-macro overleeft de nacht niet

[P_Tingen]

Situatie:
Bij de klant waar ik zit komen de orders binnen per email. Via postvak-in regels worden de orders van klanten verplaatst naar de folder "Orders". Dat triggert een VBA macro die de bijlage van de mail in een map op het netwerk zet, de mail als gelezen markeert en vervolgens verplaatst naar de map "Archief". Onze ERP applicatie pakt de bewaarde bestanden weer op.

Dit systeem draait al jaren prima, maar omdat we tegenwoordig al heel vroeg orders krijgen, hebben we besloten de mail-pc aan te laten staan 's nachts. Als er dan orders komen voor 7 uur, dan worden ze door het systeem opgepakt, zo is het idee.

Dit proces draait de hele dag goed, maar blijkt de nacht niet te overleven. Outlook draait 's morgens nog prima en laat ook geen foutmeldingen zien. De mails worden nog steeds verplaatst naar de Orders map, maar verder gaat het niet; de bijlagen worden niet op schijf bewaard en de mail is ook niet als gelezen gemarkeerd. Het lijkt alsof de macro het gewoon niet doet. Outlook herstarten en de macro doet het weer en verwerkt alsnog de mails, maar dat was natuurlijk niet het idee hierachter.

Mijn vraag:
Enig idee wat hier aan de hand is of waar ik moet zoeken?

Relevante software en hardware die ik gebruik
Outlook 2013 via Citrix op Windows Server 2012R2
De macro in kwestie is te zien op GitHub

Wat ik al gevonden of geprobeerd heb
- de macro's doorgekeken op gekke dingen
- pc opnieuw gestart
- half internet afgestruind op termen als "outlook macro stops overnight"

[Croga]

Mijn eerste gedachte zou zijn een issue met het opslaan van de bijlagen.

Om maar eens wat ideëen te bedenken;
- Schijven achter de netwerk share zijn spinned down waardoor de response tijd te lang is en de macro af breekt
- Toegang tot de schijven heeft een tijds-beperking
- Inlog van de gebruiker waaronder het script draait is timed-out waardoor de macro een time-out krijgt

Allemaal zaken die je overdag niet gebeuren omdat je continue aan het werk bent.

[Oon]

Dus concreet; de macro lijkt uitgeschakeld te worden op zo'n manier dat het niet zichtbaar is in Outlook?

Ik zou eens kijken of het niet is opgelost met task scheduler door Outlook eens per 4 uur ofzo te laten herstarten.


Een mooier alternatief is vanuit een server gewoon via IMAP de juiste map uitlezen en het direct vanuit de mail verwerken, zodat je nooit een client PC aan hoeft te laten staan.

[P_Tingen]

Croga schreef op donderdag 10 maart 2022 @ 08:57:
Mijn eerste gedachte zou zijn een issue met het opslaan van de bijlagen.

Om maar eens wat ideëen te bedenken;
- Schijven achter de netwerk share zijn spinned down waardoor de response tijd te lang is en de macro af breekt
- Toegang tot de schijven heeft een tijds-beperking
- Inlog van de gebruiker waaronder het script draait is timed-out waardoor de macro een time-out krijgt

Allemaal zaken die je overdag niet gebeuren omdat je continue aan het werk bent.

Schijven: zou kunnen, maar er draait van alles 's nachts en uiteindelijk komt alles bij 1 set met schijven terecht. daarnaast, als dit het is, zou het op een zeker moment toch ook weer moeten werken als de schijven op snelheid zijn.

Toegang: niet van toepassing voor zover ik weet, toegang wordt alleen met login/ww geregeld, zonder verdere beperkingen.

Inlog: alles werkt nog 's morgens, ook de ERP applicatie zelf (die doet nml de verwerking van die orders)

[P_Tingen]

Oon schreef op donderdag 10 maart 2022 @ 08:57:
Dus concreet; de macro lijkt uitgeschakeld te worden op zo'n manier dat het niet zichtbaar is in Outlook?

Correct

Ik zou eens kijken of het niet is opgelost met task scheduler door Outlook eens per 4 uur ofzo te laten herstarten.

Krijg je met een task scheduler niet dat je elke 4 uur een Outlook erbij krijgt, dus 6 Outlook instances per dag?

Een mooier alternatief is vanuit een server gewoon via IMAP de juiste map uitlezen en het direct vanuit de mail verwerken, zodat je nooit een client PC aan hoeft te laten staan.

Verhuizen naar de server is wel waar we nu over nadenken maar we hebben het druk zat, dus op hele korte termijn gaat ons dat niet lukken. Sterker nog, we hebben wel meer van dit soort zaken die eigenlijk in een scheduler moeten draaien in ons ERP systeem (eigen software) en die gaat er wel komen, maar zoals gezegd niet deze maand.

[ Voor 16% gewijzigd door P_Tingen op 10-03-2022 09:06 ]

[Mint]

Kun je logging inbouwen in je script en die ergens wegschrijven naar een logfile? Op die manier kun je zien of het script zelf mis gaat.

Wilde gok: die mapped drive op Y is 's nachts misschien even niet (op tijd) beschikbaar is in de nacht (backups oid?) en je script gaat onderuit.

[Oon]

P_Tingen schreef op donderdag 10 maart 2022 @ 09:05:
[...]

Krijg je met een task scheduler niet dat je elke 4 uur een Outlook erbij krijgt, dus 6 Outlook instances per dag?

Nouja, je zou er een bash scriptje van kunnen maken dat eerst Outlook killt, 30 seconden oid wacht (zodat die netjes z'n verbinding met de server kan afsluiten) en dan weer start.

[Lustucru]

Meest logische verklaring is dat die windows server / citrix sessie op een zeker moment in hybernate gaat. Daar merk je weinig van 's-ochtends. Zodra je probeert verbinding te maken met de terminal server, schrikt het ding wakker en alles doet het weer, maar ondertussen heeft hij wel een paar uur zo goed als uit gestaan.

[DVX73]

Is het mogelijk om dit script om een ander device te draaien en niet op een Citrix server?
Mogelijk dat iets is de Citrix server ervoor zorgt dat deze na een aantal uur wordt gestopt.

Ander attentiepuntje is dat Outlook 2013 en Windows Server 2012R2 volgende jaar end of life zijn, dus investeren in een toekomstbestendige oplossing is geen gek idee.

[Brahiewahiewa]

P_Tingen schreef op donderdag 10 maart 2022 @ 08:53:
... De mails worden nog steeds verplaatst naar de Orders map, maar verder gaat het niet; de bijlagen worden niet op schijf bewaard en de mail is ook niet als gelezen gemarkeerd...

?? Maar je weet toch wel hoe je vbscript moet debuggen? Gewoon die vbs file pakken en elke regel laten volgen door een regel waarin alle parameters worden weggeschreven naar een log-file. Ja, vreselijk tijdrovend process maar dat roep je over jezelf af als je vbscript gaat gebruiken. De meeste automatiseerders hebben dat in de jaren '90 afgeleerd

[nextware]

Als ik het zo lees lijkt het erop dat het verplaatsen van de mail een Outlook regel is, maar het verder verwerken gebeurd door dat VBA-script.

Ik zou de oorzaak gaan zoeken in de betreffende Citrix omgeving (session timeout, etc).

Of kijken of je deze handeling op een apart systeem (dus buitenom Citrix) kunt laten uitvoeren.

[P_Tingen]

Lustucru schreef op donderdag 10 maart 2022 @ 10:57:
Meest logische verklaring is dat die windows server / citrix sessie op een zeker moment in hybernate gaat. Daar merk je weinig van 's-ochtends. Zodra je probeert verbinding te maken met de terminal server, schrikt het ding wakker en alles doet het weer, maar ondertussen heeft hij wel een paar uur zo goed als uit gestaan.

Dit klinkt inderdaad als een logische verklaring, zal eens overleggen met de systeemmannen.

DVX73 schreef op donderdag 10 maart 2022 @ 11:06:
Ander attentiepuntje is dat Outlook 2013 en Windows Server 2012R2 volgende jaar end of life zijn, dus investeren in een toekomstbestendige oplossing is geen gek idee.

Nieuwe servers zijn besteld, met - naar ik hoop - een iets nieuwere Outlook erbij.

Brahiewahiewa schreef op donderdag 10 maart 2022 @ 12:48:
?? Maar je weet toch wel hoe je vbscript moet debuggen? Gewoon die vbs file pakken en elke regel laten volgen door een regel waarin alle parameters worden weggeschreven naar een log-file. Ja, vreselijk tijdrovend process maar dat roep je over jezelf af als je vbscript gaat gebruiken. De meeste automatiseerders hebben dat in de jaren '90 afgeleerd

Probleem is waarschijnlijk dat de macro het wel doet als ik hem handmatig 's morgens herstart (ga ik morgen proberen) dus uitgebreide logging inbouwen gaat me denk ik niet veel helpen. De macro gaat domweg niet af. En voor wat je wijze les betreft over het gebruik van vbscript: dank, ik zal het doorgeven.

nextware schreef op donderdag 10 maart 2022 @ 13:30:
Als ik het zo lees lijkt het erop dat het verplaatsen van de mail een Outlook regel is, maar het verder verwerken gebeurd door dat VBA-script.

Ik zou de oorzaak gaan zoeken in de betreffende Citrix omgeving (session timeout, etc).
Of kijken of je deze handeling op een apart systeem (dus buitenom Citrix) kunt laten uitvoeren.

Zit in de planning....

[Piebas]

Herstart de pc een voor iedereen naar huis gaat, kijk of het dan wel doorloopt....

[Tylen]

Niet op je xenapp server draaien maar gewoon op een normaal werkstation. Ik kan mijn voorstellen dat die xenapp servers elke dag/om de dag sowieso herstarten.

[Killah_Priest]

Outlook icm automation zijn een zeer slechte combinatie (sowieso zijn rules client-side afhandelen af te raden als betrouwbaarheid belangrijk is).
Zoals al eerder geopperd is: schrijf/bouw iets om de mails direct in te lezen en af te handelen zonder gebruik te maken van Outlook.
Of je nou Pop3 (yuck), IMAP of Exchange Web Services gebruikt (mocht het om Exchange gaan), je script direct laten verbinden, mails ophalen en verwerken werkt veel betrouwbaarder ipv Outlook als zwakke schakel ertussen plaatsen.

(Ik heb in het verleden veel automation gedaan mbt Exchange dmv EWS icm Powershell of soms een service welke ik in C# bouw. Dit werkte in alle gevallen vele malen sneller en betrouwbaarder als outlook client side rules icm vbs. Tevens is vbs tegenwoordig een redelijk dode taal)