Trigger van een self startende service achterhalen

[MC trouble]

Beste allemaal,

Hoe kan ik achterhalen waardoor een service gestart/getriggerd wordt?

Ons huidige ERP systeem heeft een nare bug die leid tot afspraken die visueel wel in de planning komen te staan, maar die vervolgens niet verwerkt wordt in de PDA's/tablets. Dit gebeurt bij een paar services wanneer die data verzenden tijdens het verslepen van een afspraak.Dit komt pas aan het licht wanneer de planning vernieuwd wordt... of wanneer de monteur niet op zijn afspraak verschijnt.

De Autodesk Vault, iets van Solidworks en ik geloof de printer wachtrij service staan op handmatig. Als ze niet actief zijn hebben we geen problemen . Start de planner één van de bijhorende programma's dan start de service alsnog.

Nu is er één service waar we niet zonder kunnen en krijg hem niet onder controle: Microsoft Office Click-to-Run (OCTR)



Deze service start zichzelf zonder dat er een Office programma gebruikt is. De service staat binnen een uur na het opstarten aan en binnen 2 uur nadat de service handmatig gestopt is.

Alle hulp wordt zeer gewaardeerd

Koen.


Wat we zover geprobeerd hebben (dit probleem is al maanden bekend):

- De service helemaal blokkeren kan niet, want dan werkt Office niet meer
- Office 365 help chat kon niet helpen want OCTR hoort altijd aan staan
- In de Windows logboeken kan ik niets terug vinden over de start van een service
- Microsoft forum doorgespit en een topic gestart, maar (nog) geen resultaat:https://answers.microsoft...b?tm=1583324661195&auth=1
- Het ERP systeem is uitgefaseerd en de leverancier heeft de bug proberen te verhelpen, maar kan/wil niets doen (de implementatie van Ridder IQ is gestart, maar dat duurt nog minstens een jaar)
- Een snelkoppeling laten maken die de service start en stopt: https://superuser.com/que...blestop-any-windows-servi
- De OCTR service kladblok laten starten zodat we weten wanneer OCTR aan staat. Dit werkt soms
- Opnieuw opstarten na een error uitgezet

- Starttijd zoeken en dan kijken wat er rond die tijd gebeurde: https://www.coretechnolog...vices/service-start-time/

code:

C:\WINDOWS\system32>sc queryex ClickToRunSvc

SERVICE_NAME: ClickToRunSvc
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 10560
        FLAGS              :

code:

 PS C:\Users\Administrator> Get-Process | select name, id, starttime | select-string 10560

@{Name=OfficeClickToRun; Id=10560; StartTime=}

Zelfs als ik de service een paar keer aan en uit zet kan powershell geen starttijd vinden omdat dit by default niet in de logboeken komt
- Alle Office meuk van de taakbalken en startmenu's halen

Wat ik nu aan het proberen/leren ben is het maken van een batch file dat de service kan stoppen

code:

 net stop servicenamehere

. Het batchfile werkt op zich wel, nu het uitvoeren wanneer OCTR start nog

[ Voor 3% gewijzigd door MC trouble op 05-03-2020 18:53 ]

[akimosan]

Rare bug, ik neem aan dat het in de client voor je ERP zit en niet in je ERP backend systeem. Maar dan nog heel raar dat een taak die wat gegevens queried en verstuurt (op de achtergrond) een proces verstoord wat op de voorgrond draait (net tijdens een drag & drop actie?). Het lijkt me meer iets van een applicatie/proces wat interactief draait wat roet in het eten gooit, maar goed.

Verschilende services worden ook gestart vanuit de TaskScheduler (al dan niet reagerend op een event)

Ik denk dat het in dit geval de task "Office ClickToRun Service Monitor" is, onder de Office bibliotheek in de Taakplanner.
Deze staat standaard op starten om 4:00 en elk uur herhalen.
Let op dat als je aanpassingen maakt aan die taak, er ook weer taken zijn die de "health" van je Office installatie controleren en middels een "reparatie" die taak wellicht weer met standaardwaarden instellen.
Maar je kunt er mee gaan testen.

[Trommelrem]

Heb je in Intune geconfigureerd dat je steeds de latest version krijgt? Of is Office vastgezet op een specifieke versie?

[MC trouble]

Akimosan je bent de beste!

Ik had nog nooit van de TaskScheduler gehoord om eerlijk te zijn. Het elk uur herhalen heb ik er net eruit gegooid op me thuis PC. Best raar dat een PC die soms weken geen Office draait elk uur Office dingen 'moet' doen

