web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics AX (Archived)

Atlas 5.0 is Unstable with AX2012?

(0) ShareShare
ReportReport
Posted on by 1,155

Hi All,

It is heard that Atlas 5.0 is not very stable with AX2012,

anyone could provide more information and how to avoid this problem?

I have purchased Atlas 5.0 license and will use it in AX2012 very soon.

Thanks!

Arqxlep

*This post is locked for comments

I have the same question (0)
  • Suggested answer
    Community Member Profile Picture
    on at

    Arqlxep

    We released Atlas 5 Service Pack 1  (5.1 )  back in July 2012 which offers much greater support for AX 2012 and AX 2012 R2.    This build is extremely stable.

    Download from our web site or email helpdesk@globesoftware.com.au if you need assistance.

    Steve

  • Brandon Wiese Profile Picture
    17,788 on at

    We currenly use Atlas 5.1 for a relatively small number of users with plans to scale it to hundreds. Frankly we burn a lot of time and fuel keeping it running.  Daily (sometimes multiple times daily) restarts of the server services, individual users unable to login and needing to have their sessions killed manually, and so on.  Definitely an ankle-biter as far as reliability goes.  I don't see how it's possibly going to scale to our needs if we're having this much trouble using it with 1 company and dozens more companies to bring online.

  • Community Member Profile Picture
    on at

    Brandon

    I suggest you contact our helpdesk@globesoftware.com.au, our support team will be able to profile what is going on with AX.    

    Atlas integrates to Dynamics AX solely through the AX Business Connector and so if you're needing to kill sessions from the AX online users form then there may be a hotfix available from Microsoft.      If you're running AX 2012 or R2 then AX is all named user licensing so I am not sure why you need to kill sessions..    If your AX service is being restarted then again we would need more event log information from to learn how/why.   Atlas passes AX query objects to AX to resolve and so there may be something going on with the AX Business Connector.     An example here is some versions of the AX Business Connector don't handle date/time fields too well.

    When you email, please advise of your environment - AX version - 4.0, 2009, 2012 or 2012 R2.

    Thanks

  • Andrei Stefan Profile Picture
    20 on at

    Hi Brandon,

    I`m going to Emphasise what Steve said, please e-mail us at helpdesk@globesoftware.com.au and we will have a look at your issue, no problem.

    What I would suggest as a quick fix is try and start the Atlas server service with the same service account as the AOS is started.

    This problem is not unknown but it is not caused by Atlas. If you look in the Event viewer under Windows Logs - Applications, on the machine that hosts the Atlas server service, you will notice you will probably have a lot of business connector warnings and errors. It is those crashes of the business connector that make our server service loose connectivity with the AOS. This is usually solved by starting the Atlas server service with the same service account as the AOS.

    Please try this and if you are still having issues please contact us and we`ll have a more in depth look at your issue. It is not a very common issue and it is environmental usually.

    Thanks,

    Andrei

  • Brandon Wiese Profile Picture
    17,788 on at

    I did not originally install the Atlas software, server or client.  The server is installed on a different machine from the AOS, which I did install.  I will try using the AOS service account, which is a domain account, on the Atlas services and see if that helps.

    I also suspect the client software was not installed with CHANGE USER /INSTALL mode activated, as not many people know to do this on Terminal Server (even up to 2012) and how important it can be, so I have e-mailed the person who installed the Atlas client to see if this was done correctly.  Since your installation and configuration documentation specifies this, I assume it's even MORE important that it be done correctly for Atlas to work.

    For clarification, we do not restart the AX AOS service to resolve any Atlas issues.  In general we are forced to restart the Atlas server services.  In fact this is so common that we have created a single batch file to restart them all at the same time.  This batch file is scheduled to run at least once daily, and it is frequently run as a knee-jerk response to any user complaint that they can't login to Atlas or are getting any one of several very common error messages.  I have my own suspicions that restarting the Atlas server services does bad things to other users already logged into the Atlas client (does it automatically reconnect and stay happy or does it then generate error, which generates tickets, and the cycle continues?)  I will post some of those here as well in follow-up replies.

    Thanks for your feedback.

  • Andrei Stefan Profile Picture
    20 on at

    Indeed it is very important that you install Atlas in install mode as it has a deep impact especially on how roaming profiles are dealt with, as with any application installed on a TS that has user specific configs.

    Having a batch to restart the Atlas server is good but should not be done every day. Once a week including a cache clear is optimum. How to clear cache and restart service:

    1) Create a .bat file

    2) Enter the following code in the content of the file:

    sc stop "Name of your Atlas Service"

    ping –n 60 –w 1000 127.0.0.1 > null

    C:\Atlas\Server\GlobeSoftware.Atlas40.AtlasServerServiceApp (or the path wherever your Atlas install folder is) CacheClear ServicePath=”C:\Atlas\Server\Name of your Atlas service”

    sc start "Name of your Atlas Service"

    I`m sure you`re aware of it, the ping command is to delay the execution of the cache file deletion with 60 seconds, in order to make sure that the service is completely stopped before deleting the cache. Instead of 60 you can enter any value you think is fit(I think 15-20 seconds will do just fine).

    You are spot that restarting the Atlas server is bad for online user sessions, in the sense that it disconnects the sessions connected to that particular service, which is why it should be done out of working hours. Atlas client does not automatically reconnect. Next time your user will attempt to do something in Excel they will get a "Communication between server and client has failed" error and no data is returned/uploaded.

    Trust all this info will make your life easier. The service restart is environment and, as I said, should be solved by the allowance of the same service account/domain account as the AOS(which will make the business connector not throw any exceptions anymroe).

    Have a good weekend.

    Andrei

    P.S. Our best practice states that you should always install the Atlas server service on the same machine as the AOS whenever possible so that any network bottlenecks/hops are eliminated for best performance.

  • Brandon Wiese Profile Picture
    17,788 on at

    Thanks for the excellent information about the CacheClear.  I was not aware that it could be done or needed to be done.

    What information is cached?  Is it something that should be done automatically anytime code or schema is changed on the AOS?

  • Andrei Stefan Profile Picture
    20 on at

    That`s exactly right, every time a modification is done to the AOT, you need a clear cache in order to import the new structure(new tables. new fields, modifications to classes etc.)

  • Brandon Wiese Profile Picture
    17,788 on at

    Unfortunately we continue to be forced to restart the Atlas server service regularly, often multiple times daily, to solve what can only be described as an unending string of crashes and odd behavior for which there is never really an explanation or a solution.

    I have spoken with friends managing other AX environments with Atlas, and they confirm that this is something you just have to do to make Atlas work in their systems as well and that the ongoing experience is more painful than software really should be.  We have submitted multiple "tickets" to helpdesk, many of which are unresolved and even without response.  

    At this point there is just no way to make it scale at an acceptable level or provide Atlas service to users with any SLA that is acceptable, so we are looking for alternatives.

    If anyone knows how to make Atlas "just work", specifically to run for days and weeks, servicing user requests without breaking itself, I'd love to hear what you did to make that happen.

    If anyone knows of any alternatives, we are very interested in that too.

  • André Boekestijn Profile Picture
    on at

    We experienced the same issue (restarting the Atlas server service) with Atlas XL 4 and Ax2009.

    At that time we where using the License model "Named user".

    After changing back to License model "Concurrent user" we did not experience this problem anymore.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

#1
Martin Dráb Profile Picture

Martin Dráb 4 Most Valuable Professional

#1
Priya_K Profile Picture

Priya_K 4

#3
MyDynamicsNAV Profile Picture

MyDynamicsNAV 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans