Stephen Smith's Blog

All things Sage 300…

Diagnosing Problems with Sage ERP Accpac 6.0A

with 22 comments

Now that people are installing and deploying Accpac 6, hopefully, to get the new Web technologies working you just need to install, play with Database Setup and then away you go with no problems. Or at least hopefully this is how it works out for most people. But for those that it doesn’t, this blog posting is to help you figure out what has gone wrong. The main purpose of this blog posting is to help you track down and solve unforeseen problems on your own, hopefully giving you tools that will give you clues to what is wrong and allow you to come up with solutions.

This blog posting assumes that you can run both regular Database Setup and the classic Accpac Desktop. If you are having trouble at this step then check out these blog postings on diagnosing problems in Accpac part 1, part 2, part 3 and part 4.

Database Setup

The first time you hit some of the new technologies is when you configure the Portal’s database from Database Setup’s Portal… button. When you click here it runs a Java program that configures the portal for JDBC and tests the connection. Often if you are going to have trouble with the Java runtime or with accessing the database server from Java, this is where you will run into problems.

Bad Java Runtime

The Accpac 6 installation installs the Java Runtime version 6 update 17. If you previously have a later version of the Java runtime or let the Java Updater run then you will have a newer version. If you get an error about having trouble with a Java class such as, then chances are you have a problem with the runtime. We’ve seen systems where many versions of the Java runtime are installed and even though they are supposed to co-exist, there appear to be problems, plus now and then a bad Java update gets installed from the Java Updater. This was especially a problem shortly after Oracle bought Sun, at which point Oracle renamed quite a few things from Sun to Oracle and put out a couple of bad updates. They seem to be getting better at this again, but this is something to watch out for. A good remedy for this is to un-install all versions of the Java runtime and delete the program files\java directories (or the x86 variant if running 64 bit). Then either re-install Accpac or install a good known version of Java directly. Remember that Accpac is a 32 bit application and as such we require the 32 bit version of Java.

Troubles Connecting to SQL Server from Java

If your Java runtime is ok, then the next thing is: the Java classes will test your settings by connecting to the Portal database. If you get an error about “can’t locate server or user id/password are incorrect”, it might be a SQL Server configuration problem. The configuration of SQL Server from Database Setup for normal Accpac companies is fairly forgiving; it is quite smart about finding SQL Server’s and SQL Server instances and can use any communications protocol that is configured. But we access the Portal database using JDBC which is a bit more stringent. If you can setup regular Accpac companies, but not the Portal database then it is usually due to a few SQL Server configuration properties:

  1. In the SQL Server Configuration Manager – SQL Server Network Configuration – Protocols for serverinstance: make sure TCP/IP is enabled (usually it isn’t for SQL Server express and a few other varieties). Make note of the Port number used to ensure you are using the correct one (right click on TCP/IP and choose properties).
  2. Use the servername alone and the correct port number. Do NOT use server/instancename, this isn’t currently recognized (we will probably fix this for Product Update 1).
  3. In SQL Server Management Studio: in the properties for the server, security tab, ensure “SQL Server and Windows authentication mode” is selected for Server authentication.
  4. In SQL Server Management Studio: in the properties for the server, connections tab, make sure “Allow remote connections to this server” is checked.

If none of this works, then you are going to have to run a SQL Trace to see what is failing.

Hopefully this helps you get past Database Setup.

Tracing Web Requests

Below is a deployment diagram of the new Web components included with Sage ERP Accpac 6.0A. For more details look here.

As you can see requests come from the Internet and enter the Web Server via Microsoft Internet Information Services (IIS). Static content like HTML files and bitmap images will be served up directly from here. Requests for data are sent through the Jakarta ISAPI re-director to Tomcat which runs our SDataServlet which in turn calls the Accpac business logic objects (Views) to get the actual accounting data.

The general approach to troubleshooting here is to use logging to figure out how far requests from the Browser are getting and then to see why are failing at that point. All the components in the above deployment diagram have logging capabilities. Usually by default they only log errors which at this point are often all you need, however they can all be configured to provide much more detail on everything that is going on in the system.


