Nas and maillog issues

lzr

Our system is currently running Navision 4.0 sp1 with SQL 2005. I installed NAS and the maillog runs as it should. However it crashes like 5 times a day and I have to manually restart the service. As I can see there are 3 different crashes so far.

1. Nassql crashes and has to be manually started. Event viewer says:

The following information is part of the event: nassql.exe; 4.0.1.21666; 430b5706; ntdll.dll; 5.2.3790.1830; 424377d2; 0; 000396d0.

2. Event viewer gives a c/al warning and echoes this warning until I restart the service. Event viewer says:

The following information is part of the event: This message is for C/AL programmers:

The call to member Logon failed. Collaboration Data Objects returned the following message:
[Collaboration Data Objects - [MAPI_E_INVALID_OBJECT(80040108)]]

3. The maillog just stop logging, no error or warning is reported in the event viewer.

Anyone have any ideas?

mjrogers

Did this setup ever work on other versions of SQL/Navision?

We had similar problems with an installation recently, and although the problem finally turned out to be a bug in Navision, we initially had no idea what was causing NAS to crash.

We used the SQL profiler to log what activity was going on. We also monitored activity and growth of the logfile. This gave us some important information which led us on to finally resolving the issue.

Unfortunately I can't help with the specific message you are getting but I hope my tips help you find the issue.

lzr

Yes, it worked when we were running Navision 4.0 with native database.

Might be a bug, but then again it is strange there are 3 different reasons..

anyway thanks for your input.

kriki

lzr wrote:

Our system is currently running Navision 4.0 sp1 with SQL 2005. I installed NAS and the maillog runs as it should. However it crashes like 5 times a day and I have to manually restart the service.

Can't you put in the service that Windows has to restart the service when it crashes? (see recovery-tab of the service)

lzr

Good idea! I'll do that. Should sort out at least one of the problems.

Anyone noticed any similar problems with the NAS SQL 4.0 SP1?

Scott_Frappier

Hello everyone!

I see that this is a fairly old post. I was wondering if anyone has ever found out what was going on with it as we're running into it as well.

From what I can tell - it looks to be caused by MAPI because the design of the codeunit looks to CREATE COM objects, but never releases them. I have tried numerous things, from changing all automation controllers to globals, to CLEAR functions after everything is said and done. I still run into the same issue if there are a number of emails, or over a period of time with a very busy email site.

I created a basic design in C# that also used the Marshal.ReleaseComObject method and I cannot re-create this issue. My guess is that the CLEAR() function does not actually release the COM object in NAV, and there are RPC connections open between Exchange and NAV but I can't seem to pinpoint it...

I'm almost ready to re-design this in C# so that it also works with Exchange 2010, as the new journaling functionality creates journal reports with the original message as an attachment (so the Sender method used in CDO does not work). Anyone tackled this by chance?

Any info would be appreciated.

Thanks!

danlindstrom

Scott Frappier wrote:

Hello everyone!
...
From what I can tell - it looks to be caused by MAPI because the design of the codeunit looks to CREATE COM objects, but never releases them. I have tried numerous things, from changing all automation controllers to globals, to CLEAR functions after everything is said and done. I still run into the same issue if there are a number of emails, or over a period of time with a very busy email site.
...

Youre on the right track. We had similar problems and after installing a hot fix of codeunit 5064+5065 (maillog dispatcher + logging) it works well.
The key part is that the old logging-codeunit logged in and out from Exchange server every time it had to check the queue-folder.
After the fix NAS only logon once and dont release the conection to the Exchange server (it had been implemented in later versions)

Brett_Barabash

Dan, where did you obtain the hotfix for this? I can't see anything on PartnerSource.

Aside of using the Job Queue table, NAV 2009 R2 still operates in a similar manner, logging on and off between job runs. I have tried everything for one of my customers running 4.02 including using the newest 5064/5065 codeunits and NASAppHandler.dll. It still results in NAS freezing for long periods followed by the error message in the original post.

Brett

Brett_Barabash

Scott Frappier wrote:

I'm almost ready to re-design this in C# so that it also works with Exchange 2010, as the new journaling functionality creates journal reports with the original message as an attachment (so the Sender method used in CDO does not work). Anyone tackled this by chance?

I tried writing preprocessing code in 5064 to go through the journal messages and save the attachments to a separate folder before the standard code runs. Problem was, certain messages would trigger CDO errors. Usually it was the auto-generated Exchange Administrator ones, but there were some external senders that would cause it to fail as well.

