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.
sm
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.
sm
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
you would normally use different accounts per environment, to stop any issues, or mistakes happening something like
DOMAIN\SVC.AX2012.AOS.LIVE
DOMAIN\SVC.AX2012.AOS.DEV
DOMAIN\SVC.AX2012.AOS.TEST
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
DOMAIN\SVC.AX2012.AOS.LIVE
DOMAIN\SVC.AX2012.AOS.DEV
DOMAIN\SVC.AX2012.AOS.TEST
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
ASKER
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!
Scott
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!
Scott
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
ASKER
Thanks for your help, Damon. The service accounts are in much better shape now.
ASKER
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!
Scott