First I’ll quickly summarize how to turn up and control the logging levels for the various services.  When running normally you won’t want to leave all these logging levels high since it wastes a lot of disk space and causes a performance drag writing out all this information. Usually you want to leave IIS logging on for every request so you can audit and keep an eye out for malicious attacks. But the other logs may as well be left at the error level.

IIS’s logging is controlled from the IIS Manager via the Logging icon for the web server. By default it’s enabled and the logs are stored in: C:\Inetpub\logs\LogFiles\W3SVC1. Note that the various versions of IIS are different so you might need to look around a bit for the settings.

The Jakarta IIS redirector is configured via the file: C:\Program Files (x86)\Common Files\Sage\Sage Accpac\Tomcat6\Jakarta\ Change the log_level from error to debug. Note that this setting causes an extremely large amount of output and will affect server performance, so remember to set this back to error when you are done. The log file is AccpacRedirector.log in the same C:\Program Files (x86)\Common Files\Sage\Sage Accpac\Tomcat6\Jakarta folder.

For Tomcat and SDataServlet, the log files are stored in: C:\Program Files (x86)\Common Files\Sage\Sage Accpac\Tomcat6\logs . To configure the logging level edit: C:\Program Files (x86)\Common Files\Sage\Sage Accpac\Tomcat6\webapps\SDataServlet\WEB-INF\classes\ and change “log4j.rootLogger=ERROR, logfile” to “log4j.rootLogger=ALL, logfile”.

Diagnosing Problems

The general approach is to follow messages through the system by looking at the log files. Having a set of log files from a working system can help greatly since then you can compare them, since differences often give a clue to the cause of problems.


First, do the Browser requests even get to IIS? If not try using the server’s IP address instead of the URL. Try Browsing from the server using localhost. This can give an indication if IIS just isn’t working at all or you have DNS problems or there is some problem resolving your URL. Obvious things to check are that the IIS service is running, check the Windows Event Log if it won’t start or that IIS is configured on port 80 (HTTP) and 443 (HTTPS). Note that only one program can use a given port so if something else is using port 80, say Apache as a web server for something else then only one of them can have port 80 and one process will fail to start. If you have to use a different port, this is ok, just remember to put :portnumber after the servername in your URLs.

Next, what if the browser requests get to IIS but are rejected? What if you get a 403 error return (access forbidden)? This also manifests itself in that you will see “isapi_redirect.dll” as part of URLs in the log file. This means you don’t have sufficient permissions to execute the Jakarta redirector or there is some other sort of access problem. If you get general 403 errors on requests for static content like HTML files or image files, then the file permissions on the WebUIs folder under the Accpac directory are too strong. This folder only contains HTML, JavaScript and image files. Neither data, nor anything valuable is stored in this folder, so it is ok to relax the permissions and grant read-only access for everyone (don’t grant write since you certainly don’t want to risk a hacker writing files here). The other case is if you see isap_redirect.dll in the URL, this means you don’t have sufficient permissions to load this DLL. We install IIS with all our processes running as the local system account, this account should have permission to do anything on the machine, but it won’t have access to network resources so the most common cause of this is having key files installed on a network share. The best solution here is to ensure the Accpac programs are installed on the web server so it only needs to access the LAN to get to the database server. You can also change the user the Sage Accpac Application pool runs under to something with domain privileges.

Another problem we’ve seen with IIS is that in some cases the Accpac install fails to create the various virtual directories and application pools inside IIS. We haven’t figured out why this happens yet, but it’s worth quickly checking that the SageERPAccpac and SDataServlet applications are added to the default web site and that Sage ERP Accpac App Pool is added to the application pools. Right now the only solution we have for this is to create these entries manually, copying from a good system. I’ll update this blog posting with more details once we figure this out. It’s strange because we don’t get any errors back from IIS when this happens.


So far we haven’t seen problems with Jakarta. This is an ISAPI module that loads into IIS and redirects all the Accpac SData requests to the Tomcat Server. I would first look in Tomcat’s logs and then only come back here if nothing is appearing in the Tomcat logs.