I recently discovered from this article that setting up hub transport rules to BCC internal and external messages to a different mailbox works much better.

Brett

Scott_Frappier

Brett:

Hope business is going well for you! I think the last time we had contact with you was at your previous employer!

I was never able to fully fix the issue - even with the hotfix. I would run into a number of different issues - from COM/Automation errors to just plain weird NAS issues. Instead of fighting the issues as we even tried to re-create them with Microsoft, I decided to get things up and running where it will not cause issues for the client.

First thing was getting past the journaling - we used the BCC functionality in the Message Hub Transport to correct the issue with Exchange 2010. This worked for our environment as they only have one server, but from what I've heard and read, if you have a large organization with many emails - this can cause a significant performance issue on the Exchange Server. We also developed an integration with another custom automation controller called "Redemption" that extends CDO past where Microsoft left it at in 1.21. Google it if you're curious - we used the "SentOnBehalfOf" method to get information regarding who sent the email so that we didn't retrieve the Exchange system attendant email.

Secondly - We've had issues with Outlook 2007 and 2010 and MAPI/CDO - we decided to create a new virtual server using Windows Server 2008 R2 and loaded NAS/Classic Client and Outlook 2003 SP2 on the machine. Set it to 512MB of RAM and the server basically uses no resources but it is an isolated environment that we know works well with Outlook.

After all of the basic setup with the NAS, Job Queue, and Client for Folders - we made the following code changes in codeunit 5064 to account for "real-world" data that we found (i.e. no senders which caused it to error on the same message over and over and also no subject which caused the message filter to fail):

Function
RunEmailLogging()

...
= WHILE NOT ISCLEAR(CDOQueueMessage) DO BEGIN
=   TempSegLine.DELETEALL;
=   TempSegLine.INIT;
=   Continue := FORMAT(CDOHandler.GetSensitivity(CDOQueueMessage)) = '0'; // CdoNoSensitivity
=   
+  //>> SYM/SF
+  Continue := CDOHandler.SenderExists(CDOQueueMessage);
+  //<< SYM/SF
=
=  IF Continue THEN
=    Continue := NOT AlreadyInStorage(CDOQueueMessage);
...

Function
IdentialItemInStorage(VAR CDOQueueMessage, VAR CDOStorageMessage)

...
= SenderVariant := CDOQueueMessage.Sender;
= IF SenderVariant.ISAUTOMATION THEN
=   CDOStorageMessageFilter.Sender := CDOQueueMessage.Sender;
=
+ //>> SYM/SF
+ //CDOHandler.SetSubjectComparisonField(CDOStorageMessageFilter,CDOQueueMessage);
+ IF STRLEN(CDOHandler.GetSubjectSubString(CDOQueueMessage,1,10)) > 0 THEN
+   CDOHandler.SetSubjectComparisonField(CDOStorageMessageFilter,CDOQueueMessage);
+ //<< SYM/SF
+
= CDOStorageMessage := CDOStorageMessages.GetFirst;
...

Function
AddressEntryEmail(VAR CDOAddressEntry, Return Code(250))
Added CDOValue(local) = Variant

...
= WHILE FieldNumber > 0 DO BEGIN
=   CDOField := CDOFields.Item(FieldNumber);
+   //>> 001 SYM/SF
+   CDOValue := CDOField.Value;
+   IF CDOValue.ISTEXT OR CDOValue.ISCODE THEN
+   //<< 001 SYM/SF
=     IF STRPOS(FORMAT(CDOField.Value),'@') <> 0 THEN
...

Once all of the code was working properly and we didn't see processing errors - we started noticing MAPI errors due to the connection never closing properly. To correct this and keep from running a hot fixed codeunit until another release addresses it, we went down the old fashioned way.

We created two scheduled jobs with batch files. The first was called "RestartNAS.bat" and the other was called "StartService.bat".

RestartNAS.bat contained the following:

@ECHO OFF
for /F "tokens=3 delims=: " %%H in ('sc query NASSERVICE-SQL ^| find /i "STATE"') do (
  if /I "%%H" == "RUNNING" (
   ECHO Service is running and a stop command has been issued
   net stop NASSERVICE-SQL
  )
  ECHO Service has been sent the start command
  net start NASSERVICE-SQL
)

