I have a service account for our ERP system that is working with a ballooning temp profile. I am looking for advice as to how to prevent this in the future.

Hello Experts!

I have a Windows Server 2008 R2 Enterprise server that is running our ERP system (Microsoft Axapta 2012 R2).  I'm a one-man show, and IT is not supposed to be my primary focus, so I haven't been monitoring the event logs like I wish I were.

We have had some 'flaky' things happening with our ERP system.  I attempted to install an update last evening, and the installation completed successfully, but things began to break down from there.  Subsequent investigation revealed that some of the installed dlls don't seem to have the security that they should have.

Further investigation showed that one of the key services for the ERP system is running with a temporary profile.  It's temp profile is up over 1 GB in size (filled with log files of some kind, maybe... i haven't investigated that yet).  My hunch is that because the main service for the ERP is not functioning properly, the install my have had issues.

I can resolve the profile issue by halting services later tonight, removing the profile via the control panel (and the registry) and restarting things.  In any event, this is how I would 'fix' the issue if it were a standard user profile issue.

My question is... is this how you would go about resolving an issue with a service account?  Do service accounts actually use a windows profile like other accounts?  These accounts were set up long before I got here, so I'm really even unsure that they are configured properly.

For example, the ERP service account in question has the following properties:

Member Of:  AX SSRS Reports, Domain Users, Windows Authorization Access Group
Profile:  Logon script:  SBS_LOGIN_SCRIPT.bat    (I know this shouldn't be here... i'm told we converted from an SBS environment 5 years ago)
Account:  Account options: User cannot change password, password never expires
Security:  Permissions look fairly standard, except that there are four 'Account unknowns' with permissions.  I cannot remove them without disabling inheritance, and I'm a bit nervous about doing that without fully knowing the repercussions.

I'm reluctant to change much for this account, for fear that anything 'non-standard' may have been added over the years to address problems, but never documented.  That being said, I've found enough 'cobbled-together' stuff in this environment that I'm certain the person who was adminning the environment before me didn't fully understand what they were doing in many cases.

Does anyone have some advice on how the service account should actually be set up?

Thanks for your time.

Scott MilnerApplication AdministratorAsked:
Who is Participating?
Damon ReptonConnect With a Mentor Owner\DirectorCommented:
hello SM,

when you say install a patch, do you mean windows or AX??

regards service accounts its hard to say without a lot more information, AX should have different service accounts for different roles, for example,

Application Object Server (AOS) service account
Business Connector proxy account
SQL Server Database Engine account
SQL Server Analysis Services account
SQL Server Reporting Services account
SQL Server Agent account
and permissions to the database

if for some reason the same account has been used for more than one of these roles account settings might be different.

normally for the AOS the service account only needs:

•      Must be a Windows domain user account
•      Must be a dedicated account, used only for the specific service.
•      Must be able to log on as a service
•      Must have password set to not expire
•      Should have User cannot change password set

when you say the system is flaky what do you mean???


Scott MilnerApplication AdministratorAuthor Commented:
Thanks for the response, Damon.

It sounds like you have some knowledge of AX... I was installing a kernel update to update, not a windows server update.

The account in question is the AXAOSSERVICE account.  It's odd to me to see it building a windows profile... i don't recall seeing a service account do that.  That makes me think it is configured incorrectly.  It may be that because the account was configured with a login script, it built the profile... i'm not savvy enough to state that for certain.

The AXAOSSERVICE account shouldn't be used elsewhere... I agree.  I'm not certain that is how it was used here, however.  I'm researching to see if I find it elsewhere in our environments.  At a minimum it appears that it was used in our DEV, TEST, and PROD environments, although I'm not certain that was a bad choice.

When I said that the system was running a bit flaky, I was seeing some very odd 'invalid login attempt' messages, usually as part of an EventID 110 sources from Dynamics Server 01, as some service attempts to log on to a method.  (this is just one example)

I appreciate your input!

Damon ReptonOwner\DirectorCommented:
you would normally use different accounts per environment, to stop any issues, or mistakes happening something like


I have also never seen a service account use a log on script, what is it doing???

is this a single AOS system?? are you able to share event logs? you might want to do this via email for security reasons, my email is damon@ibrl.co.uk
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Scott MilnerApplication AdministratorAuthor Commented:
you don't have any issues doing modelstore moves when the service accounts for each environment are different?  If not, I'll begin working toward that change.

I have no idea why the service account had that login script.  There's no reason for it at all.  My guess is that the person who originally set up the environment made the mistake.

It is a single AOS environment, so I'm limited as to what I can do while production is going on.  I'm going to clean up the service account and remove the profile this evening, then restart the services and see what the event logs show.  If I'm still running into difficulties, I'll contact you via email with the event logs.

I truly appreciate the offer to help, Damon!

Damon ReptonOwner\DirectorCommented:
No you would not have issues with the modelstore, but when moving data DB you need to run an SQL script, which you should anyway to change the ID of the system to force a AUC file recreate, but the scripts can replace business connector details, EP and SSRS urls and server names, if you don't have anything I can send you an example
Scott MilnerApplication AdministratorAuthor Commented:
Thanks for your help, Damon.  The service accounts are in much better shape now.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.