Generally here you need to turn on the logging and then look to ensure messages are making it to Jakarta (i.e. the log isn’t empty). Then usually Jakarta provides fairly good diagnostics in its log when things don’t work. These are usually along the lines that the Tomcat service isn’t running, there is a port conflict or something of this nature.


Apache Tomcat is a Java application server that runs the server side of Java web applications. The Accpac SData server is written in Java and runs under this. Tomcat’s own log files give good information if there are problems with Tomcat. Tomcat can have problems if a bad version of the Java runtime is installed, hopefully this was resolved back when you ran Database Setup, but if you get a bunch of weird Java errors in the Tomcat logs then check out the info in the Database Setup section above on cleaning up the Java runtimes.

Tomcat is also the point where we need to load DLLs from the Accpac\runtime directory. If you see errors about loading Java classes and you see a4wapiShim.dll mentioned, then you probably don’t have the Accpac\runtime folder in your system PATH. Note that since Tomcat runs as a system service under Windows, this must be in the system PATH and not your user PATH.

Next when you look in the SDataServlet log files you will see various Accpac error messages. Make sure you can login to the standard Windows desktop and access the company you are using. You can’t perform data activation from the web portal, so this needs to be done from the Windows desktop.

If you installed an alpha, beta or release candidate of Accpac 6, try uninstalling, deleting the C:\Program Files (x86)\Common Files\Sage\Sage Accpac\Tomcat6 folder and then re-installing. There might be some old leftover files that need deleting.

Watch out for IE6

We see people trying to use IE6 a surprising amount. It’s always surprising to me that people are still using IE 6, but they are. If the reported symptom is that the browser is hanging, then it is probably IE6. We don’t support IE6 and IE6 definitely doesn’t work in anyway. Worse the IE6 JavaScript engine can completely lock up Windows causing you to need to re-boot your workstation. The usual symptom of IE6 is that the first time you hit the portal it creates the uiContent table and then locks up, not creating the other three tables in the PORTAL database.

Remember we only officially support IE 7 and 8 for Sage ERP Accpac 6.0A. We will add support for Safari, Chrome and Firefox in Sage ERP Accpac 6.1A. However we won’t ever be adding support for IE 6. We will validate IE 9 once it’s released. Also if you are running IE 7, although it works, why not upgrade to IE 8? It does work quite a bit better.

Quotes to Orders

Diagnosing problems with Quotes to Orders is done the same as above. But just a couple of notes:

  • Ensure you use .Net remoting as the protocol from the Web Deployment Manager.
  • Make sure that you have activated and setup the SageCRM (EW) module within Accpac.


Fiddler is a great tool for tracking down problems. It spies on TCP/IP traffic through IE. Note that you have to use the proper server name in the URL, you can’t use localhost. This will show you all the requests and responses made from the Browser, often giving important clues when solving problems.


I hope as you deploy Sage ERP Accpac 6.0A, that you don’t need to refer to this blog posting very often. Further I hope that this blog posting doesn’t need to be read much. But if you do run into problems, I hope you find this information helpful.

Now off to TPAC.

Update 2011/03/29: If you have an individual workstation that is having trouble loading the Portal, try clearing the Browser cache. Sometimes if the Portal failed to load half way through then IE caches that and won’t finish until the cache is cleared and it can start clean.

Update 2014/10/02: For SQL Server Express, by default it uses dynamic ports. To work with the Portal you need to configure it to use a specific port. To do this run the SQL Server Configuration Manager. Choose “SQL Server Network Configuration”. First ensure TCP/IP is enabled, then right click on it and choose properties. Choose the IP Addresses tab, scroll to the bottom and in the IPAall setting, blank out the TCP Dynamic Ports entry and set the TCP Port to 1433 (or whatever you need).

Written by smist08

March 5, 2011 at 5:24 pm

Posted in sage 300

Tagged with , , , ,

22 Responses

