Our hands were tied recently when we had to develop a 32 bit web app due to the reliance on a 3rd party app that was 32 bit only.

We quickly worked out how to get the app running in 32 bit mode in IIS7 just by setting the “Enable 32-Bit Applications” setting within the application pool used for the app.

This worked great until we went to do this on a server running OWA 2010. After setting the application pool to run 32 bit apps, we still got an error:

Service Unavailable

HTTP Error 503. The service is unavailable.

And as an added bonus, the application pool was now stopped. Yippee – I guess that was 5 errors in less than 5 minutes!

A quick look in the Application event log showed the following error:

The Module DLL ‘C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll’ could not be loaded due to a configuration problem. The current configuration only supports loading images built for a x86 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see http://go.microsoft.com/fwlink/?LinkId=29349.

The Source was IIS-W3SVC-WP and the Event ID was 2282.

A bit of research pointed us in the direction of setting the kerbauth.dll to be 64 bit only in the applicationHost.config file for IIS (located in C:\Windows\System32\inetsrv\config). So we stopped IIS and edited the file. In the globalModules section, we found the line for kerbauth, and added the precondition=”bitness64” attribute as follows:

<add name=kerbauthimage=C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dllpreCondition=bitness64 />

We restarted IIS (and also the app pool!) and now the app showed the following error:

HTTP Error 500.0 – Internal Server Error

Calling LoadLibraryEx on ISAPI filter “C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\auth\owaauth.dll” failed

So we applied the same theory again, and again for each dll that caused an issue – luckily for us there were only two – owaauth.dll and AirFilter.dll. Both were listed in the <isapiFilters> section of the applicationHost.config file:

<filter name=Exchange OWA Cookie Authentication ISAPI Filterpath=C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\auth\owaauth.dllenabled=true preCondition=bitness64 />

<filter name=Exchange ActiveSync ISAPI Filterpath=C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\sync\bin\AirFilter.dllenabled=true preCondition=bitness64/>

We restarted IIS again and voila – a happy application, and OWA still worked to boot. Who says you need to run 32 bit apps on a separate server! Happy days…

Now I’ve just gotta get that song out of my head… “taking care of bitness and working overtime…” ;-)

Recently I was dealing with an interesting issue regarding the SplendidCRM marketing system.

Whenever the client sent emails out via the CRM, it would not de-duplicate the emails.  Therefore, if the recipient was on two target lists in the campaign they would receive the email twice. Not ideal really.

After much searching I could not find any settings in the CRM which offer the de-duplication of emails, so I decided to come up with my own solution.

After downloading the latest SplendidCRM community edition which comes with all the source code including SQL stored procedures, I dug through the code and found that the send email function was using the spCAMPAIGNS_SendEmail stored procedure.

I decided to update this stored procedure so that it marks any duplicate email as deleted when the campaign is sent, and now the recipients only receive the email once. I found this to be the most efficient and cost effective solution for our client.

Please click here to download the updated SQL query for the stored procedure.

Please note: Should you apply this updated stored procedure, please be aware that it supplied as is and applied at your own risk.  You should ensure adequate backups are in place and that you apply any appropriate testing for your environment.

© Copyright - Mosmar