StartService.bat contained the following:

@ECHO OFF
for /F "tokens=3 delims=: " %%H in ('sc query NASSERVICE-SQL ^| find /i "STATE"') do (
  if /I "%%H" NEQ "RUNNING" (
    ECHO Service has been sent the start command
    net start NASSERVICE-SQL
  )
)

Two jobs were created in the Windows Task Scheduler (Start --> All Programs --> Accessories --> System Tools):
[*] First Job was called Restart Application Server. The "Trigger" for this was "On an Event" and the "Custom" Event Filter looked for any Critical, Warning, or Error states for the service. It would then execute the "RestartNAS.bat" file with the highest privilege. The XML event filter looked as follows:

<QueryList>
  <Query Id="0" Path="Application">
    <Select Path="Application">*[System[Provider[@Name='NASSERVICE-SQL'] and (Level=1  or Level=2 or Level=3)]]</Select>
  </Query>
</QueryList>

[*] The second job would check to make sure that the NAS was running - just in case we ran into a condition where it stopped during the previous process for some unknown reason. It was set to execute daily and would repeat every 5 minutes. It would execute the StartService.bat file which checks to see if the service is running, and if so does nothing, otherwise it starts the service.

After we implemented these changes, we have seen the application process all emails without issues - it no longer hangs on anything, and there is no user intervention. It may be a overkill to stop and restart the NAS for any warning and you could fine tune it to look for specific event id's, but we didn't want to bother with it and as it is on it's own VM, we have been able to contain and isolate the service without incident.

Also note - we decided to re-add the old "MAILLOG" parameter to be used for the NAS startup as the Job Queue was _not_ something that we wanted to infringe with multiple NAS servers. It shouldn't matter either way as the Job Queue basically does the same thing as the dispatcher.

Hope this helps anyone else running into these fun issues.

- Scott

Brett_Barabash

Hey Scott, great to hear from you! Things have been going really well, but it's been an interesting year.

I added your 2 code changes into my code, and I'm fairly sure the SenderExists check will solve their problem with errors from unknown senders.

The biggest problem they were having involved NAS locking up for long periods of time. Dan Lindström had suggested that this was caused by it constantly logging in and out of CDO. Here's what worked for me:

Changes to codeunit 5064 RunEMailLogging() trigger:

RMSetup.TESTFIELD("Storage Folder Name");
IF ISCLEAR(CDOSession) THEN  //added
  Logon;

...

  CDOQueueMessage.Delete;
  CDOQueueMessage := CDOPrevQueueMessage;
END;
//Logoff;  //commented out

This way it will only logon if it needs to, and doesn't logoff afterwards. This causes a potential problem if it loses its connection between runs. To get around this, I made the following changes to codeunit 5065:

Created global variable - ErrorCount, Type int

Changes to Timer::TimerError() trigger:

ErrorCount += 1;  //added
IF ErrorCount = 1 THEN  //added
  EMailLogging.Logon();  //added

Changes to Timer::Timer() trigger:

EMailLogging.RunEMailLogging; 
ErrorCount := 0;  //BB added

This code prevents it from repeatedly trying to logon for subsequent errors. If the mail log process runs successfully, the error count is reset and it can try to logon again if needed.

When NAS shuts down it's bad form to keep the connection open so I attempt to logoff when the application closes. First, a new trigger was added to codeunit 5065:

Shutdown()
MESSAGE('Shutting down E-Mail Dispatcher');
EMailLogging.Logoff();

2 global variables added to codeunit 1:
EmailDispatcher - Type: Codeunit, SubType: E-Mail Dispatcher
MailLogRunning - Type: Boolean

Changes to codeunit 1 NASHandler() trigger:

    CASE Parameter OF
      'MAILLOG':
//        CODEUNIT.RUN(CODEUNIT::"E-Mail Dispatcher");  //commented out
        BEGIN  //added
          EmailDispatcher.RUN;  //added
          MailLogRunning := TRUE;  //added
        END;  //added

Changes to codeunit 1 CompanyClose() trigger:

IF GUIALLOWED THEN
  LogInEnd;

IF MailLogRunning THEN  //added
  EmailDispatcher.Shutdown();  //added

They already had an external app that monitors services so I didn't get a chance to try your batch files for that. You should post it to Tips & Tricks, I'm sure others would find it helpful as well.

Thanks for all your help.

Brett