Subscribe to comments with RSS.

  1. I get the following error message when logging in remotely: How can this be corrected

    An unexpected error occurred when trying to open Batch List. Run Workstation Setup and try again. If the error persists, contact your Sage ERP Accpac administrator for assistance.

    Sam Mutsauri

    December 7, 2011 at 11:42 am

    • If you are running from the Portal, then workstation setup must be installed on the computer to run the VB UIs. These will only run from the Portal if you can also run them from the old Windows desktop.


      December 7, 2011 at 4:23 pm

      • Hi Stephen
        Is this the only way now, as I am trying to get SAGE 300 ERP 2012 Web deployment working on a 2012 server but continue to get “HTTP Error 500.0 – Internal Server Error
        Calling LoadLibraryEx on ISAPI filter “C:\Program Files (x86)\Common Files\Sage\Sage 300 ERP\Tomcat\Jakarta\isapi_redirect.dll” failed”
        My Portal is working fine no problem, so now I wonder if that is the way to go on server 2012?


        January 9, 2014 at 12:40 pm

      • This message usually means your application pool isn’t set to enable 32-Bit applications. Sage 300 is a 32-bit application so the IIS application pool being used must be set to 32 bit. Sometimes its easiest to set all the application pools in IIS to 32 bit so you know you get the right case.


        January 9, 2014 at 3:55 pm

  2. Thanks. Was testing using a machine without setup files.

    Sam Mutsauri

    December 8, 2011 at 3:04 pm

  3. When logging into ACCPAC using portal,an error message “orgOpen domain org value 1” appears.The sign on screen appears but with no companies to log into. What do I need to do to solve this.

    Sam Mutsauri

    March 5, 2012 at 10:58 am

    • If you have multiple versions of Accpac installs, then maybe the wrong DLL is being loaded. orgOpen is trying to open orgs.ism in the site folder, perhaps this isn’t accessible? Remember that the local system account that the tomcat service runs under doesn’t have access to network resources, if it needs this then you need to change the service to run under an domain user.


      March 5, 2012 at 5:07 pm

  4. The Problem has been solved by uninstalling IIS and reinstalling. Its now working fine.

    Sam Mutsauri

    March 6, 2012 at 12:05 pm

  5. Is there some way to get a transparent redirect working? I cannot figure out where the root directory is being redirected!

    basically i want users to be able to go to and be transparently redirected to “”

    Otherwise, the user would have to type in the whole URL or save a bookmark! both quite undesireable. I just cant figure out how this jakarta thing is doing the redirect. I have tried putting index.html file in a whole bunch of different directories on the server but none will be available as the / of the website.

    i tried IIS root
    Sage\Sage Accpac\Tomcat6\webapps\ROOT
    Sage\Sage Accpac\Tomcat6\webapps\
    Sage\Sage Accpac\WebUIs

    etc… nothing. Of course if i go to the direct Url it works. My question is where is the DLL file relocating the root directory of the site to?


    April 16, 2012 at 9:37 pm

    • Perhaps just have a default.htm in the wwwroot folder which could have some entries like:

      Sage ERP Accpac 6.0A

      Or just get it to redirect automatically. (need to view source on this since WordPress seems to be processing the HTML).


      April 16, 2012 at 10:16 pm

      • Yeah i just tried there same deal. I am just trying to display “hello world” right now, as that is the contents of my index.html file. It doesnt work and all i get is a 500 error.

        I have another website container on the same machine, which does not use the ISAPI redirect and I am able to drop files into its “Physical Path” no problem. However the accpac site, the physical path must be getting redirected. I just cant figure out where.

        Using procmon, i can compare the way w3wp (IIS process) handles both events. In the accpac case, it clearly tries to talk to isapi_redirect.dll before failing. In the other websites case, it goes straight to the correct directory and retrieves the file.

        Do you know of any other way around this? is sage’s recommendation that people should have to type the very long URL in? Is there a way to specify a “root” directory in jakarta??


        April 16, 2012 at 11:07 pm

      • The sample I gave, I just took from a test server I setup at: Feel free to have a look at this. I don’t remember doing anything special to IIS when I set this up.

        The redirection comes from the SDataServlet application under the default web site, this routes any URI that starts with SDataServlet to Jakarta. Then the config files in c:\program files\common files\sage\sage accpac\tomcat\jakarta handle where jakarta sends the requests (ie which Java application to route them to).


        April 16, 2012 at 11:26 pm

  6. I fixed it. It seems deteting and re adding the ISAPI filter under the parent website container for accpac fixed the issue. Now everything works as it should.

    Stupid IIS. Man I hate IIS where you can delete a config and then re add that same config and then it works!! doing the same thing, getting different results… ah microsoft.

    I used the code labeled “asp redirect” from the following page to perform the actual redirect:

    There are a bunch of different methods there for redirection which you could pick based on your environment.

    Thanks for the help smist! was just IIS being retarded. You guys should think about going full apache. Much less error prone.


    April 19, 2012 at 8:05 pm

  7. Hi there
    I am getting the following error when logging onto the portal – any ideas
    Request failed. Requet URL;
    /sdataservlet/sdata/sageerp/accpac/-/assessions/$service/opensession. Reason response came back with status code 500 . Response status message – internal server error

    Ricky Fields

    August 7, 2013 at 7:13 pm

    • Strange, SData is somewhat working since it could get the list of companies and strings for the signon dialog. You should check the sdataservlet log (under tomcat\logs). It should give you some more information. If not try increasing the logging level.


      August 8, 2013 at 8:37 pm

  8. I keep getting the following error when loading a module task, say inventory, items “An unexpected error occurred when trying to open Items. Run Workstation Setup and try again. If the error persists, contact your Sage ERP Accpac administrator for assistance.” The portal loads fine, the snapshots are loading, inquiry works fine, explorer is version 10. I have reinstalled smdotnet.exe and also run regacc?


    October 21, 2013 at 9:00 am

    • Can you run this UI from the regular Accpac desktop on this system? The error sounds like a problem with I/C or with something attached to I/C.


      October 21, 2013 at 2:43 pm

  9. Hi,

    i am getting this Errpr when try to run the Portal – Accpac 6.0A
    The server cannot process the request for UI content. Contact your Sage ERP Accpac administrator for assistance.
    would you please assist me


    January 4, 2015 at 5:47 am

    • Perhaps confirm that you configured the Portal database in Database Setup ok. Then that the 4 tables were created in it from SQL Server Management studio. If these are ok then ensure the Tomcat service is running ok.


      January 4, 2015 at 6:01 pm

  10. Users can’t run Sage 300 ERP 2014 without administrative privileges. How do I resolve this problem?

    Saheed Ilupeju

    May 20, 2015 at 12:34 pm

    • I would open procmon, find out what registry keys and directories the program is touching and give them permissions on those directories. Like any other program. You may also want to run regacc.exe which will probably solve the issue.

      Here is my “post install” scripts. they give everyone permissions to the directories which is fine in our environement. you can modify obvioulsy if you want tighter security or the machines are shared:

      cacls “C:\Program Files\Sage Software” /E /C /T /G everyone:F
      cacls “C:\Program Files (x86)\Sage” /E /C /T /G everyone:F
      cacls “C:\Program Files (x86)\SAP BusinessObjects” /E /C /T /G everyone:F
      cacls “C:\Program Files (x86)\Business Objects” /E /C /T /G everyone:F
      cacls “C:\Program Files\Sage” /E /C /T /G everyone:F
      cacls “c:\windows\temp” /E /C /T /G everyone:F
      “C:\Program Files\Sage Software\Sage Accpac\Runtime\RegAcc.exe”
      “C:\Program Files\Sage\Sage Accpac\Runtime\RegAcc.exe”
      “C:\Program Files\Sage\Sage 300 ERP\Runtime\RegAcc.exe”
      “C:\Program Files (x86)\Sage\Sage 300 ERP\Runtime\RegAcc.exe”


      May 20, 2015 at 3:27 pm

    • Yes, after running regacc as administrator, you should be able to put the user back to being a regular user. There are some features like database setup that require you be a power user, but most users won’t run into this.

      The next version (2016) is looking to make this far easier and more transparent.


      May 20, 2015 at 3:32 pm

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: