In order to change the service account for an AOS, the service account must be updated in the Microsoft Dynamics AX 2012 database, tempdb, and baseline database (if it exists). To perform this, the script Grant-DBPermissionsToAosAccount is provided for Dynamics AX 2012 RTM
Since there are differences in the scripts between Dynamics AX 2012 RTM and R2 and other releases you can use a if you have a copy of the Stored Procedures from a working environment that matches your version. The alternative would be to un-install the AOS service and re-install it using the service account you want to use going forward. Usage The Dynamics AX 2012 RTM script contains four parameters located near the top of the file. Edit these parameters for each database. 1. Stop the AOS service, and any other AOS's in your environment. Drain users, if necessary.
2. Update the service account in the Database.a. Open the script Grant-AosDatabasePermissions.sql in an editor.b. Set @createStoredProcedures to 1.c. Set @loginName to the new service account using the format domain\username.d. Set @aosServerName to the name of the server the AOS is running on.e. Set @aosInstance to the instance number of the AOS.i. To determine an AOS's instance number, open the Services control manager on the AOS server.ii. Find the service corresponding to the AOS.iii. Note the service name. It will be of the form "Microsoft Dynamics AX Object Server 6.0$<XX>-<Name>". The instance number is the XX.f. Set @tempDBName to the name of the tempdb on the database instance.g. Run the script in the context of the Dynamics AX database.
3. Update the service account in the tempdb.a. Set @createStoredProcedures to 0.b. All other parameters should remain the same as in Step 2.c. Run the script in the context of the tempdb database.
4. (Optional) Update the service account in the baseline database.a. Set @createStoredProcedures to 0.b. All other parameters should remain the same as in Step 2.c. Run the script in the context of the baseline database.
5. Grant folder permissions. Starting in the install location of the AOS, which should look something like %PROGRAMFILES%\Microsoft Dynamics AX\60\Server\%INSTANCENAME%, grant the following permissionsa. \Log - Read and Writeb. \bin\Application - Read and Write to this folder and all subfolders and files.c. \bin\XppIL - Read and Write. Then, add special permissions to "Delete" and "Delete subfolders and files." This applies to all subfolders and files.
6. Set URL ACLs.a. Open an elevated command window.b. Execute the following commands to remove the old urlacl and grant it to the new account:i. Netsh http delete urlacl url=http://+:<WSDLPORT>/DynamicsAx/Servicesii. Netsh http add urlacl url=http://+:<WSDLPORT>/DynamicsAx/Services user=<DOMAIN\USER>
7. Change the AOS service account using the Services control manager.8. Start your AOS, and any other AOS's that were shut down earlier.
9. Do a refresh on the Dynamics AX 2012 configuration utility for the client configuration and BC configuration. (if you get an error unable to resolve url check step 6 to make sure that accounthas rights to that url) You may run the following command in an elevated command window -
Netsh http show urlacl
And verify the user listed for the Reserved URL http://+:8101/DynamicsAX/Services is your new AOS account.
10. If you have Enterprise portal, restart your SSRS, SSAS and do an iisreset.
Thanks a lot for the detailed procedure. It helped a lot.
We use this great script every day. Is there an updated version for R2? We have found the permissions have changed in the DB and require scripting out some of the stored procedures and changing them.
Hi bes3020, we haven't updated it yet. As far as we know there are only a few things that need to change which may be the added partition column on the userinfo table.
Can you email us with details about which stored procs you're having trouble with?
What email address? Through normal support channels or yours our Larry's email?
To give some more info, we were moving across domains and the error message was "A user session on the server could not be created. Try to start the client again". This was when launching the client.
We tracked this back to the execution of stored procedures CREATESERVERSESSIONS and CREATEUSERSESSIONS
Sorry not to be clear. You can use the email blog author link to blogs.msdn.com/.../contact.aspx, or you can email me at Margo.Crandall@microsoft.com.
Thanks Margo. I actually ran this again without issue with the latest Contoso demo data for R2, so I am not sure if it will be easy to replicate and give you more information of our last issue, since we fixed it. I am not sure why it was necessary, but if we see it again, I will be sure to reach out to you or Larry.
Thanks for the support!
Thanks a lot, it really helped.