Skip to main content

ePortal stops due to Lumisoft malfunction (IMAP No Login)

Article # 3026481 - Page views: 108


Question / Problem: 

How to handle random Lumisoft errors in ePortal (mostly due to failed IMAP Login)?

Answer / Solution: 

the simple answer: Restart ePortal station. But this can be annoying, first because the issue can happen once or twice per day, second because when the issue gets recognized, there may already be hundreds of unprocessed eMails in the mail-account.

The automation of the station restart is possible with 2 Powershell scripts:
   -    the first monitors ePortal for throwing Lumisoft errors (string 'Lumisoft' in Eventlog). Runs as a scheduled task every <nn> minutes.
   -    the second restarts ePortal in case of 2 conditions met: the mentioned error message must be found in the eventlog AND the ePortal has not been restarted yet.
        (The restart should not just kill and start the station, but should delete the according database records as well.)

Enter How to here:

  1. ePortal_monitor.ps1
    # checks if eportal is connected to mail account, if not creates an Event that will trigger the ePortal_Restart.ps1

    [String]$creportal = Get-WmiObject -query "select creationdate from win32_process where commandline like '%StationID:eportal%'" | Select-Object Creationdate

    # gets the process creation time into creportal.
    $procid $creportal = $creportal.substring(15)
    $creportal = $creportal.remove(14)
    [String]$nologin=Get-EventLog TIS_Log -source tis_app -Message "*efsimpleauto*lumisoft*no login*" -newest 1 |select -property TimeGenerated
    # gets the event creation time into nologin.


    # changes the datetime format into the one from creportal: yyyyMMddHHmmss.  
    if ($bruchzeit -gt $creportal) {write-EventLog -LogName tis_log -Source tis_app -EntryType Error -EventId 4759 -Message "ePortal needs Restart"}
    # triggers the restart if crash point younger than the latest process creation.eportal_restart.ps1
  2. # restarts station ePortal, including the deletion of the records in the management and workflow DB
    Function Invoke-SQL {
    $userid="<dbadmin username>"
    # to be filled with the correct values
    $sqlCommand = "DELETE FROM [eFlow_Management].dbo.[E_Station] where stationtype = 'ePortal'; DELETE FROM [<appname>_Workflow].dbo.[E_Session] where QueueId = '142';"
        $connectionString="Data Source=$server;Initial Catalog=$database;User ID=$userid;Password=$pw"
    $connection = new-object$connectionString)
    $command = new-object$sqlCommand,$connection)

    $adapter = New-Object System.Data.sqlclient.sqlDataAdapter $command
    = New-Object System.Data.DataSet
    $adapter.Fill($dataSet) | Out-Null

    $ErrorActionPreference ="Continue"
    Stop-Service eFlowAutorunStationStarter
    timeout /t
    [String]$procid = Get-WmiObject -query "select ProcessID from win32_process where commandline like '%StationID:eportal%'" | Select-Object ProcessID
    $procid = $procid.substring(12)
    $procid = $procid.remove(4)
    Get-WmiObject win32_process -filter "Name='efSimpleAuto.exe' AND CommandLine LIKE '%ePortal%'" | foreach { $_.terminate() }
    timeout /t
    # kills every efsimpleauto with 'eportal' station

    # calls the function from above and deletes the records in the DB

    timeout /t 5
    Start-Service eFlowAutorunStationStarter
    # restarts the autorun service which then restarts the ePortal station

    It has to be mentioned, that both scripts have always to be adjusted and tested carefully within the specific customers' environment, e.g. Station Name
    could be 'MailPortal', Queue-ID could be different, eFlow_Management DB could have a different name like eFlow_management_Prod, etc.

    Originally this scripting was meant to be a workaround, until either the issue would be fixed in ePortal or the root cause would have been found in the
    various customers' eMail-Server configurations.

Applies to:  

Product Version
ePortal all



Group Conditional Block
  • Was this article helpful?