Rare bug, ik neem aan dat het in de client voor je ERP zit en niet in je ERP backend systeem.

Geen idee. Het is zit in de user interface van de planners.

Maar dan nog heel raar dat een taak die wat gegevens queried en verstuurt (op de achtergrond) een proces verstoord wat op de voorgrond draait (net tijdens een drag & drop actie?).

De problemen zijn voor mijn tijd begon. Waarschijnlijk toen ze met de remote desktop begonnen (de UI van de ERP draait wel op de PC). De calculatie programma's etc draaien op de server. De module van de PDA's en Tablets is bijna helemaal custom op maat gemaakt... een jaar of 10 geleden.

Het lijkt me meer iets van een applicatie/proces wat interactief draait wat roet in het eten gooit, maar goed.

Ik heb de link naar de achtergrond services gelegd omdat het leek op een bug die een studie maat ooit in een spel had. Potato laptop en slecht internet gingen toen niet samen met Office click to run. Heb me toen naderhand wijs laten maken dat zulks helemaal geen invloed zou hebben.

@Trommelrem Ik heb geen idee hoe dat ingesteld is op me werk. Office reset de Tasks zeker met een update... Tijdens het Google heb ik ergens zo iets gelezen. Dacht dat dat over de tasks in zijn programmeer code ging

De Task Scheduler lijkt me een goeie tool om de service ook weer mee af te stoppen zodra er geen office programma's meer open staan. Heb wel ingesteld dat het starten en stoppen van applicaties gelogd wordt. Alleen nog "FF" doorkrijgen hoe ik complexere voorwaarde, filters etc. in het stukje XML verwerk, maar dat is voor later.

code:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
     *[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and Task = 13312 and (band(Keywords,9007199254740992)) and (EventID=4688)]] 
   and 
     *[EventData[Data[@Name='NewProcessName'] and (Data='C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE')]]
    </Select>
  </Query>
</QueryList>

Het is inmiddels ***Edit: bijna***gelukt om kladblok te starten wanneer excel gesloten wordt

[ Voor 6% gewijzigd door MC trouble op 05-03-2020 23:36 ]

[akimosan]

Waarom helemaal met een XML uitzoeken? Je kunt die taak ook gewoon vanuit de Taakplanner maken: trigegr: als een bepaalde gebeurtenis optreedt.
Kies vervolgens logboek, bron, eventID en bepaal dan welke actie moet worden uitgevoerd.
En waarom Office365 click to run gebruiken als je toch niet wilt dat je Office installatie automatisch wordt gecontroleerd / bijgewerkt?

Stop even met copy paste dingen van internet te plukken om acties gedaan te krijgen en ga daadwerkelijk onderzoeken wat er nu precies plaatsvindt op de machine als bepaalde acties worden gedaan zodat je een echte oorzaak boven water haalt in plaats van services dichtplakken en killswitches inbouwen.

Iets als Process Explorer en Process Monitor kan je daarbij helpen: https://docs.microsoft.co...wnloads/process-utilities

[ Voor 22% gewijzigd door akimosan op 06-03-2020 10:33 ]

[MC trouble]

akimosan schreef op vrijdag 6 maart 2020 @ 10:31:

En waarom Office365 click to run gebruiken als je toch niet wilt dat je Office installatie automatisch wordt gecontroleerd / bijgewerkt?

Dat willen we dus wel. Anders hadden we de service helemaal geblokkeerd. De CAD/CAM vaults zijn ook afhankelijk van hun services. Die kunnen we ook niet blokkeren.

Stop even met copy paste dingen van internet te plukken om acties gedaan te krijgen en ga daadwerkelijk onderzoeken wat er nu precies plaatsvindt op de machine als bepaalde acties worden gedaan zodat je een echte oorzaak boven water haalt in plaats van services dichtplakken en killswitches inbouwen.

Dit probleem proberen we al sinds eind vorig jaar te verhelpen. Uiteraard hebben we eerst de bug zelf proberen te verhelpen. Niet alleen zelf, maar ook door een IT bedrijf, de office help desk en de makers van het programma. Veel kosten gemaakt, tijd verspilt en uiteindelijk Office naar de server/remote desktop verplaats en terug geschakeld naar Office 2010 op de PC's.

Iets als Process Explorer en Process Monitor kan je daarbij helpen: https://docs.microsoft.co...wnloads/process-utilities

Bedankt voor de andere tips. Alles lijkt nu goed te werken, maar mocht er iets fout gaan dan kan ik daar op terug vallen